May 30, 2007 at 12:59 HTML Validation - Myth
The time has come and I will reveal the main secret:
Try to come up with a good reason why this statement is fundamentally wrong before reading further.
Let's first imagine ourselves in the place of the microwave of the future. Say, you, as a strict and inexpensive microwave, support display only (!) XHTML. Most likely, it’s unlikely that you will validate each document before rendering, it will take extra processor time, and besides, you would need DTD, the ability to validate against it (just in case, I recall that a valid document is not just well-formed). Rather, it will be cheaper for you to just try to display it. No one argues that an unclosed tag or incorrect nesting (not well-formed case) can seriously confuse the XHTML code parser, but will you really clear the screen if you find an invalid attribute (in the case of not valid XHTML) and show the housewife an error? Not. Because you will not find them. Because you do not need to detect them. You will only search for attributes which you support, which you can display. Even if you loop through all the attributes of an element, I’m sure it makes no sense to process unknowns.
The HTML and XHTML specification from the very beginning included a useful recommendation: if an unknown attribute or element is detected, the browser is advised to ignore it. Imagine, otherwise it would be impossible to ensure forward compatibility and we would only be sitting on HTML 3.2.
Yes, this is not valid XHTML, which automatically means that it is not XHTML at all. But this does not mean that it is not compatible with XHTML and that any XHTML browser cannot output it using the principle of graceful degradation.
Create your own attributes and elements, create JavaScript support for them, don’t use class / rel / for to indicate a sign of a required form field, it makes no sense to use type comments to indicate blocks. This creates problems for the same layout designer. Use required = "required". Use. Extend XHTML within your site only. Ensure compatibility with JavaScript disabled. And no one will tell you anything bad.
There is no point in running up to the perfect browser that only Strict XHTML understands. It has not been created yet just because no one needs it and this is not the end in itself of the W3C (although some people think so for some reason). After all, the basis of any competent specification (which distinguishes it from a “castle in the sand”) is not a desire to tighten, but the provision of flexibility, compatibility on both sides and competent thinking over graceful degradation. And all this has long been implemented within the framework of HTML and XHTML. Just start enjoying these thoughtful principles.
It’s okay if your site is invalid because of 2-3 attributes that you yourself have created.
Try to come up with a good reason why this statement is fundamentally wrong before reading further.
Let's first imagine ourselves in the place of the microwave of the future. Say, you, as a strict and inexpensive microwave, support display only (!) XHTML. Most likely, it’s unlikely that you will validate each document before rendering, it will take extra processor time, and besides, you would need DTD, the ability to validate against it (just in case, I recall that a valid document is not just well-formed). Rather, it will be cheaper for you to just try to display it. No one argues that an unclosed tag or incorrect nesting (not well-formed case) can seriously confuse the XHTML code parser, but will you really clear the screen if you find an invalid attribute (in the case of not valid XHTML) and show the housewife an error? Not. Because you will not find them. Because you do not need to detect them. You will only search for attributes which you support, which you can display. Even if you loop through all the attributes of an element, I’m sure it makes no sense to process unknowns.
The HTML and XHTML specification from the very beginning included a useful recommendation: if an unknown attribute or element is detected, the browser is advised to ignore it. Imagine, otherwise it would be impossible to ensure forward compatibility and we would only be sitting on HTML 3.2.
Yes, this is not valid XHTML, which automatically means that it is not XHTML at all. But this does not mean that it is not compatible with XHTML and that any XHTML browser cannot output it using the principle of graceful degradation.
Create your own attributes and elements, create JavaScript support for them, don’t use class / rel / for to indicate a sign of a required form field, it makes no sense to use type comments to indicate blocks. This creates problems for the same layout designer. Use required = "required". Use
There is no point in running up to the perfect browser that only Strict XHTML understands. It has not been created yet just because no one needs it and this is not the end in itself of the W3C (although some people think so for some reason). After all, the basis of any competent specification (which distinguishes it from a “castle in the sand”) is not a desire to tighten, but the provision of flexibility, compatibility on both sides and competent thinking over graceful degradation. And all this has long been implemented within the framework of HTML and XHTML. Just start enjoying these thoughtful principles.