DOM4 Core (was: childElements, childElementCount, and children)

[Doug Schepers-3]

Hi, Folks-

John Resig wrote (on 10/18/09 1:50 PM):
>>  They already do. Which casts some amount of doubt on Maciejs argument
>>  that it was too performance heavy to implement in WebKit. :)

Well, it does work in HTML, but not in SVG [1]... which may or may not
be desirable, since .children returns an HTMLCollection, and SVG
elements are not HTML elements.


>>  p.s. It also works in Opera and IE.

Sure, but I mentioned that already. :)  (Note to self... write pithier
emails.)


> Yeah, .children is already the de facto standard here - implemented in
> every major browser. It's a real shame that it hasn't (and won't?)
> make it in to a spec, especially considering that it's already
> implemented everywhere.

Nothing to stop it from being specified, but I doubt that Internet
Explorer will change its behavior, since that will likely break existing
Web content (IE team, thoughts?).  I generally agree with Garrett here,
so I've followed up on my early promise to specify this by starting the
DOM4 Core spec [2], and included 'children' as an HTMLCollection (to
satisfy the case that John rightly describes), and 'childElements' as a
new ElementCollection (to supply a more progressive interface that
authors can rely on predictably).

The WebApps WG is explicitly chartered [3] to produce the DOM4 Core
spec, along with a new version of Element Traversal:
[[
  Element Traversal 2.0
     an extension of Element Traversal 1.0 to provide a nodelist interface
]]

However, I think it makes more sense at this point to simply include
these new attributes in DOM4 Core, along with the indispensable bits of
Element Traversal (that is, everything except the childElementCount,
which is superfluous to childElements.length). I'd like this to also
contain the work that Simon Pieters did on Web DOM Core [4], if he's
willing to have that folded in (I left it out pending word from him...
he's BCCed on this message).

I'm happy to help editing this document, but I would be even happier if
someone else would also step up to serve as co-editor.


[1]
http://www.schepers.cc/w3c/webapps/elementtraversal/tests/et-children.svg (cf.
.html and .xhtml)
[2] http://dev.w3.org/2006/webapi/DOM4Core/DOM4Core.html
[3] http://www.w3.org/2008/webapps/charter/
[4] http://simon.html5.org/specs/web-dom-core

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Simon Pieters-3]

On Mon, 19 Oct 2009 06:56:45 +0200, Doug Schepers <schepers@...> wrote:

> Hi, Folks-
>
> John Resig wrote (on 10/18/09 1:50 PM):
>>>  They already do. Which casts some amount of doubt on Maciejs argument
>>>  that it was too performance heavy to implement in WebKit. :)
>
> Well, it does work in HTML, but not in SVG [1]... which may or may not  
> be desirable, since .children returns an HTMLCollection, and SVG  
> elements are not HTML elements.

That does not matter.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/281

WebKit, Opera and Firefox include the svg element in the collection.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/282

Opera and Firefox has .children on non-HTML elements.

>>>  p.s. It also works in Opera and IE.
>
> Sure, but I mentioned that already. :)  (Note to self... write pithier  
> emails.)
>
>
>> Yeah, .children is already the de facto standard here - implemented in
>> every major browser. It's a real shame that it hasn't (and won't?)
>> make it in to a spec, especially considering that it's already
>> implemented everywhere.
>
> Nothing to stop it from being specified, but I doubt that Internet  
> Explorer will change its behavior, since that will likely break existing  
> Web content (IE team, thoughts?).  I generally agree with Garrett here,  
> so I've followed up on my early promise to specify this by starting the  
> DOM4 Core spec [2], and included 'children' as an HTMLCollection (to  
> satisfy the case that John rightly describes), and 'childElements' as a  
> new ElementCollection (to supply a more progressive interface that  
> authors can rely on predictably).

I don't understand why we should have both .children and .childElements.  
Isn't one attribute enough?

> The WebApps WG is explicitly chartered [3] to produce the DOM4 Core  
> spec, along with a new version of Element Traversal:
> [[
>   Element Traversal 2.0
>      an extension of Element Traversal 1.0 to provide a nodelist  
> interface
> ]]
>
> However, I think it makes more sense at this point to simply include  
> these new attributes in DOM4 Core, along with the indispensable bits of  
> Element Traversal (that is, everything except the childElementCount,  
> which is superfluous to childElements.length). I'd like this to also  
> contain the work that Simon Pieters did on Web DOM Core [4], if he's  
> willing to have that folded in (I left it out pending word from him...  
> he's BCCed on this message).

Certainly.

> I'm happy to help editing this document, but I would be even happier if  
> someone else would also step up to serve as co-editor.
>
>
> [1]  
> http://www.schepers.cc/w3c/webapps/elementtraversal/tests/et-children.svg 
> (cf. .html and .xhtml)
> [2] http://dev.w3.org/2006/webapi/DOM4Core/DOM4Core.html
> [3] http://www.w3.org/2008/webapps/charter/
> [4] http://simon.html5.org/specs/web-dom-core
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs

Cheers,
--
Simon Pieters
Opera Software

[Geoffrey Sneddon-3]

Doug Schepers wrote:
> However, I think it makes more sense at this point to simply include
> these new attributes in DOM4 Core, along with the indispensable bits of
> Element Traversal (that is, everything except the childElementCount,
> which is superfluous to childElements.length).     I'd like this to also
> contain the work that Simon Pieters did on Web DOM Core [4], if he's
> willing to have that folded in (I left it out pending word from him...
> he's BCCed on this message).

I started playing around with Web DOM Core back in the end of August,
mainly from a viewpoint of getting a complete test suite for DOM Core. I
did, however, also edit the spec a bit (mainly just adding one or two
missing exceptions from DOM Level 3 Core). What I did is in the hg repo
at [1].

That said, there are quite a few issues with the spec (both DOM 3 Core
and Web DOM Core) as it stands today from a browser POV:

- There isn't in any sense of an abstract model, and browsers (through
their HTML parsers) can create DOMs that could not be created via the
scripting interface to the DOM (e.g., an <a@b> tag). There is no way to
explain the current DOM behaviour in DOM 3 Core.

- Likewise, from that above point, it seems better to try and sort out
the current mess of the error checking: sometimes it matches what can be
serialized in XML 1.0 Fourth Edition, sometimes it matches some of the
restrictions in XML 1.0 Fourth Edition (but not all!), and sometimes it
doesn't do any error checking. This leads to a state of play in which
the error checking doesn't actually help ensure the DOM can be
serialized as XML, and as such, little is gained by it. It would be nice
to resolve the above issue with element local names such as "a@b" by
just removing error checking. (However, this can't be done blindly as IE
supports weirdness like document.createElement("<div title=magic>") to
create a "div" element with a "title" attribute whose value is "magic".
To prevent this from seeming too sensible, this appears to use a
different HTML tokenizer to the one normally used. In this case, content
relies upon browsers throwing exceptions to work in other UAs!)

- The behaviour of several operations in the DOM needs to depend upon an
HTMLness bit. The current state of play is that HTML 5 redefines certain
operations for HTMLDocument. (However, HTML 5 also states: "All Document
objects (in user agents implementing this specification) must also
implement the HTMLDocument interface, available using binding-specific
methods. (This is the case whether or not the document in question is an
HTML document or indeed whether it contains any HTML elements at all.)
Document objects must also implement the document-level interface of any
other namespaces that the UA supports.").

- Probably quite a few other things I've forgotten off the top of my
head (Simon, can you think of other major things?).

[1]: http://hg.gsnedders.com/web-dom-core/

HTH,

Geoffrey Sneddon — Opera Software
<http://gsnedders.com/>
<http://www.opera.com/>

[Simon Pieters-3]

On Mon, 19 Oct 2009 11:26:15 +0200, Geoffrey Sneddon <gsneddon@...>  
wrote:

> Doug Schepers wrote:
>> However, I think it makes more sense at this point to simply include  
>> these new attributes in DOM4 Core, along with the indispensable bits of  
>> Element Traversal (that is, everything except the childElementCount,  
>> which is superfluous to childElements.length).     I'd like this to  
>> also contain the work that Simon Pieters did on Web DOM Core [4], if  
>> he's willing to have that folded in (I left it out pending word from  
>> him... he's BCCed on this message).
>
> I started playing around with Web DOM Core back in the end of August,  
> mainly from a viewpoint of getting a complete test suite for DOM Core. I  
> did, however, also edit the spec a bit (mainly just adding one or two  
> missing exceptions from DOM Level 3 Core). What I did is in the hg repo  
> at [1].
>
> That said, there are quite a few issues with the spec (both DOM 3 Core  
> and Web DOM Core) as it stands today from a browser POV:
>
> - There isn't in any sense of an abstract model, and browsers (through  
> their HTML parsers) can create DOMs that could not be created via the  
> scripting interface to the DOM (e.g., an <a@b> tag). There is no way to  
> explain the current DOM behaviour in DOM 3 Core.
>
> - Likewise, from that above point, it seems better to try and sort out  
> the current mess of the error checking: sometimes it matches what can be  
> serialized in XML 1.0 Fourth Edition, sometimes it matches some of the  
> restrictions in XML 1.0 Fourth Edition (but not all!), and sometimes it  
> doesn't do any error checking. This leads to a state of play in which  
> the error checking doesn't actually help ensure the DOM can be  
> serialized as XML, and as such, little is gained by it.

Indeed.


> It would be nice to resolve the above issue with element local names  
> such as "a@b" by just removing error checking. (However, this can't be  
> done blindly as IE supports weirdness like document.createElement("<div  
> title=magic>") to create a "div" element with a "title" attribute whose  
> value is "magic". To prevent this from seeming too sensible, this  
> appears to use a different HTML tokenizer to the one normally used. In  
> this case, content relies upon browsers throwing exceptions to work in  
> other UAs!)

I think it would probably be disruptive to change the error checking in  
the DOM at this point.

> - The behaviour of several operations in the DOM needs to depend upon an  
> HTMLness bit. The current state of play is that HTML 5 redefines certain  
> operations for HTMLDocument. (However, HTML 5 also states: "All Document  
> objects (in user agents implementing this specification) must also  
> implement the HTMLDocument interface, available using binding-specific  
> methods. (This is the case whether or not the document in question is an  
> HTML document or indeed whether it contains any HTML elements at all.)  
> Document objects must also implement the document-level interface of any  
> other namespaces that the UA supports.").
>
> - Probably quite a few other things I've forgotten off the top of my  
> head (Simon, can you think of other major things?).

* The "legal hierarchy" checking is wrong and should be revamped and  
probably be part of appendChild/insertBefore/etc.

* At some point, I had hope that we could somehow drop support for Attr  
nodes and related methods, but I think Web compat requires at least some  
of the methods to be supported, so it's probably better to just spec them  
to the extent that browsers have implemented them.


> [1]: http://hg.gsnedders.com/web-dom-core/

--
Simon Pieters
Opera Software

[Laurens Holst-3]

Hi,

I see .children [1] is being discussed, let me pitch in for a little:

.children interoperability is very bad, particularly the
.children.tags() [2] method.

- Firefox 3.0 doesn’t have it,
- Firefox 3.5 implemented children collection but not tags() method
(breaking my code in the process)
- Safari’s tags() method does not function well, I believe it does not
only return direct children but works something like getElementsByTagName()
- Opera’s tags() method does not work in XHTML mode, it returns an array
of undefined.

In my Selectors implementation [3] I was using .children.tags() to
optimise looping over child nodes, if it is available. The lifecycle of
that code’s guard went something like this:

Original guard:

   if (oNode.children)

Found Safari bug:

   if (oNode.children && !browser_webkit)

Firefox 3.5 was released:

   if (oNode.children && oNode.children.tags && !browser_webkit)

Found Opera bug:

   if (oNode.children && oNode.children.tags && !browser_webkit &&
!browser_opera)

Decided this was getting a bit rediculous:

   if (browser_ie)

So, the morale of this story: tread with caution. :)

~Laurens

[1] http://msdn.microsoft.com/en-us/library/ms537446%28VS.85%29.aspx
[2] http://msdn.microsoft.com/en-us/library/ms536776%28VS.85%29.aspx
[3] http://www.grauw.nl/projects/pc/selectors/

--
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com

[Simon Pieters-3]

On Mon, 19 Oct 2009 14:04:16 +0200, Laurens Holst  
<laurens.nospam@...> wrote:

> Hi,
>
> I see .children [1] is being discussed, let me pitch in for a little:
>
> .children interoperability is very bad, particularly the
> .children.tags() [2] method.
>
> - Firefox 3.0 doesn’t have it,
> - Firefox 3.5 implemented children collection but not tags() method
> (breaking my code in the process)
> - Safari’s tags() method does not function well, I believe it does not
> only return direct children but works something like  
> getElementsByTagName()
> - Opera’s tags() method does not work in XHTML mode, it returns an array
> of undefined.

tags() is an HTMLCollection thing, not specific to .children. Maybe we  
should limit tags() to HTMLAllCollection (returned by document.all) like  
Firefox, or maybe Firefox should add it to HTMLCollection.

Have you filed a bugs?


> ...

--
Simon Pieters
Opera Software

[Boris Zbarsky]

On 10/19/09 10:01 AM, Simon Pieters wrote:
> tags() is an HTMLCollection thing, not specific to .children. Maybe we
> should limit tags() to HTMLAllCollection (returned by document.all) like
> Firefox, or maybe Firefox should add it to HTMLCollection.

Note that I strongly support the former, and have gotten feedback from
both Opera and Webkit that they might be on board with it maybe
sometimes if I can convince hixie to change the spec text perhaps.

-Boris

[Laurens Holst-3]

Op 19-10-2009 4:01, Simon Pieters schreef:
> tags() is an HTMLCollection thing, not specific to .children. Maybe we
> should limit tags() to HTMLAllCollection (returned by document.all)
> like Firefox, or maybe Firefox should add it to HTMLCollection.
>
> Have you filed a bugs?

No I didn’t, I felt it wasn’t exactly a standard method anyway and
probably the browser vendors only added it for compatibility with
content that was specifically made for IE… And then the children
collection in particular, probably the tags method is little used and
thus did not receive much or any testing.

If tags() is also on document.all, this perhaps explains the Safari
behaviour of returning more than just direct children.

~Laurens

--
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com

[Ian Hickson]

On Mon, 19 Oct 2009, Boris Zbarsky wrote:
> On 10/19/09 10:01 AM, Simon Pieters wrote:
> > tags() is an HTMLCollection thing, not specific to .children. Maybe we
> > should limit tags() to HTMLAllCollection (returned by document.all)
> > like Firefox, or maybe Firefox should add it to HTMLCollection.
>
> Note that I strongly support the former, and have gotten feedback from
> both Opera and Webkit that they might be on board with it maybe
> sometimes if I can convince hixie to change the spec text perhaps.

I'm happy to change the spec text as soon as the implementations change. :-)

I just don't want to end up in a situation where a feature is implemented
almost everywhere but not in the spec.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Jonas Sicking-2]

On Mon, Oct 19, 2009 at 1:27 PM, Ian Hickson <ian@...> wrote:

> On Mon, 19 Oct 2009, Boris Zbarsky wrote:
>> On 10/19/09 10:01 AM, Simon Pieters wrote:
>> > tags() is an HTMLCollection thing, not specific to .children. Maybe we
>> > should limit tags() to HTMLAllCollection (returned by document.all)
>> > like Firefox, or maybe Firefox should add it to HTMLCollection.
>>
>> Note that I strongly support the former, and have gotten feedback from
>> both Opera and Webkit that they might be on board with it maybe
>> sometimes if I can convince hixie to change the spec text perhaps.
>
> I'm happy to change the spec text as soon as the implementations change. :-)
>
> I just don't want to end up in a situation where a feature is implemented
> almost everywhere but not in the spec.

So does this mean that you'll add back Theora if it's implemented in
Opera, Mozilla and Chrome? ;)

My point is that you're inconsistent here. Previously a feature hasn't
been put in the spec if some vendor says that they won't implement it.
In this case you seem to be doing the opposite, and not remove it from
the spec unless all major vendors agree to remove it.

I sent a formal request to have .tags removed from HTMLCollection to
the whatwg list.

/ Jonas

[Ian Hickson]

On Mon, 19 Oct 2009, Jonas Sicking wrote:

> >
> > I just don't want to end up in a situation where a feature is
> > implemented almost everywhere but not in the spec.
>
> So does this mean that you'll add back Theora if it's implemented in
> Opera, Mozilla and Chrome? ;)
>
> My point is that you're inconsistent here. Previously a feature hasn't
> been put in the spec if some vendor says that they won't implement it.
> In this case you seem to be doing the opposite, and not remove it from
> the spec unless all major vendors agree to remove it.
>
> I sent a formal request to have .tags removed from HTMLCollection to the
> whatwg list.

I think there's a difference between 4 out of 5 and 3 out of 5; and I
think there's a difference between one spec requiring that another spec be
implemented, and one spec including or not including a feature.

If browsers support something, then we want them to do it in an
interoperable way, which means that there needs to be a spec for that
feature. There _is_ a spec for Theora, the question is just whether it
should be implemented or not. With tags(), there is no other spec.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Jonas Sicking-2]

On Mon, Oct 19, 2009 at 4:27 PM, Ian Hickson <ian@...> wrote:

> On Mon, 19 Oct 2009, Jonas Sicking wrote:
>> >
>> > I just don't want to end up in a situation where a feature is
>> > implemented almost everywhere but not in the spec.
>>
>> So does this mean that you'll add back Theora if it's implemented in
>> Opera, Mozilla and Chrome? ;)
>>
>> My point is that you're inconsistent here. Previously a feature hasn't
>> been put in the spec if some vendor says that they won't implement it.
>> In this case you seem to be doing the opposite, and not remove it from
>> the spec unless all major vendors agree to remove it.
>>
>> I sent a formal request to have .tags removed from HTMLCollection to the
>> whatwg list.
>
> I think there's a difference between 4 out of 5 and 3 out of 5; and I
> think there's a difference between one spec requiring that another spec be
> implemented, and one spec including or not including a feature.

So you got an official response from Microsoft saying that they were
not going to implement Theora? What about Vorbis which they are
apparently shipping in other products?

> If browsers support something, then we want them to do it in an
> interoperable way, which means that there needs to be a spec for that
> feature. There _is_ a spec for Theora, the question is just whether it
> should be implemented or not. With tags(), there is no other spec.

I think this is a distinction without a difference. For authors
neither .tags() nor theora can be reliably used on the web, and the
way things are looking right now neither of them will be. Weather
there is some separate document that defines how .tags() works when
it's available doesn't seem to make much of a difference? You end up
with the absurd situation where if microsoft improved their
documentation for .tags() to be precise enough to be considered a
spec, all of a sudden it could be dropped from the HTML5 spec and thus
less likely for developers to be reliably available.

/ Jonas