Inline SVG: Embedded vs. Metadata Content Distinction (Was: Fwd: [whatwg] Allow Select SVG Elements In <head>)

Bueller...? Bueller...?

This request is almost 5 years old now, but it is even more relevant today,
now that web developers are increasingly embracing SVG for purposes of
responsive design and accommodating HiDPI displays.

Putting SVG <defs> and other metadata-related elements in HTML's <head>
seems like an obvious choice from a semantic standpoint. But it is
currently illegal in the HTML spec because SVG does not distinguish between
embedded and metadata content models for its elements, which Hixie has
requested so that the HTML spec can simply point to the SVG spec's
definitions. (Please see quoted text.)

Again, is this something the SVG WG is willing to do?

Thank you,
Hugh

On Thu, Dec 22, 2011 at 7:28 AM, Hugh Guiney <hugh.guiney@gmail.com> wrote:

> Cameron McCormack forwarded this proposal to public-svg-wg a year ago
> (thanks, Cameron!) but no one commented on it, so I'm reposting it
> here. Is this something the SVG WG is willing to do?
>
> Thanks!
> -Hugh
>
> ---------- Forwarded message ----------
> From: Ian Hickson <ian@hixie.ch>
> Date: Mon, Dec 6, 2010 at 9:35 PM
> Subject: Re: [whatwg] Allow Select SVG Elements In <head>
> To: Hugh Guiney <hugh.guiney@gmail.com>
> Cc: whatwg <whatwg@whatwg.org>
>
>
> On Fri, 27 Aug 2010, Hugh Guiney wrote:
> >
> > I'm authoring an XHTML host document with namespaced inline SVG and
> > XLink. I have vector images that recur throughout the site. I'd like to
> > implement SVG's <defs> and <use> to reduce the file size of the document
> > and keep style separate from content, as with CSS.
> >
> > If I put an SVG tree with <defs> anywhere in the XHTML document, other
> > trees with <use xlink:href> will correctly reference it, as tested in
> > the latest public release Gecko, Webkit, and Opera. So the question
> > becomes, where do I put it? The most obvious answer seems to be <head>,
> > since, like CSS definitions, this is metadata being defined for use
> > elsewhere in the document. The only problem is, Validator.nu doesn't
> > like it:
> >
> > "Error: SVG element svg not allowed as child of XHTML element head in
> > this context. (Suppressing further errors from this subtree.)"
> >
> > Same error when ditching the root <svg> and including only <defs>, the
> > result of which still works in all but Opera.
> >
> > This error can be avoided if the <defs> tree is put in the XHTML <body>,
> > but then there is blank space the size of the defined shapes at the top
> > of the document in all 3 engines. A workaround is to give <svg> a @width
> > and @height both of 0. But leaving the definitions in the <body> when
> > they technically don't represent contextual content strikes me as
> > non-semantic.
> >
> > My proposition would be to simply spec a subset of SVG consisting only
> > of metadata elements as valid in HTML's <head> context. This could be
> > just <defs>—I'm unsure if there are any other elements that fit this
> > definition since I am relatively new to SVG; but in either case it'd aid
> > semantics and is already supported in today's SVG-capable browsers.
>
> This is an interesting idea. I would recommend approaching the SVG working
> group and suggesting that they define the content model of <svg> and other
> SVG elements such that there's two ways to use it: one where <svg> is
> considered embedded content, and one where it's considered metadata
> content, with appropriate restrictions on the latter. With such a set of
> definitions in place, the HTML spec's model would just work (it already
> refers to the content model of <head> as just "metadata content", for
> instance).
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Friday, 28 August 2015 22:52:29 UTC