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
- 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
| Field | Original Value | New Value |
|---|---|---|
| Salesforce Case | [] | |
| Fix Version/s | 3.1 [ 10312 ] | |
| Affects | [Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial] |
| Salesforce Case | [] | |
| Assignee Priority | P1 | |
| Assignee | yip.ng [ yip.ng ] |
The components are TextEntry, MaskedEntry, AutoCompleteEntry and DateTimeEntry.
Initial work checked in under ICE-7824 at revision: 29145.
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #29210 | Fri May 25 17:04:19 MDT 2012 | yip.ng | |
| Files Changed | ||||
MODIFY
/icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/renderkit/InputRenderer.java
|
| Attachment | screenshot-01.png [ 14470 ] |
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.
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Fix Version/s | 3.1.0.BETA2 [ 10336 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
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.