- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Fri, 21 Jul 2006 13:24:47 +0200
- To: Anne van Kesteren <annevk@opera.com>
- Cc: www-svg <www-svg@w3.org>
Hi Anne,
> How could it ever get brackets? Those are _elements_ not brackets.
> Brackets are encoded like < or whatever or are inside some CDATA
> section. I'm asking about getting the text value within a script
> element.
It doesn't "get brackets" as such, I believe that was metaphorical.
What happens is this:
- If the type (coming from the type attribute, the
contentScriptType attribute, or the default) is unknown, then the
content is not processed as executable content (effectively being
ignored for all matters scripting).
- If the type is an XML media type, the subtree isn't touched and
is passed as is to the script engine (presumably script engines for
XML languages can accept being passed a DOM or something, but that's
a detail internal to the UA anyway).
- Otherwise, the following pre-processing is done to obtain the
content that is passed to the script engine:
. all element children of the executable element are removed
. the textContent of the executable element is passed on to the
script engine
The reason we chose to reference textContent instead of using
language similar to that of the XBL draft is because the latter has a
few issues, notably in that it's not yet entirely idiot-proof in its
definition of text content, and also because as currently written it
appears to exclude EntityReference nodes that may be in the DOM,
which is a bug (I know that's a contrived example, but we have to
deal with it). In trying to patch it up to be as tight as we wanted
it to be, we noticed that all we were doing was repeat the definition
of textContent. So we went with referencing that instead.
Thank you very much for your comments, please let us know shortly if
this does not address your concerns.
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
Received on Friday, 21 July 2006 11:24:57 UTC