유효하지 않은 HTML을 사용하는 것과 비교하여 모든 주요 브라우저에서 작동하는 것과 비교하여 모든 페이지의 유효성을 확인하는 장점과 단점 (있는 경우)은 무엇입니까?
또한 Javascript가 중요하게 실행 된 후 유효한 HTML이 있습니까?
유효하지 않은 HTML을 사용하는 것과 비교하여 모든 주요 브라우저에서 작동하는 것과 비교하여 모든 페이지의 유효성을 확인하는 장점과 단점 (있는 경우)은 무엇입니까?
또한 Javascript가 중요하게 실행 된 후 유효한 HTML이 있습니까?
답변:
확실히 가치가 있다고 생각 하지만 검증의 노예가되어서는 안됩니다. 바보의 게임입니다.
http://www.codinghorror.com/blog/2009/03/html-validation-does-it-matter.html
HTML을 확인하십시오. 유효한 HTML 마크 업이 무엇을 의미하는지 이해하십시오. 툴링을 이해하십시오. 정보가 많을수록 정보가 적을수록 좋습니다. 왜 장님 비행?
HTML이 유효한지 아무도 신경 쓰지 않습니다. 당신을 제외하고. 원한다면 웹 사이트를 운영하거나, 사용자를 즐겁게하거나, 업무를 수행하는 기능을 제공하는 것보다 완벽하게 유효한 HTML을 만드는 것이 더 중요하다고 생각하지 마십시오.
유효성 검사를 통해 많은 마크 업 및 논리 오류를 발견했기 때문에 그만한 가치가 있다고 생각합니다. 그것은 "필요하지만 충분하지 않은"것들 중 하나입니다. 오류, 경고 및 힌트가없는 컴파일 (또는 JSlint를 통해 체크 아웃)하는 코드와 같은 올바른 마크 업은 올바르게 처리하는 첫 번째 단계입니다.
유효한 HTML의 큰 장점은 페이지가 "주요 브라우저"이외의 것들에 더 쉽게 액세스 할 수 있다는 것입니다. 모든 "주요 브라우저"에는 WWW를 채우는 모든 유효하지 않은 정크를 처리하기위한 끝없는 해결 방법이 있습니다. 그러나 유효한 HTML을 고수하면 누군가가 시각 장애인을 위해 브라우저를 사용하거나 오프라인으로 페이지에 액세스하는 등의 경우에 도움이됩니다.
100 % 호환 브라우저는 거의없고 규칙을 해석하는 방법에 대한 사양이 100 % 명확하지 않기 때문에 자체 검증은 그다지 중요하지 않습니다.
그러나 유효한 HTML을 사용하면 사이트를 적응하고 개선 할 수있는 더 나은 위치에있게됩니다. 표준이 진행됨에 따라 표준은 일반적으로 마이그레이션되며 새 사이트가 유효하면 최신 정보를 지원하도록 업데이트하는 것이 더 쉬워야합니다.
바닥이 유효하면 게임을 더욱 쉽게 유지하고 최대한 많은 사람들과 최대한 호환 될 수 있습니다.
가장 좋은 방법은 어떤 잘못된 HTML이 잘못되었고 어떤 잘못된 HTML이 중요하지 않은지 알아 보는 것입니다.
예를 들어, <div>
태그 를 닫는 것을 잊어 버리면 레이아웃이 하나 이상의 브라우저에서 거의 확실하게 작동하기 때문에 매우 나쁩니다 .
그러나 XHTML <br>
대신 대신 사용 하는 <br />
것은 중요하지 않습니다. 모든 브라우저는 두 가지를 모두 문제없이 줄 바꿈으로 해석합니다. target
링크 에서 속성을 사용하는 것은 유효하지 않지만 최악의 시나리오는 브라우저가 새 창에서 링크를 열지 않는 것입니다.
target
과도기적 XHTML에서 유효하며, 마조히스트 만 엄격하게 사용합니다. 닫는 슬래시를 생략하면 페이지가 유효하지 않은 XML이되어 화면 스크레이퍼가 혼동 될 수 있습니다. XHTML을 사용하기로 선택한 경우 페이지는 최소한 유효한 XML이어야합니다.
유효성 검사기를 실행할 때 제공하는 오류를 사례별로 검사해야합니다. 유효성 검사가 중요합니까? 나에게, 네, 매우 중요합니다. 그러나 그것은 요구 사항입니까? 아니.
클래스 대신 동일한 ID를 여러 번 사용하고 블록 레벨 요소를 인라인 레벨 요소에 넣는 것 (보통 이러한 요소는 의미 상이 방식에도 맞지 않음), 이미지의 대체 속성 누락 (손상된 사용자의 접근성 부족) ), 모두 중요합니다. 태그의 알 수없는 속성과 같은 것은 중요 하지 않습니다 . 조금도. Dojo와 같은 Javascript 프레임 워크 또는 끔찍한 Meebo 소셜 미디어 막대는 사용자 정의 속성을 후크로 사용하며 HTML 스펙에서는 이러한 속성이 허용되며 알 수없는 속성은 무시되어야한다고 명시합니다. 유효성 검사기는 무시하지 않지만 오류가 발생합니다. 이러한 오류는 무시해도됩니다.
유효성을 검사 할 때 오류가있는 경우 잘못했다고 가정하지 마십시오. 의미론이 훨씬 더 중요하며, 유효한 HTML이 적절한 의미론을 갖는 자연스러운 결과가 아닌 경우가 많습니다.
사이트에서 유효한 HTML을 테스트하는 한 가지 이유는 검색 엔진 스파이더가 페이지의 의미를 완전히 색인화하고 결정할 수있게하기 때문입니다. 잘못된 형식의 HTML (주요 브라우저로 인해 역사적인 이유로 문제를 해결할 수 있음)로 인해 그렇게 할 수없는 경우 검색 엔진 순위가 제한 될 수 있습니다.
주요 검색 엔진은 잘못된 HTML을 처리하는 데 능숙하지만 페이지 품질에 "포인트"를 할당하여 콘텐츠의 가치에 따라 순위를 매기는 능력에 영향을 줄 수 있다는 추측도있었습니다.
나는 그것이 더 이상 중요하지 않다고 생각합니다. 예전에는 검증의 노예 였지만 이제는 거의 확인하지 않았습니다. 아마도 내 사이트가 유효하다는 것을 확인하면서 화상을 입었거나 다른 사람이 없기 때문에 더 이상 신경 쓰지 않았을 것입니다. 방문자의 99.9 %가 자신이 무엇을하고 있는지, 심지어 관심을 갖고 있는지조차 알지 못하도록 보장 할 수 있습니다. 미래의 브라우저 소프트웨어가 그 날이 오면 걱정할 것입니다.
아무도 언급하지 않은 요점은 브라우저가 표시 할 때 비표준 HTML을 이해하려고 시도하는 동안 잘못된 HTML로 인해 렌더링 시간이 느려질 수 있다는 것입니다.
유효한 html이 있다는 단점은 없습니다. 처음에 사양이있는 이유와 작동 방식을 정의하기 위해 사양에 많은 노력을 기울이는 이유가 있습니다.
기본적으로, 당신이 얻는 모든 사양을 충족하는 것입니다. 즉, html (브라우저, 봇)을 읽도록 작성된 프로그램은 문제가 발생하면 사양을 충족하지 않았다고 비난 할 수 없습니다. 이러한 프로그램 중 일부는 추가 포인트를 제공합니다 (봇이 "사양을 충족"한다고보고하는 경우 검색 엔진에서 더 높은 순위). 사양을 충족하면 일부 브라우저가 깨진 HTML을 생각하지 않은 방식으로 렌더링하지 않으면 놀라움에 덜 빠질 것입니다.
따라서 사양을 충족하고 유효한 html을 작성하는 것이 나쁘지 않은 장점이 있습니다.
일부 HTML 유효성 검사 오류로 인해 명확하지 않은 레이아웃 문제 (예 : 잘못 중첩 id
되거나 닫히지 않은 태그), JavaScript 버그 (예 : 두 번 이상 사용 ) 및 일부 사용자에 대한 문제 (예 : alt
이미지에 의미 있거나 공백 속성이 포함되지 않음)가 발생할 수 있습니다.
모든 페이지의 유효성이 검사되면 오류의 원인을 배제하기 위해 자동으로 확인하는 것이 좋습니다. 아무런 해를 끼치 지 않는다는 것을 알기 때문에 일부 유효성 검사 오류가 발생하면 검사가 더 이상 자동화되지 않습니다. 각 오류를 살펴보고 괜찮습니다. 개인적으로, 나는 컴퓨터가 증가시키는 것보다해야 할 일의 양을 줄일 때 선호합니다.
아무도 언급하지 않은 한 가지 점은 미래의 브라우저 개발입니다. 오늘날의 모든 브라우저가 유효하지 않은 마크 업을 비교적 잘 처리하지만 항상 그런 것은 아닙니다.
앞으로의 브라우저 제작자들은 브라우저가 HTML / XHTML 표준에 맞게 작동 할 것이므로 웹 개발자들에게도 인기가 있습니다. 특정 비트의 유효하지 않은 마크 업이 작동한다고해서 향후 브라우저에서 작동한다는 보장은 없습니다.
<font>
태그 나 그 ilk에 대한 지원을 중단시키는 브라우저는 없습니다 .
유효성은 비 호환성을 피하고 코드를 유지 관리 할 수 있도록 도와줍니다. 브라우저는 마크 업 오류를 복구하지만 때로는 매우 직관적이지 않은 방식으로 복구합니다.
DTD 기반 (HTML4, XHTML1 @ W3C) — 가치가 없습니다. DTD는 원시적이며 예를 들어 대부분의 속성의 유효성을 확인할 수 없습니다. 엔터티 및 중첩에 대한 오류를 이해하기가 어렵습니다.
HTML5 검사기 — 예 . 명확히. HTML5는보다 실용적이고 오류가 없었던 일부 무해한 구성을 허용합니다. OTOH Henri의 유효성 검사기는 실제 문제를 발견하는 데 훨씬 더 철저하고 좋습니다.
브라우저가 DOM에서 생성 된 방식에 상관없이 브라우저에서 작동하므로 JS 생성 코드의 유효성이 중요 할 수 있습니다. 을 사용 document.write()
하면 구문이 정확하도록주의를 기울여야합니다 (페이지 소스와 동일한 파서를 통과합니다).
HTML이 모든 주요 브라우저에서 작동하더라도 googlebot과 같은 검색 엔진 크롤러에 문제를 일으킬 수 있으므로 여전히 가치가 있습니다. 예를 들어 이것을보십시오 :
http://www.codeproject.com/KB/server-management/Google_Indexing_Problem.aspx
Google과 Bing은 CSS 또는 HTML 유효성 검사를 순위 요소로 사용하지 않습니다.
대부분의 웹 사이트에는 수십에서 수백 개의 오류가 있으며 모든 검색 엔진이 관심을 갖는 것은 페이지 렌더링 방식이므로 걱정할 필요가 없습니다. 귀하의 웹 사이트가 모든 주요 브라우저와 Google의 Fetch 에서 올바르게 렌더링되도록하십시오 .