Re: XSLT and SVG

Chris Bayes wrote:

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

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

Correct.

> As SVG would usually have a style attribute 

Well, not necessarily but lets assume that this particular example does

> then specificity doesn't come into it.

Yes it does; the style attribute with specificity 100 will override all
selectors with lesser (or equal) specificity but wil litself be overridden
by a higher specificity selector. 

Here is an example

<g id="foo"><text class="bar"><tspan style="fill: red">hello</tspan>
world</text></g>

the selector
#foo bar { fill: green }

will make "hello world" all be green, overiding the style attribute saince
it has higher specificity.

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

Thats because the implementations seem to have a problem with reentrancy of
their XML parsers, so external symbols etc seem to be a problem. Thats a
short-term problem though.

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

Well, thats what links are for.

> Would GIF or JPG have become popular if you had to give installation
> instrictions rather than just clicking on them.

I don't see the need for URL-fear in this instance, nor do I accept your
'installation instructions' strawman.

--
Chris


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