그렇다면 사용자 정의 HTML 속성이 유효한 XHTML이 아니라면 어떻게 될까요?

나는 그것이 어떤 사람들이 그들을 승인하지 않는 이유라는 것을 알고 있지만, 그것이 정말로 중요합니까? JavaScript와 상호 작용하고 서버에서 정보를 저장하고 보낼 때 제공하는 힘이 유효성 검사 문제를 능가한다고 생각합니다. 내가 뭔가를 놓치고 있습니까? "잘못된"HTML의 결과는 무엇입니까? 그리고 사용자 지정 DTD가이를 해결하지 않습니까?

결과는 w3c가 2 년, 5 년, 10 년 후에 제공되고 동일한 이름의 속성을 생성한다는 것입니다. 이제 페이지가 깨졌습니다.

HTML5는 합법적 인 사용자 지정 속성 (예 : data-myattr = "foo")에 대한 데이터 속성 유형을 제공하므로 지금부터 사용을 시작하고 향후 이름 충돌로부터 합리적으로 안전 할 수 있습니다.

마지막으로 사용자 정의 논리가 클래스 속성 뒤에있는 합리적이라는 사실을 간과 할 수 있습니다. 일반적으로 스타일 속성으로 간주되지만 실제로는 요소에 사용자 지정 메타 속성을 설정하는 합법적 인 방법입니다. 불행히도 기본적으로 부울 속성으로 제한되어 있기 때문에 HTML5가 데이터 접두사를 추가합니다.

BTW, "기본적으로 부울"은 원칙적으로 의미합니다. 실제로 클래스 이름에 구분 기호를 사용하여 사용자 지정 값과 특성을 정의하는 것을 막을 수는 없습니다.

class="document docId.56 permissions.RW"

예, "데이터"를 사용하여 합법적으로 맞춤 속성을 추가 할 수 있습니다.

예를 들면 :

<div id="testDiv" data-myData="just testing"></div>

그런 다음 최신 버전의 jquery를 사용하여 다음과 같은 작업을 수행하십시오.

alert($('#testDiv').data('myData'))

또는 데이터 속성을 설정하려면 :

$('#testDiv').data('myData', 'new custom data')

그리고 jQuery는 거의 모든 브라우저에서 작동하므로 문제가 없어야합니다.)

최신 정보

• data-myData는 자바 스크립트 엔진에 관한 한 일부 브라우저에서 data-mydata로 변환 될 수 있습니다. 소문자로 유지하는 것이 가장 좋습니다.

유효성 검사는 그 자체로 끝나는 것이 아니라 실수를 조기에 발견하고 여러 브라우저 유형에서 사용할 때 웹 페이지가 직면 할 수있는 신비한 렌더링 및 동작 문제의 수를 줄이는 데 사용되는 도구입니다.

사용자 지정 속성을 추가해도 지금은 이러한 문제에 영향을주지 않으며 앞으로는 그렇게 할 가능성이 낮지 만 유효성을 검사하지 않기 때문에 페이지 유효성 검사의 출력을 평가하려면 다음을 수행해야합니다. 중요한 유효성 검사 문제와 그렇지 않은 문제 중에서 신중하게 선택하십시오. 페이지를 변경하고 재 검증 할 때마다이 작업을 반복해야합니다. 페이지의 유효성이 완전히 확인되면 멋진 녹색 PASS 메시지가 표시되고 테스트의 다음 단계 또는 수행해야하는 다음 변경으로 이동할 수 있습니다.

나는 사람들이 간단한 사용자 정의 속성을 사용하는 것보다 훨씬 더 나쁘거나 이상한 일을하는 검증에 집착하는 것을 보았습니다.

<base href="http://example.com/" /><!--[if IE]></base><![endif]-->

제 생각에는 사용자 지정 속성은 실제로 중요하지 않습니다. 다른 말처럼, 표준에 향후 추가되는 속성에주의를 기울이는 것이 좋습니다. 하지만 이제 HTML5에 data- * 속성이 있으므로 저장되었습니다.

정말로 중요한 것은 적절하게 중첩 된 태그와 적절하게 인용 된 속성 값이 있다는 것입니다.

사용자 정의 태그 이름 (머리글, 바닥 글 등 HTML5에서 도입 한 이름)도 사용하지만 이러한 이름은 IE에서 문제가 있습니다.

그건 그렇고, 나는 종종 이러한 모든 검증 열광자가 iframe 업로드와 같은 Google의 영리한 트릭 앞에 어떻게 굴복하는지 아이러니하게 발견합니다.

사용자 지정 속성을 사용하는 대신 JSON을 사용하여 HTML 요소를 속성과 연결할 수 있습니다.

var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };

결과에 대해서는 SpliFF의 답변을 참조하십시오 .

클래스 속성에 여러 값을 저장하는 것은 올바른 코드 캡슐화가 아니며 복잡한 해킹 방식 일뿐입니다. 예를 들어 jquery를 사용하는 사용자 지정 광고 회 전자를 사용하십시오. 할 페이지가 훨씬 깨끗합니다.

<div class="left blue imagerotator" AdsImagesDir="images/ads/" startWithImage="0" endWithImage="10" rotatorTimerSeconds="3" />

여기에서 간단한 jquery 코드가 작업을 수행하도록합니다. 이제 모든 개발자 또는 웹 디자이너가 광고 로테이터에서 작업하고 별다른 노력없이 요청을 받으면이 값을 변경할 수 있습니다.

1 년 후 프로젝트로 돌아 오거나 이전 개발자가 분리되어 태평양 어딘가에있는 섬으로 갔던 새로운 프로젝트로 돌아 오는 것은 코드가 다음과 같이 명확하지 않은 암호화 방식으로 작성 될 때 의도를 알아 내려는 지옥이 될 수 있습니다.

<div class="left blue imagerotator dir:images-ads endwith:10 t:3 tf:yes"  />

C # 및 기타 언어로 코드를 작성할 때 모든 사용자 지정 속성을 공백으로 구분 된 문자열로 하나의 속성에 넣는 코드를 작성하지 않고 액세스하거나 쓸 때마다 해당 문자열을 구문 분석해야합니다. 여러분의 코드에서 작업 할 다음 사람에 대해 생각해보십시오.

유효성 검사가있는 것은 오늘은 중요하지 않을 수 있지만 내일 문제가 될지 여부를 알 수 없다는 것입니다 (머피의 법칙에 따라 내일 문제가 될 것입니다).

미래에 대비 한 대안을 선택하는 것이 좋습니다. 존재하지 않는 경우 ( 이 특정 경우에 해당 ) 이동 방법은 미래 증명 대안을 발명하는 것입니다.

사용자 정의 속성을 사용하는 것은 무해 할 수 있지만, 여전히 해를 끼치 지 않을 것이라고 생각하기 때문에 잠재적으로 해로운 솔루션을 선택하는 이유는 무엇입니까? 미래 증명 대안이 너무 비싸거나 다루기 힘들다면 이에 대해 더 논의 할 가치가있을 수 있지만, 확실히 그렇지 않습니다.

그러나 그럼에도 불구하고 오래된 논의; 제 생각에는 html은 프로그래밍 언어가 아닌 마크 업이기 때문에 항상 마크 업 '오류'에 대해 관대하게 해석되어야합니다. 브라우저는 완벽하게 그렇게 할 수 있습니다. 나는 이것이 앞으로도 변할 것이라고 생각하지 않는다. 따라서 유일하게 중요한 실용적인 기준은 대부분의 브라우저에서 HTML이 올바르게 표시되고 몇 년 안에 계속 표시된다는 것입니다. 그 시간이 지나면 html은 아마도 재 설계 될 것입니다.

내 성분을 믹스에 추가하기 위해 자동화 도구를 사용하여 후 처리 할 수있는 / 후 처리 할 수있는 콘텐츠를 만들어야 할 때 유효성 검사도 중요합니다. 콘텐츠가 유효하면 마크 업을 한 형식에서 다른 형식으로 훨씬 쉽게 변환 할 수 있습니다. 예를 들어, 특정 스키마를 사용하여 유효한 XHTML을 XML로 수행하는 것은 사용자가 알고 있고 예측 가능한 형식을 따르는 지 확인할 수있는 데이터를 구문 분석 할 때 훨씬 쉽습니다.

예를 들어 다양한 작업을 위해 XML로 변환 된 다음 데이터 손실이나 예상치 못한 렌더링 결과없이 다시 변환되기 때문에 콘텐츠가 유효한 XHTML이어야합니다.

클라이언트 / 보스 / 등에 따라 다릅니다. 그들은 XHTML을 확인해야합니까?

어떤 사람들은 해결 방법이 많다고 말하며 장면에 따라 훌륭하게 작동 할 수 있습니다. 여기에는 클래스 추가, rel속성 활용, HTML 주석에서 JSON을 추출하기 위해 자체 파서를 작성한 사람 이 포함됩니다 .

HTML5는이를 수행하는 표준 방법을 제공하며 사용자 정의 속성에 "data-"접두어를 붙입니다. 어쨌든 표준 XHTML에서 트랙 아래로 사용될 속성을 사용할 수 있으므로 지금이 작업을 수행하는 것이 좋습니다.

비표준 HTML을 사용하면 브라우저가 "특별한 모드"로 페이지를 렌더링 할 수 있습니다.이 경우 페이지의 다른 부분이 다르게 렌더링 될 수 있고 위치와 같은 다른 것들이 약간 다를 수 있습니다. 그러나 사용자 지정 DTD를 사용하면이 문제를 해결할 수 있습니다.

표준이 아니기 때문에 현재도 미래에도 어떤 일이 일어날 지 전혀 모릅니다. 다른 사람들이 W3C가 앞으로 동일한 이름을 사용하기 시작할 것이라고 말했듯이. 하지만 더 위험한 것은 "브라우저 xxx"개발자가 만났을 때 어떤 일을했는지 ​​모른다는 것입니다.

페이지가 쿼크 모드로 렌더링되거나 페이지가 전혀 렌더링되지 않을 수 있습니다. 일부 모호한 모바일 브라우저에, 어쩌면 브라우저는 아마도 바이러스 킬러 페이지, 등, 등, 등에 질식 것, 메모리 누수가됩니다

나는 종교적으로 표준을 따르는 것이 속물처럼 보일 수 있음을 알고 있습니다. 하지만 한번 따르지 않아 문제가 생기면 그런 생각을 멈추는 경향이 있습니다. 그러나 대부분 너무 늦기 때문에 다른 프레임 워크로 처음부터 애플리케이션을 시작해야합니다.

개발자가 유효성을 검사하기 위해 유효성을 검사한다고 생각하지만 마크 업을 깨끗하게 유지한다는 사실에 대해 말할 것이 있습니다. 그러나 모든 (과장 경고!) 브라우저는 모든 것을 다르게 표시하기 때문에 실제로 표준이 없습니다. 우리는 적어도 방향이있는 것처럼 느끼게 해주기 때문에 표준을 따르려고 노력합니다. 어떤 사람들은 코드 표준을 유지하면 향후 문제와 충돌을 예방할 수 있다고 주장합니다. 내 의견 : 어쨌든 오늘날에는 아무도 표준을 정확하고 완전하게 구현하지 않는다는 나사는 모든 코드가 결국 실패 할 것이라고 가정 할 수도 있습니다. 그것이 작동한다면, 그것이 지저분하거나 W3C 또는 무언가에 집착하기 위해 표준을 무시하려고하지 않는 한 그것을 사용하십시오. 표준이 매우 느리게 구현되고 5 년 만에 웹이 많이 변경되었음을 기억하는 것이 중요하다고 생각합니다. 나는' 잠재적 인 갈등을 해결해야 할 때 누구에게나 수년간 통지 할 것입니다. 오늘날의 표준에 의존 할 수없는 미래에 표준의 호환성을 계획 할 이유가 없습니다.

오, 당신의 코드가 새끼 고양이 10 마리가 죽는다는 것을 확인하지 않으면 거의 잊었습니다. 당신은 고양이 살인자입니까?

마크 업 이 유효 하지 않으면 Jquery .html (markup)이 작동하지 않습니다 .

확인

유효성 검사를 제공하기 위해 사용자 지정 속성이 필요하지 않습니다. 더 나은 접근 방식은 실제 작업 필드를 기반으로 유효성 검사를 추가하는 것입니다.

클래스를 사용하여 의미를 지정하십시오. 다음과 같은 클래스 이름이 있습니다.

• date (날짜)
• zip (우편 번호)
• area (영역)
• ssn (사회 보장 번호)

마크 업 예 :

<input class="date" name="date" value="2011-08-09" />

예제 자바 스크립트 (jQuery 사용) :

$('.date').validate(); // use your custom function/framework etc here.

특정 또는 시나리오에 대한 특수 유효성 검사기가 필요한 경우 새 클래스를 발명하거나 선택자를 사용합니다. )하면됩니다.

두 암호가 일치하는지 확인하는 예 :

<input id="password" />
<input id="password-confirm" />

if($('#password').val() != $('#password-confirm').val())
{
 // do something if the passwords don't match
}

(이 접근 방식은 jQuery 유효성 검사와 mvc .net 프레임 워크 및 아마도 다른 프레임 워크에서 매우 원활하게 작동합니다.)

보너스 : 공백으로 구분 된 여러 클래스를 할당 할 수 있습니다. class = "ssn custom-one custom-two"

"서버에서"정보 보내기

데이터를 다시 전달해야하는 경우 <input type="hidden" /> . 그들은 상자에서 작동합니다.

(숨겨진 입력이있는 민감한 데이터는 거의 아무런 노력없이 사용자가 수정할 수 있으므로 전달하지 마십시오.)