Re: Status of XSL and CSS?

Chris Lilley wrote:
> 
> 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>

There are an infinite number of variations on a single rendition. A
conforming application could not render it to braille or onto a text
display that did not support the angles and line widths that are
specified. There is no human communications medium that does not support:

<P>A paragraph <emph>with some emphasis</emph>..</P>

That's what makes it generic markup.

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

Structured text is a good idea but experience shows that it only works
when it is not optional. Most document types make a strict distinction
between content and presentation specifically so that authors do not have
the choice! If you cannot rely on the markup to express all of the
semantics you expect then the markup-related features are useless because
you cannot make reliable software based upon them. SVG is not a generic
markup language because it gives you no mechanism for requiring semantic
tagging. That isn't a flaw: SVG isn't intended to be a generic markup
language.

> Once graphics are described in XML, styling those
> graphics becomes an obvious thing to do, and uses already defined
> mechanisms.

I'm not arguing that styling graphics is a bad thing. I'm arguing that
making inline style inconvenient through a previously but not currently
appropriate attribute hack.

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

Advantages? Yes. The order of magnitude efficiencies achieved through
generic markup? No. Without a mechanism for enforcing style usage, complex
automation will be rare, just as it is with HTML.

I'm not claiming that the styling is a bad idea: it just isn't a
sufficiently good idea that inline style should be deprecated and made
inconvenient as it was in HTML 4.0.

> We did that discussion already. I don't see anything new here. To recap
> - changing the syntax offers no advantages, 

This is simply not true. Using an XML-convention based syntax makes SVG
easier to read and write by XML applications including the XML DOM and
XSL. It also makes SVG easier to understand from an XML user's point of
view. 

> and has disadvantages such
> as adding 180 or so attributes onto every element, 

How is it that 180 magical CSS properties in a special syntax is not a
problem but 180 attributes are? As a software developer I would prefer
attributes to special-case properties any day.

> and having to reinvent how inheritance works, 

There is nothing to reinvent. As I said last time, the inheritance rules
are fine.

> and messing up the DOM, and so on and so forth.

How does making the inline presentation information directly available in
DOM 1.0 as attributes in any way interfere with your ability to reflect it
in DOM 2.0? My proposal is actually much more DOM friendly because it will
allow programmers to get by with the XML DOM *alone* if they do not need
CSS for some other reason. If you want styling: great! Use CSS. If you
just want to make a picture you should not need a CSS DOM.

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

A one line stylesheet is a different issue from inline style:

<P FONT="Helvetiva">Blah</P>

Do you claim that the FONT attribute is a "stylesheet?" Now if I use this
syntax:

<P STYLE="Font: Helvetiva">Blah</P>

Does it become a stylesheet?

> > 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 are some things that we can say without star gazing. The spec says:
"The baseline for acceptable commercial SVG viewer quality is bicubic
resampling of images." How would bicubic image resampling be implemented
in braille or on a TTY? The concept doesn't even make sense to me.

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

Unfortunately standards creation is explicitly about predicting the
future. It isn't very efficient to put out the wrong standard, wait and
find out what people do and then fix the standard. (it works, but it isn't
very efficient)

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

I didn't say that CSS was a hack. The hack that I am referring to is a
particular attribute in HTML.

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

You do not have to create a new DOM for XML attributes. The DOM that is
already widely implemented supports XML attributes! I'm trying to get the
maximum advantage from that fact!

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

By lumping computers and televisions together, as if they exerted a 
single malign influence, pessimists have tried to argue that the 
electronic revolution spells the end of the sort of literate culture 
that began with Gutenberg’s press. On several counts, that now seems 
the reverse of the truth.

http://www.economist.com/editorial/freeforall/19-12-98/index_xm0015.html

Received on Sunday, 11 April 1999 04:51:30 UTC