Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@h...] > Sent: 06 September 2007 20:19 > To: 'Henry S. Thompson'; 'bryan rasmussen' > Cc: xml-dev@l... > Subject: RE: 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@i...] > Sent: September 6, 2007 5:39 AM > To: bryan rasmussen > Cc: Fraser Hore; xml-dev@l... > Subject: Re: 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@i... > 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@l... > subscribe: xml-dev-subscribe@l... > 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@l... > subscribe: xml-dev-subscribe@l... > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
