- From: T. V. Raman <tvraman@us.ibm.com>
- Date: Fri, 25 Oct 2002 14:50:33 -0400 (EDT)
- To: Mark Birbeck <Mark.Birbeck@x-port.net>
- Cc: "'www-forms@w3.org'" <www-forms@w3.org>, "'www-style@w3.org'" <www-style@w3.org>
What you bring up is a very useful CSS design point. To summarize what you're saying, it would be nice to be able to specify a mapping between CSS styles and the type of a value (here type == schema type) and further to attain this mapping via a CSS pseudo class. I think the right thing to do might be to have CSS recognize "type" or "datatype" as a pseudo class, in which case this mechanism would work with XForms, but also provide a framework for styling XML documents for which there is a XML Schema available via CSS. >>>>> "Mark" == Mark Birbeck <Mark.Birbeck@x-port.net> writes: Mark> Hello all, Mark> I have tried to see if I am resurrecting an old discussion Mark> on CSS, and can't find it. Apologies if I am. Mark> The issue I'm raising concerns the selection criteria for Mark> CSS, when used with XForms. Mark> INTRO For those on the CSS list who are not familiar with Mark> XForms, a quick intro. With XForms we can have some data in Mark> an XML document that is then bound to a set of UI controls, Mark> using XPath statements. The data might be like this: Mark> <person> <firstName>Mark</firstName> Mark> <surname>Birbeck</surname> </person> Mark> and the UI part of the form might be like this: Mark> <xforms:input ref="person/firstName"> <caption>Please Mark> enter the first name</caption> </xforms:input> <xforms:input Mark> ref="person/surname"> <caption>Please enter the Mark> surname</caption> </xforms:input> Mark> In the main, a lot of things from CSS work quite well. For Mark> example, you can do the following, and the syntax copes Mark> fine: Mark> @namespace xforms "http://www.w3.org/2002/01/xforms"; Mark> xforms|input { display: block; } Mark> This sets all of our input controls to blocks. We can also Mark> set the style on the captions that appear inside input Mark> controls: Mark> xforms|input > xforms|caption { font-weight: bold; Mark> width: 50%; color: white; background-color: #cfd7df } Mark> All pretty much as you would expect. However, we are trying Mark> to find a consistent way of solving two issues at the Mark> moment, and unless we have missed something, we can't seem Mark> to do it within the CSS framework at present: Mark> * ensuring that a particular piece of data is displayed Mark> consistently throughout a site Mark> * ensuring that a particular *type* of data is displayed Mark> consistently throughout a site Mark> CONSISTENT DATA If we wanted all surnames in our system to Mark> be displayed with a red background, we would either have to Mark> add a class attribute to all such xforms:input statements, Mark> or we could use an attribute selector: Mark> xforms|input[ref="person/surname"] { background-color: Mark> #ff0000; } Mark> The problem is that the following input statement refers to Mark> exactly the same node in the instance data: Mark> <xforms:input ref="//surname"> <caption>Please enter Mark> the surname</caption> </xforms:input> Mark> We would now need to add another attribute selector for this Mark> different syntax. Alternatively we could use: Mark> ref$="/surname" Mark> but in other situations this would match elements Mark> incorrectly. Mark> It would be better if there were some way of tying the style Mark> to the source data. One simple possibility would be to have Mark> a pseudo-attribute that takes an XPath statement: Mark> *:bound="person/surname" { background-color: #ff0000; Mark> } Mark> This would affect the style of *any* XForms control that is Mark> bound to a 'surname' element that is a child of a 'parent' Mark> element. Mark> Another possibility is to put the onus back onto XForms. In Mark> CSS we would just use the normal syntax to say that any Mark> element of type 'surname' that appears underneath an element Mark> of type 'person' is to be shown with a red background: Mark> person > surname { background-color: #ff0000; } Mark> There would never be an element 'surname' in the actual UI Mark> part of the form, but what we could then do is modify the Mark> styling part of XForms and say that the style of a control Mark> is a combination of the style of the control elements *and* Mark> the style of the underlying data elements. These two would Mark> both be applied to our surname control: Mark> xforms\:input { display: block; } person > surname { Mark> background-color: #ff0000; } Mark> Although this takes the burden off CSS, I think ultimately Mark> that it is the weaker solution. Mark> CONSISTENT DATA TYPES A related issue concerns the type of Mark> the underlying data that is being bound to. It should be Mark> possible to say that all controls that bind to a date are Mark> shown in one way, all integers in another. For example: Mark> *:dataType="xsd:integer" { background-color: #ff0000; Mark> } Mark> All UI controls that have as their underlying data an Mark> integer will now be shown with a red background. Mark> If XForms is set to become the 'forms module' for XHTML, Mark> then it seems to me that CSS will need some way of handling Mark> the link between underlying data and the user interface used Mark> to manipulate that data. Mark> Best regards, Mark> Mark Mark> Mark Birbeck Co-author Professional XML and Professional XML Mark> Meta Data, both by Wrox Press Mark> See x-port's XForms plug-in for IE, at Mark> http://www.FormsPlayer.com/ Mark> Managing Director x-port.net Ltd. 4 Pear Tree Court London Mark> EC1R 0DS Mark> E: Mark.Birbeck@x-port.net W: www.x-port.net T: +44 (20) Mark> 7689 9232 -- Best Regards, --raman ------------------------------------------------------------ T. V. Raman: PhD (Cornell University) IBM Research: Human Language Technologies Architect: Conversational And Multimodal WWW Standards Phone: 1 (408) 927 2608 T-Line 457-2608 Fax: 1 (408) 927 3012 Cell: 1 650 799 5724 Email: tvraman@us.ibm.com WWW: http://www.cs.cornell.edu/home/raman AIM: TVRaman PGP: http://emacspeak.sf.net/raman.asc Snail: IBM Almaden Research Center, 650 Harry Road San Jose 95120
Received on Wednesday, 30 October 2002 12:35:55 UTC