Re: Status of XSL and CSS?

Paul Prescod wrote:
> 
> 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.

Aha, I see - you are saying its a language for describing graphics.
Well, yes ;-)

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

And similarly there are an infinite number of renditions of

<svg>
  <g>
    <desc>This is a picture of a butterfly</desc>
    <path etc etc/>
    <g>
      <desc>This is a butterfly wing</desc>
      <path etc etc/>
     </g>
    <!-- and so forth -->
  </g>
</svg>

> [speaking about styling in graphics]
> > They are hardly ever used in other vector graphics languages 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.

You could use the same argument to show that structured text is a bad
idea. It isn't. Once graphics are described in XML, styling those
graphics becomes an obvious thing to do, and uses already defined
mechanisms.

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

Well, I guess we will just have to disagree about whether restyling
graphics offers any advantages.

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

Well, the same doomsaying could be used to show that XML won't take of
either, or the Web for that matter.

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

We did that discussion already. I don't see anything new here. To recap
- changing the syntax offers no advantages, and has disadvantages such
as adding 180 or so attributes onto every element, and having to
reinvent how inheritance works, and messing up the DOM, and so on and so
forth.

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

I have the CSS1 and CSS2 definition of a "stylesheet". They cascade,
remember. A one line stylesheet is still a 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. 

You have a tendency to make authoritative sounding pronouncements about
what will happen in the future, but you don't know what will happen any
more than I do. So, I would thank you to preceede your star-gazing with
a bit more "I think" or "in my opinion".


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

Since these are statements made about the future, I can only say that we
will see.

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

You may see CSS as a hack; I don't, obviously.

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

You are better at technical argument than sarcasm. However, I will point
out that CSS does indeed have its own DOM, already, specific for style
sheet usage; and that creating a new DOM for your proposed radical
reworking of CSS would merely be one part of reinventing, without
gaining in fuctionality, a variant style sheet language.

--
Chris

Received on Saturday, 10 April 1999 23:34:57 UTC