Highest z-index was an astonishing 999999999999999999999999999 or 9.99e26. With a default key repeat on OS X, this would take 3 seconds of holding down 9 to type. If you took that many pieces of paper at .05mm thick, the stack would reach from Earth to the Sun 10 trillion times. The worst part about this large of a z-index is that a number that high will overflow and not work in the expected manner anyhow. The lowest was a more reasonable -999999.
FWIW, max z-index that is cross-browser safe is: 16777271
I think we've all been there and started throwing out crazy z-index values at one point or another, usually out of frustration. The only real solution is to keep this stuff under control from the start and always use exactly the z-index you need.
Ahaha totally. I can just imagine the hilarious scene where a poor dev just breaks after a solid 45 minutues of trying to get that god-forsaken div to overlap another and gets to his feet, punchs down the 9 key for a whole 3 seconds screaming a 3-syllable combination of rage-soaked curses ("cock-sucking cunt" comes to mind), finally collapsing back into his seat on the last; too pissed to even bother hitting Ctrl+R to see if it had worked, typing 'git add . && git commit -m "fuck everything." ' before going home.
imo, flex-box and evangelism of box-sizing border-box have been the best things since CSS3 selectors and transforms/transitions.
i only wish that <col> elements could propagate style rules as if they were parents of all the related td/th cells. there's still no way to specify text-align and font-* on entire columns easily, which is just silly.
Depends on your definition of "easy"... assuming your markup is being generated on the server or using templates or whatever (in other words, a loop), you can add a different class to each table cell that is in the 2nd column.
Or if you don't need IE8 support you could use the nth-child selector (e.g. .my-table td:nth-child(2) { text-align: center; }).
In some cases I would argue one of these techniques would be cleaner / better than adding a <col> element just for a styling hook. But in other cases I agree with you that it would be nice if <col> styles propogated.
I wish Apple would add a SASS/CSS compiler into XCode for native UI. I know there are a couple side projects for this but if it were baked in it could really take off.
Besides the potential of sharing across platforms, it would be one less system for layout and styles that had to be learned.
The reason I usually use hex over rgb is because it's easier to snag the hex color from the Photoshop layout given to me. That, and if I'm not using alpha then I suppose I don't really care that much.
I never liked the double colons for pseudo selectors either. I kind of understand the idea of using two colons for the pseudo elements and single colon for pseudo classes to differentiate the two. But again, I can't seem to care that much. I can tell what they are by their names.
The correct number for !important should be zero but it's whatever number of times you have to use it because someone inlined styles into the HTML and you don't have access to remove it.
Are there any indicators that can reliably indicate usage of a CSS preprocessor? If so, what preprocessors are used and which ones? (Could property ordering, presence of hacks/comments, misspellings, prefixes, or source mapping comment be used to identify?)
What are the common values in ::before and ::after pseudo-element content properties?
If you leave out the identifiable CSS libraries, how does that affect the numbers? Do they scale by 10% or do the libraries (Bootstrap primarily) use rules/properties disproportionately enough to scale the other results?
What percent of files are minimized?
What does the histogram of selectors per site look like?
Edit: Also, how frequently do dataURIs show up (probably as background images)?
I thought long and hard about trying to identify preprocessor usage reliably because that is a super interesting piece of data, but nothing stuck out as a smoking gun. Sequentially increasing selectors
tr
tr td
tr td a
could be LESS unrolling a nested bit:
tr {
td {
a {
OR... could just be how people write CSS.
I mostly ignored by-domain grouping in my queries, but there is a host of analysis you could do that would get into the modeling portion of data science, teasing our correlation and trying to find 'groups' or styles' of CSS that is written on a site. I had only so much time ;-)
I also did a web perf report that is not fully edited or ready for consumption, but does not that 54% of sites I ran Google Page Speed Insights against didn't compress all of their CSS assets. (Same sample of domains)
FWIW, max z-index that is cross-browser safe is: 16777271