Re: Element Whitelisting

Hi, Henri-

Henri Sivonen wrote (on 3/24/09 10:20 AM):
>
> Concretely: Should new SVG 1.2 Tiny elements be on the list today
> (regardless of which WG maintains the list) when browsers differ in
> their treatment of 1.2 Tiny as part of the platform?

A fair question, which we hope to resolve by producing an SVG 2.0 that 
has broad support by desktop browsers and mobile UAs.  Different 
profiles for SVG made sense at the time that SVG Tiny 1.1/1.2 was 
started, to provide a subset of SVG for limited devices, but mobile 
device capabilities are quickly approaching the point where it doesn't 
make as much sense anymore.

Concretely speaking, I would like to see SVG Tiny 1.2 referenced and 
supported in HTML5, though I can also understand some reluctance to 
certain features.  However, SVG Tiny 1.2 doesn't really add that many 
new elements or attributes, so from that perspective it shouldn't be 
hard for browsers to implement them.  YMMV.


> Is the issue at hand acknowledging SVG 1.2 Tiny with its normative
> references to XML 1.1, xml:id, XML Events, Namespaces in XML 1.1 and XSL
> 1.1 and informative references to WebCGM and XHTML Vocabulary Collection?

FWIW, the current SVG Tiny 1.2 spec advises content authors to use @id 
over @xml:id for Web content.  (As you know, Henri, I agree with you 
that XML 2.0 should have @id==ID.)


> In practice, except perhaps for textArea, it should be pretty safe to
> put 1.2 Tiny names on the list even if 1.2 Tiny isn't supported by the
> SVG implementation of the application that includes the HTML5 parser.
> For textArea, it should either be safe to add it now or it will never be
> safe to add it.

Sigh.  I've said before that I think the <textArea> name is silly, but 
by the time I joined the SVG WG, it was a done deal.  For myself, I 
would prefer a different name and different functionality.  Maybe that's 
something for SVG 2.0.

As an SVG developer, the problem with <svg:textArea> is that one of the 
most useful things to add to SVG content from HTML are the form 
controls, including <html:textarea>.  For standalone SVG, having 
<svg:textArea> is a real blessing, but for mixed HTML+SVG content, a 
well-styled <p> should serve about as well (and maybe better).  I 
wouldn't cry if <svg:textArea> were special-cased in HTML, except that 
it would be a slippery slope in terms of consistency.


> What's the current guess on 1.2 Tiny camelCase names making it into an
> SVG 2.0?

The SVG WG is carefully considering names for new elements, attributes, 
and attribute values, in light of the issues with camelCasing.  Where we 
are trying to match existing patterns (like the filter element names or 
attribute values for existing attributes), we are considering camelCase 
names, but for new unrelated elements and attributes, we should only be 
adding lowercase names.  I'm sorry that's not a more definitive answer. 
  Folks on the SVG WG differ on the matter.


> (What other 1.2 Tiny camelCase names are there in addition to textArea?)

Of those introduced in SVG Tiny 1.2: <solidColor>, @defaultAction, 
@focusHighlight, @initialVisibility, @mediaCharacterEncoding, 
@mediaContentEncodings, @mediaSize, @mediaTime, @playbackOrder, 
@snapshotTime, @syncBehavior, @syncBehaviorDefault, @syncMaster, 
@syncTolerance, @syncToleranceDefault, @timelineBegin, @transformBehavior.

I think that's a fairly comprehensive list, though I might have missed a 
couple.  You'll note that most of them are inherited from SMIL media.


> If we want the list to be more malleable than the rest of the algorithm
> definition document, the algorithm spec should have a link to a URI
> which will dereference to the latest list at any given point in time. A
> great bonus would be if the document at the URI came with revision history.

Cameron and Erik alluded to this earlier.  SVG 1.1 and SVG Tiny 1.2 both 
have explicit lists of elements and attributes [1][2][3][4], and the 
plan is to do the same for SVG 2.0.  It's not great overhead for the SVG 
WG to compile these into a W3C Note (or whatever) with links to the most 
appropriate specs and definitions, if that's desirable.


[1] http://www.w3.org/TR/SVG11/eltindex.html
[2] http://www.w3.org/TR/SVG11/attindex.html
[3] http://www.w3.org/TR/SVGTiny12/elementTable.html
[4] http://www.w3.org/TR/SVGTiny12/attributeTable.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Tuesday, 24 March 2009 15:15:44 UTC