HTML 유효성 검사 : 그만한 가치가 있습니까?


52

유효하지 않은 HTML을 사용하는 것과 비교하여 모든 주요 브라우저에서 작동하는 것과 비교하여 모든 페이지의 유효성을 확인하는 장점과 단점 (있는 경우)은 무엇입니까?

또한 Javascript가 중요하게 실행 된 후 유효한 HTML이 있습니까?


5
이것은 귀하의 질문에 대답하지 않지만 페이지에 doctype을 배치하면 브라우저가 쿼크 모드 대신 표준 모드로 설정됩니다. 무슨 뜻인지 알아 보려면 쿼크 모드를 찾아보십시오.
Evan Plaice

1
@Evan 가자미 - 아니 모든 하지만 DOCTYPE. 일부 DOCTYPES는 실제로 특이점 또는 거의 표준 모드를 ​​트리거합니다. HTML5 사양은이를 자세히 설명합니다.
luiscubal

1
@luiscubal en.wikipedia.org/wiki/Quirks_mode 에서 "... 전체 DOCTYPE이 있으면 브라우저는 표준 모드를 ​​사용하고,없는 경우 브라우저는 쿼크 모드를 사용 하기 때문에 HTML 5의 새로운 기능입니다. ".
Evan Plaice

@Evan Plaice 이전 HTML 버전은 확실하지 않지만 HTML5는 고대 DOCTYPES
luiscubal

1
@Evan Plaice 즉, "DTD HTML 2.0 레벨 1"은 쿼크 모드를 트리거합니다.
luiscubal

답변:


42

확실히 가치가 있다고 생각 하지만 검증의 노예가되어서는 안됩니다. 바보의 게임입니다.

http://www.codinghorror.com/blog/2009/03/html-validation-does-it-matter.html

  1. HTML을 확인하십시오. 유효한 HTML 마크 업이 무엇을 의미하는지 이해하십시오. 툴링을 이해하십시오. 정보가 많을수록 정보가 적을수록 좋습니다. 왜 장님 비행?

  2. HTML이 유효한지 아무도 신경 쓰지 않습니다. 당신을 제외하고. 원한다면 웹 사이트를 운영하거나, 사용자를 즐겁게하거나, 업무를 수행하는 기능을 제공하는 것보다 완벽하게 유효한 HTML을 만드는 것이 더 중요하다고 생각하지 마십시오.


3
나는 이것을 두 번째로해야한다. 잘못된 HTML에서 비난받을 수있는 자바 스크립트 라이브러리와 관련된 많은 문제를 보았습니다. 다수의 중첩 양식과 불법 폐쇄 태그가 주요 범죄자입니다. Jeff처럼 노예는 아니지만 페이지가 유효한 HTML이 아니기 때문에 jQuery가 작동하지 않을 때 불평하지 마십시오 (XHTML, HTML 5 또는 문서 유형으로 선택한 것).
Gareth Farrington

@Jeff Atwood : "HTML이 유효한지 아무도 신경 쓰지 않습니다. 당신을 제외하고"라고 말할 때 더 이상 동의 할 수 없습니다. 슬프지만 사실, 고객은 실제로 신경 쓰지 않습니다.
Marco Demaio

@MarcoDemaio 왜 슬픈가요? 클라이언트 및 최종 사용자로서, 사이트가 유효성 검사 여부보다 모든 브라우저에서 작동하는지 (대부분의 표준은 표준을 준수하지 않는지)에 더 관심이 있습니다. 유효한 HTML은 실제로 중요하지 않습니다. Google, Facebook, Twitter,이 사이트 등에는 유효한 마크 업이없는 관련 사이트가 없습니다. 왜? 유효한 HTML은 페이지를 부풀려 버리고 대역폭 비용을 증가시키기 만합니다.
NullUserException

완벽하게 들여 쓰기 된 마크 업에 대해서도 마찬가지입니다. 이것은 훨씬 더 쓸모가 없으며 100 % 대역폭 낭비이며 실용적인 용도는 없습니다.
NullUserException

@ NullUserException : 검증 된 웹 사이트가 일반적으로 모든 브라우저에서 훨씬 더 나은 것으로 나타났기 때문에 슬프다 고 생각합니다. Alan의 답변에 대한 내 의견을 참조하십시오 : webmasters.stackexchange.com/a/373/1429 저장된 웹 사이트를 확인하면 저에게 많은 시간을 절약 할 수 있습니다. 완벽하게 들여 쓰기 된 마크 업에 대해서는 결코 그 사양에 대해 들어 본 적이 없습니다. 3 칸 들여 쓰기를 원할 수도 있고, 1 칸 들여 쓰기를 원할 수도 있습니다.
Marco Demaio

32

나는 유효한 HTML을 가치있는 목표로 생각하지만 좋은 웹 사이트를 구축하는 것이 전부라고 생각하지는 않는다.

요령은 마크 업이 완벽하게 유효 할 수는 있지만 레이아웃이나 탐색을 위해 테이블을 사용하는 것과 같이 의미가 없을 수도 있습니다. 유효한 코드와 의미 적 코드에는 차이가 있습니다.

또 다른 참고로, 광고 또는 외부 스크립트를 사용하는 경우 자신의 마크 업을 삽입하여 실제로 자신을 엉망으로 만들 수 있습니다.


22

유효성 검사를 통해 많은 마크 업 및 논리 오류를 발견했기 때문에 그만한 가치가 있다고 생각합니다. 그것은 "필요하지만 충분하지 않은"것들 중 하나입니다. 오류, 경고 및 힌트가없는 컴파일 (또는 JSlint를 통해 체크 아웃)하는 코드와 같은 올바른 마크 업은 올바르게 처리하는 첫 번째 단계입니다.


+1은 이것에 전적으로 동의합니다. 페이지를 검증하면 JS 이후에 실행하는 데 걸리는 시간과 신비한 것처럼 보이는 버그, HTML 태그가 닳았거나 닫혀 있지 않기 때문에 발생하는 버그가 크게 줄어 듭니다. 또한 FF addon Html Validator [ addons.mozilla.org/en-US/firefox/addon/html-validator/] 와 같은 도구를 사용하면 모든 페이지를 로컬에서 확인하는 것이 쉽지 않습니다.
Marco Demaio

9

유효한 HTML의 큰 장점은 페이지가 "주요 브라우저"이외의 것들에 더 쉽게 액세스 할 수 있다는 것입니다. 모든 "주요 브라우저"에는 WWW를 채우는 모든 유효하지 않은 정크를 처리하기위한 끝없는 해결 방법이 있습니다. 그러나 유효한 HTML을 고수하면 누군가가 시각 장애인을 위해 브라우저를 사용하거나 오프라인으로 페이지에 액세스하는 등의 경우에 도움이됩니다.


8

100 % 호환 브라우저는 거의없고 규칙을 해석하는 방법에 대한 사양이 100 % 명확하지 않기 때문에 자체 검증은 그다지 중요하지 않습니다.

그러나 유효한 HTML을 사용하면 사이트를 적응하고 개선 할 수있는 더 나은 위치에있게됩니다. 표준이 진행됨에 따라 표준은 일반적으로 마이그레이션되며 새 사이트가 유효하면 최신 정보를 지원하도록 업데이트하는 것이 더 쉬워야합니다.

바닥이 유효하면 게임을 더욱 쉽게 유지하고 최대한 많은 사람들과 최대한 호환 될 수 있습니다.


4

가장 좋은 방법은 어떤 잘못된 HTML이 잘못되었고 어떤 잘못된 HTML이 중요하지 않은지 알아 보는 것입니다.

예를 들어, <div>태그 를 닫는 것을 잊어 버리면 레이아웃이 하나 이상의 브라우저에서 거의 확실하게 작동하기 때문에 매우 나쁩니다 .

그러나 XHTML <br>대신 대신 사용 하는 <br />것은 중요하지 않습니다. 모든 브라우저는 두 가지를 모두 문제없이 줄 바꿈으로 해석합니다. target링크 에서 속성을 사용하는 것은 유효하지 않지만 최악의 시나리오는 브라우저가 새 창에서 링크를 열지 않는 것입니다.


target과도기적 XHTML에서 유효하며, 마조히스트 만 엄격하게 사용합니다. 닫는 슬래시를 생략하면 페이지가 유효하지 않은 XML이되어 화면 스크레이퍼가 혼동 될 수 있습니다. XHTML을 사용하기로 선택한 경우 페이지는 최소한 유효한 XML이어야합니다.
Tgr

1
@Tgr : 우스운, 나는 masochists가 비표준 모드를 ​​선호한다고 생각했다. 과도기 doctype조차도 (거의 표준 모드를 ​​사용하는 등) 문제가 있습니다
DisgruntledGoat

1
Strict가 필수적이라고 주장합니다. 더 이상 사용되지 않는 코드 및 쿼크 모드의 위험을 감수해야하는 이유는 무엇입니까? 선호하는 마크 업 버전에 대해 더 많이 알도록 권장하는 것 외에는 Strict를 사용하는 데 드는 비용이 없습니다.
CJM

3

유효성 검사기를 실행할 때 제공하는 오류를 사례별로 검사해야합니다. 유효성 검사가 중요합니까? 나에게, 네, 매우 중요합니다. 그러나 그것은 요구 사항입니까? 아니.

클래스 대신 동일한 ID를 여러 번 사용하고 블록 레벨 요소를 인라인 레벨 요소에 넣는 것 (보통 이러한 요소는 의미 상이 방식에도 맞지 않음), 이미지의 대체 속성 누락 (손상된 사용자의 접근성 부족) ), 모두 중요합니다. 태그의 알 수없는 속성과 같은 것은 중요 하지 않습니다 . 조금도. Dojo와 같은 Javascript 프레임 워크 또는 끔찍한 Meebo 소셜 미디어 막대는 사용자 정의 속성을 후크로 사용하며 HTML 스펙에서는 이러한 속성이 허용되며 알 수없는 속성은 무시되어야한다고 명시합니다. 유효성 검사기는 무시하지 않지만 오류가 발생합니다. 이러한 오류는 무시해도됩니다.

유효성을 검사 할 때 오류가있는 경우 잘못했다고 가정하지 마십시오. 의미론이 훨씬 더 중요하며, 유효한 HTML이 적절한 의미론을 갖는 자연스러운 결과가 아닌 경우가 많습니다.


동의합니다-웹 페이지의 유효성을 검사하지만 일부 상황에서는 경고가있는 이유를 알고있는 한 경고를 무시하도록 선택할 수 있습니다.
Casebash

3

사이트에서 유효한 HTML을 테스트하는 한 가지 이유는 검색 엔진 스파이더가 페이지의 의미를 완전히 색인화하고 결정할 수있게하기 때문입니다. 잘못된 형식의 HTML (주요 브라우저로 인해 역사적인 이유로 문제를 해결할 수 있음)로 인해 그렇게 할 수없는 경우 검색 엔진 순위가 제한 될 수 있습니다.

주요 검색 엔진은 잘못된 HTML을 처리하는 데 능숙하지만 페이지 품질에 "포인트"를 할당하여 콘텐츠의 가치에 따라 순위를 매기는 능력에 영향을 줄 수 있다는 추측도있었습니다.


2
구글은 유효하지 않은 HTML이 순위에 영향을 미치지 않는다고 범주 적으로 언급했다. 그러나 HTML의 형식이 잘못되어 스파이더가 페이지의 실제 내용을 읽을 수없는 경우를 볼 수 있습니다.이 경우 브라우저에서 렌더링 문제가 발생하기 시작하는 것이 거의 확실합니다.
DisgruntledGoat

@DisgruntledGoat 옳습니다. 여기에 대한 참조가 있습니다. youtube.com/watch?v=FPBACTS-tyg
JasonBirch

@DisgruntledGoat 분명히 ... 구글 자체는 유효하지 않은 HTML로 가득 차 있으며, 그들이 정말로 신경 쓰지 않는다고 말한 것을 기억 합니다.로드 시간이 더 빠르면 유효하지 않은 HTML을 갖는 것이 좋습니다 .
NullUserException

3

나는 그것이 더 이상 중요하지 않다고 생각합니다. 예전에는 검증의 노예 였지만 이제는 거의 확인하지 않았습니다. 아마도 내 사이트가 유효하다는 것을 확인하면서 화상을 입었거나 다른 사람이 없기 때문에 더 이상 신경 쓰지 않았을 것입니다. 방문자의 99.9 %가 자신이 무엇을하고 있는지, 심지어 관심을 갖고 있는지조차 알지 못하도록 보장 할 수 있습니다. 미래의 브라우저 소프트웨어가 그 날이 오면 걱정할 것입니다.


2

유효성 검사는 다음과 같은 캐치하기 어려운 오류를 발견하는 데 도움이되므로 유용합니다.

<input name=foo value=<?php echo htmlspecialchars($_GET['foo']); ?> />

또는 예측할 수없는 브라우저 동작 (예 : aFirefox에서 블록 요소를 배치하는 것이 때때로 추악한 방식으로 중단 될 수 있음)


2

아무도 언급하지 않은 요점은 브라우저가 표시 할 때 비표준 HTML을 이해하려고 시도하는 동안 잘못된 HTML로 인해 렌더링 시간이 느려질 수 있다는 것입니다.


내가 할 수 있다면 이것을 공감할 것이다. 나는 매우 이 어떤 관찰 효과가 의심; 유효한 마크 업으로 페이지를 부풀리고 로드 하는 데 더 많은 시간이 필요합니다 (특히 느린 / 모바일 연결의 경우).
NullUserException

@ NullUserExceptions : BradB가 만든 포인트에 -1이 필요하다고 생각하지 않습니다. 증명하기 어려울 수도 있지만 HTML 엉망으로 분류하고 수정 해야하는 브라우저에는 오류가없는 올바른 형식의 유효한 HTML 페이지보다 약간 더 걸릴 수 있습니다. HTML 유효성 검사 남용으로 인해 과장된 페이지의 좋은 예를 보여주는이 질문에 대한 답변을 제공하십시오. 유효한 HTML 코드가있는 동일한 페이지와 비교할 때 유효한 HTML 페이지가 과도하게 과장 될 수 있다고 생각할 수 없습니다.
Marco Demaio

1

유효한 html이 있다는 단점은 없습니다. 처음에 사양이있는 이유와 작동 방식을 정의하기 위해 사양에 많은 노력을 기울이는 이유가 있습니다.

기본적으로, 당신이 얻는 모든 사양을 충족하는 것입니다. 즉, html (브라우저, 봇)을 읽도록 작성된 프로그램은 문제가 발생하면 사양을 충족하지 않았다고 비난 할 수 없습니다. 이러한 프로그램 중 일부는 추가 포인트를 제공합니다 (봇이 "사양을 충족"한다고보고하는 경우 검색 엔진에서 더 높은 순위). 사양을 충족하면 일부 브라우저가 깨진 HTML을 생각하지 않은 방식으로 렌더링하지 않으면 놀라움에 덜 빠질 것입니다.

따라서 사양을 충족하고 유효한 html을 작성하는 것이 나쁘지 않은 장점이 있습니다.


흠, 사양을 충족하면 어떤 검색 엔진에서 더 높은 순위를 얻습니까?

2
단점은 모든 코드가 사양을 충족시키는 데 소비하는 추가 개발 시간입니다. 이 비용은 일반적으로 최소이지만 단점으로 여전히 해결해야합니다.
chatche

@kinopiko : 존재하는 경우 주요 항목 (Google, Yahoo, Bing, Ask)이 아닙니다. 갖는 완전 엉망 심지어 양념 (인간) 웹 개발자가 당신을 아마 방해가됩니다 읽을 수있는 코드를하지만 일부 "불법"속성을 사용하여 순위에 절대적으로 제로 효과가 있습니다.
DisgruntledGoat

이것이 유효성 검사 용어의 문제입니다. 당신은 유효하거나 유효하지 않습니다. 학위가 없습니다. 깨진 HTML (예 : 닫히지 않은 태그, 잘못 배치되었거나 누락 된 구조 태그 등)은 유효하지 않으며 SEO에 해를 끼치지만 대부분의 사람들은 "유효성"이라고 말할 때 이에 대해 이야기하지 않습니다. 초보자는 유효성 검사기를 사용하여 초보자 실수를하지 않았는지 확인하지만 전문 개발자는 코드가 이미 "유효"하므로 SEO 용어로 말할 필요가 없습니다.
Lèse majesté

1

일부 HTML 유효성 검사 오류로 인해 명확하지 않은 레이아웃 문제 (예 : 잘못 중첩 id되거나 닫히지 않은 태그), JavaScript 버그 (예 : 두 번 이상 사용 ) 및 일부 사용자에 대한 문제 (예 : alt이미지에 의미 있거나 공백 속성이 포함되지 않음)가 발생할 수 있습니다.

모든 페이지의 유효성이 검사되면 오류의 원인을 배제하기 위해 자동으로 확인하는 것이 좋습니다. 아무런 해를 끼치 지 않는다는 것을 알기 때문에 일부 유효성 검사 오류가 발생하면 검사가 더 이상 자동화되지 않습니다. 각 오류를 살펴보고 괜찮습니다. 개인적으로, 나는 컴퓨터가 증가시키는 것보다해야 할 일의 양을 줄일 때 선호합니다.


1

아무도 언급하지 않은 한 가지 점은 미래의 브라우저 개발입니다. 오늘날의 모든 브라우저가 유효하지 않은 마크 업을 비교적 잘 처리하지만 항상 그런 것은 아닙니다.

앞으로의 브라우저 제작자들은 브라우저가 HTML / XHTML 표준에 맞게 작동 할 것이므로 웹 개발자들에게도 인기가 있습니다. 특정 비트의 유효하지 않은 마크 업이 작동한다고해서 향후 브라우저에서 작동한다는 보장은 없습니다.


그것이 사실인지 궁금합니다.

2
예, <font>태그 나 그 ilk에 대한 지원을 중단시키는 브라우저는 없습니다 .
DisgruntledGoat

더 이상 사용되지 않거나 유효하지 않은 마크 업에 대한 지원 이 향후 변경 될 수 있습니다. 대부분의 브라우저에서 (X) HTML의 불완전한 구현을 간과하면 유효한 마크 업을 사용하는 것이 더 안전 할 것입니다. 단순히 수행중인 작업을 아는 것 외에는 유효한 마크 업과 관련된 비용이 없습니다.
CJM

1

유효성은 비 호환성을 피하고 코드를 유지 관리 할 수 ​​있도록 도와줍니다. 브라우저는 마크 업 오류를 복구하지만 때로는 매우 직관적이지 않은 방식으로 복구합니다.


  • DTD 기반 (HTML4, XHTML1 @ W3C) — 가치가 없습니다. DTD는 원시적이며 예를 들어 대부분의 속성의 유효성을 확인할 수 없습니다. 엔터티 및 중첩에 대한 오류를 이해하기가 어렵습니다.

  • HTML5 검사기 . 명확히. HTML5는보다 실용적이고 오류가 없었던 일부 무해한 구성을 허용합니다. OTOH Henri의 유효성 검사기는 실제 문제를 발견하는 데 훨씬 더 철저하고 좋습니다.


브라우저가 DOM에서 생성 된 방식에 상관없이 브라우저에서 작동하므로 JS 생성 코드의 유효성이 중요 할 수 있습니다. 을 사용 document.write()하면 구문이 정확하도록주의를 기울여야합니다 (페이지 소스와 동일한 파서를 통과합니다).



0

Google과 Bing은 CSS 또는 HTML 유효성 검사를 순위 요소로 사용하지 않습니다.

대부분의 웹 사이트에는 수십에서 수백 개의 오류가 있으며 모든 검색 엔진이 관심을 갖는 것은 페이지 렌더링 방식이므로 걱정할 필요가 없습니다. 귀하의 웹 사이트가 모든 주요 브라우저와 Google의 Fetch 에서 올바르게 렌더링되도록하십시오 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.