- From: Sander Tekelenburg <st@isoc.nl>
- Date: Wed, 26 Sep 2007 07:22:27 +0200
- 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