Re: [whatwg] HTML differences from HTML4 document updated
On Fri, 03 May 2013 18:20:51 +0200, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-05-03 18:37, Simon Pieters wrote: The past few days I've been working on updating the HTML differences from HTML4 document, which is a deliverable of the W3C HTML WG but is now also available as a version with the WHATWG style sheet: http://html-differences.whatwg.org/ I think you should start from making the title sensible. HTML differences from HTML4 is too esoteric even in this context. Do you have a suggestion? Besides, the spelling is HTML 4. Especially if you think HTML 4 is ancient history, retain the historical spelling. I don't think this is of particular importance. On Fri, 03 May 2013 20:10:58 +0200, Xaxio Brandish xaxiobrand...@gmail.com wrote: The important thing (IMHO) to remember here regarding the title is that HTML released two subversions of HTML 4, HTML 4.0 [2] and HTML 4.01 [3]. Three, actually. I don't see what's important about that, though. The document must be intended as a differentiation between the entire version of HTML4, since it does not specify a specific subversion to diff? However, it links to the HTML 4.01 specification in the References section. If this is *only* a diff between HTML 4.01 and the living standard, perhaps the title should then be HTML differences from HTML 4.01 so that the document has additional meaning. If there are differences between HTML 4.0, HTML 4.01, *and* HTML5 in the same section of the document, those should probably be appropriately marked. HTML 4.01 is intended. The differences between revisions of HTML4 is out of scope. On Fri, 03 May 2013 20:53:21 +0200, Xaxio Brandish xaxiobrand...@gmail.com wrote: I see what you're saying. The document title on the WHATWG site is titled based on the W3C document [1]. However, I see no reason to keep the same title structure; it will be easy to find either way. The W3C version will have the same title. In that case, Differences between HTML and HTML4 sounds nice as well. That doesn't seem to address Jukka's concern. The only reservation I have is that the from preposition connotates that HTML follows HTML4 (which it does, in a manner of speaking), whereas the between preposition implies a comparison among similar but equal ideas. That suggests from is better. :-) On Fri, 03 May 2013 21:17:34 +0200, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-05-03 21:19, Xaxio Brandish wrote: Ah. The document scope [1] explains why it uses HTML in the title as opposed to HTML5 or HTML(5). No, it only says *that* it uses HTML to refer to the W3C HTML5 specification, W3C HTML5.1 specification, and the WHATWG HTML standard. *Why* it does so is not addressed at all, though the reader might infer that people just couldn't agree on a name, after WHATWG decided to abandon the name HTML5. It's mostly for readability. Noted in the document. HTML has been used through the ages to denote a markup language (and associated definitions) in a broad sense, as opposite to specific versions. This is still the everyday meaning. And a title of a work should be understandable without reading some explanation inside it, saying that some common term has an uncommon meaning. If you can't agree on a proper name, at least call it something like modern HTML. Or, perhaps more realistically, near-future HTML. Modern HTML differences from HTML4? I'm not convinced that's a win. Near-future seems wrong since it's more like current. It's not clear to me why the document is needed in the first place. It would seem to be much more relevant to document in detail the differences between HTML 5, HTML 5.1, and WHATWG Living HTML than to write a rather general document about the differences between them (as if they were a single and stabile specification) and HTML 4. Such a document would be useful, but it's not this document. The primary focus for this document is what is different from HTML4. -- Simon Pieters Opera Software
Re: [whatwg] HTML differences from HTML4 document updated
On Sat, 04 May 2013 00:21:18 +0200, Jens O. Meiert j...@meiert.com wrote: http://html-differences.whatwg.org/ Thanks Simon! Unrelated to the rest of the conversation, could we reconsider whether every version of this document needs to list *all* document-internal changes, in section 6? I’d argue it suffices to list the changes to the last version of the document. This keeps the document length at bay while it’s still possible for people who are actually interested in all changes to go back and check for them. This document doesn't have versions (anymore). Is the length of that section a problem? -- Simon Pieters Opera Software
Re: [whatwg] HTML differences from HTML4 document updated
2013-05-06 15:12, Simon Pieters wrote: I think you should start from making the title sensible. HTML differences from HTML4 is too esoteric even in this context. Do you have a suggestion? I made some suggestions, which you comment later, but I will make another one here. Besides, the spelling is HTML 4. Especially if you think HTML 4 is ancient history, retain the historical spelling. I don't think this is of particular importance. If it isn't, why not use the correct spelling? When referring to specifications, it is usually a good idea to use their own spelling, even when it is odd and confusing. HTML 4.01 is intended. The differences between revisions of HTML4 is out of scope. Then the heading should say HTML 4.01. HTML has been used through the ages to denote a markup language (and associated definitions) in a broad sense, as opposite to specific versions. This is still the everyday meaning. And a title of a work should be understandable without reading some explanation inside it, saying that some common term has an uncommon meaning. If you can't agree on a proper name, at least call it something like modern HTML. Or, perhaps more realistically, near-future HTML. Modern HTML differences from HTML4? I'm not convinced that's a win. Near-future seems wrong since it's more like current. The difficulty here directly reflects the vague nature of HTML5: it partly tries to describe HTML as actually implemented and partly specifies features that should (or shall) be implemented. Hence it is both modern and (intended to be) near-future. But the fundamental difficulty is that you are trying to describe a specific version, or set of versions, of HTML without giving it a proper name or version number. Since WHATWG does not use a proper name for its version (the title is just HTML), I think the only way to refer to it properly is to prefix it with WHATWG. This would lead to the title Differences of HTML5 and WHATWG HTML from HTML 4.01 It's not clear to me why the document is needed in the first place. It would seem to be much more relevant to document in detail the differences between HTML 5, HTML 5.1, and WHATWG Living HTML than to write a rather general document about the differences between them (as if they were a single and stabile specification) and HTML 4. Such a document would be useful, but it's not this document. The primary focus for this document is what is different from HTML4. But why? What is the purpose of this document? This is relevant to naming it, and to the content too, of course. Now it is neither a reliable comparison with links the relevant clauses nor an overview - it has too many details, to begin with. Is this for authors who consider moving from HTML 4.01 to HTML 5? Then I think it should primarily specify what HTML 4.01 features are forbidden in HTML 5, then the extensions. Yucca
[whatwg] API to delay the document load event (continued)
I just joined the mailing list, so I apologize for not continuing the existing thread started here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039422.html Disclaimer: I submitted the Mozilla Bugzilla ticket for some kind of capability in this area. Summarizing previous discussion points: 1) Should this be tied to document load or some new event/state? Concerns about messing up scripts that bind to document load. Not using document load as the API target means also adding a mechanism for a script that does want to wait for this new state to detect if that state is in play. For the paired JS API, it implies providing something like a document.appReadyState if the new event is tied to some name like appload. For the html attribute approach, detecting the attribute is probably enough. In my experience as a JS library provider (first with dojo and more recently with requirejs), JS scripts heavily favor binding to DOMContentLoaded over document load to do work. DOMContentLoaded is also what jQuery's ready() uses, which I expect is what most sites that use jQuery use. It would be good to do a survey of existing public source to verify the uses of document load vs. DOMContentLoaded. Anyone know if this has been done before? Just going on my experience (admittedly a limited data set): anything that actually binds to document load really wants to know when all resources loaded (images/iframes) and page is considered complete, which fits with the motivations of this new capability. 2) Use paired JS API (document.delayLoadEvent and document.stopDelayingLoadEvent being one example) vs. setting an html attribute loading and removal the attribute trigger the event. The JS API allows less coordination among multiple scripts. I can see this becoming more important with Web Components. The HTML attribute loading solution would likely push that API into library-specific APIs use cases, which just seems to result in the same outcome, but in ways that make it harder to use scripts from disparate sources -- the scripts would need to buy into library-specific APIs. 3) What about errors? I would expect this to work how errors affect onload notification now. The behavior/consequences seem to be the same for paired JS API vs. attribute approach. If the concern is about an async script erroring out between the paired calls/addition and removal of an attribute, then perhaps any uncaught error ends up triggering the same behavior that occurs now when there is an error during onload determination. Summary I am fine with the paired JS API approach tied to document load, as a web app developer and consumer of the API. I do not have a particular favored design of what that paired API looks like. If there is agreement on focusing on a paired JS API and for it being tied to onload, perhaps the API discussion could begin. document.delayLoadEvent and document.stopDelayingLoadEvent is one suggestion, and I am fine with that. Glenn Maynard also suggested a `new Something` then `somethingInstance.finished()` as the API. That one implies tracking the instance, so something that could get lost particularly if attached to an object and incorrect `this` bindings interfere. But I have no strong opinion on the API matter, and defer to whatever browser vendors would want to implement. James
Re: [whatwg] API to delay the document load event (continued)
Le 06/05/2013 21:35, James Burke a écrit : In my experience as a JS library provider (first with dojo and more recently with requirejs), JS scripts heavily favor binding to DOMContentLoaded over document load to do work. DOMContentLoaded is also what jQuery's ready() uses, which I expect is what most sites that use jQuery use. If the UA load event is delayed, I guess the delayed value is what is registered in performance.timing [1]. Then, how do people keep track of their performance for the actual UA load event? I would recommend separating the app ready mechanism from the UA load event. It would be good to do a survey of existing public source to verify the uses of document load vs. DOMContentLoaded. Anyone know if this has been done before? Just going on my experience (admittedly a limited data set): anything that actually binds to document load really wants to know when all resources loaded (images/iframes) and page is considered complete, which fits with the motivations of this new capability. An app could be considered complete before the UA load event (hidden iframe hasn't finished loading, below-the-fold images haven't fully loaded yet, etc.) Delaying the load event doesn't take that into account. 2) Use paired JS API (document.delayLoadEvent and document.stopDelayingLoadEvent being one example) vs. setting an html attribute loading and removal the attribute trigger the event. The JS API allows less coordination among multiple scripts. I can see this becoming more important with Web Components. The HTML attribute loading solution would likely push that API into library-specific APIs use cases, which just seems to result in the same outcome, but in ways that make it harder to use scripts from disparate sources -- the scripts would need to buy into library-specific APIs. Light versions of Caja [2][3] would allow each independent components to both use standard APIs and coordinate easily. Specifically for Web Component, maybe each component could have a component-wide setting to tell it's ready. That probably even makes a lot of sense. 3) What about errors? I would expect this to work how errors affect onload notification now. The behavior/consequences seem to be the same for paired JS API vs. attribute approach. Agreed. If the concern is about an async script erroring out between the paired calls/addition and removal of an attribute, then perhaps any uncaught error ends up triggering the same behavior that occurs now when there is an error during onload determination. In case a component fails to notice it's ready, having the app readiness event separated from the UA load event would allow outsiders to use the UA load as fallback (which is the current best approximation). Summary I am fine with the paired JS API approach tied to document load, as a web app developer and consumer of the API. I do not have a particular favored design of what that paired API looks like. If there is agreement on focusing on a paired JS API and for it being tied to onload, perhaps the API discussion could begin. I still strongly believe the UA load event should be kept out of this discussion and a new independent thing should be added instead. Thanks, David [1] https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#performancetiming [2] https://groups.google.com/d/msg/google-caja-discuss/tFhYLJ4abL4/1Mq34zXd_z0J [3] https://groups.google.com/d/msg/google-caja-discuss/tFhYLJ4abL4/p0xUcsV99boJ
Re: [whatwg] font security on measureText
On Sat, May 4, 2013 at 1:16 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 3, 2013 at 6:25 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, May 3, 2013 at 2:23 AM, Anne van Kesteren ann...@annevk.nl wrote: 1. That assumes tainted cross-origin as a fetching mode. http://fetch.spec.whatwg.org/#concept-request-mode Whereas you assume it uses CORS. What do you mean by 'you'? The link in Canvas from the WhatWG spec is to the above section What I'm saying is that the section you're referring to is written from the perspective of using tainted cross-origin as mode for font fetching. Which is incorrect per the CSS fonts specification as per that specification fonts will always be CORS-same-origin with the document. OK. So it seems that the canvas spec should NOT say that the font has to be the same origin. It should refer to CSS portion that describes this fetching or be silent. It would not have to say anything. Thanks. I logged https://www.w3.org/Bugs/Public/show_bug.cgi?id=21943
Re: [whatwg] HTML differences from HTML4 document updated
Unrelated to the rest of the conversation, could we reconsider whether every version of this document needs to list *all* document-internal changes, in section 6? This document doesn't have versions (anymore). Is the length of that section a problem? Yes. It’s probably a lesser important part of the document but it appears to take up about half of the space (or blows the document up to double its size, respectively). -- Jens O. Meiert http://meiert.com/en/
