- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 12 Jan 2009 11:17:02 +1100
- To: public-svg-wg@w3.org
We discussed SVG in HTML a little at the 11/12/2008 telcon. Here is a summary of the points made distilled from the minutes, with my comments in brackets: * Doug says that the goal “SVG should remain XML when inline in HTML” should be a consequence of the later, more high level goals listed in Erik’s mail. * Erik says that neither his nor my earlier mail captures exactly what we want from this goal, since there are certain kinds of XML non-well-formednesses that would be reasonable to allow in HTML. * Chris says that we shouldn’t be concerned about validity, just well-formedness. (Although in HTML, the term “validity” covers both validity and well-formedness in the XML sense.) * Erik says that we want parsing fixups to be marked as parse errors. (I would like to know exactly what things would be classed as parse errors here and what would be allowable syntax.) * I say that we wouldn’t want to have any implied end tags, as that would restrict our ability to extend the language. * Chris says that for the “copying the XML SVG and pasting it into an HTML document” use case, there was agreement at TPAC that the author wouldn’t be copying the DOCTYPE. (I assume that goes for the XML declaration if it exists, too.) * Doug says that until there are tools that understand SVG in HTML, authors will not understand how it exactly works (parses, etc.), and that we will need to educate authors on what different syntax is allowed in XHTML and HTML. * Chris says that entities are a “kind of transitional phase”, and that Unicode should just be used these days. (I might disagree with that; I think many authors will continue to use entities because they are easier to type with a regular keyboard layout, and easier to remember than numeric character references.) * Anthony says that omitted attribute quotes are a bad idea because with SVG’s complex attribute syntaxes, it wouldn’t always be clear where the attribute value ends. (I would say that this shouldn’t matter, and would require just the same amount of thought from authors as in HTML; i.e., if your attribute value has a space in it, then you’ll need to use quotes around it.) * Doug says that lots of attributes can take space-less strings, and that omitting the quotes here would be fine, and would be error corrected. I wondered whether it was worth classing these as parse errors, since they are not parse errors for HTML elements. Doug says that it should be a parse error to help people who are trying to do standalone SVG. * Doug raises a concern that people will have SVG-like files (i.e., using the SVG in HTML syntax), which is served as text/html, and which will be confused with regular SVG files, and will be found not to work when loaded into an authoring tool. Anthony says that an artist would understand “right click → save as, then open the file”, which could ameliorate the problem. * Chris says that if browsers do silent parsing correction that this will cause SVG files to exist that are not well formed and thus cannot be edited in standard authoring tools. (Perhaps it’s just quibbling, but this would cause HTML files to exist whose SVG contents aren’t well formed XML. I would expect content served as image/svg+xml to still be parsed with an XML parser.) * Doug says that the above point is why accepting non-XML syntax should be seen as a parse error rather than valid syntax, and that there needn’t be a visible indication of error in the content, but a log or a validator can point this out as a warning. (Currently browsers don’t seem to log HTML parse errors in their error consoles. I believe HTML parse errors are classified as errors and not warnings in the two validators that I’ve used (the W3C one and Henri’s one): do you still want to have these as a warning as opposed to an error? I am not convinced that making non-XML syntax as a parse error will prevent the issue of proliferating non-XML SVG content.) * Doug says that he wouldn’t be surprised to see this kind of parse error correction in XML within the next five years. * Doug says that SVG requires quotes, and that he’s OK with no quotes being parsed as long as it’s acknowledged as error correction. Please correct any of the above if I have misinterpreted the minutes. Since that telcon, there was also the news that the HTML WG’s proposal has been updated to allow SVG <font> elements, which is good news. I think it might help the discussion if someone were to summarise the characteristics of the HTML WG’s current proposal and send it to the list. We could then look at the concrete differences between our current thoughts (which I believe aren’t written up, since the TPAC discussions) and that proposal, so that we can find points where we might converge. I would still appreciate replies to my earlier mail (http://www.w3.org/mid/20081209010141.GB25522@arc.mcc.id.au), as well as this one. IMO we should try to hash out the arguments over mail, rather than during the limited telcon time, if possible. Thanks, Cameron ACTION-2383 -- Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 12 January 2009 00:17:52 UTC