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
