On 16/08/07, Keryx Web <[EMAIL PROTECTED]> wrote:
> CSS considers only element nodes to be children or siblings. The DOM
> does not.
Actually, selectors considers ONLY elements, never text nodes or
entity references (or comments, or PIs, or CDATA blocks or whatever).
Selectors work on the element tree only, the DOM works on the node
tree.
> This is a pedagogic discrepancy understandable to people used in
> traversing the DOM who are frustrated that MSIE is "natural" with
> nextSibling and that the rest are according to spec.[1] Something that
> has led to the Element Traversal Specification[2] and a lot of userland
> convenience functions[3].
Well, the DOM has drastically different uses than selectors have -
selectors are used to layout containing boxes and style them and their
contents - in other words selectors only need to deal with the
containing boxes, never the actual content. But the DOM needs to be
able to manipulate the full node tree for many reasons - it needs to
be able to deal with the full content, to be able to place elements
and text nodes in correct order as content, not as containing boxes.
> As for the DOM the spec actually makes sense, even if whitespace-only
> text nodes can be ignored 99% of the time. Compare the following:
Actually, for specific applications such as HTML, the program building
a DOM is not agnostic about content models. So, in other words for
HTML leaving whitespace out from element content should not be problem
for MOST content models. There are exceptions though: Elements with
both inline and block content models. So in order to both make sense
and be internally consistent, having whitespace text nodes is probably
better than only being able to throw them out in some cases.
> In CSS 3 there will be new selectors, and I wonder if it would not be
> useful to clearly specify when whitespace is indeed ignorable and when
> it is of real use.
I'd say the Selectors spec makes it pretty clear what it means. Let me
give you an example:
http://www.w3.org/TR/css3-selectors/#only-child-pseudo>
:only-child pseudo-class
Represents an element that has a parent element and whose parent
element has no other element children. Same as :first-child:last-child
or :nth-child(1):nth-last-child(1), but with a lower specificity.
The spec clearly states "no element children", which means non-element
children are not included.
> When I run this in FFox 2.0 I get three pink background a-elements and
> the forth is light blue. One could reasonably argue that it should be
> the other way around. But it is according to the spec[4]:
> The only-child pseudoclass "Represents an element that has a parent
> element and whose parent element has no other *element* children. Same
> as :first-child:last-child or :nth-child(1):nth-last-child(1), but with
> a lower specificity." (emphasis added)
>
> Ergo: The second and third a-elements are not an only child from the DOM
> point of view, but they are from an CSS POV.
They are from a *Selectors* point of view. As stated, selectors work
on the element tree and not the node tree. As you surely know, the
WebAPI WG have been making a DOM API for Selectors.
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?content-type=text/html;%20charset=utf-8>
--
David "liorean" Andersson
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
