- 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