hi,
Re: scoping !importants
Putting !important on every property regardless of scope is an issue if we
don't want classes to over-ride each other when put on the same element. Ex:
both a font size class and a theme class are added to an element and each one
attempts to set font-size to a different value - which should win? I think in
this case, whichever style is last in the css file. However, most of our
classes are for setting very specific styles so overlap like this isn't an
issue.
Also if a class (with important) is added to a child element where the parent
has an important style, the child class will still win for that element due to
specificity, so users still have flexibility that way. I think I'm making sense.
I tried adding !importants to all of the text and bg colour styles in the HC
theme, and tested demos/fss/themes/html/themes.html - it looks fine. I tried
the same with the 1.3 version of the theme and it wasn't fine - some of the
text was invisisible (white on white). But I think this just signifies that we
have improved the stability of our fss themes in general, filling in the
missing gaps.
So I guess what I'm saying is - go for it without distinguishing scope and
let's do a bunch of testing afterwards to confirm that it all works as it
should. :)
By the way, the rust theme is deprecated, and coal and slate aren't used by UI
Options in 1.4, tho I'm thinking we'll likely add them in later on.
best,
heidi
On 2011-07-04, at 6:48 PM, Clark, Colin wrote:
> I've gone through each of the FSS stylesheets on an !important hunt. Here's
> what I found:
>
> fss-text.css adds !important to the following properties:
> font-size
> line-height
> font-family
> color
> background-color
> background-image
>
> the theme files add !important to these properties:
> td border
> background-color
> background
> color
>
> However, not every reference to these properties was made !important. Are we
> safe to add !important to any occurrence of these properties, or do we need
> to scope them only to certain selectors? If so, it'll involve a bit more work
> in our code, but not a lot.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
