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.gui...@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 i...@hixie.ch
Date: Mon, Dec 6, 2010 at 9:35 PM
Subject: Re: [whatwg] Allow Select SVG Elements In head
To: Hugh Guiney hugh.gui...@gmail.com
Cc: whatwg wha...@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. `._.-(,_..'--(,_..'`-.;.'
