[Bug 16833] New: consider always exposing a length property for objects with indexed properties

2012-04-24 Thread bugzilla
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

2012-04-24 Thread Rafael Weinstein
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

2012-04-24 Thread Brian Kardell
 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

2012-04-24 Thread Erik Arvidsson
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

2012-04-24 Thread Yuval Sadan
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

2012-04-24 Thread James Graham

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

2012-04-24 Thread Clint Hill
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

2012-04-24 Thread Brian Kardell
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

2012-04-24 Thread Clint Hill
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

2012-04-24 Thread Tab Atkins Jr.
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

2012-04-24 Thread Tab Atkins Jr.
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

2012-04-24 Thread Clint Hill
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

2012-04-24 Thread bugzilla
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

2012-04-24 Thread bugzilla
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

2012-04-24 Thread Tab Atkins Jr.
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

2012-04-24 Thread Brian Kardell
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

2012-04-24 Thread Scott González
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

2012-04-24 Thread Olli Pettay

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

2012-04-24 Thread Glenn Maynard
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

2012-04-24 Thread Travis Leithead
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

2012-04-24 Thread Glenn Maynard
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

2012-04-24 Thread Tobie Langel
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

2012-04-24 Thread Tobie Langel
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

2012-04-24 Thread Glenn Maynard
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

2012-04-24 Thread Glenn Maynard
(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

2012-04-24 Thread Anne van Kesteren

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

2012-04-24 Thread Boris Zbarsky

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

2012-04-24 Thread Tobie Langel
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

2012-04-24 Thread Boris Zbarsky

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

2012-04-24 Thread Anne van Kesteren

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

2012-04-24 Thread Erik Arvidsson
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

2012-04-24 Thread David Herman
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

2012-04-24 Thread David Herman
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

2012-04-24 Thread bugzilla
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

2012-04-24 Thread Boris Zbarsky

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

2012-04-24 Thread Travis Leithead
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

2012-04-24 Thread bugzilla
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

2012-04-24 Thread Olli Pettay

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.