W3C home > Mailing lists > Public > www-svg@w3.org > April 2009

Re: Selectors, getElementsByTagName() and camelCase SVG

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 01 Apr 2009 19:03:04 +0200
To: "Dailey, David P." <david.dailey@sru.edu>, "Henri Sivonen" <hsivonen@iki.fi>, "HTML WG" <public-html@w3.org>
Cc: www-svg <www-svg@w3.org>
Message-ID: <op.urpwbea964w2qv@annevk-t60.oslo.opera.com>
On Wed, 01 Apr 2009 18:53:45 +0200, Dailey, David P.  
<david.dailey@sru.edu> wrote:
> 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.

You can always use getElementsByTagNameNS of course, though it would be  
nice if getElementsByTagName did the right thing in most cases.


> 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.

They execute in the same scripting context so indeed share variables, etc.  
You can try this out today using XHTML+SVG.


> 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?

In both (this follows from the above). See XHTML+SVG.


> 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.

That would probably work.


> 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?

SVG textArea is not a form control. (And XForms is not compatible with  
HTML form controls by design.)


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Wednesday, 1 April 2009 17:03:58 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:42 GMT