- 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