is one way to avoid an Opera bug when the * contenteditable attribute is included anywhere else in the document. * Otherwise it causes space to appear at the top and bottom of elements * that are clearfixed. * 2. The use of `table` rather than `block` is only necessary if using * `:before` to contain the top-margins of child elements. */ .cf:before, .cf:after { content: " "; /* 1 */ display: table; /* 2 */ } .cf:after { clear: both; } /** * For IE 6/7 only * Include this rule to trigger hasLayout and contain floats. */ .cf { *zoom: 1; } http://nicolasgallagher.com/micro-clearfix-hack/ floats + clearfix
look be[er than most -‐> may be worth the effort rounded corners shadows gradients s,cky footer corner images traslucid png image pa>ern hacky html/css
implementa,on for a large % * people with old browsers are used to ugliness rounded corners shadows gradients s,cky footer border-‐radius box-‐shadow background gradient flexbox
checking your own data’ They are largely useless, transient and too subjec/ve. (…) I generally never worry CSS selectors when authoring a style sheet (typically I just put a class on anything I want to style and select it directly) (…) “It is prac/cally impossible to predict the final performance impact of a given selector by just examining the selectors ( css performance ) GitHub's CSS Performance (Dec 2012) https://speakerdeck.com/jonrohan/githubs-css-performance Browser representa,ves on CSS performance (Mar 2015)
IE limit of 4096 selectors (..) Older versions of Internet Explorer (version 9 and below) have a hard limit for the number of CSS selectors they can process, which is 4095 (..) CssSpliHer integrates with the Rails 3.1+ Asset Pipeline to generate addiOonal split stylesheets IE limit of 4096 selectors Use a spli[er with your pipeline
are not enough * Be[er than condi,onal stylesheets in some cases /* ie10.css */ /* Lines no one remembers that exist */ /* relevant_context.css */ #foo.ie10{ /* ... */ }
buJon to the user preferences almost like the one on the demo page.. damn, the rules fight each other and are split into three places, let’s just create a new one
work like this with sass: #signup-button { @extend button-basics; @extend button-large; @extend button-primary-color; } I think that requires extra discipline … you still need to design your classes/mixins like components whose permutations are not explicit … you can not copy paste html and expect it to work, you need to find similar elements and learn about them, think new names like if you were a taxonomist and add them to different stylesheets…
reuse -‐ easy to fall into wars -‐ tends to fragmenta,on (look in several places to get all the styles) -‐ possible smaller html size (negligible) -‐ makes you think about descrip,ve names constantly #signup-‐bu[on
-‐ no-‐brainer, doesn’t need a name -‐ it comes in mul,ple colors and flavours -‐ allows html copy pas,ng .btn.btn-‐primary.btn-‐lg happy efficient programmers
get perfect css is more interes,ng to focus on reducing complexity. It could be messy, but as long as it lives isolated from the other styles, as long as it consists on a few bunch of lines in the same stylesheet, with just a couple of simple clearly related classes, it won’t hurt the development, and you could clean it in the future (or not).
-‐ some parts won’t work at all in very old browsers -‐ more support = more hours, more €€ -‐ fancy startup = early adopters = modern browsers -‐ very targeted product for a few tradi,onal customers = solves a pain -‐> you could specify your browser support, they are mo,vated to install it
wide browser support = reasonable well adapted to some browsers Our support for other browsers/devices is always limited, test it and get it ~100% right is very expensive and only makes business sense for large companies