Re: SVG in text/html

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 ..."

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.

You cite Jonas' [1] and Lachlan's [2] arguments as reasons you did not
accept the above change.

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.

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.

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'.  The error handling and
resulting UA behavior are both well-defined and expected.  In real
world terms, parse errors serve to "gently educate" authors on correct
syntax and that seems perfectly appropriate for this specific
scenario.

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.

Regards,
Jeff Schiller

[1] http://lists.w3.org/Archives/Public/public-html/2009Mar/0233.html
[2] http://lists.w3.org/Archives/Public/public-html/2009Mar/0250.html
[3] http://lists.w3.org/Archives/Public/public-html/2009Mar/0261.html

Received on Wednesday, 25 March 2009 14:30:13 UTC