Orbeon Forms community mailing list

Style problem with OPS 3.0 Beta 4 release

Classic

List

Threaded

7 messages Options

Ryan Puddephatt

Style problem with OPS 3.0 Beta 4 release

Hi All,

I have just downloaded and updated a 3.0 Beta 3 unstable build 17^th Nov 2005 application to the Release version of 3.0b4. After a bit of refreshing I got it all to work fine and the back button issue is irradicated ;-)

I previously had the following input on my page :

<xforms:input

ref="summaryFinancialTreeIDDisplayString"

id="profitCenterPath"

xhtml:style="background-color:white;border: 0px white; width: 100%;"

xhtml:readonly="true">

</xforms:input>

This should show the an uneditable input with and id of “profitCenterPath” which has no border and covers the screen, instead the following code is produced in view-source :

<span id="profitCenterPath" class="xforms-control xforms-input" style="background-color:white;border: 0px white; width: 100%;" readonly="true"><span class="xforms-date-display"></span><input type="text" name="profitCenterPath" value="" class="xforms-input-input xforms-type-string"><span class="xforms-showcalendar xforms-type-string"></span></span>

This creates a standard input box with no styling as it has been applied to the span

Is this a bug?

Thanks

Ryan Puddephatt

Web Developer

TFX Group

1 Michaelson Square

Livingston

West Lothian

Scotand

EH54 7DP

* [hidden email]

( 01506 407 110

7 01506 407 108

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Alessandro Vernet

Re: Style problem with OPS 3.0 Beta 4 release

Administrator

Hi Ryan,

You have a good point. It used to be the case that an <xforms:input>
was simply translated into an <xhtml:input type="text">. Now we
generate more HTML to take into account the fact that an XForms input
can take different forms depending on the type of the node it is bound
to.

In particular if the node has the type xs:date, you will see a date
picker. So in the generated HTML you get the HTML input, the date
picker, and all this is put inside a span. Now when you specify a
class or style on the <xforms:input>, do you want this class on the
containing span (what we do now), the input field, the date picker, or
several of those?

Do you, or anyone here, see a good way to solve this problem?

Alex

On 12/8/05, Ryan Puddephatt <[hidden email]> wrote:

>
>
>
> Hi All,
>
> I have just downloaded and updated a 3.0 Beta 3 unstable build
> 17th Nov 2005 application to the Release version of 3.0b4. After a bit of
> refreshing I got it all to work fine and the back button issue is
> irradicated ;-)
>
>
>
> I previously had the following input on my page :
>
>
>
> <xforms:input
>
> ref="summaryFinancialTreeIDDisplayString"
>
> id="profitCenterPath"
>
> xhtml:style="background-color:white;border: 0px white; width: 100%;"
>
> xhtml:readonly="true">
>
> </xforms:input>
>
>
>
> This should show the an uneditable input with and id of "profitCenterPath"
> which has no border and covers the screen, instead the following code is
> produced in view-source :
>
> <span id="profitCenterPath" class="xforms-control xforms-input"
> style="background-color:white;border: 0px white; width: 100%;"
> readonly="true"><span class="xforms-date-display"></span><input type="text"
> name="profitCenterPath" value="" class="xforms-input-input
> xforms-type-string"><span class="xforms-showcalendar
> xforms-type-string"></span></span>
>
>
>
>
> This creates a standard input box with no styling as it has been applied to
> the span
>
>
>
> Is this a bug?
>
>
>
> Thanks
>
>
>
> Ryan Puddephatt
>
> Web Developer
>
> TFX Group
>
> 1 Michaelson Square
>
> Livingston
>
> West Lothian
>
> Scotand
>
> EH54 7DP
>
>
>
> * [hidden email]
>
> ( 01506 407 110
>
> 7 01506 407 108
>
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email]
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>

--
Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

Ryan Puddephatt

RE: Style problem with OPS 3.0 Beta 4 release

Hi Alex,
I would personally say I would want the styles applied to the
<input> as the styles I'm setting would only occur for the input itself. The
span surrounding it would probably not have any styles set. I can't see any
reason for changing the date picker, but if you did need to I would have
though it would be a global change in which case you could amend the style
in the CSS file.

I don't know how other people feel about this? Or if anyone has a better
solution?

Thanks

Ryan Puddephatt
Web Developer
TFX Group
1 Michaelson Square
Livingston
West Lothian
Scotand
EH54 7DP

* [hidden email]
( 01506 407 110
7 01506 407 108

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Alessandro
Vernet
Sent: 10 December 2005 00:41
To: [hidden email]
Subject: Re: [ops-users] Style problem with OPS 3.0 Beta 4 release

Hi Ryan,

You have a good point. It used to be the case that an <xforms:input>
was simply translated into an <xhtml:input type="text">. Now we
generate more HTML to take into account the fact that an XForms input
can take different forms depending on the type of the node it is bound
to.

In particular if the node has the type xs:date, you will see a date
picker. So in the generated HTML you get the HTML input, the date
picker, and all this is put inside a span. Now when you specify a
class or style on the <xforms:input>, do you want this class on the
containing span (what we do now), the input field, the date picker, or
several of those?

Do you, or anyone here, see a good way to solve this problem?

Alex

On 12/8/05, Ryan Puddephatt <[hidden email]> wrote:

type="text"
> name="profitCenterPath" value="" class="xforms-input-input
> xforms-type-string"><span class="xforms-showcalendar
> xforms-type-string"></span></span>
>
>
>
>
> This creates a standard input box with no styling as it has been applied

> the span
>
>
>
> Is this a bug?
>
>
>
> Thanks
>
>
>
> Ryan Puddephatt
>
> Web Developer
>
> TFX Group
>
> 1 Michaelson Square
>
> Livingston
>
> West Lothian
>
> Scotand
>
> EH54 7DP
>
>
>
> * [hidden email]
>
> ( 01506 407 110
>
> 7 01506 407 108
>
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email]
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>

Erik Bruchez

Re: Style problem with OPS 3.0 Beta 4 release

Administrator

You can still style the HTML input element even with the new scheme, by
using something like:

.xforms-input input { ... }

So I don't think this is a real problem. In the future, IMO, the
solution will consist in using CSS pseudo-classes and doing some CSS
rewriting anyway.

-Erik

Ryan Puddephatt wrote:

> Hi Alex,
> I would personally say I would want the styles applied to the
> <input> as the styles I'm setting would only occur for the input itself. The
> span surrounding it would probably not have any styles set. I can't see any
> reason for changing the date picker, but if you did need to I would have
> though it would be a global change in which case you could amend the style
> in the CSS file.
>
> I don't know how other people feel about this? Or if anyone has a better
> solution?
>
> Thanks
>
> Ryan Puddephatt
> Web Developer
> TFX Group
> 1 Michaelson Square
> Livingston
> West Lothian
> Scotand
> EH54 7DP
>
> * [hidden email]
> ( 01506 407 110
> 7 01506 407 108
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Alessandro
> Vernet
> Sent: 10 December 2005 00:41
> To: [hidden email]
> Subject: Re: [ops-users] Style problem with OPS 3.0 Beta 4 release
>
> Hi Ryan,
>
> You have a good point. It used to be the case that an <xforms:input>
> was simply translated into an <xhtml:input type="text">. Now we
> generate more HTML to take into account the fact that an XForms input
> can take different forms depending on the type of the node it is bound
> to.
>
> In particular if the node has the type xs:date, you will see a date
> picker. So in the generated HTML you get the HTML input, the date
> picker, and all this is put inside a span. Now when you specify a
> class or style on the <xforms:input>, do you want this class on the
> containing span (what we do now), the input field, the date picker, or
> several of those?
>
> Do you, or anyone here, see a good way to solve this problem?
>
> Alex
>
> On 12/8/05, Ryan Puddephatt <[hidden email]> wrote:
>
>>
>>
>>Hi All,
>>
>> I have just downloaded and updated a 3.0 Beta 3 unstable build
>>17th Nov 2005 application to the Release version of 3.0b4. After a bit of
>>refreshing I got it all to work fine and the back button issue is
>>irradicated ;-)
>>
>>
>>
>>I previously had the following input on my page :
>>
>>
>>
>><xforms:input
>>
>> ref="summaryFinancialTreeIDDisplayString"
>>
>> id="profitCenterPath"
>>
>> xhtml:style="background-color:white;border: 0px white; width: 100%;"
>>
>> xhtml:readonly="true">
>>
>></xforms:input>
>>
>>
>>
>>This should show the an uneditable input with and id of "profitCenterPath"
>>which has no border and covers the screen, instead the following code is
>>produced in view-source :
>>
>> <span id="profitCenterPath" class="xforms-control xforms-input"
>>style="background-color:white;border: 0px white; width: 100%;"
>>readonly="true"><span class="xforms-date-display"></span><input
>
> type="text"
>
>>name="profitCenterPath" value="" class="xforms-input-input
>>xforms-type-string"><span class="xforms-showcalendar
>>xforms-type-string"></span></span>
>>
>>
>>
>>
>>This creates a standard input box with no styling as it has been applied
>
> to
>
>>the span
>>
>>
>>
>>Is this a bug?
>>
>>
>>
>>Thanks
>>
>>
>>
>>Ryan Puddephatt
>>
>>Web Developer
>>
>>TFX Group
>>
>>1 Michaelson Square
>>
>>Livingston
>>
>>West Lothian
>>
>>Scotand
>>
>>EH54 7DP
>>
>>
>>
>>* [hidden email]
>>
>>( 01506 407 110
>>
>>7 01506 407 108

Ryan Puddephatt

RE: Style problem with OPS 3.0 Beta 4 release

Erik,
I agree this is a solution to the problem, but do you not agree that
there is no real reason why the style attribute of the <xforms:input> should
style the surrounding <span> rather than the element it will transform to,
which is ultimately <input>?

Thanks

Ryan

Ryan Puddephatt
Web Developer
TFX Group
1 Michaelson Square
Livingston
West Lothian
Scotand
EH54 7DP

* [hidden email]
( 01506 407 110
7 01506 407 108

-----Original Message-----
From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik Bruchez
Sent: 12 December 2005 11:16
To: [hidden email]
Subject: Re: [ops-users] Style problem with OPS 3.0 Beta 4 release

You can still style the HTML input element even with the new scheme, by
using something like:

.xforms-input input { ... }

So I don't think this is a real problem. In the future, IMO, the
solution will consist in using CSS pseudo-classes and doing some CSS
rewriting anyway.

-Erik

Ryan Puddephatt wrote:
> Hi Alex,
> I would personally say I would want the styles applied to the
> <input> as the styles I'm setting would only occur for the input itself.
The
> span surrounding it would probably not have any styles set. I can't see
any

> reason for changing the date picker, but if you did need to I would have
> though it would be a global change in which case you could amend the style
> in the CSS file.
>
> I don't know how other people feel about this? Or if anyone has a better
> solution?
>
> Thanks
>
> Ryan Puddephatt
> Web Developer
> TFX Group
> 1 Michaelson Square
> Livingston
> West Lothian
> Scotand
> EH54 7DP
>
> * [hidden email]
> ( 01506 407 110
> 7 01506 407 108
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Alessandro
> Vernet
> Sent: 10 December 2005 00:41
> To: [hidden email]
> Subject: Re: [ops-users] Style problem with OPS 3.0 Beta 4 release
>
> Hi Ryan,
>
> You have a good point. It used to be the case that an <xforms:input>
> was simply translated into an <xhtml:input type="text">. Now we
> generate more HTML to take into account the fact that an XForms input
> can take different forms depending on the type of the node it is bound
> to.
>
> In particular if the node has the type xs:date, you will see a date
> picker. So in the generated HTML you get the HTML input, the date
> picker, and all this is put inside a span. Now when you specify a
> class or style on the <xforms:input>, do you want this class on the
> containing span (what we do now), the input field, the date picker, or
> several of those?
>
> Do you, or anyone here, see a good way to solve this problem?
>
> Alex
>
> On 12/8/05, Ryan Puddephatt <[hidden email]> wrote:
>
>>
>>
>>Hi All,
>>
>> I have just downloaded and updated a 3.0 Beta 3 unstable build
>>17th Nov 2005 application to the Release version of 3.0b4. After a bit of
>>refreshing I got it all to work fine and the back button issue is
>>irradicated ;-)
>>
>>
>>
>>I previously had the following input on my page :
>>
>>
>>
>><xforms:input
>>
>> ref="summaryFinancialTreeIDDisplayString"
>>
>> id="profitCenterPath"
>>
>> xhtml:style="background-color:white;border: 0px white; width: 100%;"
>>
>> xhtml:readonly="true">
>>
>></xforms:input>
>>
>>
>>
>>This should show the an uneditable input with and id of "profitCenterPath"
>>which has no border and covers the screen, instead the following code is
>>produced in view-source :
>>
>> <span id="profitCenterPath" class="xforms-control xforms-input"
>>style="background-color:white;border: 0px white; width: 100%;"
>>readonly="true"><span class="xforms-date-display"></span><input
>
> type="text"
>
>>name="profitCenterPath" value="" class="xforms-input-input
>>xforms-type-string"><span class="xforms-showcalendar
>>xforms-type-string"></span></span>
>>
>>
>>
>>
>>This creates a standard input box with no styling as it has been applied
>
> to
>
>>the span
>>
>>
>>
>>Is this a bug?
>>
>>
>>
>>Thanks
>>
>>
>>
>>Ryan Puddephatt
>>
>>Web Developer
>>
>>TFX Group
>>
>>1 Michaelson Square
>>
>>Livingston
>>
>>West Lothian
>>
>>Scotand
>>
>>EH54 7DP
>>
>>
>>
>>* [hidden email]
>>
>>( 01506 407 110
>>
>>7 01506 407 108

Erik Bruchez

Re: Style problem with OPS 3.0 Beta 4 release

Administrator

I think that's debatable.

An XForms control does not necessarily directly have an HTML
counterpart. Sure, xforms:input and xhtml:input are similar, and
currently we implement xforms:input with xhtml:input. But you don't have
to: you could implement inline editing for example (see
https://wiki.objectweb.org/ops/attach?page=Images%2Ftextfield.png).

> the surrounding <span> rather than the element it will transform to

That's the issue: xforms:input transforms into *several* elements, and
it may not even transform into an xhtml:input. It is fairly simple and
consistent to always copy XHTML attributes on XForms controls to the
outermost HTML element that implements the XForms control, rather than
trying to guess which of the HTML elements that implement it is "closer"
to being the main component of the control.

It should also be noted that in XForms 1.0, the "XForms and Styling"
section is non-normative, and that it only suggests that the host
language add "class" and "xml:lang" attributes on XForms controls. This
means that at this point, we don't have much guidance from the XForms spec.

-Erik

Ryan Puddephatt wrote:
> Erik,
> I agree this is a solution to the problem, but do you not agree that
> there is no real reason why the style attribute of the <xforms:input> should
> style the surrounding <span> rather than the element it will transform to,
> which is ultimately <input>?
>
> Thanks
>
> Ryan

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Ryan Puddephatt

RE: Style problem with OPS 3.0 Beta 4 release

Erik,
I agree that the styling cannot be tailored to every use of the
<xforms:input> I have moved my style into a class, which now does the trick.
Looking at the solution more clearly I can see that the style attribute
really looses its use. I think the solution of attaching attributes to the
highest element, namely <span> will allow the most functionality when it
comes to changing things other than just the input

The implementation works a treat :-)

Thanks Guys keep up the good work!

Ryan Puddephatt
Web Developer
TFX Group
1 Michaelson Square
Livingston
West Lothian
Scotand
EH54 7DP

* [hidden email]
( 01506 407 110
7 01506 407 108

-----Original Message-----
From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik Bruchez
Sent: 12 December 2005 15:18
To: [hidden email]
Subject: Re: [ops-users] Style problem with OPS 3.0 Beta 4 release

I think that's debatable.

An XForms control does not necessarily directly have an HTML
counterpart. Sure, xforms:input and xhtml:input are similar, and
currently we implement xforms:input with xhtml:input. But you don't have
to: you could implement inline editing for example (see
https://wiki.objectweb.org/ops/attach?page=Images%2Ftextfield.png).

> the surrounding <span> rather than the element it will transform to

That's the issue: xforms:input transforms into *several* elements, and
it may not even transform into an xhtml:input. It is fairly simple and
consistent to always copy XHTML attributes on XForms controls to the
outermost HTML element that implements the XForms control, rather than
trying to guess which of the HTML elements that implement it is "closer"
to being the main component of the control.

It should also be noted that in XForms 1.0, the "XForms and Styling"
section is non-normative, and that it only suggests that the host
language add "class" and "xml:lang" attributes on XForms controls. This
means that at this point, we don't have much guidance from the XForms spec.

-Erik

Ryan Puddephatt wrote:
> Erik,
> I agree this is a solution to the problem, but do you not agree that
> there is no real reason why the style attribute of the <xforms:input>
should
> style the surrounding <span> rather than the element it will transform to,
> which is ultimately <input>?
>
> Thanks
>
> Ryan

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws