RE: XSLT and SVG

Subject: RE: XSLT and SVG
From: "Chris Bayes" <Chris@xxxxxxxxxxx>
Date: Tue, 19 Sep 2000 18:11:27 +0100
>Chris Bayes wrote:
>> Chris Lilley wrote:
>> >Just pointing out that nothing precludes using style elements
>of external
>> >stylesheets in SVG.
>>
>> No very true but they don't normally override style attributes
>on elements.
>
>That depends on their specificity - if its greater than 100 then clearly
>they will override them.
>>
>> >Also, why edit a style attribute?
>>
>> Why not it was just an excersize.
>
>Oh - ok.
>
>> >Why not just add a
>> >selector of higher specificity that overrides the property you want to
>> >change?
>>
>> Not sure what you mean here.
>
>Specificity, as defined in the CSS spoec.
>
>> Are you talking about !important or
>> <text...style="color:red;"><span style="color:blue;">some
>text</span></text>
>no.

I looked at the spec for the first time today. Well just this bit of it

A declaration in the 'STYLE' attribute of an element (see section 1.1 for an
example) has the same weight as a declaration with an ID-based selector that
is specified at the end of the style sheet:

<STYLE TYPE="text/css">
  #x97z { color: blue }
</STYLE>

<P ID=x97z STYLE="color: red">

In the above example, the color of the 'P' element would be red. Although
the specificity is the same for both declarations, the declaration in the
'STYLE' attribute will override the one in the 'STYLE' element because of
cascading rule number 5.

As SVG would usually have a style attribute then specificity doesn't come
into it.
>
>> I think it is cleaner to change the style attribute rather than
>overriding
>> things or having external stylesheets. Less stuff to transmit
>and maintain.
>
>If you are worried about maintenence, don't use style attributes.

In HTML I would definitely agree with you. HTML documents are often made up
of many parts images scripts etc so having an external stylesheet is not a
problem. Most SVGs I have seen are contained in a single file and I think it
is a good idea to keep it that way. If you have to ship around a zip file
and/or installation instructions then I think that is not a good thing.
Would GIF or JPG have become popular if you had to give installation
instrictions rather than just clicking on them.
>
>> >> So what looked like a simple answer to a simple problem
>*isn't*. Maybe Ms
>> >> and Mike can shed some light on this
>> >
>> >I think this is a case where server-side DOM 2 makes more sense than
>> >server-side XSL-T.
>>
>> Possibly but the question was about XSLT and the more weapons in your
>> armoury the better.
>
>True, and its interesting to discuss edge cases and push the envelope, but
>its also wise to point out when someone is using a cone wrench as a hammer
>;-)

Well I don't think it could be described a cone wrench. If you are already
using XSLT to do a lot of transforms on a document then having to break out
and manipulate the DOM possibly could be. And the use of server-side DOM
wouldn't be much use if you are doing client-side transforations or using
saxon from the commandline.

Ciao Chris


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread