Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
On Mon, 20 Jul 2009, Boris Zbarsky wrote: Ian Hickson wrote: Actually what's going on is more subtle than that. When you set innerHTML, it's actually triggering the deferred scripts right there, if it has them loaded (e.g. inline scripts or cached scripts). If it doesn't have them loaded yet, it drops them on the floor and doesn't ever run them. I've specced this, except that the spec requires that not-yet-loaded scripts be loaded then run, rather than dropped, before innerHTML continues, so there's no race conditions. Er... wait. So innerHTML has to block on network access? And possibly spin the event loop as it does so? This doesn't seem desirable to me Why do we want this behavior? Jonas describes why what the spec said before was a compatibility problem in his e-mail: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020843.html He cites the following bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=28293 https://bugzilla.mozilla.org/show_bug.cgi?id=461555 https://bugzilla.mozilla.org/show_bug.cgi?id=461724 https://bugzilla.mozilla.org/show_bug.cgi?id=469751 https://bugzilla.mozilla.org/show_bug.cgi?id=474392 The change I have checked in makes us more compatible with what IE actually does here, which pages are apparently relying on. We could also make the spec introduce a whole new kind of behaviour, such as the one Jonas described, but that seems just as likely to have compatibility problems as what the spec said before, and also has some weird side-effects, like making it possible for the parser to go through the EOF point more than once, or having odd behaviour around document.close(). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
Ian Hickson wrote: The change I have checked in makes us more compatible with what IE actually does here, which pages are apparently relying on. We could also make the spec introduce a whole new kind of behaviour, such as the one Jonas described, but that seems just as likely to have compatibility problems as what the spec said before, and also has some weird side-effects, like making it possible for the parser to go through the EOF point more than once, or having odd behaviour around document.close(). The thing is, your behavior also introduces issues as far as I can see (e.g. requirements that network loads be performed while a script is running without reentering the script, which means not firing any progress events associated with those network loads, requirements about execution of script with src pointing to javascript URIs, if those are supported to start with, etc, etc). It's not clear to me that what you're proposing is any simpler than what Jonas is proposing. Note that the bugs he cited had to do with various problems he brought up with the spec text, including but not limited to this one. Which, if any, of them actually require this innerHTML behavior? From my reading of the bugs, none of them really do. I'd be very interested in other implementor feedback here, but it seems to me that the current proposal is much more complicated than simply saying that document.write in a deferred script never blows away the document... Is that not sufficiently compatible for some reason? -Boris
Re: [whatwg] Typo in 3.4.1.5 Phrasing Content
On Tue, 7 Jul 2009, Ben Leslie wrote: In section 3.4.1.5 Phrasing Content, the text reads: a (if it contains only phrasing content), abbr (if it is a descendant of a map element), area, audio,... I believe it should read: a (if it contains only phrasing content), abbr, area (if it is a descendant of a map element), audio,... Thanks. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
On Tue, 21 Jul 2009, Boris Zbarsky wrote: The thing is, your behavior also introduces issues as far as I can see (e.g. requirements that network loads be performed while a script is running without reentering the script, which means not firing any progress events associated with those network loads, requirements about execution of script with src pointing to javascript URIs, if those are supported to start with, etc, etc). It's not clear to me that what you're proposing is any simpler than what Jonas is proposing. I agree it's no simpler; I'm saying it's more compatible with IE. I'd be very interested in other implementor feedback here, but it seems to me that the current proposal is much more complicated than simply saying that document.write in a deferred script never blows away the document... Is that not sufficiently compatible for some reason? I don't really understand what your proposal would actually translate to, in precise spec terms. One alternative would be to make the scripts that have src attributes but are deferred be excluded from the innerHTML behaviour, and just have them do the old behaviour (which, in imprecise terms, is blowing away the document, and in more precise terms, is to execute once the parser has passed the EOF point, with the insertion point undefined, such that document.write() implies a document.open()). This might work; I didn't see any of the bugs be regarding script elements with src= attributes. But it's less compatible with IE than I usually try to be (I would have specced this innerHTML behaviour long ago if I'd thought to test for it). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
On Jul 20, 2009, at 7:30 PM, Boris Zbarsky wrote: Ian Hickson wrote: Actually what's going on is more subtle than that. When you set innerHTML, it's actually triggering the deferred scripts right there, if it has them loaded (e.g. inline scripts or cached scripts). If it doesn't have them loaded yet, it drops them on the floor and doesn't ever run them. I've specced this, except that the spec requires that not-yet- loaded scripts be loaded then run, rather than dropped, before innerHTML continues, so there's no race conditions. Er... wait. So innerHTML has to block on network access? And possibly spin the event loop as it does so? This doesn't seem desirable to me Why do we want this behavior? innerHTML blocking on network access seems seriously problematic to me. I don't think blocking the UI is preferable to a race condition, when we are talking about a compatibility quirk for content doing something dubious. Regards, Maciej
Re: [whatwg] Errormessages in forms
Dne Fri, 26 Jun 2009 07:17:17 +0200 Ian Hickson i...@hixie.ch napsal/-a: On Tue, 2 Dec 2008, Oldřich Vetešník wrote: Dne Tue, 02 Dec 2008 11:31:07 +0100 Ian Hickson i...@hixie.ch napsal/-a: Well, in the snippet above, the following seems adequate: label Instructions input name=idfield Type in dd-mm-yyy format/label ...and the custom error message should be set from script, using addCustomValidity(). How is that not accessible? It seems fine to me. The AT can read the whole label when entering the field, and the error message handling is done by the UA. Alright, I agree, I don't have a problem with it. But is it possible to create a detailed documentation for this, including How do I code it right?, with wrong good and examples? In my opinion, if there was a good, clear and understandable (for human regular beings that is) documentantion which developers could refer to, and if it succeeded in getting known widely, it could improve the overall knowledge and accessibility. It reminds of the longdesc attribute - it's useful but nobody really knows how to make it right. I think it would be reasonable to have examples, yes. I've added one for label similar to the above. Do you have any other areas where you would like particular examples? Mm, maybe adding an error message would be fine - just to nail the head :) plabelPost code: input name=pc smallFormat: AB12 3CD/small spanThere seems to be an error, please type the post code in the correct format./span/label/p (for example) Note that Lachy is working on a whole authoring guide for HTML5 which will probably cover things like this in more detail also. Great, can I see it somewhere? Thanks, O.V.
Re: [whatwg] Driveby typo notice
On Tue, Jul 21, 2009 at 6:27 AM, Jeff Waldenjwalden+wha...@mit.edu wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource When the user agent has completely fetched of the entire media resource s/ of// Also, completely and entire do the same thing. ' Remco
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] Audio synthesis
Ian Hickson wrote: On Tue, 7 Jul 2009, Philip Jagenstedt wrote: For all of the simpler use cases you can already generate sounds yourself with a data uri. For example, with is 2 samples of silence: data:audio/wav;base64,UklGRigAAABXQVZFZm10IBABAAEARKwAAIhYAQACABAAZGF0YQQA. I hope we haven't infringed a John Cage copyright here. It might be worthwhile implementing the API you want as a JavaScript library and see if you can actually do useful things with it. If the use cases are compelling and require native browser support to be performant enough, perhaps it could go into a future version of HTML. A JS library attempting to do this would definitely be helpful in determining how much need there is for this. I've just started playing a bit with audio. One thing I noticed with both FF 3.5 and WebKit nightlies is that usage of the loop attribute set to true does not provide seamless looping. ie, there is a significant pause between when the audio clip end is reached and when the clip starts again. The spec makes no statement on the seamless-ness of the looping. From a practical standpoint though, having seamless looping is important if you actually have audio that is designed to loop, and you'd like to just allocate the resource for one loop. Think of the background sound for a game, for instance. It also makes the trick of using a very short sound clip specified in a data: url pretty much worthless, as you'd presumably want to loop such a clip seamlessly. It makes me wonder what the use of having the seamful looping actually is, besides of course annoying people. :-) -- Patrick Mueller
Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
Ian Hickson wrote: It's not clear to me that what you're proposing is any simpler than what Jonas is proposing. I agree it's no simpler; I'm saying it's more compatible with IE. And I'm saying it's incompatible with IE in precisely the way that's unacceptable to me as an implementor, I guess I'm also not sure that the IE compat is important here; we've had no reports of compat issues with not doing what IE does. I don't really understand what your proposal would actually translate to, in precise spec terms. I haven't internalized your parsing algorithm rules, but my intuition given the one compat requirement I know of here (not blowing away documents in cases where IE doesn't blow them away) is that deferred scripts should be treated as if the script tags appeared in the HTML character stream after all the content that is actually there... That is, immediately before the EOF point. One alternative would be to make the scripts that have src attributes but are deferred be excluded from the innerHTML behaviour, and just have them do the old behaviour I could probably live with that, for what it's worth, but I'm still wondering why we need this innerHTML behavior at all. innerHTML doesn't even run scripts it directly inserts; why would it run some other random script? That said, if for compat we need this I can see doing it... But it's less compatible with IE than I usually try to be (I would have specced this innerHTML behaviour long ago if I'd thought to test for it). Again, what you specced is also incompatible with IE, and the precise incompatibility is the issue I (and apparently Maciej) have with it. -Boris
Re: [whatwg] Rel and META values
Ian Hickson wrote on 7/19/2009 5:39 AM: On Wed, 15 Jul 2009, Bil Corry wrote: I'm curious too, since the HTML5 draft itself says[1]: - This specification does not define how new values will get approved. It is expected that the Wiki will have a community that addresses this. - So the verbiage at the bottom regarding how a status becomes Accepted appears to be incorrect. There is no process currently in place to adopt any proposed rel value as Accepted. The community right now is defined as the microformats+w3c communities. I'd like a more dedicated community, but that doesn't just happen on its own -- someone has to step forward and own that process. It's a lot of work, and if we are to have continuity and stability in the process, it would have to be someone willing to commit to this for many years. What do you think of adopting Web Linking's registry and registration process? http://tools.ietf.org/html/draft-nottingham-http-link-header-06#section-6.2 The other issue is Mark Nottingham's Web Linking draft[2]. It section 6.2, it establishes its own Link Relation Type Registry and the process by which additional link relations are added. It would seem to me that it would be prudent to have a single registry and process for both HTML5 and the Web Linking draft. Web Linking isn't really compatible with the HTML5 spec as far as I can tell. For example it doesn't let you create types that depend on the other types present (e.g. as we do with up and alternate), it doesn't let you add other attributes (as we do for icon and sizes=), it doesn't define how the linking fits into the processing models for other technologies (e.g. where style sheets from Link: headers fit in to the cascade), and so on. Mark is aware of these issues, but has declined to make his draft handle them. At the moment, HTML5 doesn't hook rel= into the Web Linking registry. I spoke with Mark, he is willing to work with WHAT WG to ensure compatibility between his draft and HTML5 if you're committed to resolving the differences between them. - Bil
Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
The specification says: For historical reasons, if the URL is a javascript: URL, then the user agent must not, despite the requirements in the definition of the fetching algorithm, actually execute the given script; instead the user agent must act as if it had received an empty HTTP 400 response. [4.3.1] (This is probably needed because the script block type overrides the script type, which is, in this case, text/html.) While we are at it: 1. What is the script source of inline scri...@type='text/xml']? The rules are contradictory: source = text because it is text-based and source = infoset because it is XML-based. (An external script is created with the source text without any preliminary parsing.) Does being XML override being text? 2. Why is the special provision for XML needed at all? Does it require invoking an embedded XML parser before the script is created? Does it allow nested script elements? (That would not be backwards-compatible and it would be fatal for HTML error recovery.) What if the XML is not well-formed? Is the embedded parser allowed to validate the XML? What if validation fails? Are external DTD allowed? --- forbidden? Are XHTML scripts embedded in the XML code allowed to run in this step? (they should not be!) 3. Why is the script source for XML-based scripts allowed to be a node list? Internet Explorer supports only well-formed XML documents, i.e. single trees, otherwise you get a parse error which is not very useful, except for the developer. 4. Is scri...@type='text/xml'] allowed to be externally loaded? (I suppose that it is allowed, if supported by the browser, in spite of the specification requiring data scripts to be inline.) 5. Is the browser allowed to expose the embedded XML document using a custom DOM property like XMLDocument? Creating an XML script means attaching the infoset to the declaring script element in Internet Explorer. I think most of these questions would be void (postponed to the creation phase where the answers are implementation-defined) if the special definition of source for inline XML script blocks was removed. Thx in advance, Chris
Re: [whatwg] Audio synthesis
On Wed, Jul 22, 2009 at 1:36 AM, Patrick Mueller pmue...@muellerware.orgwrote: I've just started playing a bit with audio. One thing I noticed with both FF 3.5 and WebKit nightlies is that usage of the loop attribute set to true does not provide seamless looping. ie, there is a significant pause between when the audio clip end is reached and when the clip starts again. That might be related to the fact that we haven't implemented 'loop' yet. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
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] Create my own DTD and specify in DOCTYPE? Re: Validation
Am I correct in concluding that my best option is to create my own HTML5 DTD, and use a DOCTYPE along the lines of: !DOCTYPE html SYSTEM http://www.chaosreigns.com/DTD/html5.dtd; ? Can the HTML5 spec be modified slightly to say that this sort of thing complies? ( http://dev.w3.org/html5/spec/Overview.html#the-doctype ) It seems like if I do create a DTD, I should not permit copying, in order to increase the number of individually created DTDs to check against each other? I'm also open to the possibility of HTML5 specifying some sort of comment stating the HTML version number. Reasons for the above conclusion: An official HTML5 DTD is not desired because official schemas are buggy and people don't fix them, and having only non-official DTDs will improve quality, according to Ian Hixie, March 2009 - http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2009-March/000192.html Also, there does not appear to be an XML 1.0 conformant way to specify more than !DOCTYPE html (which conforms) without specifying a url for a DTD. http://www.w3.org/TR/REC-xml/#dt-doctype The bit in quotes is a Public Identifier, which is the entire contents of RFC3151: http://www.ietf.org/rfc/rfc3151.txt And the full spec is in ISO 8879:1986 (SGML) which costs US$ 222.525, so I don't know what the Public Text Class (NONE above) could be replaced with, other than ENTITIES. http://www.blooberry.com/indexdot/html/tagpages/d/doctype.htm Another use that occurred to me is the case where someone has thousands of html files, which they want to automatically validate at once, and some of them have been updated to a more recent standard (and they want to make sure they stay compliant with it), but others have not been dealt with yet. On 07/21, Philip Taylor wrote: !DOCTYPE html SYSTEM 6 as the shortest string that provides a Violates XML 1.0 and RFC3151 (Public Identifier). 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 Indeed. Do you have that information? If not, I would still like the option of noting a version type in my documents. Although the possibility of creating a DTD based on what conforms to standards *and* current browsers are capable of is a fun idea. like meta name=check-ua-compatibility content=ie=10;fx=5 seems a Cool. -- For gasoline vapor, the explosive range is from 1.3 to 6.0% vapor to air...useful against soft targets such as...armored vehicles...and bunkers. - http://www.fas.org/man/dod-101/sys/dumb/fae.htm http://www.ChaosReigns.com
Re: [whatwg] Create my own DTD and specify in DOCTYPE? Re: Validation
On Tue, Jul 21, 2009 at 2:21 PM, dar...@chaosreigns.com wrote: Am I correct in concluding that my best option is to create my own HTML5 DTD, and use a DOCTYPE along the lines of: !DOCTYPE html SYSTEM http://www.chaosreigns.com/DTD/html5.dtd; ? Can the HTML5 spec be modified slightly to say that this sort of thing complies? ( http://dev.w3.org/html5/spec/Overview.html#the-doctype ) It seems like if I do create a DTD, I should not permit copying, in order to increase the number of individually created DTDs to check against each other? I'm also open to the possibility of HTML5 specifying some sort of comment stating the HTML version number. Reasons for the above conclusion: An official HTML5 DTD is not desired because official schemas are buggy and people don't fix them, and having only non-official DTDs will improve quality, according to Ian Hixie, March 2009 - http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2009-March/000192.html Also, there does not appear to be an XML 1.0 conformant way to specify more than !DOCTYPE html (which conforms) without specifying a url for a DTD. http://www.w3.org/TR/REC-xml/#dt-doctype The bit in quotes is a Public Identifier, which is the entire contents of RFC3151: http://www.ietf.org/rfc/rfc3151.txt And the full spec is in ISO 8879:1986 (SGML) which costs US$ 222.525, so I don't know what the Public Text Class (NONE above) could be replaced with, other than ENTITIES. http://www.blooberry.com/indexdot/html/tagpages/d/doctype.htm Another use that occurred to me is the case where someone has thousands of html files, which they want to automatically validate at once, and some of them have been updated to a more recent standard (and they want to make sure they stay compliant with it), but others have not been dealt with yet. On 07/21, Philip Taylor wrote: !DOCTYPE html SYSTEM 6 as the shortest string that provides a Violates XML 1.0 and RFC3151 (Public Identifier). 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 Indeed. Do you have that information? If not, I would still like the option of noting a version type in my documents. Although the possibility of creating a DTD based on what conforms to standards *and* current browsers are capable of is a fun idea. like meta name=check-ua-compatibility content=ie=10;fx=5 seems a Cool. HTML5 is not an SGML or XML language. It does not use a DOCTYPE in any way. The !DOCTYPE HTML incantation required at the top of HTML5 pages serves the sole purpose of tricking older browsers into rendering the document as well as possible. No checking is made against a DTD, official or otherwise. Version numbers are explicitly left out of the the HTML5 doctype incantation for several reasons; one such reason is to help prevent people from assuming that the incantation has any significance. ~TJ
Re: [whatwg] Create my own DTD and specify in DOCTYPE? Re: Validation
On 07/21, Tab Atkins Jr. wrote: HTML5 is not an SGML or XML language. It does not use a DOCTYPE in I thought HTML5 conformed to XML? any way. The !DOCTYPE HTML incantation required at the top of HTML5 pages serves the sole purpose of tricking older browsers into rendering the document as well as possible. No checking is made against a DTD, official or otherwise. I understand that, but the spec says an HTML5 document must include !DOCTYPE html. And I would like, for my own purposes, to be able to instead use !DOCTYPE html SYSTEM http://www.chaosreigns.com/DTD/html5.dtd; without violating HTML5. -- The most merciful thing in the world, I think, is the inability of the human mind to correlate all its contents. http://www.ChaosReigns.com
Re: [whatwg] Create my own DTD and specify in DOCTYPE? Re: Validation
On Tue, Jul 21, 2009 at 3:02 PM, dar...@chaosreigns.com wrote: On 07/21, Tab Atkins Jr. wrote: HTML5 is not an SGML or XML language. It does not use a DOCTYPE in I thought HTML5 conformed to XML? Nope. HTML5 offers an XML serialization, but it is not an XML language. any way. The !DOCTYPE HTML incantation required at the top of HTML5 pages serves the sole purpose of tricking older browsers into rendering the document as well as possible. No checking is made against a DTD, official or otherwise. I understand that, but the spec says an HTML5 document must include !DOCTYPE html. And I would like, for my own purposes, to be able to instead use !DOCTYPE html SYSTEM http://www.chaosreigns.com/DTD/html5.dtd; without violating HTML5. And again, that is only there to trick as many old browsers as possible into using their most standards-based rendering mode. If it were possible to do so without that incantation, it would be dropped entirely. If you absolutely need to embed extra information (such as a validation schema that you will use for your own purposes to validate your own documents), there are a multitude of ways to do so. You could use a data-* attribute on the html element. You could use Microdata to encode the information onto the document. You could use a link element to point to the schema. ~TJ
Re: [whatwg] Create my own DTD and specify in DOCTYPE? Re: Validation
On Tue, Jul 21, 2009 at 10:02 PM, dar...@chaosreigns.com wrote: On 07/21, Tab Atkins Jr. wrote: HTML5 is not an SGML or XML language. It does not use a DOCTYPE in I thought HTML5 conformed to XML? any way. The !DOCTYPE HTML incantation required at the top of HTML5 pages serves the sole purpose of tricking older browsers into rendering the document as well as possible. No checking is made against a DTD, official or otherwise. I understand that, but the spec says an HTML5 document must include !DOCTYPE html. And I would like, for my own purposes, to be able to instead use !DOCTYPE html SYSTEM http://www.chaosreigns.com/DTD/html5.dtd; without violating HTML5. First things first: DTDs are a quite limited mechanism to describe what a specific XML or SGML language allows. The decision of HTML5 not having a DTD was influenced by two essential factors: first, and most obvious, is that HTML5 isn't neither XML nor SGML (sure, it provides a XML serialization; but if you are using it you might use XML Schema instead of DTD anyway); and second, less obvious but not less important: many of the requirements, restrictions, and so on defined in HTML5 can't be properly described via DTDs. So, what would be the point on defining a DTD which can't be used to actually validate the document? It is possible to go nuts treating your HTML documents as pure XML (you'd need to ensure that they are well-formed and so on), and use a DTD (or a XML Schema) with it. To spice it up, toss in an XSLT stylesheet with the HTML output mode that just outputs the root of the document, and voilà, you get your pure XML (served as text/xml or application/xml) document treated as pure HTML by all browsers (including IE6 onwards). IMHO, quite overkill. The issue here is that, either DTDs or Schemas have some limitations, so it wouldn't be enough to properly validate the document. This leads to some deeper thought then: If DTD or similar tools doesn't really help to validate the document, what is the problem we are trying to solve with them? IIRC, the original mail stated that the goal was to differentiate between versions (hypothetical HTML7 and HTML9) in order to ensure browser compatibility (with an hypothetical IE10, which would support HTML7 but not HTML9). Well, if your validator needs to distinguish between these two versions, there are already several mechanisms at your reach: you may use custom HTTP headers, or add a data-html-version=7 or data-html-version=9 attribute to your body tag: on both cases, your documents would still comply with (current) HTML requirements and document model, and your validator will have a way to differentiate the, Problem solved. With no changes to HTML5. And without having to write a DTD that can get close but will never be able to work properly. Furthermore, either of these approaches have additional benefits. Let's make a slight change to the original scenario: suppose that IE10 complies with most of HTML7, but fails to render properly one or two new elements; and maybe even supports some features introduced by HTML8 (IMHO, partial support of multiple iterations of the language is more likely to match reality than perfectly implementing one of them but providing zero support for the following ones). Why should you restrain yourself from using those features of HTML8 that are supported on IE10? With the @data-* approach, you don't have to: you may instead put something like this data-html-subset=IE10-compatible in your body and there you go. Your validator should be made aware of what is supported on each subset you are using, and you will be able to squeeze the most from each browser you whish to support, and automate the validation as intended in the original use case. Regards, Eduard Pascual
Re: [whatwg] Create my own DTD and specify in DOCTYPE? Re: Validation
On Tue, Jul 21, 2009 at 4:10 PM, dar...@chaosreigns.com wrote: On 07/21, Eduard Pascual wrote: in your body and there you go. Your validator should be made aware of what is supported on each subset you are using, and you will be able to squeeze the most from each browser you whish to support, and automate the validation as intended in the original use case. Is this sort of data (features supported by browsers) available? Not in any official or complete capacity, but quirksmode.org has some *very* good feature-support tables [1] and Deveria has a nice Can I Use? tool [2] which does something similar. [1]: http://www.quirksmode.org/css/contents.html (this is just css - ppk has others) [2]: http://a.deveria.com/caniuse/ ~TJ
[whatwg] Canvas.toDataURL() browser implementations
Dear WhatWG list, Since the last implementation report for the Canvas element in HTML5 was updated last February, I thought it wise to report that: The Canvas.toDataURL() method was found implemented by the following browsers: Opera 10 beta 2 (including support for image/png and image/jpeg) Google Chrome 3.0 (support for required image/png, no support for optional image/jpeg) Mozilla Firefox 3.5 (including support for image/png and image/jpeg) The Canvas.toDataURL() method isn't implemented by Microsoft Internet Explorer 8. Cheers, A.E.Veltstra OmegaJunior.Net
Re: [whatwg] Clickjacking and CSRF
I'm CCing wikitech-l here for broader input, since I do think Wikipedia would be interested in adopting this but I can't really speak for Wikipedia myself. The history of this discussion can be found in the archives: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021133.html I think both whatwg and wikitech-l are configured to bounce messages by unregistered users. For wikitech-l members who want to comment, the registration link for whatwg is: http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org I'd suggest the discussion be continued on whatwg and people not post replies to wikitech-l, to avoid confusion. On Tue, Jul 21, 2009 at 6:34 PM, Brandon Sternebste...@mozilla.com wrote: I have two competing instincts in response to this proposal. In general, I am opposed to adding a mechanism which effectively disables all the security protections offered by CSP. Why? It would most likely only be enabled temporarily. Even if it is enabled permanently (like all those sites with eternal SPF soft fail . . .), it would be no worse than no CSP at all. Would it be possible for Wikipedia to leverage its community to help convert pages to support CSP? Sure, but we have to have a list of things that are broken first. I think it would be much easier to get such a list if we could get it from the clients themselves. Then we would be enabling a totally harmless feature (reporting only), verifying that no more errors are being generated, and then enabling another feature that's already been verified to not cause a significant number of errors. We could confidently enable reporting as soon as the first Firefox dev builds shipped with CSP support. I would be happy to personally commit that. Then we could enable real protection as soon as the reports got down to an acceptable level. If we had to just hope we had caught everything important and wouldn't break anything, I think deployment would have to be a *lot* more cautious. The only thing we'd know is that we'd break lots of stuff, but we wouldn't know what. I certainly would never commit any code like that without approval from the sysadmins, and I strongly suspect they'd be hesitant to grant it. It's not that the site would go down or anything, but some scripts a lot of people are relying on would probably break; and worse, we'd have lots of little separate complaints from lots of different people going on for a long time as more minor broken scripts get noticed. I might be overestimating the potential risk here -- Wikipedia doesn't really depend on JavaScript for almost anything -- but I'm *quite* sure that it would greatly simplify deployment if we could be sure we wouldn't be breaking anything. It's not my decision, though. Hopefully some higher-ups can comment here. It seems, based on the above, that you'll need to serve users custom CSP policy based on which scripts they have enabled, so it will probably be necessary to distribute the testing of CSP across the community. Is it reasonable to expect the site admins to process all of the CSP violation reports on behalf of all the users? Wouldn't it be more scalable to have community members fixing the CSP violations and in the process have users protected from true XSS attacks? If we could do reports only, then we would probably publish the data live in some form, yes. Then community members could fix it to the extent possible. Community admins could fix the problems on the wikis, and developers could fix the problems in the software. But we need a list of what to fix. The software is hundreds of thousands of lines, and we have an enormous amount of user JavaScript: mysql SELECT SUM(page_len) FROM page WHERE page_namespace=2 AND page_title LIKE '%.js'; +---+ | SUM(page_len) | +---+ | 103877387 | +---+ 1 row in set (6.61 sec) That's almost 100 MB of (presumptive) user JavaScript on the English Wikipedia alone. We can't possibly review all of that thoroughly enough to be reasonably certain in advance that we won't get significant breakage. I am not totally opposed to your proposal, though I would like to exhaust other possibilities before we defang CSP to such an extent. I don't understand why this would be defanging anything. It would be entirely optional. Am I missing something?
Re: [whatwg] Audio synthesis
Robert O'Callahan wrote: On Wed, Jul 22, 2009 at 1:36 AM, Patrick Mueller pmue...@muellerware.orgwrote: I've just started playing a bit with audio. One thing I noticed with both FF 3.5 and WebKit nightlies is that usage of the loop attribute set to true does not provide seamless looping. ie, there is a significant pause between when the audio clip end is reached and when the clip starts again. That might be related to the fact that we haven't implemented 'loop' yet. Woops, caught me there. It's exciting to have programmatic audio available AT ALL, was forgetting some of the details. But since you mention it, any idea whether the Moz developers plan on implementing seamless looping or not? I'm curious whether anyone cares, and what folks interpretation of looping means. The spec should be made more specific, one way or another (must/should/may implement seamless looping). Or even provide some other mechanism to allow for seamless looping if the current APIs are insufficient, and it's deemed important. -- Patrick Mueller - http://muellerware.org
