[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: CSS and XSL

---

---

At 07:35 AM 2/14/99 -0600, Paul Prescod wrote:
>I don't think that there is any value in changing venue this late in the
>thread. You seemed to misunderstand my proposal so hopefully we can come
>to agreement once you understand it. Also, as a practical matter I expect
>the readers of XSL-list to have more of an interest in applying style to
>XML than the readers of "www-style".

Well, if you want the benefit of an audience stacked in your favor, I
suppose that's all right.  As a practical matter, I expect the readers of
www-style to have more experience with (and interest in) CSS than the
readers of XSL-list, but okay.

Also, please don't assume that all 'misunderstandings' can be smoothed over
and lead to agreement.  On a fundamental level, I think we disagree.  What
you see as a brutal impedance mismatch I see as a positive feature keeping
styling and structure out of each other's way.

>"Simon St.Laurent" wrote:
>> 
>> Well, actually if I wanted to hard-code, or default particular CSS
>> properties, I'd do it in an external sheet - that's what they're for, and
>> that's why it's called 'cascading'.  
>
>We're talking about the situation where someone wants *inline style*.

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.

>> Constrain?  Unless I was the
>> over-zealous corporate designer who wants to force everyone into a
>> particular letterhead, I probably wouldn't want to do that.
>
>Or maybe you are trying to comply with federal laws, the violation of
>which are cause for shutting down your corporation. Or maybe you just need
>a B element that consistently generates bold. There are terabytes on top
>of terabytes of data in the world where the only thing you can say about
>an element is that it should be bold.
>
>If inline CSS style makes sense then #FIXing or defaulting it makes just
>as much sense.

If your constraints are really that critical, then yes, you should specify
the style - all of the style - and use #FIXED on the style attribute to
keep anyone from messing with it.  Can't say I know of any cases where
using italic instead of bold gets your corporation shut down, but maybe
your federal government is harsher than the one I'm familiar with.  (And I
speak as someone who recently spent three months sorting out the IRS
cashing my check and losing the record that they'd cashed it.) As for bold,
if that's all you want, style="font-weight:bold;" will do the trick quite
nicely.  It'll even play nice with external style sheets, making certain
that your B elements stay bold whatever other styling may be applied.

>> I could, of course, define style with a #FIXED value, if I really wanted,
>> but why?
>
>As it is, you can define style with a #FIXED value, but that fixes *all*
>of the style values at once. If you don't comply with XML conventions
>XML's features (like #FIXED) don't "work right."

Given the terrifying and/or highly constrained situations you described
above, I'd say it works perfectly.

>> Making CSS style sheets use an XML vocabulary is fine with me.  Making
>> every application that allows a local override of those styles declare an
>> enormous mess of attributes to represent every possible property seems like
>> a giant waste of time, processing, and energy.  
>
>Who is suggesting that? I said that when CSS is used *inline* in XML
>documents it should use XML conventions. I didn't say that CSS must always
>be used inline in XML documents. Two different issues.

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.  It may be that I lack sympathy with your need to put
styles in straitjackets, but I don't see why your concerns are worth
exploding CSS style information into a billion different attributes to
represent each property separately.

>> Yeah, aligning it is real simple:
>> 
>> <!ATTLIST myElement
>>         style CDATA #IMPLIED>
>> 
>> Making it align with _your_ conventions, on the other hand, is a different
>> matter that makes lots of people's lives much more complicated.
>
>The convention of using separate attribute values for each property of an
>element is not "my" convention. It is the XML convention used by everyone
>except SVG. You haven't presented any evidence that separate attributes
>would make anyone's life more complicated. You should say something soon
>because the XSL formatting object paradigm uses separate attributes and if
>they are going down the wrong path then they should know.

Maybe this is better put as the 'XML convention used by everyone [except
those who disagree that it is a convention appropriate to all cases]'.

If XSL wants to use separate attributes, dandy for them.  The XSL group is
working with a very different processing model than CSS, has a very
different set of interests, and a totally different perspective.  It's not
necessary for CSS, where there are already plenty of opportunities to set
properties separately.  If the CSS folks want to create a convention for
doing so in XML documents, they're welcome to do so.  Personally, I think
_forcing_ everyone to do so is misguided at best.

Let's see here.

<!ENTITY % css-atts "
css:style	CDATA	#IMPLIED
">

or 

<!ENTITY % css-atts "
css:margin-top	CDATA	#IMPLIED
css:margin-bottom	CDATA	#IMPLIED
css:margin-right	CDATA	#IMPLIED
css:margin-left	CDATA	#IMPLIED
css:margin	CDATA	#IMPLIED
css:padding-top	CDATA	#IMPLIED
css:padding-right	CDATA	#IMPLIED
css:padding-bottom	CDATA	#IMPLIED
css:padding-left	CDATA	#IMPLIED
css:padding	CDATA	#IMPLIED
css:border-top-width	CDATA	#IMPLIED
css:border-bottom-width	CDATA	#IMPLIED
css:border-left-width	CDATA	#IMPLIED
css:border-right-width	CDATA	#IMPLIED
css:border-width	CDATA	#IMPLIED
css:border-top-color	CDATA	#IMPLIED
css:border-right-color	CDATA	#IMPLIED
css:border-bottom-color	CDATA	#IMPLIED
css:border-left-color	CDATA	#IMPLIED
css:border-color	CDATA	#IMPLIED
css:border-top-style	CDATA	#IMPLIED
css:border-right-style	CDATA	#IMPLIED
css:border-bottom-style	CDATA	#IMPLIED
css:border-left-style	CDATA	#IMPLIED
css:border-style		CDATA	#IMPLIED
css:border-top	CDATA	#IMPLIED
css:border-right	CDATA	#IMPLIED
css:border-left	CDATA	#IMPLIED
css:border-bottom	CDATA	#IMPLIED
css:border	CDATA	#IMPLIED
css:display	(inline | block | list-item | run-in | compact | marker | table
| inline-table | table-row-group | table-header-group | table-footer-group
| table-row | table-column-group | table-column | table-cell |
table-caption | none | inherit)	"inline"
css:position	(static | relative | absolute | fixed | inherit) "static"
css:top	CDATA	#IMPLIED
css:right	CDATA	#IMPLIED
css:left	CDATA	#IMPLIED
css:bottom	CDATA	#IMPLIED
css:float	(left | right | none | inherit)	#IMPLIED
css:clear	(left | right | none | both | inherit) "none"
css:z-index	CDATA	#IMPLIED
css:direction	CDATA	(ltr | rtl)
css:unicode-bidi	(normal | embed | bidi-override | inherit)	normal
[etc...]
">

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.  

Remember, CSS is about styling 'in-place', without a transformation and
without formatting objects.  The syntax proposed in the note described one
possibility for using CSS to create FO-like elements, which is hardly the
way CSS is typically used in its 'native' environment.

Earlier this week I said I'd stop griping about XSL; I'd appreciate it if
you'd stop griping about CSS.  Have you ever actually used CSS? On a large
scale project?  Just curious.

Simon St.Laurent
XML: A Primer / Building XML Applications (April)
Sharing Bandwidth / Cookies
http://www.simonstl.com


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

---