RE: publish LCWD of Server-sent Events; deadline April 23
I support the LCWD publication. Thanks, Bryan Sullivan -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, April 16, 2012 4:44 AM To: public-webapps Subject: CfC: publish LCWD of Server-sent Events; deadline April 23 The Server-sent Events spec has three open bugs: * 14900 - suggests adding an origin warning check * 15495 - generic comment re Web platform (not really SSE specific) * 16070 - request for additional reference I don't see any of these bug as important enough to block LC so this is a Call for Consensus to publish a new LCWD with these bugs open, using the latest ED as the basis http://dev.w3.org/html5/eventsource/. This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by April 23 at the latest. Positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -Thanks, AB
Custom Tags and Local Semantics
Eric Meyer (cc'd) posted an intriguing article about custom tags and local semantics: http://meyerweb.com/eric/thoughts/2012/04/10/element-customization/ I must say, even though the current direction we take with Web Components does not involve custom tags, I still find the current, is attribute-based solution awkward. This keeps me wondering about the tradeoffs of custom tags and local semantics. In terms of elegance, nothing comes close to specifying an identify of a DOM element than the localName of the corresponding tag in markup. I know there are strong opinions around keeping local semantics out of the tag names. While I respect the owners of these opinions, I also want to build something _good_ with the Web Components effort. Given that pretty much every time I explain how is attribute works results in raised eyebrows and quizzical looks, I feel we need to revisit the notion of using custom tags for custom elements in Web Components. Who would be interested in a discussion around this at the WebApps F2F next week? I would like to keep this discussion isolated from other Web Components-related topics, mostly to limit effects of the giant rabbit hole that is debating language semantics. :DG
Re: Custom Tags and Local Semantics
FWIW: my proposal (already successfully rejected) for custom elements (real custom elements with really arbitrary tag names allowed) in W3 bug tracker from 2011-09-03: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14011 BTW, it seems local semantics (what my proposal is about and what you are probably talking about) and element customization in its current form are completely different things, and the latter has nothing to do with solving the former. 23.04.2012, 22:55, Dimitri Glazkov dglaz...@chromium.org: Eric Meyer (cc'd) posted an intriguing article about custom tags and local semantics: http://meyerweb.com/eric/thoughts/2012/04/10/element-customization/ I must say, even though the current direction we take with Web Components does not involve custom tags, I still find the current, is attribute-based solution awkward. This keeps me wondering about the tradeoffs of custom tags and local semantics. In terms of elegance, nothing comes close to specifying an identify of a DOM element than the localName of the corresponding tag in markup. I know there are strong opinions around keeping local semantics out of the tag names. While I respect the owners of these opinions, I also want to build something _good_ with the Web Components effort. Given that pretty much every time I explain how is attribute works results in raised eyebrows and quizzical looks, I feel we need to revisit the notion of using custom tags for custom elements in Web Components. Who would be interested in a discussion around this at the WebApps F2F next week? I would like to keep this discussion isolated from other Web Components-related topics, mostly to limit effects of the giant rabbit hole that is debating language semantics. :DG
Re: [webcomponents] HTML Parsing and the template element
You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.comwrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of DOM structures inside my document to the client, but have those fragments exist *outside* the DOM constructed for that document for all practical purposes (rendering, traversal, resource loading, selector matching, etc...). This goal of this feature is provide webdevs with a supported mechanism to do this which lacks the pitfalls of the available hacks. Assuming (1) is uncontroversially (a), then the idea to re-serialize the parsed content and append it is a text child to the template element would resolve our worry about the contents living outside the DOM being strange, but it has the downside that nearly all uses will immediately re-parse. [Dimitri addressed the problem with (1) being (b) earlier in the thread, if anyone is interested]. :DG
Re: [webcomponents] HTML Parsing and the template element
Why don't we just use script elements for that then? On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote: You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.comwrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of DOM structures inside my document to the client, but have those fragments exist *outside* the DOM constructed for that document for all practical purposes (rendering, traversal, resource loading, selector matching, etc...). This goal of this feature is provide webdevs with a supported mechanism to do this which lacks the pitfalls of the available hacks. Assuming (1) is uncontroversially (a), then the idea to re-serialize the parsed content and append it is a text child to the template element would resolve our worry about the contents living outside the DOM being strange, but it has the downside that nearly all uses will immediately re-parse. [Dimitri addressed the problem with (1) being (b) earlier in the thread, if anyone is interested]. :DG
Re: [webcomponents] HTML Parsing and the template element
Yes. I think this issue is a distraction. Using the script tag for encoding opaque text contents is a hack, but it works as well as it can. AFAIC, The main drawback is that the contents cannot contain the string /script. This will be the case for any new element we came up with for this purpose. If someone has an idea for how to do better than this and why it's worth doing, please speak up. Part of the point of parsing the template contents as HTML is exactly so that template contents can contain subtemplates. It's a universal feature of templating systems and needs to be well supported. On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we just use script elements for that then? On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote: You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.com wrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of DOM structures inside my document to the client, but have those fragments exist *outside* the DOM constructed for that document for all practical purposes (rendering, traversal, resource loading, selector matching, etc...). This goal of this feature is provide webdevs with a supported mechanism to do this which lacks the pitfalls of the available hacks. Assuming (1) is uncontroversially (a), then the idea to re-serialize the parsed content and append it is a text child to the template element would resolve our worry about the contents living outside the DOM being strange, but it has the downside that nearly all uses will immediately re-parse. [Dimitri addressed the problem with (1) being (b) earlier in the thread, if anyone is interested]. :DG
Re: [webcomponents] HTML Parsing and the template element
I'd like to weigh in on this topic as it is something that I'm involved in at work as well. Could you maybe explain further parsing the template contents as HTML can contain sub templates? If you take this example: template div!-- A little markup //--/div template!-- subtemplate markup //--/template div!-- A little more markup //--/div /template Are you saying there is 1 Node that has a 3 children? If yes what benefit does that bring that inert tags doesn't? On 4/23/12 8:25 PM, Rafael Weinstein rafa...@google.com wrote: Yes. I think this issue is a distraction. Using the script tag for encoding opaque text contents is a hack, but it works as well as it can. AFAIC, The main drawback is that the contents cannot contain the string /script. This will be the case for any new element we came up with for this purpose. If someone has an idea for how to do better than this and why it's worth doing, please speak up. Part of the point of parsing the template contents as HTML is exactly so that template contents can contain subtemplates. It's a universal feature of templating systems and needs to be well supported. On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we just use script elements for that then? On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote: You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.com wrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of DOM structures inside my document to the client, but have those fragments exist *outside* the DOM constructed for that document for all practical purposes (rendering, traversal, resource loading, selector matching, etc...). This goal of this feature is provide webdevs with a supported mechanism to do this which lacks the pitfalls of the available hacks. Assuming (1) is uncontroversially (a), then the idea to re-serialize the parsed content and append it is a text child to the template element
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Have you looked at http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html ? On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein rafa...@google.comwrote: The main points of contention in the discussion about the template element are 1) By what mechanism are its content elements 'inert' 2) Do template contents reside in the document, or outside of it What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. This has come up in the past, and is in itself a useful feature. The problem it solves is allowing templating systems to create DOM from markup without having to sniff the content and only innerHTML on an appropriate parent element (Yehuda can speak more to this). The parser changes required for this are a subset of the changes that Dimitri uncovered here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html And I've uploaded a webkit patch which implements them here: https://bugs.webkit.org/show_bug.cgi?id=84646 I'm hoping this is a sensible way to make progress. Thoughts?
