Re: SVGWG SVG-in-HTML proposal (Was: ISSUE-41: Decentralized extensibility)

Ian Hickson wrote:
> > I believe that the following merits serious consideration:
> >
> > http://go.microsoft.com/fwlink?LinkID=110272
>
> This syntax, as well as the actual syntax that IE8 beta 1 implements
> (which to be frank is really very different from what the whitepaper
> describes), as well as the syntax supported in earlier versions of IE, and
> a number of variant syntaxes based on these ideas, have been seriously
> considered in excruciating detail already.
>
> But I've already explained this many times before, so I don't know why
> you keep bringing this up.

1) As one person who has missed this - can you please send me a link
to a discussion thread or document where these syntaces were discussed
in excruciating detail?  Considering that Microsoft is presumably
already going ahead with this, I would really like to understand the
ramifications.

2) I think it was Henri that mentioned that the <font> overlap could
be solved somehow in the HTMLWG proposal.  Can someone describe how
this might work?  i.e. would I be able to specify an SVG font inline
in HTML?

3) Ian described the scenario in the SVGWG's proposal where someone
haplessly pastes in the single line <svg:svg
xmlns:svg="http://www.w3.org/2000/svg"> and subsequently voids the
rest of the HTML page for SVG-supporting browsers while maintaining
the HTML content for older browsers.

Could the SVGWG's proposal be modified such that the SVG parser
actually returns a parser error if the element is not found to be in
the SVG namespace?  I acknowledge that this requires an extra hook
into the standard XML parser to check on the element name.

<html><body>
  <svg xmlns="http://www.w3.org/2000/svg">
<p>Hello World!</p>
<p>Goodbye!</p>
</body></html>

Upon encountering the <p> element, which does not exist in the SVG
namespace, the SVG XML parser would then tidy up and return to the
HTML parser just before <p>Hellow World!</p>

With the guarantee that the SVG and HTML WGs will work together to not
have any more element name overlaps, then the above modification would
solve some of these problems.  The SVG parser would still swallow
<html:a>, <html:font>, and <html:title> elements, if they immediately
follow the malformed SVG fragment, but perhaps that's an acceptable
casualty?

4) Speaking on my own behalf, I've more and more felt that if browsers
can be required (asked? coerced? paid? convinced?) to support "View
XML DOM' in any context where they currently support 'View Source'
that I wouldn't have a problem with a new syntax for SVG in HTML,
since the XML DOM in text/html would exactly match the XML DOM in
application/xhtml+xml, right?  In fact, once this capability is in
place, I'd even go so far as to propose this to be the browser default
(CTRL+U keyboard accelerator, for instance), though View Raw Source
should always still be available.

Yes, I've heard the argument that UI reqts are not allowed in the HTML spec.

Regards,
Jeff

Received on Wednesday, 30 July 2008 05:24:06 UTC