- From: Doug Schepers <schepers@w3.org>
- Date: Tue, 05 May 2009 00:00:00 -0400
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: Jonas Sicking <jonas@sicking.cc>, "public-html@w3.org" <public-html@w3.org>, www-svg <www-svg@w3.org>
Hi, Henri- Henri Sivonen wrote (on 5/4/09 1:51 PM): > > On May 1, 2009, at 12:13, Doug Schepers wrote: > >>>> 2) we add a new element, like<link>, to SVG (I've already shown that >>>> this >>>> sometimes works when the<link> is in the XHTML NS [1], but that isn't >>>> specified anywhere, and isn't intuitive) > > For <link> in SVG namespace, it's important to consider the backwards > compat story with legacy UAs in the SVG-in-text/html case. > >> The <param> element would be used, for example, as a child of the >> <use> or <animation> elements, where it's referencing other SVG files >> which can take parameters. In other words, it would be used like it is >> in <object>: >> >> <use xlink:href="somefile.svg#someElement"> >> <param name="color" value="cornflowerblue"/> >> </use> > > Has the backwards compat story of this one been reviewed for the > SVG-in-text/html case considering that HTML <param> is a void element? What backwards-compatibility issues are you specifically concerned with, for both these elements? The SVG WG will need more details before we can answer in any substantive way. At first glance, we didn't see any issues, which is why we brought it to the HTML WG. Regarding <html:param> as a void element, SVG would differ there. Any element in SVG can contain children, independent of its utility. This is another minor thing that would have to be treated as special in "foreign-content" parsing mode, regarding look-ahead, but shouldn't have too many implications for the semantics, behavior, or processing of <param>. (In practice, I wouldn't expect authors to put child content into an <svg:param>, but I haven't thought too deeply about it.) Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Tuesday, 5 May 2009 04:00:25 UTC