Thanks - your point about utilizing semantics in the host language is critical to creating a cleaner starting point for implementors. We should definitely avoid redundant information when there is a native property that can do it for us, which is what Eli touched upon with his example.
On Thu, 31 Jul 2008 16:12:50 -0400, David Bolter <[EMAIL PROTECTED]> wrote: > Interesting. My gut likes this Jacob. > > In cases where you do a selector like "state_foo", probably a good rule > of thumb to look to see if there is an aria-foo property/state/attribute > so that semantics are captured. Look for semantics in the host language > (html, xhtml or whatever) too of course. > e.g. for "state_disabled" consider also adding the aria-disabled state: > http://www.w3.org/WAI/PF/aria/#disabled > > (... and for "mySelector" look for a corresponding aria role) > > cheers, > David > > Jacob Farber wrote: >> Hello, >> Eli and I are working on a system to neatly package our components >> into more approachable examples of what they can do. In doing so, the >> discussion led to a technique I wanted to toss around: >> >> The ideas was about separating CSS selectors and CSS as other functions. >> What we do now is something like this- >> >> <div class="mySelector-disabled"></div> >> >> which represents a lot information. >> >> Sometimes we prefix the class with "mySelector" and save that as a >> selector, we attach a suffix like "disabled" to represent a state for >> the element, or maybe we even bake the state into the javascript that >> spits out visual effects like >> $("div.mySelector").css("display","none"). >> More so, we overload this element with css stylings through either >> that class name and/or css3 selector patterns (which are fragile). >> >> What about a more semantic and recycleable approach, where you divide >> class names into roles (Selector, State, Presentation)? >> >> <div class="mySelector state_disabled theme_redAndBlue"></div> >> >> Here, by default we can offer a semantic class name as a selector, or >> allow the implementor to override it with another pattern (maybe no >> class name at all), without any negative effects on presentation or >> state. >> >> We can offload the presentation into an easy to read canned css group >> or file where a designer can easily modify it or erase its properties >> entirely. >> >> we can also offload the elemetns state into a more semantic and >> re-usable class name, which will be easier to maintain and reduce the >> amount of code required to achieve certain effects (state_focus/blur, >> state_disabled/enabled, state_valid/invalid, etc) >> >> The idea is we've put a lot of brainpower into making our JS less >> fragile and prone to breakage, but I think CSS needs the same TLC. >> Any thoughts? >> >> > -- Jacob Farber _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
