Re: Status of XSL and CSS?

Chris Lilley wrote:
> 
> > SVG is
> > a formatter-specific graphics language.
> 
> No, it isn't formatter-specific at all. I'm not sure what you are trying
> to say here.

SVG is formatter-specific in the sense that it is specific to formatters.
The only appropriate rendition for:

<svg:rectangle x="100" y="100" width="100" height="100"/>

is a rectangular diagram.

There are, on the other hand, an infinite number of correct renditions for 

<P>This is an <emph>paragraph</emph>.</P>

(though of course at any particular time certain renditions will be more
popular than others!)

But I think that you agree with that because you agreed that SVG is not
generic markup.

> They are hardly ever used in other vector graphics l;anguages because
> no-one saw the need, until now; 

Usually when nobody sees the need for a feature it is because they don't
want it. Trying to force it on them will not work.

> and I think that the reason many
> wordprocessors do not have their stylesheets used much is because the UI
> is clunky and thus patchwork overides are easier for users than
> structured styling.

Wordprocessors are organized around what users want. I don't really think
that every WP user interface design is a mistake. I give them more credit
than that. At SGML 97 Charles Goldfarb said that generic markup (and by
extension SGML) was an unnatural act. He quipped "XML is also an unnatural
act, but it's quicker." Using styles with SVG does not offer the
substantial benefits of generic markup (generic processing!) Users and
software will max out the "style" attribute in a gruesome way.

> > -creating tools will not encourage
> 
> You don't know that, unless you are aware of more product plans than I
> am

No, but I am aware of the nature of the software industry and also of
human nature. I don't expect either to turn around because of a W3C REC.

> They may not, but the generated SVG can still be styled even if the
> original generating application did not produce any styling.

That's all very well. But if the application is going to put a bunch of
stylistic information inline -- as it should, if that's what the user
wants, then why shouldn't that information be available in the most
atomic, managable way: separate XML attributes?

> > Stylesheet use should be a valid choice. Inline style should be another.
> 
> External stylesheets and inline stylesheets are both stylesheets. One
> just has implicit selectors, is all.

You have a very odd definition of "stylesheet."

The "style attribute" was a hack invented in HTML to allow inline
presentation attributes without encouraging it or making it an integral
part of HTML. From a purely political point of view, a dozen formatting
attributes would never have flown (thank goodness!). So the style hack was
invented: it isn't very convienent but that's the *point*.

Now we are dealing with a purely presentational language. There will be no
SVG renderers for braille or TTYs. There will be no web search engines
that do weighting based on SVG element types. There will be no
"client-side overrides" for SVG style (there were hardly even client-side
overrides CSS?)

Therefore there is no moral or technical reason that we should try to push
people away from using inline style when they want to. Thus the hack is no
longer appropriate. Style properties are just like any other properties:
they should be specified in atomic attributes. We should build on XML, not
around it.

Alternately, we could be consistent and make a special "xml:link"
attribute that can contain ALL information relating to XLink usage and an
"rdf" attribute for all information relating to RDF. Each attribute could
have a unique syntax, its own parser and its own DOM.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

"The Reduced * Set (R*S) is a design paradigm promoting simplicity 
over all other design constraints. R*S may be applied to all 
seven OSI networking layers. In fact, layers one through six 
may be simplified to the point of extinction, promoting the 
ultimate goal of reduced complexity and utility."
 - http://www.w3.org/1999/04/REC-Reduced-set

Received on Saturday, 10 April 1999 01:37:11 UTC