Re: [whatwg] Validation
!DOCTYPE html6 would be an abomination, unless the root element changes to html6 also :-)
Re: [whatwg] Validation
On Tue, Jul 21, 2009 at 11:22 AM, Kristof Zelechovskigiecr...@stegny.2a.pl wrote: !DOCTYPE html6 would be an abomination, unless the root element changes to html6 also :-) Also it would trigger quirks mode in many existing browsers, and in any conforming HTML5 implementation. You'd have to use something like !DOCTYPE html SYSTEM 6 as the shortest string that provides a version identifier, if you insist on putting it in the doctype. (The HTML5 doctype reflects that in practice there aren't several independent carefully-separated languages - there's just a single vaguely-defined mess called HTML, described in a range of specifications and sometimes not specified at all, implemented incrementally with various extensions and bugs and missing features in various browsers, with people writing pages that mix all the different features together. The version numbering is an artifact of the W3C's process of developing a numbered sequence of specifications, and isn't aligned with how HTML browsers or documents are usually written. If you want to check that your pages are compatible with certain browser releases, the language version number is a very bad approximation - you'd want a tool that understands what features IE10 supports (maybe some (but not all) from HTML4, some (but not all) from HTML5, some proprietary extensions, etc), and it would be misleading to think that a pure HTML-version-N validator is going to be good enough for that. Maybe you want some in-band mechanism for identifying which pages a spider should check with which rules, but then something like meta name=check-ua-compatibility content=ie=10;fx=5 seems a better solution than a language version number in the doctype; if the problem is real, it should be examined independently of these particular solutions.) -- Philip Taylor exc...@gmail.com
Re: [whatwg] Validation
On Tue, Jul 21, 2009 at 1:02 PM, Philip Taylor wrote: (The HTML5 doctype reflects that in practice there aren't several independent carefully-separated languages - there's just a single vaguely-defined mess called HTML, described in a range of specifications and sometimes not specified at all, implemented incrementally with various extensions and bugs and missing features in various browsers, with people writing pages that mix all the different features together. The version numbering is an artifact of the W3C's process of developing a numbered sequence of specifications, and isn't aligned with how HTML browsers or documents are usually written. Agree. To add to that, think about JavaScript and CSS support, and new features introduced by HTML5: - Safari has canvas for some time now, but only Safari 4 has tabindex= turning elements into focusable items (leading JS libraries to hack around this with hidden form elements –as only those are in tab order by default–); Safari also innovates in the CSS field although it isn't yet perfect re. CSS 2 support (no browser is perfect, and Safari has amongst the best CSS support). It does support (some draft version of) WebDatabase and geolocation APIs yet not video. - Firefox/Mozilla is a leading actor in the JS field and supports E4X as well as not-yet-standardized JS features (for each loop, generators and iterators, destructuring assignment, array comprehensions, let, etc.), yet it too has incomplete (though mostly complete) support for CSS 2.1. - Opera is/was the first to support (part of) Web Forms 2.0 (now merged into HTML5) As for CSS, many browsers started to support some CSS 2 and now CSS 3 selectors without having complete support for CSS 1 and CSS 2 properties or even syntax (e.g. the double class selector bug in Internet Explorer) If you want to check that your pages are compatible with certain browser releases, the language version number is a very bad approximation - you'd want a tool that understands what features IE10 supports (maybe some (but not all) from HTML4, some (but not all) from HTML5, some proprietary extensions, etc), and it would be misleading to think that a pure HTML-version-N validator is going to be good enough for that. I'd add that some HTML editors have switched to this kind of selectors too (a while ago, you turned netscape navigator support off and layer started to be flagged as errors, same for blink for Internet Explorer, and same thing for JavaScript: document.all vs. document.layers vs. document.getElementById, elt.attachEvent vs. elt.addEventListener, etc.) For example, Microsoft Expression Web 2 has an IE6 mode in IntelliSense CSS settings: http://expression.microsoft.com/en-us/library/cc294957.aspx -- Thomas Broyer
Re: [whatwg] Validation
The comparison to Don Quixote is skew; HTML (hopefully) improves while spoken languages (just as currencies) deteriorate. Chris -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Eduard Pascual Sent: Monday, July 20, 2009 11:12 PM To: dar...@chaosreigns.com Cc: whatwg Subject: Re: [whatwg] Validation Of course, a lot of legacy content will no longer validate with HTML5 validators; but where is the issue? It will still render. After all, no one would expect Don Quixote or Hamlet to be valid according to modern Spanish and English rules, respectivelly, but people who know either language are still able to read them. This is an inherent part of language evolution; and hence is a needed side-effect for evolving HTML. And we need to evolve HTML, becuase the current standard is over a decade old, and is falling short to the web's needs every now and then. Just my PoV anyway. Regards, Eduard Pascual
[whatwg] Validation
Why is it okay for a document to not specify its HTML version? Do all browsers ignore it? How should a validator handle lack of HTML version info when the next standard is released with no DOCTYPE? Should validators ignore older HTML version numbers which are listed in DOCTYPES? Why aren't MIME type version numbers included in HTTP Accept headers? Looks like it would be a valid HTTP/1.1 accept-extension: Accept: text/html; q=0.9; v=4.01, application/xhtml+xml; q=1; v=1.1, */*; q=0.1 I don't see anything about registering accept-extensions. -- Let's just say that if complete and utter chaos was lightning, then he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'. - The Color of Magic http://www.ChaosReigns.com
Re: [whatwg] Validation
Am Montag, den 20.07.2009, 15:01 -0400 schrieb dar...@chaosreigns.com: Why is it okay for a document to not specify its HTML version? Because HTML 5 is designed with upwards-compatibility in mind. HTML 6 browsers should read HTML 5 documents just fine. Do all browsers ignore it? All modern browsers skip into standards mode on encountering !DOCTYPE html. How should a validator handle lack of HTML version info when the next standard is released with no DOCTYPE? I assume the validator will probably check for a current version of HTML. Most of the older versions of HTML are subsets of current versions. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Validation
On 07/20, Nils Dagsson Moskopp wrote: How should a validator handle lack of HTML version info when the next standard is released with no DOCTYPE? I assume the validator will probably check for a current version of HTML. Most of the older versions of HTML are subsets of current versions. Say I have some pages on my site that are HTML7, because I know that IE 10 has pretty good support for it. And I have some other pages that are in HTML9 which became a Recommendation 4 years ago but which which IE 10 still doesn't support, but I have been very careful to accommodate IE 10 users by various means. And I want to use a spidering validator on my entire site. And I want to make sure that the HTML7 stuff is valid HTML7 so I can mostly not worry about it working with IE 10, but the HTML9 pages obviously wouldn't validate as HTML7. It seems to me that in this case having an HTML version number somewhere in the document would be useful. And that this is a practical example. -- No human thing is of serious importance. - Plato http://www.ChaosReigns.com
Re: [whatwg] Validation
Am Montag, den 20.07.2009, 16:12 -0400 schrieb dar...@chaosreigns.com: Say I have some pages on my site that are HTML7, because I know that IE 10 has pretty good support for it. And I have some other pages that are in HTML9 which became a Recommendation 4 years ago but which which IE 10 still doesn't support, but I have been very careful to accommodate IE 10 users by various means. Uh-okay. What could various means be ? And I want to use a spidering validator on my entire site.And I want to make sure that the HTML7 stuff is valid HTML7 so I can mostly not worry about it working with IE 10, but the HTML9 pages obviously wouldn't validate as HTML7. Why not use a HTML7 and a HTML9 validator in this case ? The HTML 7 validator could check all pages and report those that aren't valid HTML 7. Those pages could then put onto a list that is checked by the HTML 9 validator. It seems to me that in this case having an HTML version number somewhere in the document would be useful. And that this is a practical example. See the above question. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Validation
On 07/20, Nils Dagsson Moskopp wrote: Uh-okay. What could various means be ? Something like: object src=image.svg img src=image.png /object Why not use a HTML7 and a HTML9 validator in this case ? The HTML 7 validator could check all pages and report those that aren't valid HTML 7. Those pages could then put onto a list that is checked by the HTML 9 validator. Because I don't want to have to tell the validator which pages are HTML7 and which pages are HTML9, I want it to figure it out automatically. -- in the grim future of hello kitty there is only war - http://onastick.net/sitz/images/ http://www.ChaosReigns.com
Re: [whatwg] Validation
On Mon, Jul 20, 2009 at 10:27 PM, dar...@chaosreigns.com wrote: On 07/20, Nils Dagsson Moskopp wrote: Uh-okay. What could various means be ? Something like: object src=image.svg img src=image.png /object Why not use a HTML7 and a HTML9 validator in this case ? The HTML 7 validator could check all pages and report those that aren't valid HTML 7. Those pages could then put onto a list that is checked by the HTML 9 validator. Because I don't want to have to tell the validator which pages are HTML7 and which pages are HTML9, I want it to figure it out automatically. You don't have to tell the validator which version is each page. All the previous knowledge included in the setup Nils posted would be some pages are HTML7, and some are HTML9; then you just feed/send/pipe/whatever all pages to the HTML7 validator: since HTML9 would be a superset of 7, everything that passes this validation is valid as both HTML7 and HTML9. Then, based on the result, failed pages would be sent to the HTML9 validator: if they pass, they are HTML9 with features not included in 7; otherwise they are just invalid. Although it may depend from the specifics of the validation software used, automating this sequence would be easy on the general case, and trivial on the best scenario. Browsers are built incrementally. For example, IE10 is very likely to render properly any page that IE9 had rendered properly (plus some that IE9 couldn't handle). And IE9 will handle any page that IE8 handles (plus some that are too much for IE8), just like IE8 handles any page that IE7 (in addition to those that use CSS2 features not supported by IE7), and IE7 renders all the stuff that IE6 renders, and so on... The same is true for any other browser sequence: Firefox3 handles all pages that Firefox2 did; and the later included all those pages that rendered properly in FF1. More on the same with Opera, Safari, Konkeror, and so on (Chrome isn't too relevant here because it's quite young). The only problem could happen if, for example, I (or someone else) built a new browser, only with HTML5 on mind, when trying to open an HTML4 (or earlier) page; but the HTML5 spec already addresses this: to be compliant a browser must treat any valid input in a well-defined way; but it also must treat invalid input in a well-defined way; which is actually defined to make HTML5-compliant browsers render old and invalid content quite like current browsers do. Thus, if after HTML5 some features are deprecated (just like font has been removed from the HTML specs), there will be pages using those features that will not be valid HTML6, but HTML6 will still define exactly what browsers are expected to do with them. It seems that you worry about validation. Actually, there is some reason to worry: many HTML4 Transitional pages (namely, those that use font or other obsolete aberrations) will be reported as invalid when processed by an HTML5 (or later) validator. So you should actually worry about this; but not complain, because it is the best thing a validator can do, warning you that you are using something (like font) that you shouldn't be using. Now, don't try to argue using font (or some other obsolete tag) should be Ok, because it's valid on HTML4: on HTML4 these things are already *deprecated*. Every time you see that word on the HTML4 spec, read it as an apologize from W3C, just like saying we should have never added this to HTML; now we regret it and it shouldn't be used. Of course, a lot of legacy content will no longer validate with HTML5 validators; but where is the issue? It will still render. After all, no one would expect Don Quixote or Hamlet to be valid according to modern Spanish and English rules, respectivelly, but people who know either language are still able to read them. This is an inherent part of language evolution; and hence is a needed side-effect for evolving HTML. And we need to evolve HTML, becuase the current standard is over a decade old, and is falling short to the web's needs every now and then. Just my PoV anyway. Regards, Eduard Pascual
Re: [whatwg] Validation
On 07/20, Eduard Pascual wrote: feed/send/pipe/whatever all pages to the HTML7 validator: since HTML9 would be a superset of 7 You didn't mean that, did you? Oh, HTML9 would specify a superset of what browsers are required to handle gracefully, not actually including everything from 7 in 9. , everything that passes this validation is valid as both HTML7 and HTML9. Then, based on the result, failed pages I think you mis-stated, but it doesn't not detract from the validity of your suggested method. would be sent to the HTML9 validator: if they pass, they are HTML9 This still leaves me to manually verify that all pages that I wanted to validate as 7, did. Now, don't try to argue using font (or some other obsolete tag) should be Ok, because it's valid on HTML4: on HTML4 these things are I would never. -- When in doubt, gas it. It may not solve the problem, But it ends the suspense. - Steve Moonitz, DoD #2319, 1994 http://www.ChaosReigns.com
Re: [whatwg] Validation
W liście Eduard Pascual z dnia poniedziałek 20 lipca 2009: Browsers are built incrementally. For example, IE10 is very likely to render properly any page that IE9 had rendered properly (plus some that IE9 couldn't handle). And IE9 will handle any page that IE8 handles (plus some that are too much for IE8), just like IE8 handles any page that IE7 (in addition to those that use CSS2 features not supported by IE7), and IE7 renders all the stuff that IE6 renders, and so on... That would be nice if it was true. Have you seen the list of pages compatible with IE6 but not IE8 (eg here: http://blogs.zdnet.com/microsoft/?p=2072tag=nl.e539)? -- Paweł Stradomski
Re: [whatwg] Validation
On Mon, Jul 20, 2009 at 8:12 PM, dar...@chaosreigns.com wrote: Say I have some pages on my site that are HTML7, because I know that IE 10 has pretty good support for it. And I have some other pages that are in HTML9 which became a Recommendation 4 years ago but which which IE 10 still doesn't support, but I have been very careful to accommodate IE 10 users by various means. And I want to use a spidering validator on my entire site. And I want to make sure that the HTML7 stuff is valid HTML7 so I can mostly not worry about it working with IE 10, but the HTML9 pages obviously wouldn't validate as HTML7. So have the validator say This is valid HTML7 or This is valid HTML9 or This is valid HTML7, HTML8, and HTML9 or whatever is applicable. It can check all the standards at once. Why does it need to check only one? If there are practical issues, of course, a later version of HTML could always mandate a different doctype, and validators would know that !doctype html means HTML 5, while !doctype html6 means HTML 6, or whatever. But this doesn't seem necessary or useful.
Re: [whatwg] Validation
Am Montag, den 20.07.2009, 23:54 +0200 schrieb Paweł Stradomski: W liście Eduard Pascual z dnia poniedziałek 20 lipca 2009: Browsers are built incrementally. For example, IE10 is very likely to render properly any page that IE9 had rendered properly (plus some that IE9 couldn't handle). And IE9 will handle any page that IE8 handles (plus some that are too much for IE8), just like IE8 handles any page that IE7 (in addition to those that use CSS2 features not supported by IE7), and IE7 renders all the stuff that IE6 renders, and so on... That would be nice if it was true. Have you seen the list of pages compatible with IE6 but not IE8 (eg here: http://blogs.zdnet.com/microsoft/?p=2072tag=nl.e539)? Caveat: This seems to be an IE issue, not an HTML issue. Why ? I checked the top 8 and bottom 4 sites on that list using the W3C validator and not a single one would validate. Quite a few generate hundreds of errors and warnings. Moral of the story ? Relying on quirks of a specific implementation is a bad idea. To turn that into a HTML needs version numbers (to accomodate exactly this behaviour) is more than a stretch. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Validation
On Tue, Jul 21, 2009 at 2:43 AM, Nils Dagsson Moskoppnils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Caveat: This seems to be an IE issue, not an HTML issue. Why ? I checked the top 8 and bottom 4 sites on that list using the W3C validator and not a single one would validate. Quite a few generate hundreds of errors and warnings. The biggest IE6 compatibility problems lie in CSS, not HTML. Authors writing code for IE6 have to willfully violate the CSS standard to get it to display correctly, e.g., because of IE6's completely broken box model. Adhering to standards doesn't help if some browsers you need to support ignore the standards. It's irrelevant to the proposal under discussion in any event. Separate doctypes would do nothing to help here.
