On Mar 5, 2009, at 4:49 PM, Tim Berners-Lee wrote:
Yes, the goal of having one code path on top of a namespace-aware
API is important.
When one has a namespace-aware API, shame not to have the namespaces.
What are the arguments against implementing xmlns: recognition in
*future* HTML5 parsers?
(I can't imagine that there are a lot of people who have
accidentally used the string xmlns: inside attribute names in the
past. :)
This assumption is incorrect.
There is quite a bit of mistaken use of xmlns in text/html, and also
use of mistaken tag and attribute names with colons. It is a
combination of outright mistakes, sending of XHTML as text/html
without full understanding, use of IE-specific extensions (in ways
that would fail in other browsers) due to the way IE does namespaces
in HTML, and generation by various tools, including Microsoft Office,
of content that uses namespaces in ways that would likely break.
If it were not for this content legacy, then I think using xmlns to
declare namespaces in HTML would be worth considering.
There would still be a need for kludge code for legacy browsers, but
with time some applications would just propose to work with XHTML
and HTML in newer browsers. (For example, things which need other
new features anyway). Others would keep the kludge code in forever.
But it would be a huge step forward toward solving this issue.
(As a side note, I think Henri has in the past pointed out serious
issues with using QNames in content, which is what CURIEs as used by
RDFa amount to. But to be fair, those issues are not entirely HTML-
specific and remain flaws even in pure XML use.)
Regards,
Maciej
