유효성 검사 오류는 사이트 페이지의 코드 오류로, 사이트의 메인 페이지와 내부 페이지의 오류는 서로 다를 수 있습니다. 사이트 페이지의 코드에 오류가 없으면 사이트가 유효한 것으로 간주됩니다. 사이트 개발 중에 오류가 나타날 수 있습니다. 예를 들어 html 태그가 잘못 닫히거나 전혀 닫히지 않은 경우, 사용되지 않는 태그를 사용하는 경우 문서 유형이 설정되지 않은 경우(), 요소의 중첩이 잘못 구성되어 있습니다. 일부 오류는 표시될 수 있으며 사용자는 사이트 페이지를 방문할 때 이를 알 수 있으며 일부 오류는 보기에서 숨겨져 있을 수 있습니다.
우리의 의견으로는 가장 인기 있고 입증된 유효성 검사기는 validator.w3.org 이며 컨소시엄에서 채택한 규칙에 따라 사이트에서 오류를 검사합니다. 월드 와이드 웹표준. 이 유효성 검사기는 오류를 확인하는 3가지 방법이 있습니다. 사이트의 특정 페이지 URL을 입력하고, 사이트 페이지 파일을 업로드하고, 확인해야 하는 사이트 코드 부분을 입력합니다.
확인을 완료하면 오류에 대한 설명, 오류가 있는 줄 번호, 오류가 포함된 줄의 부분과 함께 페이지에 오류 목록이 표시됩니다.
특정 그룹의 오류를 차례로 수정할 수 있는 오류 필터링 기능이 있으며 각 오류에 대해 이 오류의 원인을 찾을 수 있는 w3c 표준에 대한 링크가 제공됩니다.
사이트 페이지에서 오류를 찾는 브라우저용 플러그인도 있습니다.
http://users.skynet.be/mgueury/mozilla/ - Mozilla용 플러그인
https://chrome.google.com/webstore/detail/html-tidy-browser-extensi/ - 크롬용 플러그인
https://addons.opera.com/en/extensions/details/validator/ - Opera용 플러그인
사이트에 오류가 있는지 확인한 후 매우 합리적인 질문이 발생합니다. 즉시 제거해야 합니까? 이것이 SEO 프로모션에 어떤 의미가 있습니까?
사이트 순위를 매길 때 검색 엔진 검색 결과여전히 내부 사이트 최적화, 링크 프로필, 콘텐츠와 같은 다른 측면에 더 많은 관심을 기울입니다. 그러나 유효성 검사도 완전히 무시되어서는 안됩니다.
우선 내용과 관련된 오류에 주의하는 것이 좋습니다. 검색 엔진의 경우 이 요소는 사이트 순위를 매길 때 중요합니다. 사이트의 페이지에 오류가 많은 경우(25개 이상) 코드에서 오류를 제거하는 것이 좋습니다. 많은 수의 오류가 있는 사이트는 로드하는 데 시간이 더 오래 걸리고 색인을 생성하기 더 어려워 검색 엔진 색인에 사이트 페이지의 일부가 없을 수 있습니다.
대용량 리소스의 페이지 코드에 얼마나 많은 오류가 있는지 분석해 보겠습니다.
러시아 철도 JSC:
이미 눈치채셨듯이 사이트에서도 검색 엔진페이지 코드에 오류가 있습니다. 이는 오류 제거가 본질적으로 권고 사항임을 다시 한 번 확인하는 반면, 이 요소를 무시하고 사이트를 "시작"해서는 안 된다는 점을 언급할 가치가 있습니다. 사이트를 포괄적이고 종합적으로 개발하면 결과가 기대에 부응할 것입니다.
그건 그렇고, 실제로 프로모션에 영향을 미치는 오류가 있는지 사이트를 확인하는 것은 SEO 감사의 일부로 이루어집니다. 사이트의 오류를 적절하게 평가할 수 있는지 의심되는 경우 당사에 문의하십시오.
검증은 좋은 웹 디자인의 가장 중요한 측면 중 하나입니다. 그것이 무엇인지, HTML 코드의 유효성을 확인하는 방법을 살펴보겠습니다. 가장 일반적인 CMS(콘텐츠 관리 시스템)인 WordPress를 예로 들어 보겠습니다. 그 후에 우리는 실제로 발생한 오류 목록을 공유하고 가장 중요한 것은 이를 제거하기 위한 자체적이고 입증된 방법을 제공할 것입니다.
사이트의 유효성을 확인해야 하는 이유
간단히 말해서 웹 페이지를 확인하면 W3C(World Wide Web Consortium)에서 개발한 표준을 준수하는지 확인할 수 있습니다. 이는 일반적으로 W3C의 온라인 유효성 검사 서비스를 사용하여 개별 페이지의 유효성을 검사하여 수행됩니다.
문법 규칙처럼 다른 언어들, 프로그래밍에도 규칙이 있습니다. 유효성 검사를 통해 페이지가 이러한 규칙을 준수하는지 확인할 수 있으며 오류 및 경고가 있는 경우 이를 제거하기 위한 권장 사항이 제공됩니다. 그러한 검사의 필요성에 대한 자세한 내용은 아래에서 논의될 것입니다.
사이트의 유효성에 영향을 미치는 요소
브라우저가 웹 페이지를 어떻게 "읽는지" 궁금해 한 적이 있습니까? 그들은 코드를 분석하고 사람들을 위한 시각적 형태로 변환하는 "엔진"을 가지고 있습니다. 불행히도 각 브라우저에는 고유한 코드 처리 메커니즘이 있으며 이로 인해 페이지가 다르게 표시될 수 있습니다.
유효하지 않은 웹 페이지는 브라우저에서 다양한 방식으로 읽을 수 있습니다. 이로 인해 방문자가 브라우저에서 페이지 콘텐츠를 제대로 볼 수조차 없게 됩니다. 유효성 검사는 나중에 거의 모든 주요 차이점을 수정하고 거의 모든 웹 브라우저에서 웹 페이지를 읽을 수 있도록 합니다(대부분의 경우 예외는 인터넷 익스플로러이전 버전). 여기에서 "크로스 브라우저 레이아웃"이라는 용어가 나왔습니다. 모든 인기 있는 브라우저에 똑같이 좋은(호환성) 레이아웃입니다.
이것이 SEO에 어떤 영향을 미칩니까? 검색 엔진 봇이 시맨틱 웹 페이지를 좋아한다는 것을 이해하는 것이 중요합니다. Wikipedia에 따르면 시맨틱 레이아웃은 웹 페이지를 만드는 접근 방식입니다. HTML 언어, 사용량 기준 HTML 태그의미론(목적)에 따라. 또한 구조적 의미론적 웹 페이지를 통해 검색 로봇은 웹 페이지의 개별 요소와 전체 텍스트의 중요성을 보다 정확하게 결정할 수 있습니다. 구글에 따르면, 유효한 코드어떤 식으로든 페이지 순위에 영향을 미치지 않습니다. 그러나 동시에 코드에 오류가 있으면 마이크로데이터 스캔과 모바일 장치에 대한 적응성에 부정적인 영향을 미칠 수 있습니다.
사이트에 대한 확인 도구
사이트 페이지에 유효성 검사 오류가 없어야 할 필요성을 이해하고 이러한 오류를 검색하는 방법을 살펴보겠습니다.
많이있다 무료 서비스 W3C Markup Validation Service , Web Page Analyzer , Browsershots 및 기타와 같은 사이트 유효성 검사용.
인간은 실수를 하는 경향이 있습니다. 사람들이 상호 작용할 때 오류가 발생합니다. 사용자 인터페이스. 때때로 이것은 사용자가 실수하기 때문에 발생합니다. 때때로 응용 프로그램 자체에서 오류가 발생합니다. 원인에 관계없이 오류와 처리는 UX에 큰 영향을 미칩니다. 잘못된 오류 처리는 쓸모없는 오류 메시지와 함께 사용자로부터 부정적인 반응을 일으켜 사용자가 애플리케이션 사용을 거부하게 만들 수 있습니다.
이 기사에서는 앱 디자인을 최적화하여 사용자 정의 오류사용자가 입력한 내용과 상관없이 오류가 발생할 경우 효과적인 오류 메시지를 작성하는 방법. 또한 잘 처리된 실수가 실패를 감탄으로 바꾸는 방법을 살펴보겠습니다. Adobe는 대화형 프로젝트 및 오류 상태를 디자인할 수 있는 새로운 디자인 및 개발 응용 프로그램인 Experience Design(Adobe XD)을 도입했습니다. Adobe XD를 무료로 다운로드하여 사용해 볼 수 있습니다.
오류 조건이란 무엇입니까?
오류 상태는 문제가 발생했을 때 사용자에게 표시되는 화면입니다. 이는 사용자가 원하는 상태와 다른 작업을 수행하는 상황의 예입니다. 예기치 않은 조합으로 오류가 발생할 수 있으므로 이러한 조건에는 다음이 포함될 수 있습니다. 다른 문제: 사용자 작업의 비호환성(예: 잘못된 데이터 입력)에서 응용 프로그램이 서버에 연결할 수 없거나 심지어 사용자의 요청을 처리할 수 없는 경우까지.
오류가 있는 화면
모든 실수는 원인에 관계없이 사용자의 UX 여정에서 걸림돌이 됩니다. 다행히 잘 구성된 오류는 불쾌한 영향을 줄일 수 있습니다.
예방이 치료보다 낫다
애플리케이션을 구축하는 경우 오류를 유발할 수 있는 애플리케이션과의 주요 사용자 상호 작용이 무엇인지 이해해야 합니다. 예를 들어, 일반적으로 첫 번째 시도에서 양식을 올바르게 작성하는 것이 매우 어렵거나 장치가 열악한 경우 데이터를 올바르게 동기화하는 것이 불가능합니다. 네트워크 연결. 이러한 점을 고려하여 오류 가능성을 최소화해야 합니다. 즉, 제한과 유연성을 사용하여 팁을 보여줌으로써 실수의 가능성을 방지하는 것이 좋습니다.
예를 들어 사람들이 호텔을 검색하고 예약할 수 있도록 허용한 경우 사용 가능한 날짜를 과거로 남겨두고 사용자가 해당 날짜를 선택하면 오류가 발생하는 이유는 무엇입니까?
Booking.com의 예에서 볼 수 있듯이 사용자가 오늘 날짜와 미래 날짜만 선택할 수 있는 날짜 선택기를 사용할 수 있습니다. 이렇게 하면 사용자가 유효한 날짜만 선택하도록 권장합니다.
Booking.com 앱의 날짜 선택기. 전체 월이 표시되지만 과거 날짜는 사용할 수 없습니다. 양식 유효성 검사 오류 화면
형태는 소통이다. 다른 통신과 마찬가지로 사용자와 애플리케이션 간의 직렬 통신이어야 합니다. 검증은 이 커뮤니케이션 프로세스에서 중요한 역할을 합니다. 양식 유효성 검사는 복잡성, 오류 및 오해를 통해 사용자를 안내하도록 설계되었습니다. 적절한 검증을 통해 그러한 의사 소통은 명확하고 이해할 수 있습니다. 일반적으로 좋은 양식 유효성 검사는 네 가지 중요한 요소로 구성됩니다.
- 오류(또는 성공적인 완료)에 대해 알릴 적절한 시간
- 확인 메시지의 올바른 위치
- 올바른 메시지 색상
- 메시지 언어 지우기
정확한 시간(문자열 유효성 검사)
형식 오류 유효성 검사는 불가피하며 사용자 입력의 논리적 부분입니다(사용자 입력은 오류가 발생하기 쉬우므로). 물론 오류를 유발할 수 있는 상태는 최소화해야 하지만 오류 유효성 검사는 제거할 수 없습니다. 따라서 가장 중요한 질문은 "사용자의 오류 복구 프로세스를 단순화하는 방법은 무엇입니까?"입니다.
사용자는 특히 마지막에 오류 알림을 받을 때 양식을 작성하는 과정을 좋아하지 않습니다. 특히 긴 양식을 작성한 후 여러 필드에 오류 메시지가 표시되는 것은 답답합니다. 그리고 가장 짜증나는 것은 당신이 저지른 실수와 위치에 대한 명확성이 부족하다는 것입니다.
유효성 검사는 사용자가 데이터를 입력한 직후 제공된 답변의 정확성에 대해 사용자에게 즉시 알려야 합니다. 좋은 유효성 검사의 주요 원칙은 "사용자와 대화하십시오! 무슨 일인지 말해!" 실시간 문자열 유효성 검사는 사용자에게 입력된 데이터의 정확성을 알려줍니다. 이 접근 방식을 통해 사용자는 오류를 빠르게 수정하고 확인 버튼을 누른 후 오류가 표시될 때까지 기다릴 필요가 없습니다.
그러나 대부분의 경우 사용자가 응답 입력을 완료하기 전에 데이터를 확인할 수 없으므로 각 키 입력의 유효성을 검사하지 않아야 합니다. 입력할 때 값의 유효성을 검사하는 양식은 데이터 입력을 시작하자마자 사용자를 짜증나게 합니다.
Google 설문지는 아직 입력을 마치지 않은 경우에도 이메일 오류를 표시합니다. 반면에 데이터 입력 후 유효성을 검사하는 양식은 사용자에게 오류에 대해 충분히 빨리 알리지 않습니다.
유효성 검사 애플 스토어데이터 입력 후 수행됩니다. Mikhail Konzhevich의 기사 "형식의 문자열 유효성 검사 - 경험 만들기! 다양한 검증 전략을 탐색하고 조기 보상, 늦은 처벌과 같은 하이브리드 전략을 제안했습니다.
하이브리드 - 조기 보상, 늦은 처벌 - 접근 올바른 장소
사용자 지향은 또 다른 중요한 도구. 유효성 검사 메시지를 어디에 둘지 궁금하면 다음 조언을 따르십시오. 항상 메시지를 작업의 컨텍스트에 두십시오. 특정 필드의 오류에 대해 사용자에게 알리려면 해당 필드 옆에 표시하십시오. 빠른 유효성 검사는 입력 필드의 오른쪽이나 그 아래에 배치하는 것이 가장 좋습니다.
실시간으로 양식에 오류가 있습니다. 정확한 색상(직관적인 디자인)
색상은 다음 중 하나입니다. 최고의 도구유효성 검사를 만들 때 사용합니다. 직관적인 수준에서 작동하는 방식에서 오류는 빨간색, 경고는 노란색, 성공은 녹색이 특히 강력합니다. 그러나 색상이 사용자에게 잘 인지되는지 확인하십시오. 이것은 좋은 시각 디자인의 중요한 측면입니다.
오류 텍스트는 명확하고 응용 프로그램의 배경과 명확하게 구분되어야 합니다. 명확한 메시지
일반적인 오류 메시지는 사용자에게 이메일이 잘못된 이유를 설명하지 않고 "이메일이 유효하지 않습니다"라고 표시될 수 있습니다. (타이포그래피? 이메일이 다른 사용자로 인해 바쁘나요?) 간단한 지침이나 지침은 상황을 다르게 할 수 있습니다. 예제에서 양식이 사용자에게 이메일이 이미 사용 중임을 알리는 방법을 볼 수 있습니다. 또한 몇 가지 제안 사항(로그인 또는 암호 복구)이 나타납니다.
이제 뭔가 잘못되었음을 보여주기 위해 오류 페이지를 표시할 시간입니다. 예를 들어 연결이 끊어지고 사용자가 사용할 수 있는 유일한 화면에 있는 상황을 상상해 보겠습니다. 이 기회를 사용하여 사람들에게 진행 상황을 알리고 모델을 제공해야 합니다. 빠른 도움- 귀하의 메시지는 사용자에게 뻗은 도움의 손길이 되어야 합니다. 따라서 다음을 표시해서는 안 됩니다.
- 심각한 오류 메시지입니다.애플리케이션 코드의 내부 오류에 대해 이야기하거나 "유형 2 오류가 발생했습니다"와 같은 텍스트를 포함하는 메시지는 비밀스럽고 무섭습니다.
개발자를 위해 개발자가 작성한 오류 메시지입니다. - 막다른 골목 오류.단순히 그러한 메시지가 어떤 정보도 제공하지 않기 때문에 유용한 정보사용자를 위해.
Spotify의 오류 화면에는 "오류가 발생했습니다"라고 표시되며 문제를 해결하기 위한 옵션과 단계가 포함되어 있지 않습니다. - 지정되지 않은 오류 메시지입니다.이러한 화면(아래 예에서)은 사용자에게 이전 화면만큼 많은 정보를 제공합니다. 사용자는 그것이 무엇을 의미하는지 또는 그것에 대해 무엇을 해야 하는지 전혀 모릅니다.
버퍼 앱에는 다음이 포함됩니다. 좋은 메시지오류에 대한 정보를 제공하지만 사용자에게 어떠한 정보도 제공하지 않습니다. 오류로 사용자를 놀라게 하지 마십시오. 또한 사용자를 문제의 기술적 세부 사항으로 안내하지 마십시오. 오류에 대해 간단하고 평범한 언어. 이를 위해서는 전문용어를 사용하지 말고 사용자의 언어로 자신의 생각을 표현하십시오.
게시물을 읽기 쉽고 유용하게 만드십시오. 오류는 정중하고 명확하고 유익해야 하며 다음과 같은 정보를 포함해야 합니다.
- 무엇이 잘못되었고 왜 (아마도).
- 사용자는 오류를 수정하기 위해 무엇을 해야 합니다.
Remote 앱은 사용자가 아무것도 볼 수 없는 이유를 설명하고 솔루션을 제공합니다. 오류 메시지에 유머와 이미지 포함
사람들은 텍스트보다 시각적 정보를 더 잘 인식하기 때문에 오류 메시지는 아이콘과 일러스트레이션을 사용할 수 있는 좋은 기회입니다. 그러나 더 나아가 사용자에게 유용한 이미지를 애플리케이션에 추가할 수 있습니다. 이렇게 하면 앱이 개인화되고 메시지가 부드러워집니다.
Azendoo는 일러스트레이션과 유머를 사용하여 사용자가 문제를 해결하도록 영감을 줍니다. 유머는 수명을 연장합니다. 약간의 유머는 결코 상처를 주지 않으며 실수로 인한 혼란을 완화하는 데 도움이 됩니다. Littlebigdetails에서 재미있는 메시지의 예를 많이 찾을 수 있습니다. 다음은 내가 좋아하는 것 중 일부입니다.
- 베이스캠프: 폼 검증 실패 시 왼쪽 캐릭터가 놀란 표정을 짓는다.
- 새 Gmail 계정을 만들 때 너무 많은 점을 입력하려고 하면 약간 건방진 오류 메시지가 표시됩니다.
그러나 유머가 오류 메시지에 항상 적절하지 않을 수 있으므로 유머에 주의하십시오. 오류의 심각도에 따라 다릅니다. 예를 들어 유머는 "404 오류"(페이지를 찾을 수 없음)와 같은 간단한 유효성 검사 문제에 적합합니다. 그러나 사용자가 "오!"라고 표시된 페이지를 보는 데 일정 시간을 소비하면 - 어울리지 않아 보인다.
완벽한 오류 페이지를 위한 종합 체크리스트
좋은 오류 페이지는 사용자에게 도움이 되며 다음 6가지 기준을 충족해야 합니다.
- 오류 메시지는 오류가 감지된 직후 동적으로 나타납니다. 사용자에게 문제를 알려야 합니다.
- 입력된 데이터에 대해 안전합니다. 애플리케이션은 오류가 발생했을 때 사용자가 입력하거나 업로드한 내용을 중단, 삭제 또는 실행 취소해서는 안 됩니다.
- 동일한 언어로 사용자와 대화하십시오. 메시지는 무엇이 잘못되었고 왜 잘못되었는지에 대한 명확한 이해를 제공해야 합니다. 사용자는 오류를 수정하기 위해 무엇을 해야 합니까?
- 사용자에게 충격을 주거나 혼동을 주지 마십시오. (메시지가 너무 자극적이어서는 안 됩니다.)
- 시스템에 대한 통제력을 잃지 마십시오. (문제가 심각하지 않은 경우 사용자는 애플리케이션의 나머지 부분에 액세스할 수 있어야 합니다.)
- 유머 감각을 사용하여 문제를 완화하십시오.
가장 많이 발생하는 오류에 대한 솔루션
404 오류(페이지를 찾을 수 없음)
404 오류 페이지의 주요 목적은 사용자를 가능한 빨리 찾고 있던 페이지로 리디렉션하는 것입니다. 404 페이지는 사용자가 이동할 수 있는 몇 가지 주요 링크를 제공해야 합니다. 가장 안전한 옵션은 " 홈페이지” 404페이지의 사이트입니다. 또한 사용자가 페이지가 다운되었음을 알리기 위해 "문제 신고"를 넣을 수 있습니다. 그러나 메인 페이지로의 전환이 더 명확하고 시각적으로 눈에 띄는지 확인하십시오.
로그인 문제
로그인 양식 화면은 종종 미니멀해 보이며 사용자 이름 필드와 비밀번호 필드가 포함되어 있습니다. 그러나 미니멀리즘은 단순함과 같지 않습니다. 사용자가 로그인 화면에서 멈추는 데에는 여러 가지 이유가 있습니다. 로그인 페이지의 주요 규칙 - 사용자가 추측하게 하지 마십시오.
오류 메시지를 훌륭하게 처리하는 MailChimp의 예를 사용하여 가장 일반적인 문제에 대한 솔루션을 살펴보겠습니다.
- 사용자가 사이트에서 자신의 이름을 잊어버렸습니다. 유사한 오류를 발견하면 사용자가 수정할 수 있는 링크를 제공해야 합니다. 사용자에게 어디서 받을 수 있는지(예: "메일을 확인하세요. 이메일을 보냈습니다") 또는 사이트에서 이름을 복원할 수 있는 링크를 제공하세요.
사용자는 잘못된 비밀번호를 사용하여 사이트에 많은 시도를 합니다. 이러한 서버 공격을 방지하기 위해 너무 많은 시도가 실패하면 사용자 계정이 차단됩니다. 이것은 일반적인 보안 관행이지만 계정이 차단되기 전에 사용자에게 경고해야 합니다.
신용카드 거부
신용 카드는 여러 가지 이유로 거부될 수 있습니다. 데이터 형식 오류(오타 또는 데이터 누락) 또는 카드가 만료되거나 도난당하여 거부될 수 있습니다. Gabriel Tomescu는 자신의 기사 Anatomy of a Credit Card Shape에서 두 오류에 대해 다음 전략을 제안했습니다.
첫 번째 문제의 경우 표준 문자열 유효성 검사 및 시각적 오류 표시를 따라야 합니다.
그러나 언제 신용 카드거부 지불 시스템어떤 이유에서인지 그것은 일반적으로 납치처럼 보입니다. 사용자로부터 명확한 데이터가 필요합니다. 그 후에도 사용자에게 무슨 일이 일어났는지 알려야 합니다. 오류 메시지는 매우 명확해야 합니다.
연결 문제
인터넷 연결은 모든 곳에서 사용할 수 없으며 오프라인 지원은 모든 사람의 삶에서 중요한 측면이어야 합니다. 현대 응용. 연결이 끊어지면 오프라인 UX에 대해 신중하게 생각해야 합니다. 사용자는 가능한 한 많은 응용 프로그램과 상호 작용할 수 있어야 합니다. 이는 앱이 우수한 오프라인 UX를 위해 콘텐츠를 캐시해야 함을 의미합니다.
태그: , , ,사이트 유효성 검사 오류 분석
끝없이 이어지는 주문 사이에 드디어 여유가 생겨 블로그를 시작하기로 했습니다. 유효성 검사 측면에서 개선해 보겠습니다. 아래 기사에서 사이트 유효성 검사가 무엇인지 알려 드리겠습니다. HTML 코드및 CSS, 왜 필요한지, 특정 예를 사용하여 사이트를 표준으로 가져오는 방법.
사이트 유효성 검사란 무엇입니까?
간단히 말해 표준 준수 여부를 확인하는 것입니다. 모든 브라우저에서 사이트를 올바르게 표시할 수 있습니다. 사이트의 유효성은 프로모션에 큰 영향을 미치지 않지만 확실히 나쁘지는 않습니다.
웹사이트 페이지에 대한 유효성 검사 통과의 구체적인 예
내 사이트의 첫 번째 페이지인 Java 8의 Base64 인코딩 및 디코딩을 살펴보겠습니다. 페이지 주소를 유효성 검사기에 채우고 결과를 살펴보겠습니다.
이 문서를 HTML 4.01 Transitional로 확인하는 동안 오류가 발견되었습니다! 결과: 105개의 오류, 67개의 경고(s) 예, 그림이 보기 흉합니다. 100개 이상의 오류와 67개의 경고 - 검색 엔진은 내 블로그와 사람들이 방문하는 것을 어떻게 색인화합니까? 그러나 화내지 말고 유효성 검사를 통과하고 오류를 수정하는 방법을 배우십시오. 따라서 첫 번째 경고:
구문 분석 모드를 결정할 수 없습니다! 유효성 검사기는 문서를 XML(XHTML, SVG 등과 같은 문서 유형의 경우) 또는 SGML(HTML 4.01 및 이전 버전의 경우)로 처리할 수 있습니다. 이 문서의 경우 사용 가능한 정보가 다음과 같은 이유로 구문 분석 모드를 명확하게 결정하기에 충분하지 않았습니다. MIME 미디어 유형(text/html)을 XML 또는 SGML 문서 유형에 사용할 수 있습니다. 알려진 문서 유형을 감지할 수 없습니다. XML 선언이 없습니다(예:) 문서의 시작 부분에서 찾을 수 있습니다. XML 네임스페이스 없음(예: ) 문서의 루트에서 찾을 수 있습니다. 기본적으로 유효성 검사기는 SGML 모드로 대체됩니다. 경고 DOCTYPE을 찾을 수 없습니다! 기본 HTML 4.01 Transitional Document Type으로 확인 중입니다. 이 문서에서 DOCTYPE 선언을 찾거나 인식할 수 없습니다. 이것은 일반적으로 문서가 맨 위에 문서 유형을 선언하지 않는다는 것을 의미합니다. 또한 DOCTYPE 선언에 철자 오류가 포함되어 있거나 올바른 구문을 사용하지 않고 있음을 의미할 수도 있습니다. 문서는 "HTML 4.01 Transitional"과 매우 유사한 기본 "대체" 문서 유형 정의를 사용하여 검사되었습니다. 이것은 동일합니다. 수정은 간단합니다. 페이지 맨 처음에 다음 태그를 추가합니다.
우리가 한 일을 확인하고 이 태그만으로 105개의 오류와 3개의 경고를 제거했음을 알 수 있습니다! 이제 64개의 경고만 남았습니다. 하나씩 분해를 시작해 보겠습니다.
경고: 스타일 요소의 유형 속성은 필요하지 않으므로 생략해야 합니다. 5행, 1열에서; 5행 23열로 /x-icon">↩'); var formated_str = arr_splits[i].replace(/\surl\(\'(?!data\:)/gi, function regex_function(str) ( return ' url(\'' + dir_path + '/' + str.replace (/url\(\'/gi, '').replace(/^\s+|\s+$/gm, ''); )); splited_css += ""; ) var td_theme_css = jQuery('link#td-theme-css'); if (td_theme_css.length) ( td_theme_css.after(splited_css); ) ) )); ) ))();