ITS 2.0, Selectors 4 and Selectors API 2

ITS 2.0 (the Internationalization Tag Set  2.0) [1] is a specification
attaching l10n/i18n properties to elements and attributes of a document
tree through two means:

   1. locally, using attributes in the ITS namespace

   2. globally, using rules expressed in XML in the ITS namespace and
      based on a selecting mechanism (XPath, CSS, ...)

Here are two examples of the above:

locally:

     <span xmlns:its="http://www.w3.org/2005/11/its"
           its:translate="no">NASA</span>

globally:

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

In the global case, the selecting language of the rule can be chosen
through the @queryLanguage attribute on the rules element. CSS
Selectors are explicitely listed [2] as a valid selecting mechanism and
it would be really nice to see CSS used there. Unfortunately, Selectors
[3] and its Selectors API [4] companion have two problems that are more
or less blockers for Selectors inside ITS 2.0:

a. it's not possible, even in Selectors API 2 [5], to resolve arbitrary
    namespaces in querySelectorAll()

b. Selectors cannot target attributes

In the case of querySelectorAll(), we clearly need to extend Selectors
API to allow namespaces. We had little use cases in the past but that's
not true any more. And it's totally false to say we need this for html
only. A spec like ITS 2.0 will be in most cases not implemented natively
but above abstractions like document.evaluate() or querySelectorAll().
We clearly need namespace resolvers like [6] in Selectors API.

In the case of attributes not reachable through Selectors, we may have
almost everything we need in Selectors level 4 to provide a user like
ITS 2.0 with a solution: the subject indicator [7] could be easily
extended the following way:

   1. only one subject indicator is allowed per 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]

   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.

The above would allow to express any ITS rule not only using Selectors
but also in the future in a CSS-alike syntax. Then instead of:

      <rules xmlns="http://www.w3.org/2005/11/its"
             version="2.0"
             queryLanguage="css">
        <translateRule selector="html|acronym![title]"
                       translate="css"
                       xmlns:html="http://www.w3.org/1999/xhtml"/>
      </rules>

we could have the readability of:

      @namespace html url("http://www.w3.org/1999/xhtml");
      html|acronym![title] { its-translate: no; }

and have it merged with CSS, use the power of the cascade, etc instead
of having to rely on... ahem... XPath. We could solve two problems of
ours at the same time: *finally* extend Selectors to attribute nodes
and fix that painful hole of Selectors API not working with namespaces.

[1] http://www.w3.org/TR/its20/
[2] http://www.w3.org/TR/its20/#css-selectors
[3] http://www.w3.org/TR/2011/REC-css3-selectors-20110929/
[4] http://www.w3.org/TR/2013/REC-selectors-api-20130221/
[5] http://www.w3.org/TR/selectors-api2/
[6] http://is.gd/HVrWM5
[7] http://dev.w3.org/csswg/selectors4/#subject

</Daniel>

Received on Tuesday, 2 July 2013 00:54:09 UTC