obara.justin at gmail.com
Thu Mar 17 13:33:49 UTC 2011
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.
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.
> 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.
>> 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).
>> Please let me know what you think.
More information about the fluid-work