Re: ITS 2.0, Selectors 4 and Selectors API 2
On 2.7.2013 2:53, Daniel Glazman wrote: a. it's not possible, even in Selectors API 2 [5], to resolve arbitrary namespaces in querySelectorAll() In general this might be problem, but for ITS I don't see this as a problem. People who use ITS with non-HTML content (various flavours of XML) will use XPath as a query language. Selectors will be likely used only in combination with HTML content where you don't need namespaces (of course, unless you want to target specific elements inside embedded SVG/MathML). b. Selectors cannot target attributes Indeed, this is very serious limitation of CSS selectors and we even discussed removing CSS selectors completely from ITS because of this. But at the end prevailing opinion was that CSS selectors will be useful for scenarios where there is no need to care about attributes. But without ability so select attributes some users will be forced to switch to XPath instead of CSS selectors. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz -- signature.asc Description: OpenPGP digital signature
Re: ITS 2.0, Selectors 4 and Selectors API 2
On Tue, Jul 2, 2013 at 12:57 AM, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: On 02/07/13 09:16, Tab Atkins Jr. wrote: Pseudo-elements do exist in the document tree as far as layout is concerned. No, they do not. They don't create new nodes (yet), even shadow nodes, they can't be serialized. They belong to the layout tree, NOT the document tree. As I said in the section you quoted, *as far as layout is concerned*, pseudo-elements exist. I didn't say anything about creating DOM, affecting stringification, etc. ~TJ
Re: ITS 2.0, Selectors 4 and Selectors API 2
On 02/07/13 02:53, Daniel Glazman wrote: rules xmlns=http://www.w3.org/2005/11/its; version=2.0 queryLanguage=css translateRule selector=//html:acronym translate=xpath xmlns:html=http://www.w3.org/1999/xhtml/ /rules Sorry, the above is obviously wrong, please read rules xmlns=http://www.w3.org/2005/11/its; version=2.0 queryLanguage=xpath translateRule selector=//html:acronym translate=no xmlns:html=http://www.w3.org/1999/xhtml/ /rules instead. Thanks. /Daniel
Re: ITS 2.0, Selectors 4 and Selectors API 2
On Mon, Jul 1, 2013 at 5:53 PM, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: 1. only one subject indicator is allowed per compound selector That's already the case - the subject indicator has to precede the compound selector. 2. the subject indicator can precede a universal selector (potentially omitted), a type element selector or an attribute selector. In the case of an attribute selector, the selector represents then the attribute node matching the condition expressed by the attribute selector. Note: all @foo attributes of the document is not ![foo] - that means !*[foo] - but *![foo] This is unacceptable for Selectors applied against HTML in general. Attributes are *not* nodes, either in HTML or XML, and ![foo] refers to an element. Against an arbitrary document language where attributes are translated into a tree in a different manner, it would work. 3. both Selectors and Selectors API should allow such attribute matching, but CSS rules with such attribute matching would of course not trigger any style resolution. querySelectorAll() and friends should be extended to return attribute nodes. The case of a group of selectors where one of the selectors uses a subject indicator to match attributes has to be discussed but I think it's doable. I am strongly against Selectors returning different results when used in CSS versus qSA/find. If you want Selectors to be able to select attribute nodes, address it directly with a new selector. This should not be smuggled in via the subject indicator. ~TJ
Re: ITS 2.0, Selectors 4 and Selectors API 2
On Mon, 2013-07-01 at 19:46 -0700, Tab Atkins Jr. wrote: [...] If you want Selectors to be able to select attribute nodes, address it directly with a new selector. This should not be smuggled in via the subject indicator. Maybe it would be simpler to support an XPath() selector? When you start using ITS you'll find other cases that get difficult with existing CSS selectors, e.g. . partShortDescription elements whose id attribute value appears in the list of id attributes in the includes attribute of a partsDiagram element in the same section, and where that diagram has a language=only attribute on the replacementCopies element, and the diagram issue year is earlier than 1996. This sort of thing is fairly frequently written with XPath selectors today, and is a plausible use case (e.g. the older exploded parts diagram is only available in spanish, includes Spanish labels for the parts that readers will have to match up to a table of part numbers, so they need the same text in the diagram and in the table). A rigorous comparison of XPath with CSS selectors would be worth doing; piecemeal attempts to duplicate functionality don't seem worthwhile to me. On the other hand I do agree that it sounds like some limitation in CSS selector namespace handling could be alleviated. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
