Re: ISSUE-41/ACTION-97 decentralized-extensibility

>>> ... namespaces in text/html. ...

I watched the HTML5 intro at http://vimeo.com/6691519

He made it look easy.
<doctype html>
...
<svg>
...
</svg>
...

and that was it. It worked. Why is it so easy?
Because, in his show SVG is treated as 'native' like built in, even 
'standard'  or 'native' or even 'intrinsic' keystrokes, same as 
<table>. As standard stuff, Its authortime context is in the same 
(name) space any other standard text/html markup.
Hopefully since SVG is a 'standard' element in the language, with 
authorable fallback if not supported, its elements and attributes 
should not require any namespace-like keystrokes mixed in the 
text/html. The text/html parser doesn't stop building the DOM just 
because it finds an <svg> element with or without 'namespace' 
characters. Even if it may have <mathml> or <ruby> or even <html> 
containers intermixed in there somewhere, just go forward. In 
text/html, for standard syntax, please just ignore any stuff in front 
of the standardized element and attribute names. If the native 
text/html element needs a name, allow @name.

If <svg> or any other standard markup is included as HTML 5 input, 
then how about if we allow that it is only after the DOM is built that 
the real problems start. Is the SVG 'runtime' that produces the 
graphic from the user code essentially in the main browser thread? If 
there is an 'external' to the main browser thread running, maybe sort 
of like the web workers I am learning about, then how does that 
runtime start and from where does it get its resources? As much as I 
know about it is that it seems to get challenging difficult when more 
than one runtime is using the same DOM.

But, for text/html that includes <svg> running in an HTML 5 browser 
why does the author need to know or care? All that is somebody else's 
problem not needing the author's considerations. Even if there are 
name collisions between names in the different native HTML 5 
containers then the text/html browsers will just have to handle it by 
being smart enough to make a guess to figure the runtime context by 
the element's location in the document. Likewise, for the text/html 
web author, minor details like camelcase and such shouldn't bother.
For sure, in the case of 'standard' element and attribute names in the 
<svg> family, in text/html, please just overlook any prefixes or 
whatever what may be found as namespace-like keystrokes as prefixes to 
the actual specified HTML 5 names. For native elements and attributes 
in text/html, all that stuff is meaningless and potential entry 
problems and the author should be encouraged to remove as the browser 
will (try?) to ignore them anyway for simpicity. If elements are 
nested wrong in text/html, all the UA has to do is the best it can. 
Sooner of later code pasters have to learn something about hierarchy 
and relatively simple and easy to use tools inside and outside the 
current batch of great W3C HTML 5 browsers can help a lot.

Of course this is like saying that using the HTML text/html 
implementation is like pre-xml training wheels and it is not really 
extensible. I think wrong because text/html remains extensible via 
<object> and others.
Just that the only markup for text/html is in or referenced directly 
from the current HTML spec. And, there is a complete spec so you can 
easily know for sure what is conforming or not. Finally, it is the 
spec intent that the text/html browser presses on as far as it can for 
'native' or even maybe unkinown input regardless of some minor 
problems. Like the top text/html browsers generally work now.

If people or machines really want to be sure we are getting it more 
right and reliable in a more complex and highly structured yet less 
restricted and proven extensible environment, then the author goes to 
XHTML concepts and uses the application/xhtml+xml implementation. The 
mostly simple facts of namespaces are learned, hopefully leveraging 
any information about 'context' and 'name' from work with the 
text/html type and from reading the spec. For XHTML, the parser has 
more tools and the brwoser has a bit more depth to help us get it 
right if we need to achieve the really clever while also being more 
transportable.

The important things are that the spec and related validation tools 
are correct and complete for text/html. Then the added requirements 
for application/xhtml+xml can be clearly stated.
For text/html, as far as the author is concerned, I was hoping the 
default 'namespace' for all 'standardized' or 'native' elements and 
attributes defined by the spec is, from authoring perspective, the 
same. Maybe with a couple of semantic exceptions?

Thank You and Best Regards,
Joe


----- Original Message ----- 
From: "Jonas Sicking" <jonas@sicking.cc>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "Sam Ruby" <rubys@intertwingly.net>; "Adrian Bateman"
<adrianba@microsoft.com>; "HTML WG" <public-html@w3.org>; "Tony Ross"
<tross@microsoft.com>; "Brendan Eich" <brendan@mozilla.org>
Sent: Friday, October 02, 2009 11:33 PM
Subject: Re: ISSUE-41/ACTION-97 decentralized-extensibility


> On Fri, Oct 2, 2009 at 6:07 PM, Maciej Stachowiak <mjs@apple.com>
> wrote:
>
>>
>> On Oct 2, 2009, at 5:33 PM, Sam Ruby wrote:
>>
>> I can also name representatives of browser implementors other than
>>> Microsoft which have expressed support for a mechanism similar to
>>> XML
>>> namespaces in text/html.
>>>
>>> For now, I will simply name one: Brendan Eich.
>>>
>>>
>>> http://weblogs.mozillazine.org/roadmap/archives/2007/03/the_open_web_and_its_adversari.html
>>>
>>> "Consider just the open standards that make up the major web
>>> content
>>> languages: HTML, CSS, DOM, JS ... the Web is alive precisely
>>> because of the
>>> distributed extensibility of its content languages".  Shortly
>>> after I wrote
>>> it, I specifically discussed with Brendan my previous proposal[1]
>>> which
>>> shares a number of similarities with MS's current proposal, and he
>>> indicated
>>> (to be fair: at the time) that he was in support of the general
>>> approach,
>>> though clearly there were a lot of details to work out.
>>>
>>> I've added him to the copy list to see if he wishes to comment
>>> further.
>>>
>>
> Given that Brendan says that "The web *is* alive preciesly because
> of the
> distributed extensibility", at a time when HTML did not have
> anything
> similar  XML Namespaces support, I would not share Sams
> interpretation.
> Especially when he's mentioning Greasemonkey in the same context,
> which is a
> wholly different type of extensibility.
>
>
>>  If Mozilla expresses interest in implementing some form of
>> namespaces in
>> HTML, then that would certainly change the picture. For now, I put
>> more
>> weight on recent clear statements from Jonas and Henri, than an
>> ambiguous
>> remark in a 2.5-year-old blog post from Brendan (to be fair, none
>> of the
>> three of them claimed to be speaking officially for Mozilla). In
>> context, it
>> does not look to me like Brendan was using "distributed
>> extensibility" as a
>> code word for "XML-like namespaces". But Brendan can speak for
>> himself.
>>
>
> There is no such thing as someone speaking officially for Mozilla on
> this
> type of matters. (I made that mistake once and quickly turned out
> there was
> people of dissenting opinions). We work as a community and anyone
> that's
> part of that community is allowed to have an different opinion.
>
> What I can say is that I know of several people that think that XML
> Namespaces are needlessly complex, and none that like them. However
> that's
> not to say that that is the opinion of everyone in the mozilla
> community.
>
> / Jonas
>

Received on Sunday, 4 October 2009 01:04:11 UTC