Thanks, agreed Eli covered the html disabled attribute. Actually I was hoping my main point was about ARIA :)
I'm thinking that implementors can look at both ARIA *and* native host markup for semantics. The distinction is admittedly fuzzy... especially when one looks at html5. cheers, D Jacob Farber wrote: > 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? >>> >>> >> > > > _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
