문제

저는 지금 사이트를 구축하고 있습니다. 지금까지 모든 것이 규정을 준수하도록 힘들게 노력해 왔고 모든 브라우저에서 거의 동일하게 보입니다.그러나 속성 추가와 같은 작업을 수행하는 일부 타사/무료 자바스크립트를 구현하기 시작했습니다(예:순서=2).이 문제를 해결할 수는 있지만 고통스럽고 모든 것이 유효한지 확인하는 원칙을 잃기 시작했습니다.실제로 이와 같은 문제를 해결하는 데 어떤 의미가 있습니까?Firefox용 HTMLValidator 플러그인을 얻었고 대부분의 주요 사이트(이 사이트, Google 등 포함)를 살펴보면 유효한 XHTML 또는 HTML이 아닙니다.

도움이 되었습니까?

해결책

비표준 속성을 추가하면 모든 브라우저에서 렌더링 문제가 발생하는 사례를 아직 경험하지 못했습니다.

이러한 비표준 속성을 해결하려고 하지 마십시오.유효성 검사기는 의도하지 않은 실수가 있는지 코드를 다시 확인하는 도구로 유용하지만, 우리 모두 알고 있듯이 완전히 유효한 xhtml이라도 브라우저 전체에서 항상 일관되게 렌더링되지는 않습니다.디자인 결정을 내릴 때 효과를 얻기 위해 브라우저별(및 비표준) 해킹을 사용해야 하는 경우가 많습니다.이것이 검증되지 않은 기술 추진 사이트(구글, 야후 등)의 수에서 알 수 있듯이 웹 개발자의 삶입니다.

다른 팁

검증은 귀하가 동의할 것으로 예상되는 표준을 충족하지 못하는 상황을 판단하는 데 유용합니다.검증 표준에 없는 것을 구체적으로 추가하는 도구를 의도적으로 사용하는 경우 이는 분명히 개인 표준 계약을 위반하지 않습니다.

모든 것이 승인을 받아야 한다고 믿는 상사나 고객이 있다면 이 토론은 훨씬 더 어려워집니다. 왜냐하면 여러분이 그들에게 위의 내용을 설명하고 단순히 게으른 것이 아니라는 점을 설득해야 하기 때문입니다.

즉, 단순히 게으른 경우가 아닌지 확인하세요.유효성 검사기는 제3자 속성의 모든 인스턴스를 성가시게 지속적으로 불러올 수 있지만, 이것이 그들이 언급하는 다른 유효성 검사 오류를 무효화하지는 않습니다.작업 내용을 다시 확인하는 수단으로 스캔해 볼 가치가 있는 경우가 많습니다.

표준 준수는 테스트하지 않은 브라우저에서 페이지가 작동할 가능성을 높이는 것입니다.여기에는 스크린 리더, 테스트 대상 브라우저의 다음 업데이트, 테스트 대상이지만 사용자가 예상치 못한 방식으로 구성한 브라우저가 포함됩니다.

유효성 검사는 페이지의 유효성을 검사할 수 있지만 언젠가 일부 브라우저에서 원하는 방식으로 작동하지 않을 정도로 충분히 모호할 수 있으므로 아무 것도 보장하지 않습니다.

그러나 페이지의 유효성이 확인되면 최소한 XHTML 사양에 따라 페이지가 어떻게 작동해야 하는지 알 수 있습니다.유효성이 검증되지 않으면 브라우저 작성자 간의 비공식적 규칙만 남게 됩니다.

한 쪽에서는 허용되고 다른 쪽에서는 허용되지 않는 작업이 있는 경우 잘못된 XHTML을 작성하는 것보다 유효한 HTML 3을 작성하는 것이 더 나을 것입니다.

XHTML을 XML로 활용할 계획이라면 페이지를 유효하고 올바른 형식으로 만드는 것이 좋습니다.그렇지 않으면 아마도 당신이 원하는 평범한 오래된 의미론적 HTML을 원할 것입니다.어느 쪽이든 청중의 요구 사항이 검증자의 요구 사항보다 중요합니다.

XHTML 태그는 대부분의 브라우저에서 XHTML 태그가 없는 경우와 다르게 렌더링된다는 점을 명심하세요.DOCTYPE 속성은 브라우저가 렌더링하는 모드를 결정하고 허용되는 모드와 허용되지 않는 모드를 지정합니다.XHTML 준수에서 벗어난 경우 모든 브라우저에서 다시 테스트하십시오.

개인적으로 저는 가능할 때마다 최신 표준을 고수하지만, 규정 준수 여부에 따라 시간/비용을 비교해야 하며 이는 대부분 개인 취향에 달려 있습니다.

브라우저에 관한 한 XHTML 준수는 다음과 같은 점에서 의미가 없습니다.

  1. 브라우저에는 XHTML 파서가 없습니다.그들은 버전에 구애받지 않고 웹 호환 가능한 HTML 파서를 갖고 있으며 http://www.w3.org/1999/xhtml 네임스페이스.

  2. XML 파서가 있는 일부 브라우저는 application/xhtml+xml로 제공되는 XHTML 마크업을 XML로 처리할 수 있습니다.이는 XML을 가져와서 요소에 기본 HTML 스타일과 동작을 제공합니다. http://www.w3.org/1999/xhtml 네임스페이스.그러나 구문 분석에 관한 한 XHTML과는 아무런 관련이 없습니다.일부 XHTML DTD의 규칙이 아닌 XML 구문 분석 규칙을 따릅니다.

따라서 XHTML 마크업을 사용하면 브라우저에 낯선 것을 제공하고 그것이 의도한 대로 나오는지 확인하게 됩니다.문제는 어떤 마크업으로도 이 작업을 수행할 수 있다는 것입니다.의도한 대로 렌더링되고 올바른 DOM을 생성한다면 꽤 잘하고 있는 것입니다.DOCTYPE 전환을 염두에 두고 브라우저 버그에 의존하지 않는지 확인하면 됩니다(그래서 버그가 없는 브라우저에서는 문제가 발생하지 않습니다).

XHTML 준수가 좋은 점은 마크업이 올바른 형식인지 확인하기 위한 구문 검사(검증을 통해)입니다.이는 구문 분석 버그를 방지하는 데 도움이 됩니다.물론 이는 HTML로도 수행할 수 있으므로 이 경우 XHTML에는 특별한 것이 없습니다.어느 쪽이든 여전히 브라우저에서 테스트해야 하며 브라우저 공급업체가 모든 종류의 쓰레기를 수용할 수 있는 멋진 HTML 파서를 만들기를 바랍니다.

브라우저가 기대하는 바를 따르려고 노력하는 것은 무의미하지 않습니다.HTML5는 이러한 큰 시기에 도움이 됩니다.그리고 HTML5에서는 원하는 대로 사용자 정의 속성을 정의할 수 있습니다.<p data-order="유효한 사용자 정의 속성입니다.">테스트</p>처럼 앞에 data-를 붙이면 됩니다.

유효한 HTML이 되는 것은 일반적으로 귀하와 브라우저 렌더링 엔진 모두에게 도움이 됩니다.브라우저가 처리해야 하는 문제가 적을수록 새로운 기능을 추가하는 데 더 집중할 수 있습니다.더 엄격할수록 이 빌어먹을 독점 태그가 다른 브라우저에서 작동하지 않는 이유를 궁금해하는 데 소요되는 시간이 줄어듭니다.

반면에 XHTML은 IMHO이며 일부 XML 문서 내에 통합하려는 경우를 제외하고는 더 의미가 없습니다.IE는 여전히 이를 인식하지 못하므로 계속 사용하는 것은 꽤 쓸모가 없습니다.

나는 "유효한 코드"를 작성하는 것이 중요하다고 생각합니다. 단순히 규칙을 따라 모범을 보이는 것이기 때문입니다.모든 개발자가 Fx, Safari 및 Opera용 코드를 작성했다면 IE는 버전 8보다 더 빨리 "규칙을 따르기 시작"해야 했다고 생각합니다.

나는 한 가지를 제외한 모든 경우에 청중의 요구와 시간/비용을 비교하여 대부분의 시간에 규정을 준수하는 코드를 작성하려고 합니다.코드가 503을 준수해야 하는 경우, 준수 코드를 작성하는 것이 귀하와 청중의 이익에 가장 좋습니다.코드가 약간이라도 어긋나면 폭발하는 스크린 리더를 많이 본 적이 있습니다.

대부분의 포스터에서 말했듯이, 이는 실제로 청중이 필요로 하는 것이 무엇인지에 관한 것입니다.

어떤 의미에서든 무의미하지는 않지만 이를 깨뜨릴 충분한 이유가 있습니다.CSS 개발의 초기 단계에서는 마크업이 유효한 경우 브라우저 문제를 진단하는 데 매우 유용합니다.그 외에도 뭔가를 하고 싶은데 가장 적절한 방법이 검증을 깨는 것이라고 생각한다면 일반적으로 괜찮습니다.

사용자 정의 속성을 사용하는 대신 'rel' 속성을 사용하는 것입니다. 예를 보려면 다음을 참조하세요. 라이트박스 (그리고 그 친척).

물론, 언제든지 원하는 방식으로 작성하여 최소한 작동하는지 확인할 수 있습니다.물론 우리는 이미 이러한 사고방식을 겪었고 그 결과를 목격했습니다. 인터넷 익스플로러 6.

나는 ~의 열렬한 팬이다 표준 지향 개발에 대한 Mike Davidson의 접근 방식.

코드를 검증할 수 있다고 해서 다른 사람보다 낫다는 의미는 아닙니다.도대체, 그렇다고 해서 반드시 다른 사람보다 더 나은 코드를 작성한다는 의미는 아닙니다.Flash로 뱅킹 애플리케이션 전체를 작성할 수 있는 사람은 당신보다 더 나은 코더입니다.타사 코드를 복잡한 출판 환경에 통합할 수 있는 사람이 당신보다 더 나은 코더입니다.검증을 완벽한 문법을 ​​사용하는 것으로 생각하십시오.그것은 당신의 아이디어를 전달하는 데 도움이 되고 좋은 교육의 표시이지만 당신이 생각하고 나중에 전달하는 아이디어와 개념만큼 중요하지는 않습니다.내가 함께 일해 본 사람 중 가장 카리스마 있고 아마도 가장 똑똑한 사람은 남부 출신이었으며 "ain't"라는 단어를 꽤 자주 사용했습니다.그것이 그를 덜 똑똑하게 만들지는 않았고, 사실 그를 더 기억에 남게 만들었습니다.그래서 내가 말하고자 하는 것은 누군가를 판단하는 데에는 많은 것들이 있다는 것입니다. 검증은 그중 하나이지만 확실히 가장 중요한 것은 아닙니다.

많은 사람들이 이 게시물을 표준에 따라 코딩하면 안 된다는 의미로 오해하고 있습니다.당연히 그렇게 해야 하지만 실제로 생각해 볼 문제는 아닙니다.그만큼 검증군 유효성을 검사하지 않는 코드는 항상 비난하지만 유효성 검사는 유효한 코드보다 훨씬 더 많은 것을 의미합니다.

그러니 원칙을 잃지 마세요. 하지만 그 기준을 따르면 나중에 심각한 문제에 빠질 가능성이 훨씬 적다는 점을 기억하세요.제공하려는 콘텐츠는 콘텐츠가 표시되는 방식보다 훨씬 더 중요합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top