Re: CDATA, Script, and Style

Hi, Robin-

Robin Berjon wrote (on 3/18/09 4:26 PM):
> On Mar 18, 2009, at 20:54 , Doug Schepers wrote:
>> Robin Berjon wrote (on 3/18/09 6:10 AM):
>>>
>>> I think it could be acceptable to break <style> for SVG.
>>
>> No, it wouldn't.
>
> Let me clarify that and put it in the context in which I meant it: given
> a trade-off between breaking a *subset* of the uses of <style> in SVG
> and providing inconsistency for <style> authoring in an HTML context,
> the former is IMHO acceptable.
>
> Unless I'm mistaken, the context of this discussion is SVG-in-HTML and
> (perhaps, pending on other resolutions) SVG served as text/html. It
> doesn't apply to XML SVG served as image/svg+xml.

It applies to SVG content.  The less radically that is changed, at least 
for the first iteration, the less the chance that something breaks 
(particularly when it comes to authoring tools).


>>> While <script> is commonplace, <style> is pretty rare as
>>
>> No, it's not.
>
> That's not my experiencebut since I don't have numbers and neither do
> you,

No offense intended, but since your direct experience is based on SVG 
Tiny 1.1 (which doesn't support CSS) for a set-top-box environment [1], 
you may not have as much overlap with using SVG+CSS as those of us who 
develop primarily browser-facing content, on this particular issue. 
(Not at all dissing your SVG creds in general.)

I'm sure numbers could be gathered, especially from the SVG-Developers 
list community (or maybe a search-engine db could be queried), but let's 
try the less expensive path of examining the larger issue and seeing if 
we have to make that hard choice.  It may be that we have to, but I hope 
not.


> can we at least agree that the existing set of SVG documents that
> do use <style>, that use <style> content in the limited ways that would
> actually break (as detailed by Jonas and others), and that might either
> be served as text/html and or copy-pasted into an HTML document with
> informed modifications to their prologs but not to their <style>
> elements is, even without numbers, likely to be pretty small?

Since XHTML also mandates using CDATA sections for <style>, and there's 
quite a lot of pseudo-XHTML content out there, having a common syntax 
for all these languages, for both <script> and <style> (and any other 
such container element that might come along), would seem the most 
consistent and easy to deal with for authors.

Pardon my ignorance, but could someone point me to some persistent 
exploration of the CDATA-in-style issue?  If it's not on the HTML WG 
wiki, could someone put it there so we don't have to go over years-long 
email threads to receive the wisdom?  What exactly is controversial about
  <style><![CDATA[
    ...
  ]]></style>
in modern browsers?  (Besides the fact that it's hideous and unwieldy to 
type.  Which it is.)


>> In my experience, because of the PI mechanism, most CSS in inline in a
>> <style> element. It would be easier and more consistent with HTML
>> content if the SVG spec added a link element, as I've mentioned
>> elsewhere. [1][2][3] I'm interested to hear if this would cause a
>> conflict in inline SVG in HTML, if the SVG WG defined it such that it
>> has the same syntax and behavior as in HTML?
>
> It would be nice indeed, and has been desired in one form or another
> since antiquity (sorry, member-only I'm afraid):
>
> http://lists.w3.org/Archives/Member/w3c-svg-wg/2003AprJun/0078.html

Yeah, as you can see from the minutes I pointed to, Chris also thought 
that we had included it.  Frankly, this was just a screw-up based on 
everyone being too busy.  I apologize that we didn't take care of it 
earlier, but it's certainly planned, one way or another.  (I'd like to 
put it in an errata, for the sake of speed, but I don't think that would 
fly.)


> I'm all for adding <link> to SVG by making it a shortcut to <html:link>.
> Would that involve somehow deprecating the xml-stylesheet PI?

I'm inclined to say "no", because there's content that uses it, and it 
doesn't really gain us anything to do so.  I understand that it is 
useful in the general XSLT processing toolchain, so there may even be 
good reason to keep it; if not, we could simply omit it from SVG 2.0.

As irrelevant aside, linking directly to an external stylesheet from the 
*target* document, whether in a PI, a <link>, or a <style>, is a pretty 
cruddy mechanism, if one of the goals is to separate content from 
presentation.  A better way would be to have a manifest file that 
relates one to the other.  Oh, well.


[1] http://lists.w3.org/Archives/Public/www-svg/2009Mar/0148.html

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

Received on Wednesday, 18 March 2009 21:26:48 UTC