Thoughts about the Gumby framework? Pros? Cons?

[BBunny]

http://gumbyframework.com/

[leban]

I've looked at it a bit. I think there are some nice things going on. I like that they are using rems, for example. I do have some concerns about some of the selectors I see in the compiled CSS (e.g., .tabs.pill .tab-nav > li > a would have a specificity weight of 32). All in all, I think it's a good thing to keep the frameworks diverse so we're not all using the same tools (*cough* bootstrap *cough*).

On Wednesday, July 24, 2013 4:25:19 PM UTC-5, BBunny wrote:

http://gumbyframework.com/

[Nicole Sullivan]

If you are interested in framework diversity, and I think we all should be, you probably want to check out inuit (http://inuitcss.com/), purecss (http://purecss.io/), and topcoat (http://topcoat.io/).

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-oriented-css.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Nicole Sullivan]

Are there any other frameworks people would recommend looking at? For my clients, I'll take from any framework that has a good component as long as they don't require me to take on the whole library to have a single component.

Nicole

[leban]

YES!!! Harry Roberts has done some excellent work on Inuit. Likewise, Pure touts some heavy SMACSS influences (http://purecss.io/extend/).

To add to the list of frameworks, there's also Foundation by ZURB (https://github.com/zurb/foundation). Some pretty heavy stuff going on there—a lot more than what I need in a framework, personally. But that could be exactly what someone else is looking for. They also have a Google Group (https://groups.google.com/forum/#!forum/foundation-framework-).

Nicolas Gallagher has also done some nice work on SUIT (https://github.com/suitcss). But then again, I'm generally a fan of Mr. Gallagher's work (same for Harry, Snook, and yourself).

I had forgotten about Topcoat... I'll poke around in it over the weekend. Always looking to glean what I can ;-)

[Nicole Sullivan]

leban, you bring up an interesting point... if we were to evaluate frameworks, what would the criteria be?

• modular (you can take a single component w out installing the entire library)
• low specificity
• separation of decorative styles from structural styles (bootstrap doesn't do a great job on this count, which is part of why sites made with it look "boostrappy")

Other stuff?

[Nat Woodard]

I am a big fan of Inuit.css - very dry an has no 'skin' or presentation layer, which keeps me from becoming unintentionally too 'bootstrappy'. It also has one of the smaller footprints as compared to most other frameworks. The ability to easily turn on modules as needed by setting them to true (sass) is also a bonus. Another criteria I find nice is the open/close principle of open for extension but closed for modification. Makes it very easy to override and I rarely feel like I need to modify the base code itself so I can leave Inuit unmodified which makes it easier to manage updates.

-n

[BBunny]

Aaauuugh! More cool stuff to absorb! Thanks for these references, folks. Pure sure looks like it could save some time, and the grid and skinning generators it links to are awesome.

[Steven O'Brien]

For me what OOCSS is missing is the documentation website that twitter bootstrap has, this is so powerful because it makes it very easy to use and ultimately reuse. Even though I am a huge fan of OOCSS only the more skilled team members use it, the others veer off to bootstrap.

Which saddens me inside :-) I think they are all great, but I still think some of them miss the reusability and theming point. That is what is so nice about OOCSS it elegantly stays out of your way.  Bootstrap can be difficult to theme as Nicole pointed out.

Interested to know your thoughts on foundation too? We have another camp in the office that uses that.... we havn't quite settled on a framework yet.

Steve O'Brien
Managing Director

Web & Software Development

t:	+44 (0) 117 957 5306
m:	+44 (0) 796 908 8447
e:	steve....@newicon.net
w:	newicon.net

Newicon Ltd 
Bristol & Bath Science Park
Dirac Crescent
Bristol, BS16 7FR

Registered in England & Wales. Company Number: 5904359 / VAT: GB 993 7684 47

E-mail Disclaimer: The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. In addition, any unauthorised reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free and neither Newicon Ltd nor its subsidiary companies accept any liability for changes made to this e-mail (and any attachments) after it was sent or for viruses arising as a result of this e-mail transmission.

On 28 July 2013 06:12, BBunny <fche...@gmail.com> wrote:

Aaauuugh! More cool stuff to absorb! Thanks for these references, folks. Pure sure looks like it could save some time, and the grid and skinning generators it links to are awesome.

--

[Brian Moon]

On 7/28/13 4:26 AM, Steven O'Brien wrote:
> For me what OOCSS is missing is the documentation website that twitter
> bootstrap has, this is so powerful because it makes it very easy to use
> and ultimately reuse. Even though I am a huge fan of OOCSS only the more
> skilled team members use it, the others veer off to bootstrap.
>
> Which saddens me inside :-) I think they are all great, but I still
> think some of them miss the reusability and theming point. That is what
> is so nice about OOCSS it elegantly stays out of your way. Bootstrap
> can be difficult to theme as Nicole pointed out.
>
> Interested to know your thoughts on foundation too? We have another camp
> in the office that uses that.... we havn't quite settled on a framework yet.

I stress to my team that OOCSS is not a framework. It is an example of
how to build highly reusable, understandable CSS. Sure, we use grid,
media, and template, but also extend those and add our own libraries and
use the OOCSS code as an example of how to build our CSS. Its the
difference between being a software developer and a computer operator.

Brian.
brian.moonspot.net

[John Slegers]

You might want to check out a framework I created a while ago : Cascade Framework.

Cascade Framework is based on OOCSS, is highly modular, is very lightweight and has a total separation of decorative styles and structural styles.

[GUERAS Arnaud]

Cascade Framework is not a good framework, because it has been made by a people who doesn't have a good skill in CSS, it's very obvious to see that : 

A small example : 

/* micro clearfix (using technique from http://nicolasgallagher.com/micro-clearfix-hack) */

figcaption,div:after,main:after,article:after,aside:after,details:after,figcaption:after,figure:after,footer:after,header:after,

hgroup:after,nav:after,section:after,pre:after,.nav:after,.nav a:after,.width-fill:after,.width-fit img:after,

blockquote small:after,address:after,.nav ul:after,.nav li:after {

    clear:both;

}

div:before,div:after,main:before,main:after,article:before,article:after,aside:before,aside:after,details:before,details:after,

figcaption:before,figcaption:after,figure:before,figure:after,footer:before,footer:after,

header:before,header:after,hgroup:before,hgroup:after,nav:before,nav:after,section:before,section:after,

pre:before,pre:after,.nav:before,.nav:after,.nav a:before,.nav a:after,.width-fill:before,.width-fill:after,

.width-fit img:before,.width-fit img:after,blockquote small:before,blockquote small:after,address:before,address:after,

.nav ul:before,.nav ul:after,.nav li:before,.nav li:after {

    content:" "; display:table;

}

Here the clearfix is added on EVERY BLOCK ELEMENT, it's completely crazy, by using this, you SLOW the browser when rendering CSS because he render :after on all block elements and some link elements.

Sometime it's bery usefull to not have the clearfix on a DIV because we want to use the margin collapse or we want to use the fact that the container doesn't contains it's floatted children, etc...

The Cascade Framework, is only a simple COPY PASTE of everything that we can found on the internet without any knowledge of what things does

[Dan Humphrey]

Wow, a very sweeping statement!

If you are going to be so critical of someone else's work, I suggest you provide more substance to your argument and demonstrate your css mastery with examples of how you would approach things - this may give a little weight to your argument, because at present you sound like a troll.

—
Sent from Mailbox for iPhone

[Arnaud Guéras]

I'll be back with a lot of example that show that the fact to add a clearfix or activate the haslayout (for IE) on every block element on a page is not a good thing
I can't let a framework the this kind of thing. Just activate the clearfix/haslayout (for IE) only if you need it, not everywhere.
This clearfix activate a pseudo Block Formatting context on all block element, it's not a good thing because :

It breaks the margin-collapse : http://www.w3.org/TR/CSS2/box.html#collapsing-margins
It breaks the fact a container of floated element doesn't contains it's element (it has a zero height if all it's children are floated)

<div class="hello">
��� <div class="floated">1</div>
�� <div class="floated">2</div>
</div>

.floated {
�� float:left;
}

.hello height is zero in this example

It can be usefull if you want to use this usage of the box (sorry I'm french and my english is not good).


I just want the author of cascade framework look a little bit more at this.


Le 20/11/13 07:21, Dan Humphrey a �crit�:

Wow, a very sweeping statement!

If you are going to be so critical of someone else's work, I suggest you provide more substance to your argument and demonstrate your css mastery with examples of how you would approach things - this may give a little weight to your argument, because at present you sound like a troll.

�

Sent from Mailbox for iPhone

On Wed, Nov 20, 2013 at 5:16 PM, GUERAS Arnaud <arna...@gmail.com> wrote:

Cascade Framework is not a good framework, because it has been made by a people who doesn't have a good skill in CSS, it's very obvious to see that :�

A small example :�

/* micro clearfix (using technique from http://nicolasgallagher.com/micro-clearfix-hack) */

figcaption,div:after,main:after,article:after,aside:after,details:after,figcaption:after,figure:after,footer:after,header:after,

hgroup:after,nav:after,section:after,pre:after,.nav:after,.nav a:after,.width-fill:after,.width-fit img:after,

blockquote small:after,address:after,.nav ul:after,.nav li:after {

� � clear:both;

}

div:before,div:after,main:before,main:after,article:before,article:after,aside:before,aside:after,details:before,details:after,

figcaption:before,figcaption:after,figure:before,figure:after,footer:before,footer:after,

header:before,header:after,hgroup:before,hgroup:after,nav:before,nav:after,section:before,section:after,

pre:before,pre:after,.nav:before,.nav:after,.nav a:before,.nav a:after,.width-fill:before,.width-fill:after,

.width-fit img:before,.width-fit img:after,blockquote small:before,blockquote small:after,address:before,address:after,

.nav ul:before,.nav ul:after,.nav li:before,.nav li:after {

� � content:" "; display:table;

}

Here the clearfix is added on EVERY BLOCK ELEMENT, it's completely crazy, by using this, you SLOW the browser when rendering CSS because he render :after on all block elements and some link elements.

Sometime it's bery usefull to not have the clearfix on a DIV because we want to use the margin collapse or we want to use the fact that the container doesn't contains it's floatted children, etc...

The Cascade Framework, is only a simple COPY PASTE of everything that we can found on the internet without any knowledge of what things does

Le mercredi 20 novembre 2013 04:27:43 UTC+1, John Slegers a �crit�:

You might want to check out a framework I created a while ago :�Cascade Framework.

Cascade Framework is based on OOCSS, is highly modular, is very lightweight and has a total�separation of decorative styles and structural styles.

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-oriented-css.
For more options, visit https://groups.google.com/groups/opt_out.

[Dan Humphrey]

Your English is fine - better than my French.

Maybe you don't mean it to come across this way, but your first post was very attacking.

I don't know the author of the framework, or use the framework in question, but in general, I find people more receptive of criticism and willing to take advice with a little more humility. 

—

Sent from Mailbox for iPhone

On Wed, Nov 20, 2013 at 5:36 PM, Arnaud Guéras <arna...@gmail.com> wrote:

I'll be back with a lot of example that show that the fact to add a clearfix or activate the haslayout (for IE) on every block element on a page is not a good thing
I can't let a framework the this kind of thing. Just activate the clearfix/haslayout (for IE) only if you need it, not everywhere.
This clearfix activate a pseudo Block Formatting context on all block element, it's not a good thing because :

It breaks the margin-collapse : http://www.w3.org/TR/CSS2/box.html#collapsing-margins
It breaks the fact a container of floated element doesn't contains it's element (it has a zero height if all it's children are floated)

<div class="hello">

    <div class="floated">1</div>

   <div class="floated">2</div>
</div>

.floated {

   float:left;
}

.hello height is zero in this example

It can be usefull if you want to use this usage of the box (sorry I'm french and my english is not good).


I just want the author of cascade framework look a little bit more at this.

Le 20/11/13 07:21, Dan Humphrey a écrit :

Wow, a very sweeping statement!

If you are going to be so critical of someone else's work, I suggest you provide more substance to your argument and demonstrate your css mastery with examples of how you would approach things - this may give a little weight to your argument, because at present you sound like a troll.

—

Sent from Mailbox for iPhone

On Wed, Nov 20, 2013 at 5:16 PM, GUERAS Arnaud <arna...@gmail.com> wrote:

Cascade Framework is not a good framework, because it has been made by a people who doesn't have a good skill in CSS, it's very obvious to see that : 

A small example : 

/* micro clearfix (using technique from http://nicolasgallagher.com/micro-clearfix-hack) */

figcaption,div:after,main:after,article:after,aside:after,details:after,figcaption:after,figure:after,footer:after,header:after,

hgroup:after,nav:after,section:after,pre:after,.nav:after,.nav a:after,.width-fill:after,.width-fit img:after,

blockquote small:after,address:after,.nav ul:after,.nav li:after {

    clear:both;

}

div:before,div:after,main:before,main:after,article:before,article:after,aside:before,aside:after,details:before,details:after,

figcaption:before,figcaption:after,figure:before,figure:after,footer:before,footer:after,

header:before,header:after,hgroup:before,hgroup:after,nav:before,nav:after,section:before,section:after,

pre:before,pre:after,.nav:before,.nav:after,.nav a:before,.nav a:after,.width-fill:before,.width-fill:after,

.width-fit img:before,.width-fit img:after,blockquote small:before,blockquote small:after,address:before,address:after,

.nav ul:before,.nav ul:after,.nav li:before,.nav li:after {

    content:" "; display:table;

}

Here the clearfix is added on EVERY BLOCK ELEMENT, it's completely crazy, by using this, you SLOW the browser when rendering CSS because he render :after on all block elements and some link elements.

Sometime it's bery usefull to not have the clearfix on a DIV because we want to use the margin collapse or we want to use the fact that the container doesn't contains it's floatted children, etc...

The Cascade Framework, is only a simple COPY PASTE of everything that we can found on the internet without any knowledge of what things does

Le mercredi 20 novembre 2013 04:27:43 UTC+1, John Slegers a écrit :

You might want to check out a framework I created a while ago : Cascade Framework.

Cascade Framework is based on OOCSS, is highly modular, is very lightweight and has a total separation of decorative styles and structural styles.

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-oriented-css.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-oriented-css.
For more options, visit https://groups.google.com/groups/opt_out.

[Matthew Browne]

On Wed, Nov 20, 2013 at 5:16 PM, GUERAS Arnaud <arna...@gmail.com> wrote:

Here the clearfix is added on EVERY BLOCK ELEMENT, it's completely crazy, by using this, you SLOW the browser when rendering CSS because he render :after on all block elements and some link elements.

I wonder how much traffic a site needs to get before the performance difference you claim would actually be noticeable...I've been using Cascade Framework on a couple of sites and haven't noticed any slowness.

Perhaps you missed the line "check out a framework I created" in John's post here...I agree with Dan, your post was very attacking. It would have been good for your post to be less harsh in any case, but especially in a direct response to the author of the framework.

Please do let us all know in more detail how you think the framework could be improved -- I'm all for people expressing their opinions openly -- but please try to do so in a way that doesn't come off as a personal attack on the framework's author.

On 11/20/13 2:14 AM, Dan Humphrey wrote:

Your English is fine - better than my French.

Maybe you don't mean it to come across this way, but your first post was very attacking.

I don't know the author of the framework, or use the framework in question, but in general, I find people more receptive of criticism and willing to take advice with a little more humility.�

�

Sent from Mailbox for iPhone

On Wed, Nov 20, 2013 at 5:36 PM, Arnaud Gu�ras <arna...@gmail.com> wrote:

I'll be back with a lot of example that show that the fact to add a clearfix or activate the haslayout (for IE) on every block element on a page is not a good thing
I can't let a framework the this kind of thing. Just activate the clearfix/haslayout (for IE) only if you need it, not everywhere.
This clearfix activate a pseudo Block Formatting context on all block element, it's not a good thing because :

It breaks the margin-collapse : http://www.w3.org/TR/CSS2/box.html#collapsing-margins
It breaks the fact a container of floated element doesn't contains it's element (it has a zero height if all it's children are floated)

<div class="hello">

��� <div class="floated">1</div>
�� <div class="floated">2</div>
</div>

.floated {
�� float:left;

[David Gutierrez]

Come on people, a general "what's your opinion" was asked, and he gave it. To ask him to tone it down or be nicer means that it is not his opinion. I don't understand the need to be all PC here. I assume we are all professional with professional interest in this subject, and as such, should we not be honest to each other about this topic. I mean who else will?  If he thinks it's crap, let him. If you don't, then defend it.

On that note. Can you clarify this statement "how much traffic a site needs to get before the performance difference you claim would actually be noticeable". Because it makes question your reality.

Sent from my iPhone

On Nov 20, 2013, at 7:52, Matthew Browne <mbro...@gmail.com> wrote:

On Wed, Nov 20, 2013 at 5:16 PM, GUERAS Arnaud <arna...@gmail.com> wrote:

Here the clearfix is added on EVERY BLOCK ELEMENT, it's completely crazy, by using this, you SLOW the browser when rendering CSS because he render :after on all block elements and some link elements.

I wonder how much traffic a site needs to get before the performance difference you claim would actually be noticeable...I've been using Cascade Framework on a couple of sites and haven't noticed any slowness.

Perhaps you missed the line "check out a framework I created" in John's post here...I agree with Dan, your post was very attacking. It would have been good for your post to be less harsh in any case, but especially in a direct response to the author of the framework.

Please do let us all know in more detail how you think the framework could be improved -- I'm all for people expressing their opinions openly -- but please try to do so in a way that doesn't come off as a personal attack on the framework's author.

On 11/20/13 2:14 AM, Dan Humphrey wrote:

Your English is fine - better than my French.

Maybe you don't mean it to come across this way, but your first post was very attacking.

I don't know the author of the framework, or use the framework in question, but in general, I find people more receptive of criticism and willing to take advice with a little more humility. 

—

Sent from Mailbox for iPhone

On Wed, Nov 20, 2013 at 5:36 PM, Arnaud Guéras <arna...@gmail.com> wrote:

I'll be back with a lot of example that show that the fact to add a clearfix or activate the haslayout (for IE) on every block element on a page is not a good thing
I can't let a framework the this kind of thing. Just activate the clearfix/haslayout (for IE) only if you need it, not everywhere.
This clearfix activate a pseudo Block Formatting context on all block element, it's not a good thing because :

It breaks the margin-collapse : http://www.w3.org/TR/CSS2/box.html#collapsing-margins
It breaks the fact a container of floated element doesn't contains it's element (it has a zero height if all it's children are floated)

<div class="hello">

    <div class="floated">1</div>

   <div class="floated">2</div>
</div>

.floated {

   float:left;
}

.hello height is zero in this example

It can be usefull if you want to use this usage of the box (sorry I'm french and my english is not good).


I just want the author of cascade framework look a little bit more at this.

--

[Lars Olof Berg (Gmail)]

20 nov 2013 kl. 13:52 skrev Matthew Browne <mbro...@gmail.com>:

I wonder how much traffic a site needs to get before the performance difference you claim would actually be noticeable...I've been using Cascade Framework on a couple of sites and haven't noticed any slowness.

I don't think this is performance regarding _traffic_, it's more likely to be performance regarding _rendering_ in the browser.

As a related side note: yesterday I came across an interesting article written by Paul Lewis and Paul Irish covering how browsers renders the page http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/ and which CSS properties that are cheap respectively expensive.

-- lars olof

[Matthew Browne]

Can you clarify this statement "how much traffic a site needs to get before the performance difference you claim would actually be noticeable".

I guess I'm trying to get a sense of whether the performance disadvantages of having haslayout activated for every block-level element would ever matter for a small to medium sized website, which are generally the websites I deal with, or whether it would only matter for large websites like Facebook, Microsoft, NYTimes and other major newspapers, etc.

I framed the question that way because if a site is loading quickly to begin with, the very slight delay in rendering time isn't likely to make much of a difference, whereas if you're already struggling with load times (e.g. on a very high-traffic site), every millisecond would be more important. But now that I think about it, I realize that there are some less trafficked websites for which rendering time might also be critically important (e.g. Javascript-heavy apps with a longer initial load time).

It sounds like Arnaud has some valid criticisms and I'd like to hear them...I'm not suggesting that anyone's opinion should be suppressed, just that we should stick to the facts and criticisms of the techniques themselves, and avoiding assumptions about the author personally - it seems like John put a lot of thought into the framework and was not careless about it at all, even if mistakes were made. But I don't mean to be overly touchy about this; it was more of a cautionary note.

[Matthew Browne]

Hi John, et al.,
I stand by what I've said, but I do think GUERAS Arnaud brought up an important issue with regard to Cascade Framework.

I just found some relevant background on the hasLayout property here:

The main reasons Microsoft gives for the fact that not all elements have a layout by default are “performance and simplicity.” If all elements had a layout by default, a detrimental effect on performance and memory usage would result.

(source: http://reference.sitepoint.com/css/haslayout)

GUERAS, I hope the messages about your criticism being a bit harsh didn't discourage you from sharing the examples you mentioned - I meant only to encourage a respectful tone - but in any case it seems you're right that if optimal rendering performance is a high priority, then Cascade Framework's global clearfix approach may be problematic.

The difference in rendering performance is very small as far as I can tell, but I'm sure for some sites those extra milliseconds could be important.

John, I wonder if it might be useful to have the global clearfix be an optional feature of the framework. That might mean that your "semantic grid" feature would only be possible with the global clearfix version, I'm not sure, but as far as the rest of the framework is concerned it seems like the need for a global clearfix could be easily avoided by introducing a "row" class, which would do the clearfix. So for example, instead of the grid classes the way you have them now, in the non-global-clearfix version it could be something like this:

<div class="row">
    <div class="col width-1of2">left</div>
    <div class="col width-1of2">right</div>
</div>

I posted earlier with more details about how this could be accomplished:
https://groups.google.com/d/msg/object-oriented-css/f8a6IgwSk1A/pAtQMM2ww8AJ

I coded that up before I checked out the new version of the OOCSS framework...now that I checked that out I see it's very similar. The only thing I don't understand is that in the new version of OOCSS, it talks about using the .lastCol class for compatibility with IE7, and yet border-box sizing is used throughout the new OOCSS which would seem to make support for IE7 questionable across the whole framework...IE7 has a very small market share now (less than 2%) but it would be nice to know that entire layouts wouldn't be completely broken due to columns that are slightly too wide being forced to the next line. Probably a subject for another post.

Anyhow, if anyone has further comments or suggestions about this, I'd be interested to hear them and I imagine John would be too.

[Nicole Sullivan]

I believe the widths are also adjusted down for IE7 to take into account border-box not working.

[Matthew Browne]

Thanks for the reply Nicole...it looks like the all the widths in OOCSS are percentage-based, so how is that accounting for border-box not working? For example, .cols6of12 sets the width to 50%...after your comment I would have expected to see something like 49.5%, or a pixel-based width...

Or are you referring to the fact that the .line class has margin-left: -20px; ? What's the purpose of that?

On 12/3/13 11:12 AM, Nicole Sullivan wrote:

I believe the widths are also adjusted down for IE7 to take into account border-box not working.

On Sun, Dec 1, 2013 at 10:50 PM, Matthew Browne <mbro...@gmail.com> wrote:

Hi John, et al.,
I stand by what I've said, but I do think GUERAS Arnaud brought up an important issue with regard to Cascade Framework.

I just found some relevant background on the hasLayout property here:

The main reasons Microsoft gives for the fact that not all elements have a layout by default are �performance and simplicity.� If all elements had a layout by default, a detrimental effect on performance and memory usage would result.

(source: http://reference.sitepoint.com/css/haslayout)

GUERAS, I hope the messages about your criticism being a bit harsh didn't discourage you from sharing the examples you mentioned - I meant only to encourage a respectful tone - but in any case it seems you're right that if optimal rendering performance is a high priority, then Cascade Framework's global clearfix approach may be problematic.

The difference in rendering performance is very small as far as I can tell, but I'm sure for some sites those extra milliseconds could be important.

John, I wonder if it might be useful to have the global clearfix be an optional feature of the framework. That might mean that your "semantic grid" feature would only be possible with the global clearfix version, I'm not sure, but as far as the rest of the framework is concerned it seems like the need for a global clearfix could be easily avoided by introducing a "row" class, which would do the clearfix. So for example, instead of the grid classes the way you have them now, in the non-global-clearfix version it could be something like this:

<div class="row">
��� <div class="col width-1of2">left</div>
��� <div class="col width-1of2">right</div>
</div>

I posted earlier with more details about how this could be accomplished:
https://groups.google.com/d/msg/object-oriented-css/f8a6IgwSk1A/pAtQMM2ww8AJ

I coded that up before I checked out the new version of the OOCSS framework...now that I checked that out I see it's very similar. The only thing I don't understand is that in the new version of OOCSS, it talks about using the .lastCol class for compatibility with IE7, and yet border-box sizing is used throughout the new OOCSS which would seem to make support for IE7 questionable across the whole framework...IE7 has a very small market share now (less than 2%) but it would be nice to know that entire layouts wouldn't be completely broken due to columns that are slightly too wide being forced to the next line. Probably a subject for another post.

Anyhow, if anyone has further comments or suggestions about this, I'd be interested to hear them and I imagine John would be too.

On 11/20/13 9:17 AM, Matthew Browne wrote:

Can you clarify this statement "how much traffic a site needs to get before the performance difference you claim would actually be noticeable".

I guess I'm trying to get a sense of whether the performance disadvantages of having haslayout activated for every block-level element would ever matter for a small to medium sized website, which are generally the websites I deal with, or whether it would only matter for large websites like Facebook, Microsoft, NYTimes and other major newspapers, etc.

I framed the question that way because if a site is loading quickly to begin with, the very slight delay in rendering time isn't likely to make much of a difference, whereas if you're already struggling with load times (e.g. on a very high-traffic site), every millisecond would be more important. But now that I think about it, I realize that there are some less trafficked websites for which rendering time might also be critically important (e.g. Javascript-heavy apps with a longer initial load time).

It sounds like Arnaud has some valid criticisms and I'd like to hear them...I'm not suggesting that anyone's opinion should be suppressed, just that we should stick to the facts and criticisms of the techniques themselves, and avoiding assumptions about the author personally - it seems like John put a lot of thought into the framework and was not careless about it at all, even if mistakes were made. But I don't mean to be overly touchy about this; it was more of a cautionary note.

On 11/20/13 9:09 AM, Lars Olof Berg (Gmail) wrote:

20 nov 2013 kl. 13:52 skrev Matthew Browne <mbro...@gmail.com>:

I wonder how much traffic a site needs to get before the performance difference you claim would actually be noticeable...I've been using Cascade Framework on a couple of sites and haven't noticed any slowness.

I don't think this is performance regarding _traffic_, it's more likely to be performance regarding _rendering_ in the browser.

As a related side note: yesterday I came across an interesting article written by Paul Lewis�and�Paul Irish covering how browsers renders the page�http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/�and which CSS properties that are cheap respectively expensive.

-- lars olof

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-oriented-css.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-oriented-css.
For more options, visit https://groups.google.com/groups/opt_out.