- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 03 Apr 2008 12:06:09 -0400
- To: public-html@w3.org
Hi, Henri- Henri Sivonen wrote (on 4/3/08 11:03 AM): > > Once you allow this, the whole <ext> element becomes pointless. ... > That violates one of our design principles: > http://www.w3.org/TR/html-design-principles/#dom-consistency > > And not even for a good reason once you allow the omission of the <ext> > tag in source. Like I said, I'm not advocating it, and I don't even like the idea. I was just playing around with details. I'm quite happy to reject this idea, but the question remains as to what to do when such content is encountered. Perhaps we allow both scenarios... I'm convinced that <ext> is better, though. >> Two advantages to explicitly using <ext>, however: >> >> * Compatible with Henri's general solution, but with the added benefit >> of the ability to supply a rich fallback. > > Without <ext>, SVG <desc> could be appropriated for fallback. If that's > objectionable, It is objectionable. :) That's not what <desc> is meant for. It's not clear how non-HTML UAs should interpret or display that content. Non-namespaced content (besides simple text) would break SVG UAs (authoring tools included) in copy-paste scenarios; simple text is not a sufficient fallback for SVG or MathML. > a <fallback> element could be allowed where SVG now allows <desc>. That would require a change to SVG (and to SVG UAs, and to the XHTML parser). The semantics of it don't seem to make sense... <desc> is allowed as a child of any SVG element, and we don't need a fallback for each element, just for the content as a whole. >> * Incredibly unlikely to break any content... there may be content out >> there like #2, but unlikely to be any like #1; you could think of the >> <ext> as a sort of "early warning" to browsers that a known "insertion >> mode" is about to follow. > > I'm not at all convinced that a wrapper named <ext> would solve problems > that a wrapper named <svg> wouldn't. * It decreases the risk of acting funny with legacy content. * It makes a consistent and easily understood point of extensibility for HTML, so that authors always know what to do with SVG, MathML, or some future endorsed syntax. * It provides a consistent way to allow for a rich fallback for SVG or MathML without creating incompatible content for those languages (or requiring an extension to them) Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Received on Thursday, 3 April 2008 16:06:46 UTC