Re: ZIP-based packages and URI references into them ODF proposal

On Tue, 30 Dec 2008, Julian Reschke wrote:
> Ian Hickson wrote:
> > On Tue, 30 Dec 2008, Julian Reschke wrote:
> > > Ian Hickson wrote:
> > > > On Tue, 30 Dec 2008, Julian Reschke wrote:
> > > > > Does the spec specify how to parse or serialize a future element
> > > > > called
> > > > > "foobar"?
> > > > Yes.
> > > OK, where, specifically, is the serialization defined?
> > 
> > It's not allowed.
> 
> Wow, great.
> 
> So I conclude that HTML5 does not address extensibility at all. I think 
> it should.

HTML5 does not provide for a way for groups other than the working group 
to invent new elements, yes. Historically, such attempts have proved 
somewhat disastrous -- <marquee>, <blink>, <spacer>, etc. In fact I am 
hard-pressed to come up with any good example of an extension in the 
element space that was benficial to the Web and wasn't developed by a 
working group.

HTML5, however, does address extensibility. There are actually quite a 
number of ways for people to invent their own extensions to HTML:

* Authors can use the class attribute to extend elements, effectively 
creating their own elements, while using the most applicable existing 
"real" HTML element, so that browsers and other tools that don't know of 
the extension can still support it somewhat well. This is the tack used by 
Microformats, for example.

* Authors can include data for scripts to process using the data-*="" 
attributes. These are guaranteed to never be touched by browsers, and 
allow scripts to include data on HTML elements that scripts can then look 
for and process.

* Authors can use the <meta name="" content=""> mechanism to include 
page-wide metadata. Names should be registered on the wiki's 
MetaExtensions page.

* Authors can use the rel="" mechanism to annotate links with specific 
meanings. This is also used by Microformats. Names should be registered on 
the wiki's RelExtensions page.

* Authors can embed raw data using the <script type=""> mechanism with a 
custom type, for further handling by a script.

* Authors can create plugins and invoke them using the <embed> element. 
This is how Flash works.

* Authors can propose new elements and attributes to the working group 
and, if the wider community agrees that they are worth the effort, they 
are added to the language. (If an addition is urgent, please let us know 
when proposing it, and we will try to address it quickly.)

There is currently no mechanism for including non-visible proprietary 
metadata intended for use by user agents in HTML documents (i.e. for 
introducing new elements and attributes) without discussing the extension 
with user agent vendors and the wider Web community. This is intentional; 
we don't want user agents inventing their own proprietary elements and 
attributes like in the "bad old days" without working with interested 
parties to make sure their feature is well designed.


> > I thought I had tried to reduce repetition. Could you show the text 
> > you would use? If it is better, I should use it in HTML5 for 
> > equivalent passages.
> 
> I would just state what the two allowed values are, and what they 
> indicate. Stating "if ... is present..." is (IMHO) unneeded; it it's not 
> present, it won't have one of the values by definition.

Could you show the actual text you'd use? I don't understand what you are 
proposing.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 31 December 2008 01:07:53 UTC