RE: Selectors, getElementsByTagName() and camelCase SVG

Henri wrote:

>The spec should probably prescribe the camelCase list to be used for  
>getElementByTagName() and the CSS parser. However, those lack the  
>context the HTML parser has, so textArea can't be put on the list.

Hi Henri,

I haven't been following these discussions very closely, but I cannot
think of anything in SVG for which you might never wish to use
getElementsByTagName. What comes to mind are clipPath, viewBox,
textPath, all the names of filters, linear and radial gradients,
animateMotion, animateTransform. Maybe someone can think of something
that you'd never need to use script to retrieve, but I can probably find
extant examples of at least many of the above. 

But I'm not clear about something: if we are using SVG in text/html does
that automatically mean that global variables declared within the
<script> associated with the SVG become merged with those declared
within scripts in the HTML? I'm just not sure what's supposed to happen
in documents containing compound formats.

Similarly, if a function residing in the CDATA of an SVG document were
activated by an event in the SVG documentElement, and in that function
we looked for  document.getElementsByTagName("textArea") would the scope
of that search be limited to svg.documentElement or would it
automatically expand in scope to include the entire HTML document (of
which the SVG is just a subtree) and find all text[aA]reas in both?

It could cause some troubles, but I suspect given the youthful age of
<textArea> and its probable limited deployment to date, that authors
would simply start using svgRoot.getElementsByTagName("textArea") to
work around the problem.

Regards
David

P.S. Concerning the textArea / textarea confusion between SVG and HTML
-- if that's the only really weird one then can't both the SVG and HTML
specs point to a common definition in XFORMS, or has that cow already
left the barn?

Received on Wednesday, 1 April 2009 16:55:02 UTC