Re: Decentralised extensibility idea (ISSUE-41)

Several replies in one...

----

Leif Halvard Silli wrote:
> So how would you indicate where the rel value comes from? Like 
> this: <link profile="URI" rel="value" href="somewhere" >

You can't indicate where the rel value comes from -- nor where classes
and data-* attributes come from.

Consider the HTML+RDFa and Microdata specifications. These are
extensions to HTML. If a parser understands, say, Microdata, then when
it comes across @itemprop it knows that the Microdata specification
defines that attribute. If the parser does not understand Microdata, it
doesn't know where that attribute comes from, so will not do anything in
particular with it.

In general, the solution is not designed to provide "backtracing" -
finding out which otherspec something came from, but instead just allows
user agents that support an otherspec to know which pages (or parts of
pages) use the otherspec.

> Indeed a special case. But how would <html profile="URI"> and <head 
> profile="URI"> differ? Remember, also, that HTML5, unlike HTML4, allows 
> @class and @id even on <html>, <head> and <title> - even on <meta>.

It is perhaps an annoyance for people who want to apply a profile just
to <head>.

> But thanks to HTML5's freedom w.r.t. where @id/@class might appear, 
> then a perhaps more - as you said - "HTML-ish" (not to say 
> "Twitter-ish") option would be this:
> 
> <head >
> <link id=CarML rel=profile href=http://example.com/CarML/html5 >
> </head>
> <span profile="#CarML" class="Car">Mazda</span>

I don't think adding an extra level of indirection would be especially
helpful. If it's supposed to prevent repetition, then perhaps my
original message wasn't clear enough.

 <html profile="http://example.com/CarML/html5">

would automatically license class="Car" and associated data-* attributes
to have their CarML meaning everywhere in the document. So repetition of
the profile is rarely needed.

> Note that if a <link> points to a DE profile, then it will not have any 
> descendant elements - so linking to it like this, seems fitting. :-) 
> Also note that @profile - at least <head@profile> - can link to several 
> URIs, so <link@rel="profile"> seems better than @profile for that 
> reason, for this idea.

It's certainly my intention that @profile would continue to contain a
space-separated list.

> And so, to apply two DE profiles simultaneously, then perhaps this: ?
> 
> <head >
> <link id=CarML rel=profile href=http://example.com/CarML/html5 >
> <link id=MyML  rel=profile href="http://example.com/MyML/html5 >
> </head>
> <span profile="#CarML #MyML" class="Car" >Mazda</span>
> 
> I think  - when necessary - to separate "Car" from CarML and "Car" from 
> MyML, there should be some prefix option. I don't know, but perhaps 
> simply like this: ?
> 
> <div class="Japanese" profile="#CarML" >
> <div class="Favorite" profile="#MyML" >
> <span class="Car#CarmML" data-colour="blue#MyML" >Mazda</span>
> </div></div>
> 
> Or do you see another option?

There are three situations you could be in when attempting to mix
otherspecs:

1. One otherspec defines class="Car" and the second otherspec doesn't
define any meaning for class="Car" at all. In this case, user agents
implementing the first otherspec will understand it and user agents
implementing the second will ignore it. No problem.

2. Both otherspecs define class="Car" in such a way that (for your own
use case at least) they are equivalent. In which case:

<html profile="http://example.com/CarML/html5
http://example.com/MyML/html5">
  ... <span class="Car">Mazda</span> ...
</html>

Should just work in both otherspecs. No problem.

3. Both otherspecs define class="Car", but with conflicting
interpretations. In this case, it is impossible to apply both otherspecs
to the same HTML node. This does cause a problem: scoping the profile
attribute can usually help here, but at other times, you'll just have to
drop compliance with one of the otherspecs.

----

Philip Jägenstedt wrote:

> Overloading the class attribute (like microformats) isn't a very
> good idea, it *will* clash with existing markup.

The proposal is in fact a superset of the mechanisms microformats
already use.

I agree that microformats do clash with existing class names. This is a
problem. The profile mechanism aims at avoiding clashes. Officially
speaking, microformats use profiles, but in the wild, they don't. This
is because the profile attribute in HTML 4.x is problematic: there is
confusion as to whether it takes a single URI or multiple URIs; and it
being stuck in the <head> can make it difficult to use in CMSes and
various other tools. By freeing the profile attribute from the head and
allowing it to be specified closer to where the markup is actually used,
it becomes more copy-and-pastable.

> I don't think this is a very good idea, as data-* are always hidden
> and not suitable for marking up content that is visible in the page.

You are mistaking my proposal for a method of embedding data into a
document. The proposal is not intended for embedding the kind of data
that Microdata or RDFa embed; rather it's a general purpose extension
point that other standards ("otherspecs") could use.

Which other standards? It could be used as an alternative to namespaces,
as the recommended way method of embedding things like SVG or MathML
into HTML, were it not for the fact that using namespaces for this is
quite solidly established. As far as I know, neither Microdata nor RDFa
has positioned itself as a way of doing this.

Here are some use cases, where currently XML-style namespaces, or
proprietary extensions to HTML might be used, that might instead be
solved using my proposal:

 * a WYSIWYG editor wishes to use a special attribute to note
   that certain parts of a document should be skipped by the 
   spell check function. Rather than adding a proprietary
   attribute or using namespaces, they'd just add something
   like data-spellcheck="skip" to those elements, with a
   profile attribute allowing that particular data-*
   attribute to have a globally-defined meaning.

 * A phone company introduces a revolutionary new multi-head
   browser, designed for use on dual-screen phones. Pages are
   generally viewed on the primary screen, but the documents
   can specify certain sections which are intended for the
   second screen. Rather than introduce a proprietary element,
   they suggest a class+profile combination to indicate which
   element(s) go on the second screen.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Friday, 15 January 2010 16:14:21 UTC