RE: [xml-dev] CSS as XML

["Jo Rabin" <jrabin@mtld.mobi>]

Ref the cssxml experiment [1] Henry mentioned, some answers to your
questions:

1) > One thing I don't understand is why these approaches emulate so
closely
> the
> original CSS language and syntax.  It seems to me that CSS is a bit

Our requirement was to be able to carry out various validation
activities on CSS, rather than to invent a way of defining the style of
any particular element. From that point of view it's important to stick
closely to the CSS syntax.

It's a nuisance that you can't use the familiar XML tools on CSS. There
aren't that many CSS tools and "results can vary". So the motivation is
to create an equivalent representation in XML and use familiar XML tools
to carry out validation tasks, especially since most of the rest of the
stuff we are processing can be processed with such tools.

2) > For example, styling can be nicely organized by the elements being
styled,
> such as background, text, borders, etc.  This makes a really clear,
simple

Maybe, but since CSS doesn't mind you introducing properties or property
values or units it knows nothing about, it seems important any XML
representation should preserve that at the syntactic level. That's the
motivation behind structuring declarations as e.g.

	<declaration property="padding">
			<value value="10" unit="px"/>
	</declaration>

i.e. we know it is a declaration, we know it must have a property name
and at least one value and sometimes some units, but that's about it.

3) > A final comment is on the selector approach.  It's definitely
easier to
> borrow the current CSS selector syntax since you'll have to convert it
to
> CSS anyway, but it misses the opportunity to progress toward the use
of

I think that using XPath is definitely a useful step towards the goal
outlined in 1). And allows you to make statements that we are really
very interested in making in the mobileOK checker work - e.g. "That
style sheet was 100k and none of its rulesets matched anything in your
document". It's a lot harder to do that if you are processing the CSS
selectors themselves.

That said, I haven't thought all that hard about whether any future CSS
selector syntax could necessarily be represented in XPath so the
conservative approach is to parse the selectors and represent them in a
form that is easily transformed to XPath should you so wish, but equally
could be used for other purposes by familiar XML tools too.

Hence the
		<selector element="p">
			<selector element="p" rel="preceding-sibling">
				<selector element="*" rel="ancestor">
					<condition type="class"
name="picture"/>
				</selector>
			</selector>
		</selector>

Representing a selector:

   .picture p + p 

Like you say, it's a lot more verbose.

Hope that clarifies
Jo

[1] http://dev.w3.org/cvsweb/2007/cssxml/

> -----Original Message-----
> From: Fraser Hore [mailto:fraserhore@hotmail.com]
> Sent: 06 September 2007 20:19
> To: 'Henry S. Thompson'; 'bryan rasmussen'
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] CSS as XML
> 
> Thanks very much for the links to similar initiatives.  I have some
> questions about the other approaches that I'm interested in
perspectives
> on.
> Please take my comments as a line of inquiry as they are not intended
to
> be
> critical in any way of other approaches.
> 
> One thing I don't understand is why these approaches emulate so
closely
> the
> original CSS language and syntax.  It seems to me that CSS is a bit
> outdated
> and not that logically clean.  If we're going to go to XML it might
make
> more sense to restructure things a bit to take advantage of XML's
> strengths.
> 
> 
> For example, styling can be nicely organized by the elements being
styled,
> such as background, text, borders, etc.  This makes a really clear,
simple
> and logical structure:
> 
> <text>
> 	<color unit="rgb"/>
> 	<direction/>
> 	<line-height/>
> 	...
> </text>
> 
> CSS on the other hand seems to have a not entirely consistent naming
> convention.  For example, color defines text color, but you have to
know
> that.  Border-color, border-left-color, background-color, etc. make it
> more
> clear what we're defining the color for, but why do we need define a
> schema
> for all of those different elements.  Why not just define what color
is,
> and
> then use it in each of the contexts, such as:
> 
> <style nodeset="//div[id='@bodyText']">
> 	<text>
> 		<color unit="hex">000000</color>
> 	</text>
> 	<border>
> 		<top>
> 			<color unit="hex">111111</color>
> 		</top>
> 		<bottom>
> 			<color unit="hex">222222</color>
> 		</bottom>
> 	</border>
> </style>
> 
> Admittedly, if you're coding CSS by hand it takes longer to write but
use
> a
> simple xform and it's way faster to code than CSS by hand!
> 
> Other advantages to this structure are that it's super simple to learn
and
> extend, you can make a really clean schema, it's machine readable and
> manipulable, and it's more aligned with standard xml practice.
> 
> Bryan, I can see the advantages in your approach of being able to
quickly
> define styles in only a few lines of code, such as:
> 
> Your approach:
> 
> <selector  id="p1">
> <s name="color">#ff0000</s>
> <s name="font">11pt Times</s>
> </selector>
> 
> My approach:
> 
> <style nodeset="*[id='p1']">
> 	<text>
> 		<color unit="hex">ff0000</color>
> 	</text>
> 	<font>
> 		<size unit="pt">11</size>
> 		<family>times</family>
> 	</font>
> </style>
> 
> A drawback I see is that you would have to extend by adding compound
> attribute values, such as background-color, border-left-color, etc.
So
> basically all attributes are at the same level and you can't take
> advantage
> of xml's hierarchical structure to give meaning.
> 
> Another issue is having multiple values defined in a single element.
For
> instance: "11" "pt" "times".  This could make it harder to parse the
> values
> automatically, it's harder to define the enumeration for allowable
values
> and the user has to know what values can be defined in the element
because
> it's not made explicit.
> 
> A final comment is on the selector approach.  It's definitely easier
to
> borrow the current CSS selector syntax since you'll have to convert it
to
> CSS anyway, but it misses the opportunity to progress toward the use
of
> xpath, which is a powerful and widely used standard for everything
else in
> xml.  Xpath is also probably already more powerful than CSS selectors
and
> definitely seems to be maturing as a language much faster than CSS.
From
> a
> user point of view, if I'm using xpath for xslt, xforms, etc. I'd like
to
> use it for CSS too. Why learn another language that does essentially
the
> same thing?
> 
> Thanks for the comments!?
> 
> Fraser
> 
> -----Original Message-----
> From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk]
> Sent: September 6, 2007 5:39 AM
> To: bryan rasmussen
> Cc: Fraser Hore; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] CSS as XML
> 
> You both might be interested in some exploratory work [1] in this
> space by the W3C mobileOK checker task force [2].
> 
> ht
> 
> [1] http://dev.w3.org/cvsweb/2007/cssxml/
> [2] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Checker/
> --
>  Henry S. Thompson, HCRC Language Technology Group, University of
> Edinburgh
>                      Half-time member of W3C Team
>     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131
650-4440
>             Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
>                    URL: http://www.ltg.ed.ac.uk/~ht/
> [mail really from me _always_ has this .sig -- mail without it is
forged
> spam]
> 
>
_______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> 
> 
> 
>
_______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php