Re: Status of XSL and CSS?

Chris Lilley wrote:
> 
> That is your assertion, not mine. Now you claim to know the conformance
> requirements for SVG. Can you quote them for me? Where did you get them
> from? Can I have a copy?

I don't have the full conformance requirements but I have the hint
relating to bicubic resampling. Nevertheless, it stands to reason that if
SVG's conformance requirements are going to be useful they will have to
exclude renderings of particular drawings that bear no resemblence to the
intended rendition. I will be very annoyed if I save my drawing in
CorelDraw and load it in Visio and find that it has a totally different
"interpretation" of it. 
You could leave all rendering choices up to the vendors but I think that
it would be a big mistake. "Trust your browser" does not apply to vector
graphics.

> The title, desc and text elements are also generic markup and can also
> be represented on all these output media.

So SVG has three semantic element types. That doesn't really change the
nature of the rest of the elements in SVG!

> The divide you are depicting can be crossed; it is possible to have a
> graphics markup language that still retains structured text, and that
> structuured text can be displayed in various ways on various media.

Nobody disputes that! I'm not talking about the structured text *inside*
an SVG diagram. The lines, circles and images have a range, but not an
infinite range, of correct renderings.

> > How is it that 180 magical CSS properties in a special syntax is not a
> > problem but 180 attributes are?
> 
> Because you have to invent a mechanism - alluded to for xml:lang but not
> actually made explicit - to allow them to inherit correctly and to still
> cascade correctly. 

There is no need to invent something. You are merely changing the syntax
of an already defined formalism. Each attribute maps to a CSS property.
The effective property determination is done according to CSS rules. In
code, it would probably done with a CSS engine.

Maybe some day we would want to formalize this mechanism separate from CSS
if it is useful elsewhere, but we don't have to.

> CSS already has such a mechanism. 

And we should use it. I'm not saying that we need to change CSS's data
model. The data model is fine. The *syntax* should be customized for each
host environment. When the host environment is XML, XML has a mechanism
for describing named properties: the attribute/value pair. I'm talking
about changing the syntax and *that's all*.

> And then you have
> to extend the XML DOM to account for this and to allow the fact that
> some folks will stuill want to majke a disticntion between an attribute
> that was physically present, one that was not physically present but was
> inherited, and one which was physically present but was overridden buy a
> more specific rule .... alternatively, you have to explicitly put the
> value of every one of thos eattributes on every element, and do away
> with cascading and ingeritance altogether.

Why do you have to extend the XSL DOM? There is a CSS DOM. It *is* the
extension to the XSL DOM.

> See above. Come on Paul, you made this same suggestion in the past and
> you backed off when I showed there were problems with specifics. Now you
> are doing it again.

For the record, the last discussion on this topic ended when you did not
respond to this message:

http://www.mulberrytech.com/xsl/xsl-list/archive/msg02707.html

I said then, as I say now, that the CSS DOM should continue to be used.
even when SVG's syntax is made more XML-friendly.

> Either redesign CSS in XML completely, or leave it alone; don't go
> suggesting an initially plausible sounding syntax change and then giving
> the impression that the details will somehow sort themselves out.

Since all I am proposing *is* a syntax change there isn't anything more to
work out. The CSS data model already describes everything else!

> Perhaps you could work through some examples to show how this would
> work. From here, it looks like it is full of holes.

<svg:rectangle background-color="#FFFFFF" foreground-color="#000000" ...
/>

This is equivalent in every way to the same element with a STYLE
attribute. CSS inheritance works exactly the same. After all, the
mechanism for hosting CSS in another language is *not defined in CSS*.
Therefore I am not describing a change to CSS at all.

> <p style="font-family: Helvetica'"} *is* a one line stylesheet.

I presume you meant an angle bracket at the end. So in your opinion the
application of CSS to a single element through a style attribute makes
that style attribute a "stylesheet" despite the fact that that definition
makes the word completely incompatible with the historical notion of
stylesheet and with every stylesheet implementation in existence?

> Well, it would if your syntax was correct ;-) but yes, it does. Can't
> you see the difference? One has an attribute with a suggestive sounding
> name; the other has a CSS style attribute and thus, is a CSS style rule.

According to the CSS grammar that attribute is neither a CSS stylesheet
nor a CSS rule. It is at best a CSS declaration.

> > 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.
> 
> That is because the term "svg viewer" was loosely defined, so  I can see
> how you drew that conclusion. When images are off, an SVG viewer is not
> used.

Right. So there is not intended to be such thing as a SVG viewer for
braille or a TTY. That's what I claimed. That's rational.

> Well equally it isn't very productive to make bold and informed-sounding
> statements about what will happen and how the sky will fall down.

No, the sky won't fall down. People will ignore the parts of SVG that were
intended to give them features that they don't want (SGML's concur, XML's
"standalone declaration", CSS's client-side cascading). They will also
work around the parts that make their lives harder. Heaven knows they have
a huge tolerance for doing that sort of thing! In fact, only a small
number of people will ever know or care that a mistake was made.

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

But I am. I used the word "hack" you defensively claimed I was calling CSS
a hack. I pointed out that I was talking about HTML, not CSS.

The STYLE attribute hack is not defined in CSS. Therefore its introduction
in SVG cannot be blamed on CSS.

--
 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 Wednesday, 14 April 1999 20:47:22 UTC