[Bug 16833] New: consider always exposing a length property for objects with indexed properties
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16833 Summary: consider always exposing a length property for objects with indexed properties Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Web Workers (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: c...@mcc.id.au QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Rather than relying on spec authors to add a readonly attribute unsigned long length; to an interface that has an index getter, it would be simpler to have all such objects/interfaces expose a length property. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
No, I hadn't. Let me digest this thread. Much of what I'm implicitly asking has already been discussed. I'll repost if I have anything to add here. Apologies for the noise. On Mon, Apr 23, 2012 at 10:32 PM, Ryosuke Niwa rn...@webkit.org wrote: 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.com wrote: 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?
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. I know of many, many templating systems and I have simply never (aside from MDV) seen it in exactly this light (that is templates actually embedded in others), regardless of whether those are for within the browser for generating HTML (or anything else) or on the server - or even for code generation. It seems to me that there is a rich history of templating text, it's very useful and in every case I have seen you have a template and that template can contain references to other templates, not embed them... Am I seeing this improperly? This seems to be the case with freemarker, velocity, mustache, handlbars, even jsp, asp, php, etc - (there are really a lot of them, I'm just throwing out a bunch). This kind of approach does not seem like it would be out of place in HTML or even XML - we think about a lot of things that way (in terms of references). Are there some in particular that someone could point to that illustrate otherwise? If you use the same element as both a marker for the template and as a beam off which to hang instructions (template data-iterate for example) then you are bound to wind up in this situation, but otherwise I don't see why it is so controversial to just say not embedded, referenced. Perhaps if described as 2 or 3 tags instead of 1 it would be easier to discuss? 1. the template tag, just like script (can't embed itself) only template (so it can contain scripts and is easily identified for what it is) 2. a template-ref tag which allows you to ref another template (I expect this wont actually be used by a lot of languages since this is generally a feature of the template language itself - but ok) 3. a template-instruction tag which provides your beam off which to hang whatever (iterate, condition, etc) and allows anyone who is interested in building templating languages that are fully legit HTML to do so (I think that unless there is a lot more to the sale, people will tend to stick with non-HTML looking iterators, conditions, etc - but ok) Is 1 as I describe it really controversial? 2 and 3 seem to me to be clearly about features of a particular templating language (or at least a particular class of them that mostly don't exist today). I expect, however, that there might be larger ideas behind why not to do this in the sense of web components or declarative MDV-like data binding and it would be good to hear the larger perspective of how that might fit together so decisions on one front don't negate good ideas on another. - Brian 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
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 06:46, Brian Kardell bkard...@gmail.com wrote: I know of many, many templating systems and I have simply never (aside from MDV) seen it in exactly this light (that is templates actually embedded in others), regardless of whether those are for within the browser for generating HTML (or anything else) or on the server - or even for code generation. It seems to me that there is a rich history of templating text, it's very useful and in every case I have seen you have a template and that template can contain references to other templates, not embed them... Am I seeing this improperly? This seems to be the case with freemarker, velocity, mustache, handlbars, even jsp, asp, php, etc - (there are really a lot of them, I'm just throwing out a bunch). This kind of approach does not seem like it would be out of place in HTML or even XML - we think about a lot of things that way (in terms of references). Are there some in particular that someone could point to that illustrate otherwise? Most system do allow it. The syntax they use might not make it clear. http://emberjs.com/#toc_displaying-a-list-of-items ul {{#each people}} liHello, {{name}}!/li {{/each}} /ul In here there is a template between the start each and end each. -- erik
Re: [webcomponents] HTML Parsing and the template element
Placing contents as CDATA is an option. I personally think the template/ tag as proposed is adhoc to somebody's notion of how templates should work. To avoid this I think they should be simpler. I am not seeing the added advantage of having the client parse the contents upon encountering it: there is no use for the contents before it is used programatically, and as such it could be prepared on first use, via the DocumentFragment suggestion mentioned earlier. Specifically, it's never considered to be part of the document's semantic content. Perhaps I'm overlooking something here. I would recommend adding a mime type specifier to the template. Choosing text/html as a content type may hint that contents should be parsed. Alternatively or additionally an attribute indicating that the contents should be parsed as DOM may be specified, e.g. template html/ or template dom/. On Apr 24, 2012 6:25 AM, 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
Re: [webcomponents] HTML Parsing and the template element
On 04/24/2012 05:57 PM, Yuval Sadan wrote: Placing contents as CDATA is an option. I personally think the template/ tag as proposed is adhoc to somebody's notion of how templates should work. To avoid this I think they should be simpler. I am not seeing the added advantage of having the client parse the contents upon encountering it: there is no use for the contents before it is used programatically, and as such it could be prepared on first use, via the DocumentFragment suggestion mentioned earlier. Specifically, it's never considered to be part of the document's semantic content. Perhaps I'm overlooking something here. That is actually quite a useful axis of distinction. If we want normal methods on the document like getElementsByClassName or getElementById to return elements in templates they obviously need to be parsed as actual elements in the DOM. If we don't it seems very unnatural to have them parsed as elements; making DOM Core methods, CSS selectors, etc. have some dependence on whether there is an element called template in the tree just seems like a recipe for pain. My feeling is that the elements in templates aren't like the other elements in the document and so we don't want the normal lookup/traversal methods on document to work on them.
Re: [webcomponents] HTML Parsing and the template element
Hmm. I have to say that I disagree that your example below shows a template within a template. That is IMO 1 template wherein there is iteration syntax. But to further my point: Where does the demarcation of template stop and template syntax begin in your example? Or are you saying that the template syntax is in fact that demarcation? On 4/24/12 8:48 AM, Erik Arvidsson a...@chromium.org wrote: On Tue, Apr 24, 2012 at 06:46, Brian Kardell bkard...@gmail.com wrote: I know of many, many templating systems and I have simply never (aside from MDV) seen it in exactly this light (that is templates actually embedded in others), regardless of whether those are for within the browser for generating HTML (or anything else) or on the server - or even for code generation. It seems to me that there is a rich history of templating text, it's very useful and in every case I have seen you have a template and that template can contain references to other templates, not embed them... Am I seeing this improperly? This seems to be the case with freemarker, velocity, mustache, handlbars, even jsp, asp, php, etc - (there are really a lot of them, I'm just throwing out a bunch). This kind of approach does not seem like it would be out of place in HTML or even XML - we think about a lot of things that way (in terms of references). Are there some in particular that someone could point to that illustrate otherwise? Most system do allow it. The syntax they use might not make it clear. http://emberjs.com/#toc_displaying-a-list-of-items ul {{#each people}} liHello, {{name}}!/li {{/each}} /ul In here there is a template between the start each and end each. -- erik
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 11:48 AM, Erik Arvidsson a...@chromium.org wrote: On Tue, Apr 24, 2012 at 06:46, Brian Kardell bkard...@gmail.com wrote: I know of many, many templating systems and I have simply never (aside from MDV) seen it in exactly this light (that is templates actually embedded in others), regardless of whether those are for within the browser for generating HTML (or anything else) or on the server - or even for code generation. It seems to me that there is a rich history of templating text, it's very useful and in every case I have seen you have a template and that template can contain references to other templates, not embed them... Am I seeing this improperly? This seems to be the case with freemarker, velocity, mustache, handlbars, even jsp, asp, php, etc - (there are really a lot of them, I'm just throwing out a bunch). This kind of approach does not seem like it would be out of place in HTML or even XML - we think about a lot of things that way (in terms of references). Are there some in particular that someone could point to that illustrate otherwise? Most system do allow it. The syntax they use might not make it clear. http://emberjs.com/#toc_displaying-a-list-of-items ul {{#each people}} liHello, {{name}}!/li {{/each}} /ul In here there is a template between the start each and end each. While you could think of it that way, that's not generally how we refer to it when discussing templates - right? Just pick any and the documentation (it seems to me) will refer to templates separately from instructions/macros/etc that make up the templating language (the above are an example of handlebars each block helpers). In your provided example (which uses handlebars) the better analogy to what I am arguing is partials - see https://github.com/wycats/handlebars.js/ --- about 1/2 way down the page you will find: Partials You can register additional templates as partials, which will be used by Handlebars when it encounters a partial ({{ partialName}}). Partials can either be String templates or compiled template functions. Here's an example: var source = ul{{#people}}li{{ link}}/li{{/people}}/ul; Handlebars.registerPartial('link', 'a href=/people/{{id}}{{name}}/a') var template = Handlebars.compile(source); var data = { people: [ { name: Alan, id: 1 }, { name: Yehuda, id: 2 } ]}; template(data); // Should render: // ul // lia href=/people/1Alan/a/li // lia href=/people/2Yehuda/a/li // /ul Again, all of these templating systems (it seems to me) draw a distinction between these two ideas... Am I missing something?
Re: [webcomponents] HTML Parsing and the template element
I agree with these statements: there is no use for the contents before it is used programmatically it's never considered to be part of the document's semantic content I'd like to add that the only use-case for a template/ tag (IMO) is to deliver content to the UA safely preventing the DOM from using it. I would never want the UA to present this content or place it in the element stack before something has programmatically manipulated it. To have the UA parse it and add it to the element stack seems problematic in that it would possibly have to be reversed out once I'm done manipulating it. From: Yuval Sadan sadan.yu...@gmail.com Date: Tue, 24 Apr 2012 18:57:46 +0300 To: Rafael Weinstein rafa...@google.com Cc: public-webapps public-webapps@w3.org, Ryosuke Niwa rn...@webkit.org Subject: Re: [webcomponents] HTML Parsing and the template element Resent-From: public-webapps@w3.org Resent-Date: Tue, 24 Apr 2012 15:58:26 + Placing contents as CDATA is an option. I personally think the template/ tag as proposed is adhoc to somebody's notion of how templates should work. To avoid this I think they should be simpler. I am not seeing the added advantage of having the client parse the contents upon encountering it: there is no use for the contents before it is used programatically, and as such it could be prepared on first use, via the DocumentFragment suggestion mentioned earlier. Specifically, it's never considered to be part of the document's semantic content. Perhaps I'm overlooking something here. I would recommend adding a mime type specifier to the template. Choosing text/html as a content type may hint that contents should be parsed. Alternatively or additionally an attribute indicating that the contents should be parsed as DOM may be specified, e.g. template html/ or template dom/. On Apr 24, 2012 6:25 AM, 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
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill clint.h...@gmail.com wrote: Hmm. I have to say that I disagree that your example below shows a template within a template. That is IMO 1 template wherein there is iteration syntax. The iteration syntax is basically an element - the example that Arv gave even used element-like syntax, with open and close tags. That iteration element is inside of a template. If iteration uses a different tagname than normal templating (say, iterate), thus avoiding the nesting template in template problem, you still have the problem of nesting iteration, which is *also* a common ability for template systems. Any way you slice it, common templating scenarios will create problems if you don't hook it up to a proper parser at some point. Might as well do that early so you can immediately delve into it with DOM methods and whatnot, rather than delaying it and keeping it as flat text until the point of use. ~TJ
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 9:11 AM, James Graham jgra...@opera.com wrote: On 04/24/2012 05:57 PM, Yuval Sadan wrote: Placing contents as CDATA is an option. I personally think the template/ tag as proposed is adhoc to somebody's notion of how templates should work. To avoid this I think they should be simpler. I am not seeing the added advantage of having the client parse the contents upon encountering it: there is no use for the contents before it is used programatically, and as such it could be prepared on first use, via the DocumentFragment suggestion mentioned earlier. Specifically, it's never considered to be part of the document's semantic content. Perhaps I'm overlooking something here. That is actually quite a useful axis of distinction. If we want normal methods on the document like getElementsByClassName or getElementById to return elements in templates they obviously need to be parsed as actual elements in the DOM. If we don't it seems very unnatural to have them parsed as elements; making DOM Core methods, CSS selectors, etc. have some dependence on whether there is an element called template in the tree just seems like a recipe for pain. My feeling is that the elements in templates aren't like the other elements in the document and so we don't want the normal lookup/traversal methods on document to work on them. I *believe* we don't want lookup methods to find the inert elements inside of a template. Traversal should still work, obviously - if you ask for the children of a template node, you should get its actual children, so you can manipulate them. This distinction is why one possible approach (previously stated) is to stuff the elements into a separate subtree, similar to the shadow tree. That might make the design somewhat cleaner, in that the lookup methods can continue to just lookup in the normal DOM. ~TJ ~TJ
Re: [webcomponents] HTML Parsing and the template element
Any way you slice it, common templating scenarios will create problems if you don't hook it up to a proper parser at some point. This is a great point: What parser? If you're implying the HTML Parser, then I think we're talking about a Templating syntax and not just a template/ tag. To which I would imagine is the hard road to take. On 4/24/12 9:45 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill clint.h...@gmail.com wrote: Hmm. I have to say that I disagree that your example below shows a template within a template. That is IMO 1 template wherein there is iteration syntax. The iteration syntax is basically an element - the example that Arv gave even used element-like syntax, with open and close tags. That iteration element is inside of a template. If iteration uses a different tagname than normal templating (say, iterate), thus avoiding the nesting template in template problem, you still have the problem of nesting iteration, which is *also* a common ability for template systems. Any way you slice it, common templating scenarios will create problems if you don't hook it up to a proper parser at some point. Might as well do that early so you can immediately delve into it with DOM methods and whatnot, rather than delaying it and keeping it as flat text until the point of use. ~TJ
[Bug 16840] New: i vear shiad but lagbar mypassword
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16840 Summary: i vear shiad but lagbar mypassword Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: public-webapps-bugzi...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Specification: http://www.w3.org/TR/webstorage/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: i vear shiad but lagbar mypassword Posted from: 223.176.58.30 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 16840] i vear shiad but lagbar mypassword
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16840 Olli Pettay olli.pet...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||olli.pet...@gmail.com Resolution||INVALID -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 10:14 AM, Brian Kardell bkard...@gmail.com wrote: On Tue, Apr 24, 2012 at 12:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill clint.h...@gmail.com wrote: Hmm. I have to say that I disagree that your example below shows a template within a template. That is IMO 1 template wherein there is iteration syntax. The iteration syntax is basically an element - the example that Arv gave even used element-like syntax, with open and close tags. That iteration element is inside of a template. But in his example, and most of the ones people have been citing or really want to use this for they are no tags in the HTML sense... Those are handlebars (or mustache or dust or haml or whatever) [snip further comments along similar lines] As long as it's handlebars that merely *look* like elements, we have to ship code down the wire that is simply a functional replacement for the DOM that the user already has. This is suboptimal. It's a cowpath that only curves this way because the straighter path was blocked by a boulder, and cows don't have dynamite. We do. The more we can replace code-on-the-wire with code-in-the-browser, the better. (Subject to obvious tradeoffs, of course.) ~TJ
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 24, 2012 at 10:14 AM, Brian Kardell bkard...@gmail.com wrote: On Tue, Apr 24, 2012 at 12:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill clint.h...@gmail.com wrote: Hmm. I have to say that I disagree that your example below shows a template within a template. That is IMO 1 template wherein there is iteration syntax. The iteration syntax is basically an element - the example that Arv gave even used element-like syntax, with open and close tags. That iteration element is inside of a template. But in his example, and most of the ones people have been citing or really want to use this for they are no tags in the HTML sense... Those are handlebars (or mustache or dust or haml or whatever) [snip further comments along similar lines] As long as it's handlebars that merely *look* like elements, we have to ship code down the wire that is simply a functional replacement for the DOM that the user already has. This is suboptimal. It's a cowpath that only curves this way because the straighter path was blocked by a boulder, and cows don't have dynamite. We do. I do not think it is an entirely accurate statement to say the path only curves this way because the straighter path was blocked by a boulder. There is pretty much nothing preventing existing templating languages (client or server) from looking (inside) just like has been suggested, and yet the most popular ones generally don't do that... Instead, we use things for instructions/controls/macros/etc that purposely don't look like HTML specifically to call them out as different because that increases readability and maintainability - and it makes them not use-specific (I can use them to generate anything, not just DOM). Personally, I prefer it that way - but maybe that's just me? It does seem to be the case that many people are talking about though -- using those libraries with the template tag... Maybe they can chime in... I am very interested though in knowing whether this would essentially be a case of allowed/works, but discouraged. I do agree that it is less optimal in the sense that you have to lex/parse/etc but that also means there is a lot of room for competition in variants which I think is a good thing in general. If things get so tight as to require that the template tag identifies iterators, etc as well (by way of data-* attributes) - I think that would limit the competition for templating languages to very close to 1. At that point, might as well go ahead and define it. At that point - it also seems salty enough to my taste to want to trade a few ms for something I like more... Does anyone have any kinds of metrics illustrating just how much better optimized this would be by comparison? I've used templating a lot and honestly, I've never found it to be the bottleneck or the problem. All that said, maybe with some time and experience I could learn to love it as DOM too... I'm really not trying to be the only one arguing endlessly about it, so unless someone backs me up on at least some point here I will rest my case :) -Brian
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 2:40 PM, Brian Kardell bkard...@gmail.com wrote: All that said, maybe with some time and experience I could learn to love it as DOM too... I'm really not trying to be the only one arguing endlessly about it, so unless someone backs me up on at least some point here I will rest my case :) I feel the same way. I'm not really sure why we would want to use elements and attributes to define the templating language. If the purpose is we can now parse templates using DOM, then I have to wonder if anyone using templates is actually asking for that. I know of two use cases that need to be solved: 1) Templates that cleanly include /script. 2) Generating fragments with arbitrary top-level elements. Are there other use cases that are trying to be solved with template?
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 04/24/2012 09:43 PM, Travis Leithead wrote: Based on my reading of DOM4, initEvent makes it possible to transform a trusted event into a non-trusted event and dispatch it. Is that intentional? AFAIK, yes It is only currently supported in Firefox and Opera. In IE, Chrome and Safari, the initEvent call is ignored in this scenario. After the initEvent call is ignored, Chrome will allow you to dispatch the event (unchanged), IE will not (per the prose currently in DOM3 Events). Note, chrome doesn't report the isTrusted property, so I can't tell if initEvent would have set that flag to false (hope so)! I'm trying to rationalize the behavior between DOM3 and DOM4. DOM3 Events was pretty clear that you can't dispatch an event that wasn't created with createEvent. Sounds like a bug. That wasn't the intention when isTrusted was added. Pretty simple. That's contrary to DOM4 at the moment (which allows it as long as it's been initialized); I wonder if there needs to be another check to prevent re-dispatching a trusted event?. Is there a specific reason for the current behavior? DOM3 Events is not very clear about initEvent at the moment. Should it be allowed to convert a trusted event to a non-trusted event? Yes. It should be possible to re-dispatch events. But if a script running on a web page dispatches event, the event must become untrusted. -Olli Seems like trouble. Given that IE9 and Chrome/Safari don't allow it, it won't be a compatibility issue to disallow it. Let's come to an agreement on this so that the two specs can be harmonious on this point. -Travis
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On Tue, Apr 24, 2012 at 2:23 PM, Olli Pettay olli.pet...@helsinki.fiwrote: Yes. It should be possible to re-dispatch events. But if a script running on a web page dispatches event, the event must become untrusted. What's the point of isTrusted, anyway? You have to trust other scripts running in the same page anyway. Does it come into play with cross-origin iframes or something? -- Glenn Maynard
RE: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). From: Glenn Maynard [mailto:gl...@zewt.org] Sent: Tuesday, April 24, 2012 12:38 PM To: o...@pettay.fi Cc: Travis Leithead; public-weba...@w3c.org; Anne van Kesteren (ann...@opera.com); Jacob Rossi Subject: Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent On Tue, Apr 24, 2012 at 2:23 PM, Olli Pettay olli.pet...@helsinki.fimailto:olli.pet...@helsinki.fi wrote: Yes. It should be possible to re-dispatch events. But if a script running on a web page dispatches event, the event must become untrusted. What's the point of isTrusted, anyway? You have to trust other scripts running in the same page anyway. Does it come into play with cross-origin iframes or something? -- Glenn Maynard
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On Tue, Apr 24, 2012 at 2:54 PM, Travis Leithead travis.leith...@microsoft.com wrote: Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). I know what it does; I'm asking what its purpose is. When is this useful? (It's not actually useful, and it only exists for web-compatibility is a valid answer, of course.) -- Glenn Maynard
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 9:54 PM, Travis Leithead travis.leith...@microsoft.com wrote: Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). From: Glenn Maynard [mailto:gl...@zewt.org] What's the point of isTrusted, anyway? You have to trust other scripts running in the same page anyway. Does it come into play with cross-origin iframes or something? See http://www.w3.org/TR/DOM-Level-3-Events/#events-event-type-isTrusted --tobie
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 10:00 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 24, 2012 at 2:54 PM, Travis Leithead travis.leith...@microsoft.com wrote: Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). I know what it does; I'm asking what its purpose is. When is this useful? Are you asking about the purpose of exposing the property or the purpose of trusted events? The latter's obvious: prevent visited content from triggering actions the UA wants to allow only after a user action. The former I'm not sure. --tobie
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On Tue, Apr 24, 2012 at 3:06 PM, Tobie Langel to...@fb.com wrote: Are you asking about the purpose of exposing the property or the purpose of trusted events? I'm asking about the property. The flag underneath it exists only to implement the property. The latter's obvious: prevent visited content from triggering actions the UA wants to allow only after a user action. The former I'm not sure. This is a common misconception of how events work. If you're a browser, default events do not--except for one or two web-compat exceptions--look like this: browse_button.addEventListener(click, function(e) { if(e.isTrusted) openFilePicker(); }, false); browse_button.dispatchEvent(clickEvent); Rather, they look like this: if(browse_button.dispatchEvent(clickEvent)) openFilePicker(); The default action--openFilePicker()--is not part of the event dispatch process; it's part of the caller of the dispatch. You don't need a flag to tell you that you dispatched the event. (DOM3's language about default actions confuses this; I suggest reading DOM4's event section to get a good picture of how this actually works.) (The main exception is the click event, which does activate the element when a synthetic event is dispatched. This is a historical mistake, not the norm. I don't believe that needs this flag, either, but I'll hold off explaining why unless somebody asks.) -- Glenn Maynard
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
(Sorry, forgot to merge drafts.) On Tue, Apr 24, 2012 at 3:02 PM, Tobie Langel to...@fb.com wrote: See http://www.w3.org/TR/DOM-Level-3-Events/#events-event-type-isTrusted Please don't link people to TR specs; that text is almost a year out of date, which invites pain and confusion. Always use editor's drafts: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html -- Glenn Maynard
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On Tue, 24 Apr 2012 22:00:24 +0200, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 24, 2012 at 2:54 PM, Travis Leithead travis.leith...@microsoft.com wrote: Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). I know what it does; I'm asking what its purpose is. When is this useful? FWIW, I too am interested in this. I included it in DOM4 because DOM Level 3 Events had it and I aimed for feature parity. (Also, www-dom is actually the DOM mailing list, but I guess it does not matter much...) -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 4:34 PM, Glenn Maynard wrote: This is a common misconception of how events work. If you're a browser, default events do not--except for one or two web-compat exceptions--look like this: browse_button.addEventListener(click, function(e) { if(e.isTrusted) openFilePicker(); }, false); browse_button.dispatchEvent(clickEvent); Rather, they look like this: if(browse_button.dispatchEvent(clickEvent)) openFilePicker(); Actually, no. The way events work, at least in Gecko, is more like this (conceptually; the actual implementation is somewhat different): browse_button.addEventListenerInSystemEventGroup(click, function(e) { if (e.isTrusted !e.defaultPrevented) { e.preventDefault(); openFilePicker(); } }, false); This is needed because there might be multiple things that might wish to perform a default action based on a click (in particular, every single thing the click bubbles through), and the code that actually dispatches a click can't possibly have an idea of the full set of default actions involved. The dispatch code then looks like this: someNode.dispatchEvent(clickEvent); and has no idea whether it's going to a browse_button or to a span which has an a href on the ancestor chain. The default action--openFilePicker()--is not part of the event dispatch process; it's part of the caller of the dispatch. That's a convenient spec fiction, but actually hard to implement that way; it requires some way for the event dispatch process to communicate to the caller of the dispatch the set of desired default actions. See the hoops that the spec has to jump through to deal with nested activation behavior, for example Oh, and that's before we get into default actions implemented by extensions. (DOM3's language about default actions confuses this; I suggest reading DOM4's event section to get a good picture of how this actually works.) Or rather how the DOM4 editor is choosing to conceptualize it, which may not have much bearing on how it actually works in actual browsers. (The main exception is the click event And a rather big exception it is! -Boris
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 11:04 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/24/12 5:02 PM, Boris Zbarsky wrote: Oh, and that's before we get into default actions implemented by extensions. And one more thing: extensions _definitely_ want to know whether events are trusted or not. This doesn't necessitate a web-exposed API, obviously; the property could only be visible in extension code. But it does necessitate the internal flag. So is it exposed to web content to fulfill particular use-cases? --tobie
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 5:08 PM, Tobie Langel wrote: On 4/24/12 11:04 PM, Boris Zbarskybzbar...@mit.edu wrote: On 4/24/12 5:02 PM, Boris Zbarsky wrote: Oh, and that's before we get into default actions implemented by extensions. And one more thing: extensions _definitely_ want to know whether events are trusted or not. This doesn't necessitate a web-exposed API, obviously; the property could only be visible in extension code. But it does necessitate the internal flag. So is it exposed to web content to fulfill particular use-cases? Gecko initially exposed it because it was easier to do so than to only expose it to extensions but hide it from web content, I believe (or more precisely the latter was not really possible in Gecko at the time; it would be quite possible now). I wasn't involved in the discussion about exposing it in the spec, so no idea what the precise reasons there were. Web content _can_ have the same use cases as browser extensions, but Glenn's point about web content having to trust other stuff in the same frame is of course true. At least until we start having some web content with elevated privileges (see e.g. the direction Boot2Gecko is going in) which will require something like this exposed again. -Boris
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On Tue, 24 Apr 2012 23:02:22 +0200, Boris Zbarsky bzbar...@mit.edu wrote: (DOM3's language about default actions confuses this; I suggest reading DOM4's event section to get a good picture of how this actually works.) Or rather how the DOM4 editor is choosing to conceptualize it, which may not have much bearing on how it actually works in actual browsers. Last time I discussed this with Jonas Sicking he agreed that Gecko could change some things here and he also agreed with the model put forward. If the model is wrong we should fix it of course. It does indeed not apply universally and as far as I know HTML does cater for those exceptions in various ways. It would be interesting to know where it does not. I'm not sure how extensions are relevant here. If you allow them to do complex things then of course they will be complex to implement, but there is not much we can do about that. -- Anne van Kesteren http://annevankesteren.nl/
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 12:00, Scott González scott.gonza...@gmail.com wrote: Are there other use cases that are trying to be solved with template? 3. Inert. You don't want to fetch resources at unresolved URLs. img src=/images/${user}.png 4. Selectors should not match content of the template both of these works fine with script type=text/x-this-is-a-hack -- erik
Re: BlobBuilder.append() should take ArrayBufferView in addition to ArrayBuffer
On Apr 12, 2012, at 2:48 PM, Arun Ranganathan wrote: I intend to add ArrayBufferView as a parameter to the Blob constructor . Would it be possible also to allow passing an ArrayBuffer with an offset and length as an additional alternative? This would eliminate the need to create a view when you just want a slice of the buffer but don't particularly want/need to think of it as a Uint8/Uint32/whatever array. Dave
Re: BlobBuilder.append() should take ArrayBufferView in addition to ArrayBuffer
On Apr 24, 2012, at 3:53 PM, David Herman wrote: On Apr 12, 2012, at 2:48 PM, Arun Ranganathan wrote: I intend to add ArrayBufferView as a parameter to the Blob constructor . Would it be possible also to allow passing an ArrayBuffer with an offset and length as an additional alternative? This would eliminate the need to create a view when you just want a slice of the buffer but don't particularly want/need to think of it as a Uint8/Uint32/whatever array. Oh, I just saw in the bug that the idea is to *eliminate* the ArrayBuffer argument option entirely. If that's the case then disregard my question. Dave
[Bug 16846] New: cześc to ja rodzyn i wydaje mi się ze jestem na dość dobrej pozycji i w ogóle jestem super i jestem zajebisty ale nie czaje o co chodzi ty wszystklim ludzą skoro to ma tak wyglądać n
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16846 Summary: cześc to ja rodzyn i wydaje mi się ze jestem na dość dobrej pozycji i w ogóle jestem super i jestem zajebisty ale nie czaje o co chodzi ty wszystklim ludzą skoro to ma tak wyglądać no to wydaje mi się że to będzie już koniec co wyu na no to ;;; Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: cześc to ja rodzyn i wydaje mi się ze jestem na dość dobrej pozycji i w ogóle jestem super i jestem zajebisty ale nie czaje o co chodzi ty wszystklim ludzą skoro to ma tak wyglądać no to wydaje mi się że to będzie już koniec co wyu na no to ;;; Posted from: 156.17.236.177 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 5:16 PM, Anne van Kesteren wrote: On Tue, 24 Apr 2012 23:02:22 +0200, Boris Zbarsky bzbar...@mit.edu wrote: (DOM3's language about default actions confuses this; I suggest reading DOM4's event section to get a good picture of how this actually works.) Or rather how the DOM4 editor is choosing to conceptualize it, which may not have much bearing on how it actually works in actual browsers. Last time I discussed this with Jonas Sicking he agreed that Gecko could change some things here and he also agreed with the model put forward. If the model is wrong we should fix it of course. It's a conceptual model. I'm just saying that actual implementations behave differently on the inside; I don't think the difference is black-box distinguishable from a typical web page. I'm not sure how extensions are relevant here. Glenn asked why events need internal state that indicates whether they're trusted. Extensions are one of the reasons. If you allow them to do complex things then of course they will be complex to implement, but there is not much we can do about that. Sure there is, where we == browser vendors. We can expose APIs to extensions to make them easier to implement. APIs that expose things like the trusted state of events. -Boris
RE: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16847 to track getting DOM3 updated on this point. Thanks for the info. BTW: Olli, your email isn't recognized in the Bug DB's CC list. Is there one that will work? -Original Message- From: Olli Pettay [mailto:olli.pet...@helsinki.fi] Sent: Tuesday, April 24, 2012 12:23 PM To: Travis Leithead Cc: public-weba...@w3c.org; Anne van Kesteren (ann...@opera.com); Jacob Rossi Subject: Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent On 04/24/2012 09:43 PM, Travis Leithead wrote: Based on my reading of DOM4, initEvent makes it possible to transform a trusted event into a non-trusted event and dispatch it. Is that intentional? AFAIK, yes It is only currently supported in Firefox and Opera. In IE, Chrome and Safari, the initEvent call is ignored in this scenario. After the initEvent call is ignored, Chrome will allow you to dispatch the event (unchanged), IE will not (per the prose currently in DOM3 Events). Note, chrome doesn't report the isTrusted property, so I can't tell if initEvent would have set that flag to false (hope so)! I'm trying to rationalize the behavior between DOM3 and DOM4. DOM3 Events was pretty clear that you can't dispatch an event that wasn't created with createEvent. Sounds like a bug. That wasn't the intention when isTrusted was added. Pretty simple. That's contrary to DOM4 at the moment (which allows it as long as it's been initialized); I wonder if there needs to be another check to prevent re-dispatching a trusted event?. Is there a specific reason for the current behavior? DOM3 Events is not very clear about initEvent at the moment. Should it be allowed to convert a trusted event to a non-trusted event? Yes. It should be possible to re-dispatch events. But if a script running on a web page dispatches event, the event must become untrusted. -Olli Seems like trouble. Given that IE9 and Chrome/Safari don't allow it, it won't be a compatibility issue to disallow it. Let's come to an agreement on this so that the two specs can be harmonious on this point. -Travis
[Bug 16846] cześc to ja rodzyn i wydaje mi się ze jestem na dość dobrej pozycji i w ogóle jestem super i jestem zajebisty ale nie czaje o co chodzi ty wszystklim ludzą skoro to ma tak wyglądać no to
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16846 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 04/25/2012 12:16 AM, Anne van Kesteren wrote: On Tue, 24 Apr 2012 23:02:22 +0200, Boris Zbarsky bzbar...@mit.edu wrote: (DOM3's language about default actions confuses this; I suggest reading DOM4's event section to get a good picture of how this actually works.) Or rather how the DOM4 editor is choosing to conceptualize it, which may not have much bearing on how it actually works in actual browsers. Last time I discussed this with Jonas Sicking he agreed that Gecko could change some things here and he also agreed with the model put forward. It is not only about Gecko, but all the browser engines, at least last time I tested it. If the model is wrong we should fix it of course. It does indeed not apply universally and as far as I know HTML does cater for those exceptions in various ways. It would be interesting to know where it does not. I'm not sure how extensions are relevant here. If you allow them to do complex things then of course they will be complex to implement, but there is not much we can do about that.