W3C home > Mailing lists > Public > www-svg@w3.org > June 2006

RE: [SVGMobile12] script element processing

From: Doug Schepers <doug.schepers@vectoreal.com>
Date: Tue, 20 Jun 2006 22:09:25 -0400
To: "'Ian Hickson'" <ian@hixie.ch>, "'Anne van Kesteren'" <annevk@opera.com>
Cc: <www-svg@w3.org>
Message-Id: <20060621020927.8ECFC5672@postalmail-a3.dreamhost.com>

Hi, Ian and Anne-

I'm speaking for myself here, not the SVG WG.

Ian Hickson
| HTML5 and XBL2 define how you handle this case (as does 
| CSS, in the external case). HTML4, XHTML1, and SVG don't, 
| however, as you point out.

Has this proven to be an issue with implementations in the past? Are there
UAs that treat the contents of script blocks differently? If this is
genuinely a point of necessary clarification, then I will certainly advocate
handling this in SVG Tiny 1.2. In my experience, though, this has not been
an issue.

| It would be lovely for SVG to define things like this, 
| especially since the SVG group announced their intent 
| to define error handling.

Could you please define "things like this"? I ask because this is a bit of
an open-ended issue. If you are specifically asking for defining how the
contents of script blocks are processed, that seems like low-hanging fruit,
but if this is just one of a large class of similar tasks, I might instead
prefer to defer it. 

My reason for this is simple. I agree that well-defined error handling and
parsing rules are a laudable goal, but I don't think that this is something
specific to SVG. Instead of describing such things in the SVG specification,
when they are needed in CSS, HTML4, XHTML1, and SVG alike (as well as many
other W3C languages, I'm sure), I propose that we try to create a
normatively referenceable document that can concentrate on exactly these
issues, and be broadly applicable to all relevant W3C documents. That way,
we reduce needless repetition, the opportunity for errors or omissions is
decreased, and the document could be expanded independently of any other

Such a document could serve not only as a joint reference, but as a resource
for the creation of robust specifications. It would lessen the burden on
spec writers, and also on implementors who could count on standard rules for
reuseable resources like for tokenization, parsing, error handling, data
types, and the like.

I am not claiming that this would be easy. As you are well aware, there have
been disagreements in the past between the SVG and CSS WGs on such issues as
scientific notation as a valid number, and whether lengths need units.
Clearly, such a document would need to be flexible, impartial, and take into
account the needs of all specifications affected. If you are interested in
the creation of such a document, however, I am interested in helping in
whatever way I can. I'm sure your work on both the CSS and WHAT WGs would
prove instrumental.


www.vectoreal.com ...for scalable solutions.
Received on Wednesday, 21 June 2006 02:09:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:08 UTC