Re: Distributed Extensibility

Sam Ruby wrote:
>> On Aug 2, 2007, at 18:16, Sam Ruby wrote:
>>
>>> FBML isn’t intended to be directly processed by browsers, but that 
>>> shouldn’t preclude it from being processed by other HTML5 tools, 
>>> everything from sanitizers to conformance checkers to pretty 
>>> printers, to search engines.
> ...
> While we should encourage extensions, we should recognize that users 
> will screw things up.  While I can't conceive of anything that would 
> validate the PHP script I referenced above, I can imagine conformance 
> checkers that validated the output.  Conformance checkers that not only 
> validate HTML structure, but also validate that a/@href attributes are 
> URIs (despite being defined in a separate document) and that fb:default 
> elements have fb:switch elements as their parents (again, despite being 
> defined in a separate document).

As I understand it, those cases don't require an XML-like DOM, and 
perhaps they could be handled with no UA changes (hence avoiding all 
problems with breaking the web). (Having seen some of the 
complicatedness of how IE handles HTML-namespaces, and how people rely 
delicately on DOM interactions, I can begin to understand why browser 
developers are reluctant to make any changes at all.)

   New document requirements: If an element name is of the form 
"prefix:name", then the document root must have an attribute named 
"xmlns:prefix". The conformance of such elements (and of similarly 
prefixed attributes) is left undefined by HTML5, but conformance 
checkers should report an error for documents published on the web which 
use prefixes other than [some list which browsers are expected to 
support quite widely].

Then, valid documents like

   <!DOCTYPE HTML>
   <html xmlns:fb>
   <title>Example</title>
   <fb:dashboard>
     <fb:action href="?id=1234567">My Book Reviews</fb:action>
     ....
   </fb:dashboard>

would be parsed as usual by HTML5 UAs (i.e. as in 
<http://james.html5.org/parsetree.html>), producing an element with name 
"fb:dashboard" in namespace "http://www.w3.org/1999/xhtml". (It would 
produce the same tree structure in IE7 (though with incorrect node 
names) and would match the same CSS selectors - this isn't necessarily 
aimed at browsers but it's nicer if it works in them anyway). If you 
forgot the xmlns:fb (or copied-and-pasted from the middle of someone 
else's document), it would be parsed the same by HTML5 but would break 
in IE.

Tools like conformance checkers and sanitisers and pretty-printers would 
just have rules for how to deal with the "fb:dashboard" element, the 
same as their rules for dealing with any other HTML element, and they 
might have some custom loadable module support so you can easily 
configure an HTML-plus-FBML-plus-MathML sanitiser by extending the list 
of recognised elements. Tools which feed into an XML pipeline can do 
whatever they want for mapping certain elements into real namespaces. 
The meanings of prefixes would have to be standardised within the 
environment they're used in - people on Facebook would have to always 
use "fb:...", since that's what the tools recognise.

I expect this may be insufficient, but in what ways?


(It might be easy to allow self-closing tags with minimal parser 
changes, by saying that if a start tag has a name "prefix:name" and a 
trailing slash then treat it in the tree-construction stage like a void 
element, as was suggested originally. That would differ slightly from 
current non-IE browser behaviour and have the compatibility issues 
mentioned before if you tried using it in a public web page, but would 
match IE's behaviour (both with and without the <html xmlns:prefix>). 
Since it's in a case where everyone disagrees with IE, that may indicate 
it's not a critical compatibility issue and changes would be relatively 
safe.)

-- 
Philip Taylor
philip@zaynar.demon.co.uk

Received on Sunday, 5 August 2007 19:42:30 UTC