W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2009

[Bug 8238] Add support for X3D

From: <bugzilla@wiggum.w3.org>
Date: Mon, 09 Nov 2009 01:45:25 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1N7JJt-0003Ce-4j@wiggum.w3.org>

--- 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:05 UTC