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

Re: Can XForms handle rich text?

From: Robert Simmons <derisor@arcor.de>
Date: Fri, 29 Aug 2003 18:29:31 +0200
To: www-forms@w3.org
Message-ID: <binv0g$mfp$1@sea.gmane.org>

I wholeheartedly DISAGREE. XForms in my mind is a way to declaritively specify
forms that the rendering authority can render as they see fit. In my mind what
you are talkign about is XSLT and not XForms. I certainly would want to keep the
minimum of "appearance" information out of the form. What if someone contacts
your form via a Cellular Phone. Then just exactly how are you going to pop open
microsoft word on a 4 cm x 4cm screen.

If you want to customize appearance you are seriously barking up the wrong tree
in my opinion and should be looking at XSLT.

-- Robert

"Mark Birbeck" <Mark.Birbeck@x-port.net> wrote in message
news:E3ED00A7C285EE408679DE2A26D1C7810148F6EA@S007.x-port.net...
>
> Robert,
>
> You wrote:
> > Why would you want to? XForms is a model for data entry and is not
> > related to presentation logic or data processing at all. Mixing them
> > would be ... bad. In fact the separation of presentation and data entry
> > model is at the core of the driving force for XForms.
>
> I think the original question was perfectly legitimate. Whilst it is true
> that XForms has as a goal the separation of presentation and data, this is
> only at the level of the mark-up. At the core of XForms is the desire to be
> *very* specific in terms of actual run-time presentation. So if a user is
> French, they should see a French calendar when asked for a date, and if they
> are Japanese they should see a Japanese one. If they are blind they should
> have a voice speak to them, and be able to make their selection by speaking.
> Of course at no point in our mark-up should we need to mention French or
> Japanese calendars, or voice systems - we simply ask for the ability to
> input a date - and that is the core of the separation to which you refer.
>
> So, as long as data gets transferred to the instance as (for example):
>
>     <my:article>&lt;b&gt;hello&lt;/b&gt; &lt;i&gt;mum&lt;/i&gt;</my:article>
>
> then it doesn't matter how the user entered it. If it is easier for a user
> of a visual system to highlight some text and then press 'B' on a toolbar to
> make it 'bold', then let them do that. And if it should be done with a
> right-mouse menu, then do that too. As I said before, let's be very specific
> in our run-time rendering, and agnostic in our mark-up.
>
> How we actually indicate this in a general way will probably be established
> as people start to use XForms more and more. One possibility might be to
> agree some values for the @appearance attribute:
>
>     <xforms:textarea ref="my:article" appearance="widgets:rich-text">
>         <xforms:label>Please type your article</xforms:label>
>     </xforms:textarea>
>
> On one platform "widgets:rich-text" might refer to a Microsoft Word control
> in the form, and on another it might be Open Office. Note one of the nice
> features of XForms here, in that since @appearance is only a hint, if the
> device executing the form hasn't got a rich-text editor on it, then we just
> fall back to an ordinary xf:textarea control.
>
> Another possibility might be for XForms processors to be configured to
> invoke a rich-text editor in the same way that a date control is
> instantiated, and all you would need is to define some schema type in your
> instance data and bind it to the correct handler.
>
> Now that XForms 1.0 is stable we have a strong foundation onto which to
> layer features like this - there are some exciting possibilities ahead!
>
> Regards,
>
> Mark
>
>
> Mark Birbeck
> Co-author Professional XML and
> Professional XML Meta Data,
> both by Wrox Press
>
> Download our XForms processor for IE6
> from http://www.formsPlayer.com/
>
> Managing Director
> x-port.net Ltd.
> 4 Pear Tree Court
> London
> EC1R 0DS
>
> E: Mark.Birbeck@x-port.net
> W: www.x-port.net
> T: +44 (20) 7689 9232
>
>
Received on Friday, 29 August 2003 12:29:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:55 GMT