Re: Status of XSL and CSS?

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

No.

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

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?

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

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

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

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.

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

Okay, good.

> I'm arguing that
> making inline style inconvenient through a previously but not currently
> appropriate attribute hack.

(That doesn't seem to be a full sentence. Can you re-express it?)

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

It is neither being deprecated (it is exoplicitly allowed) nor is it
inconvenient.
> 
> > 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? 

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. CSS already has such a mechanism. 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.

Neither of these options seems desirable or sensible.

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

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.

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.

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

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


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

No.

However,

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

> Now if I use this syntax:
> 
> <P STYLE="Font: Helvetiva">Blah</P>
> 
> Does it become a stylesheet?

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.

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

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. 

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

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.

SVG is being designed explicitly to allow easy use by search engines,
and to allow natural alternative textual representations. So "putting
out the wrong standard" is pretty wide of the mark.

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

As I point out above, if you were to do CSS inheritance and  cascading
while using individual attributes them you would, indeed, have to do
exactly that.

> The DOM that is
> already widely implemented supports XML attributes! I'm trying to get the
> maximum advantage from that fact!

Ok, show me the DOM call that gets the value of the xml:lang attribute
that applies to a given element. For starters.

--
Chris

Received on Sunday, 11 April 1999 14:30:29 UTC