W3C home > Mailing lists > Public > www-forms@w3.org > October 2003

RE: Will Internet Explorer support XForms

From: Mark Birbeck <Mark.Birbeck@x-port.net>
Date: Tue, 14 Oct 2003 10:09:02 +0100
Message-ID: <E3ED00A7C285EE408679DE2A26D1C7810148F7F3@S007.x-port.net>
To: 'Dharmesh Mistry' <dharmesh@edgeipk.com>
Cc: www-forms@w3.org, XForms@yahoogroups.com


> I was aware that style sheets could control fonts and backgrounds, but not
> as Mark as pointed out, they could define controls. How far does this go?
> My concern is looking at examples, especially with plug-ins, that things
> like sliders and shapes of say radio buttons were under the control of the
> plug-in. But if what you are saying is that they can be controlled by a
> style sheet this resolves one issue.

I would say they *should* be controlled by a stylesheet, but it is early
days yet! I think things will get better and better as the software evolves,
though. I'll give an illustration of how I see things evolving:

Let's look at xforms:message. Most implementations would treat this as an
instruction to display some operating system defined message box - and
indeed that is how we did it originally if formsPlayer. There are two
problems though; the first is that if there is an xforms:output inside the
message, and the instance data changes whilst the message is being rendered,
it's very difficult to get the message to change. This is because most
implementations have handed over control of the message to some message
renderer, and won't get control back again until the message disappears.

The second problem relates more directly to the issues you are raising, to
do with branding. It seems wrong to require a programmer to specify the look
and feel of messages in some external configuration file - especially since
we already have a mechanism, CSS.

So the solution would seem to be to use the xforms:message element as the
message itself. The forms processor can dynamically add 'OK' and 'Cancel',
title bars and so on, and then hide and show the element as required by the
message events. That way a form designer has complete control over how the
message looks via CSS.

This is in fact how we have now implemented messages in more recent versions
of formsPlayer, because we are trying to push 'customisation' as far as
possible. I use it mainly to illustrate how it's possible to 'fold'
everything into the CSS framework. And once things are in the CSS framework
you can customise pretty much anything you want.

Of course, to go all the way and provide complete customisation, we would
need to have further CSS properties that say how the added message features
should look - the 'OK' and 'Cancel', title bar and so on. And the same would
go for parts of complex controls, such as sliders, and so on.

> Is this anywhere I could read up on more specially defining look and feel
> of form controls?

It doesn't cover as many of the 'parts' of a control as we have been
discussing, but you can get a feel for where the CSS people are going with
all of this from:


Other CSS work is at:




Mark Birbeck
x-port.net Ltd.
Received on Tuesday, 14 October 2003 05:11:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:09 UTC