Hi Justin,

Yes, I think you're right. Having fss-reset.css @import the new files will just 
be for backwards compatibility. We can deprecate it and encourage users to 
choose amongst the finer-grained files based on the needs of their application.

We still need CSS concatenation support in the Builder, one of these days.

+1 for 2b.

Colin

On 2011-04-04, at 11:30 AM, Justin Obara wrote:

> To add my personal opinions. I'm currently leaning towards Proposal #2b. It 
> keeps things relatively the same, but provides our users with more 
> flexibility. The performance hit is something that we should make note of 
> though. Here's a page that explains some of the performance issues around 
> loading css.
> 
> http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
> 
> I wonder if we should still depricate the fss-reset.css file and encourage 
> the use of linking the two separate files directly instead?
> 
> Thanks
> Justin
> 
> On 2011-03-31, at 4:18 PM, Justin Obara wrote:
> 
>> At the FSS meeting today, we talked about a couple of proposals for 
>> addressing fss-reset, see below. Please let us know which solution you 
>> prefer and why. I'm hoping that we'll be able to come to a consensus on what 
>> is the best approach to take.
>> 
>> Thanks
>> Justin
>> 
>> Proposal #1
>> -----------------
>> 
>> Depricate the current fss-reset.css file and switch to using the reset, 
>> base, and font files from YUI3, including both the global and in-context 
>> versions of the files. These files would all be provided individually (not 
>> concatenated).
>> 
>> Rationale #1
>> ----------------
>> 
>>      • rely on YUI's expertise and resources
>>      • it's more widely used and familiar CSS
>>      • basically our current fss-reset is a componsition of YUI2's reset, 
>> base, and font files. Including YUI directly is more explicit about this
>>      • fss-reset.css mixes together reset, base, and font and might be too 
>> much for some users.
>>              • it both clears all styles and sets default styling
>> 
>> Cons #1
>> ------------
>> 
>>      • confusing to be carrying around 2 reset files
>>      • themes are likely built with the assumption that one of the resets 
>> has been applied
>>      • YUI3 namespaces their in-context version, but includes the version 
>> number in the namespace. This will make upgrading difficult for our users.
>> 
>> Proposal #2
>> -----------------
>> 
>> Keep fss-reset.css as is, and add a contextual/scoped version. This would be 
>> similar to how YUI3 has an in-context version. In this case the user would 
>> be able to only reset portions of the document, rather than having it affect 
>> the entire page when included.
>> 
>> Rationale #2
>> ------------------
>> 
>>      • By keeping fss-reset, it keeps things stable. There will be no need 
>> to worry about backwards compatibility. 
>>      • The additional contextual/scoped version allows for more flexibility 
>> in the use of the fss-reset on a page.
>> 
>> Cons #2
>> ------------
>> 
>>      • This doesn't include an update to the latest YUI 3 files. 
>>      • Users who have found the FSS too heavy handed will continue to
>> 
>> Proposal #2b
>> ------------------
>> 
>> Same as proposal 2, with the exception of breaking up the fss-reset into 
>> multiple files. For example fss-reset-clear.css and fss-reset-base.css 
>> (names are just examples, not necessarily what we will use). The fss-reset 
>> file would remain, but would only include information to link in the other 
>> two files. 
>> 
>> Rationale #2b
>> --------------------
>> 
>>      • This adds even more flexibility on top of Proposal #2, by allowing 
>> users to pick and choose what they like. 
>>              • For example, if you want the reset, but not the default base 
>> styles. 
>>      • Backwards compatibility is preserved by maintaining the single 
>> fss-reset.css file which fetches the two parts.
>> 
>> Cons #2b
>> -------------
>> 
>>      • Lots of extra files. reset will grow from 1 file to 6, after 
>> including the contextual/scoped versions. 
>>      • Importing CSS from another CSS file will slightly increase the 
>> overhead of fetching the resources for a page. 
>> 
>> On 2011-03-17, at 9:33 AM, Justin Obara wrote:
>> 
>>> At the dev meeting yesterday we talked a bit about updating the fss-reset 
>>> file. One of the things that we discussed was "At what point does updating 
>>> fss-reset become a backwards compatibility breaking api change?".
>>> 
>>> Another option would be to provide the YUI css files (base, reset, and 
>>> font) individually rather than concatenating them together. We could then 
>>> update or deprecate the fss-reset file. This would provide backwards 
>>> compatibility but allow for more flexibility for our users.
>>> 
>>> I'm wondering what the communities thoughts are on this issue.
>>> 
>>> Thanks
>>> Justin
>>> 
>>> On 2011-03-15, at 12:59 PM, Justin Obara wrote:
>>> 
>>>> I've attached a pdf with the summary of the changes between the current 
>>>> fss-reset and the fss-reset-new file that concats the YUI 3.3 css files.
>>>> 
>>>> Not that we'll probably want to maintain the custom changes.
>>>> 
>>>> Thanks
>>>> Justin
>>>> 
>>>> <reset_changes.pdf>
>>>> On 2011-03-14, at 3:34 PM, Justin Obara wrote:
>>>> 
>>>>> During our FSS chat there was some talk about the fss-reset file. Some 
>>>>> felt that it was too heavy handed at times, others didn't mind. 
>>>>> 
>>>>> Here's a site that has info about several of the popular reset files, 
>>>>> http://www.cssreset.com/ . 
>>>>> 
>>>>> The FSS-reset is based on the YUI v2.5.2 reset, base, and font files. YUI 
>>>>> has since release YUI v3.3. In addition to the few changes they have made 
>>>>> to these files, they have also provided contextual versions. What this 
>>>>> means is that rather than having the styles apply globally, you can chose 
>>>>> a version of the file that scopes changes to a class name. 
>>>>> 
>>>>> http://developer.yahoo.com/yui/3/cssreset/
>>>>> 
>>>>> I think we should consider upgrading to the latests version of the YUI 
>>>>> reset, base, and font files, as well as providing an fss-reset-context 
>>>>> file that is based on the respective contextual versions.
>>>>> 
>>>>> I've created a branch in my infusion fork on github which includes the 
>>>>> updated reset file (fss-reset-new.css), the contextual reset file 
>>>>> (fss-reset-context.css), and a test page (withNewReset.html).
>>>>> 
>>>>> https://github.com/jobara/infusion/tree/fss-reset-upgrade
>>>>> 
>>>>> Please let me know what you think.
>>>>> 
>>>>> Thanks
>>>>> Justin
>>>> 
>>> 
>> 
> 
> _______________________________________________________
> fluid-work mailing list - [email protected]
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org

_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work

Reply via email to