2014 CSS Report: Examining how CSS is being used in the wild • Hacker News Board

Re: 2014 CSS Report: Examining how CSS is being used in the wild

#21

Post by AlexMcP » Fri, Jan 09, 2015, 12:02 AM UTC

AdamTReineke wrote: post #20

AlexMcP wrote: post #11

Hey OP here, I still have the data around if anyone has further questions to investigate.

Fascinating report! 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 doe…

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)

Re: 2014 CSS Report: Examining how CSS is being used in the wild

#22

Post by AlexMcP » Fri, Jan 09, 2015, 12:14 AM UTC

TheLoneWolfling wrote: post #12

AlexMcP wrote: post #11

Hey OP here, I still have the data around if anyone has further questions to investigate.

> Out of 79 valid style properties (not counting vendor prefixes) the author found 372 in use What were the most common invalid style properties?

None were particularly common, mostly hapax legomena: typos and wishful thinking like vertical-float and other things like that

Re: 2014 CSS Report: Examining how CSS is being used in the wild

#23

Post by cauterized » Fri, Jan 09, 2015, 2:05 AM UTC

freshyill wrote: post #6

mrdrozdov wrote: post #2

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…

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.

I always used to use BASIC numbering -- 10x the actual desired value in case you need to insert something in between!

Re: 2014 CSS Report: Examining how CSS is being used in the wild

#24

Post by cauterized » Fri, Jan 09, 2015, 2:09 AM UTC

AlexMcP wrote: post #21

AdamTReineke wrote: post #20

Earlier quoted context omitted.

Fascinating report! 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 doe…

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…

Could you use the existence of CSS maps to identify the presence of certain preprocessors, even if not to distinguish them?