Re: SVG in text/html

On Wed, 25 Mar 2009, Doug Schepers wrote:
> Sam Ruby wrote (on 3/25/09 3:04 PM):
> > 
> > From what I can see, there is agreement that the desired behavior for 
> > user agents (in particular browsers) which encounter inline SVG in 
> > content served as text/html is to treat the following as identical:
> > 
> > <svg xmlns='http://www.w3.org/2000/svg'><circle r='20'/></svg> 
> > <svg><circle r=20></svg>
> > 
> > I don't sense that there is any remaining disagreement on this point. 
> > If I'm wrong, please correct me as that is more fundamentally 
> > important than the point I explore in the remainder of this email.
> 
> Actually, I strongly disagree, and while I see the SVG WG doesn't seem 
> to have much choice in the matter, I think this is a huge mistake.
> 
> Given this fragment:
>  <html><svg><g><circle ...><animateTransform ...><rect
> ...><title></title></svg></html>
> 
> This is the resulting tree:
>  <html>
>   <svg>
>    <g>
>     <circle ...>
>      <animateTransform ...>
>       <rect ... >
>        <title></title>
>       </rect>
>      </animateTransform>
>     </circle>
>    </g>
>   </svg>
>  </html>

Given this fragment of XML:

   <svg ...><g><circle ...><animateTransform ...><rect ...><title></title>

...and assuming only end tags follow, there is only one possible DOM that 
could be formed, and it's the same DOM.

So this seems consistent with XML.


> [...] My preferred behavior is that the SVG in that case simply not 
> render at all, removing the ambiguity that it is somehow "working" when 
> it is not doing what the author should have been led to suspect.

How would we make it not render at all? Is the proposal that we drop the 
entire DOM as soon as we find a missing end tag? (That would make 
debugging REALLY hard, as there would be no clue as to the problem in the 
DOM view.)


On Mon, 30 Mar 2009, Jeff Schiller wrote:
>
> I do have two other questions, I may have missed these answers so 
> apologies up-front:
> 
> 1) What (if any) SVG specification will the HTML5 spec point to?  I'm 
> assuming SVGF 1.1 for some obvious reasons.

I was just going to reference whatever the latest version was (SVG Tiny 
1.2 at the moment, but who knows by the time HTML5 is done), The only 
normative references right now are about script execution and 
SVGDocument.title, anyway.


> 2) Does there need to be relevant text in the HTML5 spec that covers 
> what DOM interfaces foreign content nodes should or must have?  I 
> believe at least one chair thinks it needs to be clarified [1].  I'm 
> assuming that cooperating browsers will extend the SVGElement (and more 
> specific) interfaces to all SVG-in-HTML elements.

Doesn't the SVG specification already define this for any node in the SVG 
namespace?


On Mon, 30 Mar 2009, Anne van Kesteren wrote:
> 
> "The interface appropriate for an element in the HTML namespace that is 
> not defined in this specification is HTMLElement. The interface 
> appropriate for an element in another namespace that is not defined by 
> that namespace's specification is Element."
> 
> I would like that to be the default interface if there is one for 
> forward compatibility. So e.g. <svg:x> would still implement SVGElement 
> just like <html:x> implements HTMLElement.

I've clarified the paragraph to allow the SVG spec to require that.


On Wed, 25 Mar 2009, Jeff Schiller wrote:
> On Tue, Mar 24, 2009 at 7:34 PM, Ian Hickson <ian@hixie.ch> wrote:
> >
> > > Added a paragraph suggesting:
> >
> > | To enable authors to use SVG tools that only accept SVG in its XML
> > | form, interactive HTML user agents are encouraged to provide a way to
> > | export any SVG fragment as a namespace-well-formed XML fragment.
> 
> Can you please change to
> 
> "user agents are strongly encouraged ..."

What difference would the word "strongly" make?


> On Tue, Mar 24, 2009 at 7:34 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On the issue of quotes being required around attribute values, the 
> > arguments given in the following e-mails seemed technically sound and 
> > argued for keeping the syntax consistent across vocabularies:
> >
> >  http://lists.w3.org/Archives/Public/public-html/2009Mar/0233.html
> >  http://lists.w3.org/Archives/Public/public-html/2009Mar/0250.html
> >
> > I have therefore not made missing quotes be a conformance error.
> 
> It seems like the relevant portion of the SVG WG's proposal consisted
> of changing the parsing algorithm from:
> 
>     8.2.4.9 Before attribute value state
>     ...
>     Anything else
>         Append the current input character to the current attribute's
> value. Switch to the attribute value (unquoted) state.
> 
> to:
> 
>     8.2.4.9 Before attribute value state
>     ...
>     Anything else
>         If the insertion mode is "in foreign content", parse error.
> Append the current input character to the current attribute's value.
> Switch to the attribute value (unquoted) state.
> 
> The feedback that unquoted attributes are harmful/painful when bringing 
> hand-coded SVG-in-HTML into the existing SVG tool infrastructure has 
> been considered as 'acceptable pain' with the assumption that all tools 
> will be updated before SVG-in-HTML achieves significant deployment 
> footprint.  I think this is a bad assumption and I ask that the above 
> parser modification be re-reconsidered. Toolchains do not change over 
> night, companies do not always buy the latest version of tools the day 
> they come out.

Your argument implies that it is asserted that SVG-in-HTML will achieve 
significant deployment footprint overnight also, but that is highly 
unlikely. It is far more likely that it would take years, and it is very 
likely that people who use this feature will in fact be exactly the kind 
of people who obtain toolchains that support SVG-in-text/html.


> Jonas argued that we should "minimize the learning curve" for HTML 
> authors.  An author who does not quote her attributes on SVG content 
> will still see their content just as they expect. The only difference is 
> that when they run it through a conformance checker, they will see 
> parser errors stating that foreign content attributes must be quoted. 
> Given that the foreign content is coming from "XML Land", this shouldn't 
> be too hard for them to understand.
> 
> You may argue that we don't need to consider SVG-in-HTML as related to 
> XML in any way, but if any author wants to explore SVG they will be 
> referring to the SVG specification which very clearly describes SVG as 
> an XML dialect.

I think it's unlikely that such an author will be reading specifications.


> Lachlan argued that it is confusing for authors to have to remember the 
> quotes for some attributes and not for others.  I've argued [3] that 
> authors already have to realistically remember to quote some HTML 
> attributes and that we really should encourage quotes across the board 
> for consistency - yet I acknowledge how some people love the feeling of 
> unquoted attributes.

The rules right now are really simple -- you only need quotes if your 
value includes spaces, quotes, or equal signs.


> Authors are free to leave the foreign content attributes unquoted and 
> ignore the parser errors if they really care about 'content 
> optimization' or 'ease of hand-coding'.

By definition, if we make it a conformance error, they are not free to do 
it. Conformance errors are the spec's way of saying what authors are not 
allowed to do.


> In real world terms, parse errors serve to "gently educate" authors on 
> correct syntax and that seems perfectly appropriate for this specific 
> scenario.

The argument, as I understand it, is that the correct syntax should allow 
unquoted attributes, not that we shouldn't educate authors.


> Once HTML5 is out the door and we observe that deployed tools has 
> largely made this shift, we can clearly drop this parsing error in 
> HTML6.

It seems highly unlikely that we won't have largely made this shift long 
before HTML5 is done.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 27 April 2009 03:27:28 UTC