Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 3.1.0.BETA2, 3.1
-
Component/s: ACE-Components
-
Labels:None
-
Environment:ICEfaces 3, ACE Components
-
Assignee Priority:P1
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial
Description
A useful new feature applicable to all ACE entry / input components is to add standard theme style support for indicating that a component has one of the following states:
- Required - If the component is "required=true", a custom style can be used to visually indicate its "required" status. Might also want to consider a custom renderer mode that would render additional markup (such as an asterisk character).
- Invalid - If the component is in an invalid state (has failed validation during it's most recent execution) a custom theme style can be used to visually indicate its "invalid" status (such as surrounding it with a thick red border, etc.).
By adding standard style-classes to all ACE input components for these states it becomes straightforward for users to customize this styling as needed.
- Required - If the component is "required=true", a custom style can be used to visually indicate its "required" status. Might also want to consider a custom renderer mode that would render additional markup (such as an asterisk character).
- Invalid - If the component is in an invalid state (has failed validation during it's most recent execution) a custom theme style can be used to visually indicate its "invalid" status (such as surrounding it with a thick red border, etc.).
By adding standard style-classes to all ACE input components for these states it becomes straightforward for users to customize this styling as needed.
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
The components are TextEntry, MaskedEntry, AutoCompleteEntry and DateTimeEntry.
Initial work checked in under ICE-7824 at revision: 29145.
Note that "required/optional" style classes should always appear before the "invalid" style class in the list, so the invalid style can override the others by default.
Changed to put "required/optional" style classes before the "invalid" style class.
Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\renderkit\InputRenderer.java
Completed: At revision: 29210
But the order of the style classes actually doesn't matter. It's the order of the style rules that really matters. See screenshot-01.png.
"The order in the class="..." has no effect - if all else is equal, it will prefer the styles from the last-defined declaration." – http://www.gamedev.net/topic/442842-css-precedence-when-element-is-assigned-multiple-classes/page__view__findpost__p__3933089
"Note that it's the order of the rules in the stylesheet that controls which takes precedence; the order of the class names in the class attribute is irrelevant." – http://css-discuss.incutio.com/wiki/Multiple_Classes
"If any rules overlap between the two classes then the class which is below the other in the CSS document will take precedence." – http://evolt.org/node/60369/
"if two declarations have the same weight, origin and specificity, the latter specified wins." – http://www.w3.org/TR/CSS2/cascade.html#cascading-order
(Nowhere in the CSS spec is it mentioned that the order of names in the class attribute can affect specificity.)
"The list of class names is considered unordered; that is, the order of the names within the space-delimited list has no semantic meaning." – "jQuery in Action," 2nd Edition, p. 66.
"If multiple class names are specified, then the order is considered unimportant." – "Professional JavaScript for Web Developers," 3rd Edition, p. 362.