W3C home > Mailing lists > Public > www-style@w3.org > November 2013

Re: [selectors4] Proposal for extending Selectors Level 4 with possibility to select attributes

From: Simon Pieters <simonp@opera.com>
Date: Wed, 06 Nov 2013 21:28:54 +0100
To: "www-style list" <www-style@w3.org>, "Jirka Kosek" <jirka@kosek.cz>
Message-ID: <op.w549ugmhidj3kv@simons-macbook-pro.local>
On Mon, 04 Nov 2013 13:59:09 +0100, Jirka Kosek <jirka@kosek.cz> wrote:

> Hi,
> please find below proposal for small extension of current Selectors
> together with rationale. I will be at TPAC next week, so I can show up
> on WG meeting in order to explain this proposal and use-case behind it.
> Thanks,
> 					Jirka
> Proposal for extending Selectors Level 4 with possibility to select
> attributes
> ==============================================================================
> Currently selectors are able to select only elements from a document
> tree. However document tree is not consisting only from elements --
> it can contain also attributes and in many markup languages, including
> HTML, attributes are conveying information which is as important as
> information stored inside element content. Selectors are becoming
> universal query language for HTML content (eg. Selectors API, usage in
> JS libraries like jQuery, ...) and should thus allow selection of
> attributes as well.

Can you please provide real examples where people select attributes in JS  
and would benefit from this proposal? Can you demonstrate that people are  
working around the lack of this feature (e.g. JS frameworks that use  
Selectors with an extension like this)?

I understand the ITS use case, but it's not clear to me that ITS is  
something that Selectors should be catering for at this point. I don't  
have anything against ITS per se, but I think it's useful to question if  
it's a need that is relevant for the Web at large or just a niche thing.

> I propose to add new type of simple selector which will allow
> selecting attribute nodes in a document tree.
> Proposed syntax is to use @attribute-name syntax, for example:
> img @alt      -- select alt attributes on images
> * @alt        -- select all title attributes
> The same syntax is used for attributes in XPath and it is quite widely
> understood. Using @ does not produce any problems in Selectors API,
> but it's used in CSS syntax for at-rules. However this is not real
> problem -- in CSS there is no need to select attributes in rules and
> if ever there will be such need we can require to use element selector
> in front of attribute node selectors which will remove potential
> parsing ambiguity.
> Apart from specifying attribute name after @ it should be possible to
> use already existing syntax for dealing with namespaced attribute
> names like @ns|E, @*|E and @|E in order to cover XML input as well.
> Rationale
> ---------
> Apart from general usefulness (which doesn't count itself) there is
> already one existing strong use-case which is not covered by existing
> Selectors spec.
> W3C Recently published new ITS 2.0 Recommendation
> (http://www.w3.org/TR/its20/). This spec defines dozen of special
> attributes which can be used in XML or HTML content to provide
> additional metadata for better localization and translation processing
> of content. For example you can say that some phrase is terminology
> and terminology database should be used when content is translated:
> <p>In 2013 your company should be in <em its-term="yes">Cloud
> computing</em> otherwise it is dead.</p>
> Apart from specifying such properties directly on each occurrence one
> can create global rules in ITS 2.0. In older version of ITS (1.0) such
> rules could use only XPath as query language, so for example in order
> to define that all title attributes should be translated, you can
> create rule saying:
>  <its:rules xmlns:its="http://www.w3.org/2005/11/its">
>     <its:translateRule selector="//*/@title" translate="yes"/>
>  </its:rules>
> One big motivation behind development of new version of ITS 2.0 was
> making it more "Web friendly". This resulted in a direct support for
> HTML content by introducing its-* prefixed attributes because HTML
> syntax doesn't play nicely with namespaced attributes. Second step in
> this direction was possibility to use Selectors as an alternative
> query language to XPath. For many cases Selectors would be just
> enough, but currently they are missing key feature -- ability to
> select attributes in a document tree. With such ability it would be
> possible to rewrite previous rule as:
>  <its:rules xmlns:its="http://www.w3.org/2005/11/its"
>             queryLanguage="css">
>     <its:translateRule selector="@title" translate="yes"/>
>  </its:rules>
> In HTML attributes are still common place for storing content in
> natural language -- apart common examples like @title or various
> attributes on form controls there is plenty of application specific
> data-* attributes. Selectors seems as a default query language for the
> current generation of web developers and other technologies should
> built on top of this common knowledge. I think that such small
> extension of Selectors could prove very useful, implementation will
> be very easy and I don't think it will break any existing content or
> usage.

Simon Pieters
Opera Software
Received on Wednesday, 6 November 2013 20:29:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:36 UTC