next »

[.]

Is it possible to create a new pseudo selector for when an input field is empty? This would allow for mandatory fields that have no entries to be highlighted automatically.

Something like:
  <Style name=".mandatory:empty">
     <StyleAttribute name="backgroundColor" value="lightGreen" />
  </Style>


In the form:

EDIT f001 = FORMONLY.required_field, STYLE="bg_white size5 mandatory";


Thanks

Jeff
PS: Is this okay in here, or should it be in the mailing list?

[Bernard M.]

Yes, Jeff the technical forum is the right place for your request. I guess people have just to take the habit.

I've registered you request as feature request #Fz.2422.

Thanks for the suggestion.

[.]

Jeff,

I presume you expect the style to be applyed "live", i.e. when the user enters data in the field, the color changes, right ?

This may raise an performance issue: currently, styles are applyed:

• on creation
• on focus in / focus out
• when changing state (active, dialogType...)

With this, we would need to recompute and reapply styles on the current field on each keystroke, which may slow the program.

To be tested !.

Is there any other pseudo selector you would like to see in further versions ?

We've already registred some requests about table (last row, header), we're also thinking about platform pseudo selector (osx, win, lnx...)...

Pierre-Nicolas

[.]

Pierre-Nicolas, 

Would you expect COLORWHERE to one-day be handled by a pseudo-selector, something like...

Code

EDIT f001 = formonly.value, STYLE="financial";

Code

<Style name="financial:where(<0)" >
   < StyleAttribute name="textColor" value="red" />
</Style>

Reuben

[.]

Jeff,

I presume you expect the style to be applyed "live", i.e. when the user enters data in the field, the color changes, right ?

This may raise an performance issue: currently, styles are applyed:

• on creation
• on focus in / focus out
• when changing state (active, dialogType...)

With this, we would need to recompute and reapply styles on the current field on each keystroke, which may slow the program.

To be tested !.

Is there any other pseudo selector you would like to see in further versions ?

We've already registred some requests about table (last row, header), we're also thinking about platform pseudo selector (osx, win, lnx...)...

Pierre-Nicolas

Hi Pierre-Nicolas.

I wouldn't expect this to react during the edit of the field, 'after field' would be good enough for most people I would imagine. As we set a general ':focus' colour anyway I would expect the field to have taken on that colour whilst the user is editing the field.

As for other selectors, I think my needs are fairly well met at the moment although last row sounds like a good idea.

Thanks

Jeff

[.]

Thanks for your feedback.

The next thing to decide is the priority of this selector.
Today, the :focus is the most important selector.

Should :empty (or whatever the name of this selector can be) have higher or lower priority ?
i.e. do you expect your current field be red because it's empty, or light orange because it's the current field ?

Personnaly, I would expect :focus to remain top priority.

[.]

Pierre-Nicolas, 

Would you expect COLORWHERE to one-day be handled by a pseudo-selector, something like...

...

Reuben

Hi Reuben,

This was not expected, but it looks like something useful, right ?
We need first to check:

• can this be done in GWC too (the team is working hard to support "GDC style" 4st, it would not be a good idea to add new styles that can hardly be managed in GWC)
• what is really supported in COLORWHERE (must be check with DVM team, I must admit I never look to much at this :) )

What was proposed a long time ago was to use STYLEWHERE instead of COLORWHERE:

• everything is centralized in the DVM (no need to implement this in all front ends)
• 100% the same behavior as COLORWHERE as it would be exactly the same code on the DVM side

Not sure which one is the best solution. As a lazy guy I would vote for STYLEWHERE so GDC is ready, but this blows GWC's smart field mode - so maybe both solutions ?

[.]

Thanks for your feedback.

The next thing to decide is the priority of this selector.
Today, the :focus is the most important selector.

Should :empty (or whatever the name of this selector can be) have higher or lower priority ?
i.e. do you expect your current field be red because it's empty, or light orange because it's the current field ?

Personnaly, I would expect :focus to remain top priority.

Hi Pierre-Nicolas,

I think your expectation is correct. :focus should remain the highest priority, so in your example (:focus = orange, :empty=red) the field would be red until it got focus, then would become orange. On exiting the field it would either revert to red if left empty or default to normal if an entry has been made. This should only happen after the field has been exited - not during edit.

If the field is the first entry field it would still start orange because it has focus and only ever go red if the user moves off the field having left it blank. This would work because the users focus has already been drawn to the field because it was the first field.

Thanks

Jeff

[Tady D.]

I think your expectation is correct. :focus should remain the highest priority, so in your example (:focus = orange, :empty=red) the field would be red until it got focus, then would become orange. On exiting the field it would either revert to red if left empty or default to normal if an entry has been made. This should only happen after the field has been exited - not during edit.

If the field is the first entry field it would still start orange because it has focus and only ever go red if the user moves off the field having left it blank. This would work because the users focus has already been drawn to the field because it was the first field.

Thanks
snow rider 3d

Jeff

I also agree with your point of view. Priority must be given to orange before this is the core to attract attention.

[Victor G.]

Jeff,

I presume you expect the style to be applyed "live", i.e. when the user enters data in the field, the color changes, right ?

This may raise an performance issue: currently, styles are applyed:

• on creation
• on focus in / focus out
• when changing state (active, dialogType...)

With this, we would need to recompute and reapply styles on the current field on each keystroke, which may slow the program.

To be tested !.

Is there any other pseudo selector you would like to see in further versions ?

We've already registred some requests about table (last row, header), we're also thinking about platform pseudo selector (osx, win, lnx...)...
coreball
Pierre-Nicolas

Hi Pierre-Nicolas.

I wouldn't expect this to react during the edit of the field, 'after field' would be good enough for most people I would imagine. As we set a general ':focus' colour anyway I would expect the field to have taken on that colour whilst the user is editing the field.

As for other selectors, I think my needs are fairly well met at the moment although last row sounds like a good idea.

Thanks

Jeff

'After field' is an adequate description of this concept, thus it's worth thinking about. Because I also changed the default ':focus' color, I thought the field would inherit that hue.