- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 09 Nov 2009 01:45:25 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238
--- Comment #8 from Maciej Stachowiak <mjs@apple.com> 2009-11-09 01:45:24 ---
(In reply to comment #6)
> (In reply to comment #4)
> >
> > With my browser implementor hat on, implementing a significant extra parsing
> > complexity in browsers solely for a single feature that will only be
> > implemented by script- or plugin-based add-ons does not seem like a good
> > tradeoff.
>
> Void elements pose a significant problem. That data, once lost, is generally
> impossible to reconstruct.
That certainly complicates things for anyone wishing to put XML vocabularies in
HTML (it would require explicitly closing empty elements or putting the content
in an inline <script> to avoid parsing). But it doesn't make me, as a UA
implementor, feel more motivated to add built-in parsing complexity for a
feature to be implemented by third-part code.
>
> > If I understand correctly, the root element of X3D is not mixed case ("X3D"
> > only has capital letters), so it doesn't seem like the email proposal satisfies
> > your request. Interesting idea though.
>
> I was imprecise. I meant elements which contain at least one capital letter.
>
That seems like it would be more likely to work for X3D. But it may also have
slightly greater compatibility risk. The email suggestion also mentions
mixed-case elements and slash-based self-closing syntax being supported. But
although an xmlns attribute is one of the triggers, it does not mention
applying namespace processing. Was that intended?
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 9 November 2009 01:45:26 UTC