W3C home > Mailing lists > Public > www-forms@w3.org > April 2002

RE: XForms UI controls customization with CSS and SVG

From: Plechsmíd Martin <Martin.Plechsmid@merlin.cz>
Date: Wed, 24 Apr 2002 08:51:49 +0200
Message-ID: <E50028F23FC6D3118B7D00609761083F015E71E9@merkur.merlin.cz>
To: "'Micah Dubinko'" <MDubinko@cardiff.com>, "'Roman Huditsch'" <roman.huditsch@hico.com>, Antoine Quint <antoine@graougraou.com>, XForms <www-forms@w3.org>

you write that XForms are meant to be combined with elements of another
namespace that provides formatting information. 

In contrast, we (in our project) have chosen another approach - the forms
are written purely in an abstract way using XForms elements only and using
an external file with sligtly extended analogy of CSS formatting
information. There are only few things which we miss in XForms and that
force us to use e.g. XHTML at some places for some particular purposes (e.g.
some kind of <text> element), otherwise these "abstract" forms are
completely satisfactory. The reason why we've chosen such an approach is in
that we wanted to completely separate the content of the forms from the
presentation information - and XHTML serves merely for formatting purposes.

From the point of view I just described, I don't think introduction of the
"style" attribute would be a good idea. On the other hand, the "class"
attribute is almost necessary, otherwise it would be very difficult to
attach a particular formatting information to a collection of elements of
the same type (e.g. to any element of "address" type). As to how often the
"class" attribute is used in various xml namespaces, it would be probably
better to put it into a separate namespace and reuse it from these various
namespaces, as like as the "xml:base" or "xlink:href" - but this we cannot
solve here. 

So, what I miss to be able to write forms purely abstractly are elements of
this kind: <text>, <em>, <subcaption>, <icon> etc. I know, these elements
shouldn't be part of the XForms language, they should belong to a more
general document-description language, but I don't know any (though I
haven't sought for any), and XHTML is not a good alternative. And I miss the
possibility to make an XForms button disabled and a particular xforms:input
form field read-only, but this is a little different story.


> -----Pùvodní zpráva-----
> Od: Micah Dubinko [mailto:MDubinko@cardiff.com]
> Odesláno: 23. dubna 2002 21:32
> Komu: 'Roman Huditsch'; Antoine Quint; XForms
> Pøedmìt: RE: XForms UI controls customization with CSS and SVG
> XForms is meant to be included in another document type (such 
> as XHTML or
> SVG, etc.) which usually already includes class and/or style 
> attributes. So,
> ultimately, the question of whether to include these 
> attributes will be
> addressed by the integrator.
> (Look for specs named 'XHTML+XForms', 'SVG+XForms', and so 
> on...) These can
> be produced by the W3C or anyone else.
> Thanks,
> .micah
> -----Original Message-----
> From: Roman Huditsch [mailto:roman.huditsch@hico.com]
> Sent: Thursday, April 18, 2002 9:23 AM
> To: Antoine Quint; XForms
> Subject: AW: XForms UI controls customization with CSS and SVG
> I would also prefer a style attribute beside the class 
> attribute for most of
> the XForms UIs because of all the reasons Antoine mentioned.
> wbr,
> Roman
Received on Wednesday, 24 April 2002 05:51:48 UTC

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