- From: Philip Taylor <philip@zaynar.demon.co.uk>
- Date: Sun, 05 Aug 2007 20:42:25 +0100
- To: Sam Ruby <rubys@us.ibm.com>
- CC: public-html@w3.org
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