Webmaster Forum / HTML, CSS, Scripts / HTML / October 2008

Stefan Ram wrote (in "More than one language in a page"):

Is this a new trend of user-agent writers (Microformats, and now Google)
staking claims on the @class namespace?  I'm surely not the only one
disturbed by this.  Somehow, an author publishing on the web, with no
control over which user agents will access his page, has to avoid
clashes with the union of all names deemed special by all those user
agents, now and in the future?

I suppose the proponents justify this practice by a line in the HTML
spec (HTML4.01 §7.5.2), that class names are also for "general purpose
processing by user agents" as well as stylesheet selectors.  It doesn't
go into any further detail, but I don't think it was the intention that
applications which the author has no control over (e.g. once a page is
published) should define class names willy-nilly.  More likely, the
author would have opted in to some scheme, such as a company's internal
robot to do some advanced indexing on all its own pages.

Here are some ideas for external interpretation, i.e. by some 'third
party' such as Google:

   * Opt in to a third party's scheme.  Register ones URIs with Google,
     so they know that 'notranslate' means what they think on those
     pages.  I don't fancy doing that with a lot of third parties, though.
   * Third parties register class names with an authority (e.g. W3C).
     But still, authors have to watch out for future uses of names.
     And third parties shouldn't have to register with W3C when they've
     already registered (for example) DNS names.
   * Define a sub-namespace not used by CSS to form DNS-like names,
     e.g. ':com:google:notranslate'.  Okay, but potentially verbose if
     used a lot.  And it doesn't generally sidestep non-CSS mechanisms
     of defining class names.
   * Use head/@profile with a URI owned by the third party.  This is
     what Microformats seem to be doing, but I don't think it is
     adequate.  Independent microformats used in the same page still
     have to avoid clashing with each other, which means going back to
     some authority's third-party register.  Plus, the author doesn't
     have control over the class names - it's all or nothing for a
     particular format.
   * Extend CSS with properties not related to style.  There's nothing
     in the framework of CSS that limits it to just style (right?).  I
     favour this, and shall elaborate on it...

Google could define a CSS property which turns translation on or off,
and the author could associate any class he chooses (indeed, any CSS
selector) with that property:

.notranslate { // Okay, so he chose the same one after all!  ;-)
 -google-translation: disable;
}

Then, to avoid Google having to scan his stylesheets just to find this
rule, the author links it in with:

<link rel="stylesheet" media="translator" href="...">

Other user agents won't touch it, because they don't recognise
"translator".  Google won't touch other stylesheets because they're not
labelled with "translator".

A few issues raised by this approach are:

   * It's not style/presentation, which is what CSS was designed for.
     But I think this is a superficial problem - just regard the name
     "CSS" and rel="stylesheet" as historical accidents, and CSS
     becomes an application of arbitrary properties, that happens to
     include ones related to style.
   * It's now invading the CSS-property and media-type namespaces.  But
     both of these could go the same way as XML namespaces and
     link/@rel schemas, if necessary.

To summarise: Rather than user agents stomping over the heretofore
author-defined namespace of class names, they should fit into it in the
same way that CSS properties do.  This would scale better, and would be
less intrusive on the author's ability to choose.