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

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

From: Jirka Kosek <jirka@kosek.cz>
Date: Mon, 04 Nov 2013 13:59:09 +0100
Message-ID: <52779A1D.2030709@kosek.cz>
To: www-style list <www-style@w3.org>

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.



Proposal for extending Selectors Level 4 with possibility to select

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.

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.


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"/>

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"
    <its:translateRule selector="@title" translate="yes"/>

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

  Jirka Kosek      e-mail: jirka@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 conference    http://xmlprague.cz

Received on Monday, 4 November 2013 12:59:40 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:34 UTC