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