Class naming conventions

[Colin Clark]

Hey all,

If we're going to do this for one component, I think it's best to make  
it consistent across the board. This release is a good opportunity to  
normalize our use of selectors in all components. It'll be a little  
more work during bug parade, but our users will thank us for the  
consistency.

Colin

On 17-Mar-09, at 10:09 AM, Michelle D'Souza wrote:

> Given that UIOptions and UIEnhancer are scheduled to come out of  
> preview mode this release I think it makes sense to make the changes  
> for them. Luckily, you've already put an appropriate JIRA into the  
> bug parade for those componnents: http://issues.fluidproject.org/browse/FLUID-2223
>
> What do people think about the other components?
>
> Michelle
>
> On 17-Mar-09, at 8:33 AM, Justin wrote:
>
>> +1  but not sure how it will play out with our constraints as we  
>> move towards our 1.0 release. Any thoughts?
>>
>> - Justin
>> On 16-Mar-09, at 4:31 PM, Michelle D'Souza wrote:
>>
>>> +1
>>>
>>> Michelle
>>>
>>> On 16-Mar-09, at 2:56 PM, Jacob Farber wrote:
>>>
>>>> I would just like to bring this thread back to life, so we can  
>>>> all agree and ratify this approach. I've noticed there are still  
>>>> a lot of collisions going on.
>>>>
>>>> Sound good?
>>>>
>>>> Jacob
>>>>
>>>>
>>>> On Thu, Mar 12, 2009 at 9:48 AM, Jacob Farber <jacob.farber at utoronto.ca 
>>>> > wrote:
>>>> the order of class names is only really relevant for human  
>>>> readability - that being said, I would just try something like
>>>>
>>>> class="[FSS] [DOM] [CUSTOM]"
>>>>
>>>> because its already recommended practice in the FSS docs to do  
>>>> FSS always first, custom always las, like:  class="[FSS] [CUSTOM]"
>>>> and so this would require less thinking in case there are no DOM  
>>>> selectors involved
>>>>
>>>> Jacob
>>>>
>>>> On Thu, Mar 12, 2009 at 8:35 AM, Justin  
>>>> <justin.obara at utoronto.ca> wrote:
>>>> Thank you for this detailed summary Anastasia.
>>>>
>>>> I'm wondering if we should have a convention for the order the  
>>>> classes appear.
>>>>
>>>> I.e. the DOM-selection class before the visual styling classes.
>>>>
>>>> Not sure how important this is or not, but it might make it  
>>>> easier to read if they are in a consistent position.
>>>>
>>>> Thanks
>>>> Justin
>>>>
>>>>
>>>> On 11-Mar-09, at 4:54 PM, Anastasia Cheetham wrote:
>>>>
>>>>
>>>> Today after Jacob's FSS walkthrough, we had a discussion about  
>>>> naming conventions for classes for the FSS and for component DOM  
>>>> selection. We came up with a general naming scheme, which is  
>>>> described below so that anyone who wasn't in on the discussion  
>>>> can weigh in.
>>>>
>>>> We decided that we would distinguish between class names used for  
>>>> visual styling, and class names used for finding DOM element for  
>>>> manipulation, etc. These different categories of classes will  
>>>> have different prefixes:
>>>>
>>>>   Visual styling class-name prefix:    fl-
>>>>   DOM-selection prefix:                flc-
>>>>
>>>> Visual styling classnames:
>>>>
>>>> The general pattern for visual styling class names is
>>>>  fl-[thing]-[role]
>>>>
>>>> So, for example:
>>>>  fl-container-flex, fl-layout-linear...
>>>>
>>>> If the visual styling is specifically for a component, then the  
>>>> component name is inserted:
>>>>  fl-[componentname]-[thing]-[role]
>>>>
>>>> So, for example:
>>>>  fl-reorderer-selected, fl-pager-links...
>>>>
>>>>
>>>> DOM-selection classnames:
>>>>
>>>> The general pattern for DOM-selection classnames (i.e. default  
>>>> classnames used by a component to find its parts) is
>>>>  flc-[componentname]-[thing]-[role]
>>>>
>>>> So, for example:
>>>>  flc-reorderer-drop-warning, flc-inlineEdit-displayText...
>

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org