Component Selectors + FSS Class names

[Michelle D'Souza]

Jacob's agreed to give us a code tour of FSS tomorrow after stand up.  
That would be a good time to discuss this issue and come to a  
decision. There is agreement that we need to standardized how fluid  
components use FSS but I'm not sure that we know at this point exactly  
how we'd like to do this.

Michelle

On 4-Mar-09, at 1:24 PM, Jacob Farber wrote:

> Hi Everyone,
> Something that I think we should take care of by the time Infusion  
> 1.0 goes public should be the inclusion of FSS class names in  
> Components' dynamic options.styles object, and the name-spacing of  
> default component selectors. This would separate the practices of  
> selecting something versus styling something.
>
> There are a few reasons why I think this is an important initiative:
> Clearer roles: By default, it gives a clear distinction where  
> stylistic selectors end and purely structural selectors begin.
> Separation of Style & State: This will emphasize how CSS is not  
> embedded in a components fundamental operation, its merely enhancing  
> it.
> Easy modifications: similar to our templating concept; it will  
> become more obvious that if you change the default selectors, you  
> wont break the appearance and vice-versa. This encourages better  
> coding practices since there will be no fear of optimizing code, and  
> no mystery as to where those modifications need to be made.
> For a components default selector namespace, I would recommend using  
> a variant on the FSS "fl-" namespace: "fl-find-" and whatever you  
> are looking for. I think it's a good idea to use a single major  
> prefix (that being the "fl-") in all our materials (FSS, Components,  
> etc).
>
> So, this would mean every component would need to be "scrubbed" to  
> comply with some sort of consistent selector namespace, as well as  
> all the styles:{} blocks need to be converted to FSS class names. In  
> some cases, there is no FSS class name where there might need to be  
> one, so it will have to be added. These are pretty large tasks, but  
> I would be happy to help here.
>
> What do you think?
>
> Jacob
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

------------------------------------------------------
Michelle D'Souza
Software Developer, Fluid Project
Adaptive Technology Resource Centre
University of Toronto



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090310/77f58201/attachment.html>