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: ~~~~<uri: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. <uri: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] *******************************************************************
