Altova Mailing List Archives


Re: CSS and XSL

From: Paul Prescod <paul@----------->
To:
Date: 2/14/1999 5:51:00 AM
After writing the note that follows it occurred to me that most of it is
not really very technical. It's mostly me defending my requirements as I
perceive them, my motivations (also as I perceive them).

I've pointed out technical problems with the current mechanism with
respect to XSL, the DOM, XML Schemas, XML Query Languages etc. Your only
*technical* argument against, thus far, has been that there will be "too
many attributes." Perhaps you can clarify how this causes problems. I'm
really more interested in the technical issues than the sociological ones.

"Simon St.Laurent" wrote:
> 
> Fine, although inline style is itself something that the style community
> has gone out of its way to discourage repeatedly.  Applying style to a
> particular element within a document doesn't necessarily require using a
> style attribute within the element, either - you can reference the element
> (via an ID, for instance) and use a style sheet custom made for that
> particular document if you really need granularity.  Requires the use of
> external resources perhaps, but the granularity you keep asking for is
> already available.

Let me repeat that I am not arguing against external styles. SVG supports
inline styles. CSS-as-XML supports inline styles. The formatting object
language supports inline style. All I ask is that they be consistent and
all follow XML conventions. 

I'm totally in favour of external styles (where feasible) already.

> If your constraints are really that critical, then yes, you should specify
> the style - all of the style - 

If I have data that must be bold then I don't necessarily want to fix its
size or slant. Or, as another example it isn't hard to think of a
situation where the background-color must be fixed but the border-width
could vary or vice versa. That's why external CSS allows you to specify
their importance separately.

Anyhow, it doesn't make sense to get bogged down in the fixed attributes
example. I've described situations such as the DOM, XSL, Schemas, queries
and others where the single-attribute way makes life harder. There is a
huge amount of infrastructure being erected to work with XML attributes
that will not work cleanly with CSS properties. 

Fixed attributes is only one example. It is even more common for me to
want to allow a single property to vary but no others. I.e. 
<emph weight="" slant=""> but not <emph background-color="">

> And I'm saying that we don't need to force CSS to use your conventions
> because you can achieve the same results quite easily with style sheets
> that are out-of-line. 

So the choice of whether a style should be inline or out-of-line should be
driven by whether you need the ability to work with individual properties
separately? Clean design would suggest that inline vs. outline of should
be completely a style management issue and not driven by weaknesses in the
internal or external style specification model.

> You can do it (I just typed it in), and it might be easier for some
> applications, but processing the style attribute to break it up isn't that
> hard, if you really need your information in that format.

That argument can be used to justify any poor encoding for information.

> Earlier this week I said I'd stop griping about XSL; I'd appreciate it if
> you'd stop griping about CSS.

Why do you want to describe this in terms of a battle between CSS and XSL?
I like CSS and promote it. I did so on XML-DEV within the last two weeks.
Admittedly it isn't as useful/interesting for the mainstream of my work as
XSL is, but that doesn't mean it is useless. I'll also admit that certain
parts of the CSS model strike me as not being nearly as useful as some
people think they are.

I'm not griping about CSS. I'm trying to figure out how to make it useful
for more of what I do. I'm trying to figure out how to mend the rift
between formatting objects and CSS.

Less than three days ago you said: "It's not too late to change CSS.  One
proposal for doing so and making it more XML-friendly was put forward in
[XSL and CSS], and [that] certainly signaled a willingness to accommodate
XML."

But when I actually suggest a change to CSS (or, more precisely, when I
suggest that the conventions from the document you pointed me to and from
the XSL formatting objects should also be applied to SVG) you crucify me.
All of a sudden I'm "griping." The really odd thing is that the sentence
above was *in response to* this same proposal! One minute CSS is ready for
change. The next, I'm griping for asking for the change.

You've confirmed something that I've suspected for a while: I can't
conduct a conversation with you without ending up in the position of "bad
guy." It doesn't matter what I say, nor what the topic, the conversation
follows a very predictable pattern after a couple of days. I don't quite
understand why, but...

> Have you ever actually used CSS? On a large
> scale project?  Just curious.

I have recommended CSS for large projects but my customers always complain
either that the current implementations are too inconsistent (or, more
important) that too many legacy browsers do not support it. They usually
vote to spend their energy on the parts that will give the most immediate
bang for buck. Even if they did accept my advice to use CSS, I am not a
user interface designer so I would not be the one working hands-on with
it. My job would be to get them sufficiently rich data for elegant
styling.

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

If you spend any time administering Windows NT, you're far too familiar 
with the Blue Screen of Death (BSOD) which displays the cause of the 
crash and gives some information about the state of the system when 
it crashed.  -- "Microsoft Developer Network Magazine"


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.