W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Re: @role etc Re: Proposal for Keyboard Shortcuts for HTML5

From: Sander Tekelenburg <st@isoc.nl>
Date: Wed, 26 Sep 2007 07:22:27 +0200
Message-Id: <p0624063ac31f89652025@[]>
To: public-html@w3.org

At 04:27 +0200 UTC, on 2007-09-24, Charles McCathieNevile wrote:

> it seems we are moving towards consensus here...

Yay ;)


> On Sun, 23 Sep 2007 19:30:13 +0200, Sander Tekelenburg <st@isoc.nl> wrote:


> There are, as you have noted elsewhere, other existing constructs that do
> some of the same things. @rel is implemented (in extensions of natively)
> in most browsers, so there is a single way in a given browser to activate
> all "next", "index", etc links that have a defined @rel.

Indeed. Although I believe currently the only UA that makes these easily
discoverable by *default* is iCab. And that's still only for <link>. Does any
UA do anything at all with <a rel=>?

> There is also an extensibility mechanism in HTML 4 based on the profile
> attribute. It isn't very clearly specified in HTML 4 how this should
> actually work.

Yeah. I was looking at that recently and found it difficult to visualize how
it is intended to work. A problem is that the format of profiles is not
defined. So every profile might well be in a different format, which wouldn't
exactly make things easier for authors (nor for UA developers, I suppose).

(Perhaps such problems are inherent to extensibility though... I suppose
namespaces are basically the same. Still, namespaces seems like a generally
easier to use approach than profiles.)


> The major problem people have with @role is that its current flavour uses
> namespaces for the attribute (it is iportant that it work in SVG (and
> potentially other XML languages) and that the values themselves use
> namespaces (to allow for decentralised extensibility).

Right. But what exactly is the argument against namespaces in HTML?


> ARIA as currently specified[1] relies on namespaces. For text/html we need
> to remove those from the attribute name somehow (or convnce us browser
> venors to implement namespaces again in HTML, and having been there we
> think that is a bad idea in general). But the use of namespaces for the
> value of the attribute is also seen as problematic - it complicates
> programming and use.

How exactly are namespaces problematic? (And how are they more problematic as
attribute values?)


> Some people hate namespaces, some think they are a relatively good
> approach to solving the name clash problem that extensibility potentially
> brings. The question is really "where is the sweet spot between simplicity
> and power that leads to the widest interoperable usage"?

Some combination of predefined values and extensibility?

For example, returning to @rel: iCab indicates recognised values through
icons, but accepts and presents other values as well. Although allowing
authors to use just any @rel value wasn't the intent of the HTML 4 spec
(which refers to @profile for such extension), this is an implementation that
suggests that there may be realistic possibilities in that direction. (Simple
test case/demo at <http://santek.no-ip.org/~st/tests/rel/>.)

Simply allowing any value would probably be too simplistic. At the very least
it would result in never being able to add new predefined values, because
those by then may well conflict with existing content. But, assuming
namespaces would make it into HTML, the spec could perhaps define a reserved
namespace, specifically for non-defined values.

Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
Received on Wednesday, 26 September 2007 05:24:46 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:22 UTC