- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 20 Aug 2009 16:12:07 +1000
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: HTMLWG WG <public-html@w3.org>, Adrian Bateman <adrianba@microsoft.com>, Henri Sivonen <hsivonen@iki.fi>
Hi Maciej. Maciej Stachowiak: > SVG and MathML have in fact been integrated. I don't think there is > a proposal for further change on the table - but if there is a > requested concrete syntax change, I believe it should go in its own > issue. Suggest closing. Thanks for bringing this one up again. Discussions on syntax issues did seem to peter out a while ago, and while I am not certain, I think that most of the issues surrounding casing, conformance, xmlns-ish things, etc. of the syntax were acceptable to the SVG WG in the end. I don’t think all issues related to the integration of SVG were resolved to the satisfaction of the SVG WG, though. The following in particular were brought up in our telcon yesterday: * Lack of requirements to process SVG in any particular way We agree with DanC’s comment that it’s a strange middle ground to have an implementation parse SVG elements in a text/html document and for them to be placed in the DOM but not processed any further (apart from a couple of selected things, like running <svg:script> elements according to the SVG spec) be a conforming implementation. * Element and attribute case fixup tables We are still of the opinion that the element and attribute name case fixup tables should be specified somewhere else that is more easily updatable, in order not to be an impediment to the SVG WG minting new names. Now, while we will have a Good Hard Look at ourselves with respect to name case and conflicts with existing HTML element names, it may be that for consistency with the other parts of the SVG language we decide to introduce new mixed case names. The SVG WG intends to produce a small spec detailing issues pertaining to integrating SVG in other contexts, one of which would be HTML. This seems like a good place to put that table. An alternative solution would be for the HTML spec to provide a spec hook that allows other specs to define case mappings for use by the text/html parser. Note that the element name case fixup table currently omits two entries from SVG Tiny 1.2, which should be added: (the poorly named) textArea and solidColor. * Foreign content parsing miscellany The following rule in foreign content: A start tag whose tag name is "font", if the token has any attributes named "color", "face", or "size" while not likely to cause any problem for SVG content at the moment, doesn’t seem worth having on the face of it. (Note that <font color=""> is conforming in SVG, color="" being the presentation attribute for the ‘color’ property.) * SVG in a CSS context It needs to be specified what sort of CSS box <svg> creates in text/html. * User interaction with mixed HTML and SVG It needs to be specified somewhere what how, for example, pointer events get dispatched when there is SVG content overlaying HTML content, or vice versa. * Reference The spec currently has a normative reference on SVG Tiny 1.2, but includes entries in the case fixup table for SVG 1.1 elements. In reality, browsers are targetting SVG 1.1 rather than 1.2T. Shouldn’t there be a normative reference to SVG 1.1 too? (Note that SVG 1.1 Second Edition will be published in the coming months.) Whether ISSUE-37 is kept open for these, or if it is closed and separate issues for the above raised, I don’t particularly mind. This isn’t necessarily an exhaustive list. It’s also not clear either whether all of the above need to be solved in HTML 5 rather than some other spec. It has been some months since we (SVG WG) have looked at SVG in text/html; we’ve been caught up with other work. I will make sure that we take a detailed look at the current state of the SVG stuff in HTML 5 soon and report back with any other issues that arise. Thanks, Cameron http://www.w3.org/Graphics/SVG/WG/track/actions/2652 -- Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 20 August 2009 06:13:00 UTC