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 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 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. Selectors can indeed augment the tree. Absolutely not, and that's precisely why we called pseudo-elements "pseudo". But that's another discussion I'm not necessarily against the concept of selecting attributes; I'm arguing against your attempted abuse of syntax. ^_^ I don't think it's an abuse at all. But I see your point better now. I still think we need to extend Selectors to attribute selection and Selectors API to namespace resolution.
Re: ITS 2.0, Selectors 4 and Selectors API 2
On Mon, Jul 1, 2013 at 11:53 PM, Daniel Glazman wrote: > On 02/07/13 04:46, Tab Atkins Jr. wrote: >> That's already the case - the subject indicator has to precede the >> compound selector. > > Tab, I know, *I* designed the subject indicator *exactly* the way it > is in the spec back in *1997* in a language called STTS and an > application implementing it... > > I meant !foo![attr] is forbidden. Yes, I was just saying that that is already forbidden. >> 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. > > Unacceptable to you. And pseudo-elements can be selected by CSS without > having any existence as Nodes in the document tree... Pseudo-elements do exist in the document tree as far as layout is concerned. Selectors can indeed augment the tree. > ![foo] refers to an element *for the time being* in a Draft. "A > Standard is not a Standard before it's published as a Standard". And > Selectors are a selecting mechanism, the CSS case being one particular > case only. ITS proves Selectors are used outside of the CSS world. No, "[foo]" refers to an element, period, in Selectors all the way back to 2.1 or earlier, and "[foo]" and "*[foo]" match exactly the same elements. The subject indicator doesn't change the meaning of anything, just which element is finally selected. Thus, "![foo]" matches the same thing as "!*[foo]". (And "*![foo]" is illegal, but even if we allowed it for some reason, it would still be the same as "!*[foo]".) > The question is the following one: do we want Selectors to become a more > generic mechanism approaching, and possibly eventually replacing, the > power of XPath? If I look at all the additions to Selectors lev4, the > answer is obviously yes. And if you ask me, yes, we should make CSS > a selecting mechanism widely usable in full replacement of XPath. > FWIW, please see the section on STTS in Håkon's thesis and its ACK > section. I'm not saying we shouldn't. Just that you shouldn't do it by smuggling in the functionality via two unrelated things. You should introduce something that actually selects an attribute. (Though, some of the things that XPath does don't agree well with Selector's data model, and vice versa. Achieving a full superset would be rather difficult.) >> I am strongly against Selectors returning different results when used >> in CSS versus qSA/find. > > I never said that. I said a p![foo] would select an attribute in both > querySelectorAll() and CSS, but it would not trigger any style in CSS. > We already have similar mechanisms in CSS, with restricted sets of > properties applicable to pseudo-elements. I'm not necessarily against the concept of selecting attributes; I'm arguing against your attempted abuse of syntax. ^_^ ~TJ
Re: ITS 2.0, Selectors 4 and Selectors API 2
On 02/07/13 04:46, Tab Atkins Jr. wrote: That's already the case - the subject indicator has to precede the compound selector. Tab, I know, *I* designed the subject indicator *exactly* the way it is in the spec back in *1997* in a language called STTS and an application implementing it... I meant !foo![attr] is forbidden. 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. Unacceptable to you. And pseudo-elements can be selected by CSS without having any existence as Nodes in the document tree... ![foo] refers to an element *for the time being* in a Draft. "A Standard is not a Standard before it's published as a Standard". And Selectors are a selecting mechanism, the CSS case being one particular case only. ITS proves Selectors are used outside of the CSS world. The question is the following one: do we want Selectors to become a more generic mechanism approaching, and possibly eventually replacing, the power of XPath? If I look at all the additions to Selectors lev4, the answer is obviously yes. And if you ask me, yes, we should make CSS a selecting mechanism widely usable in full replacement of XPath. FWIW, please see the section on STTS in Håkon's thesis and its ACK section. I am strongly against Selectors returning different results when used in CSS versus qSA/find. I never said that. I said a p![foo] would select an attribute in both querySelectorAll() and CSS, but it would not trigger any style in CSS. We already have similar mechanisms in CSS, with restricted sets of properties applicable to pseudo-elements. 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. That would be a new char or ident or whatever serving exactly the purpose of !... But why not. I want the feature, and I'm not focused on !. The meta-question still stands: how do we serve better W3C specifications like ITS 2.0? On 02/07/13 05:26, Liam R E Quin wrote: 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. Exactly.
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
Re: ITS 2.0, Selectors 4 and Selectors API 2
On Mon, Jul 1, 2013 at 5:53 PM, Daniel Glazman 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 02/07/13 02:53, Daniel Glazman wrote: http://www.w3.org/2005/11/its"; version="2.0" queryLanguage="css"> http://www.w3.org/1999/xhtml"/> Sorry, the above is obviously wrong, please read http://www.w3.org/2005/11/its"; version="2.0" queryLanguage="xpath"> http://www.w3.org/1999/xhtml"/> instead. Thanks.
