4 ms·

That query means nothing. Most of those results include the non-prefixed version as well. The prefixed one is there for backwards compatibility.

• masklinn 12y ago
  > That query means nothing. That query means developers by and large don't care and just cargo-cult through. > The prefixed one is there for backwards compatibility. Backwards compatibility with what, fucking Chrome 6? How many of these sites have been tested for backwards compatibility in Chrome 6? I'd bet it's somewhere around "none whatsoever".
  • tomjen3 12y ago
    No reason to remove them when they are there.
    • masklinn 12y ago
      Erm… the query is sorted by most recently indexed, this is code which was just changed, the top hit at this moment is https://github.com/mdilaver/mdilaverins/commits/421298cf9bf1a02ffa6619b81aa17dfb3f8dbb5b/public/assets/css/style.css https://github.com/mdilaver/mdilaverins/commits/421298cf9bf1... which is 5 days old.
      • bzbarsky 12y ago
        That's because this CSS is using CSS transforms. And while IE and Firefox have supported unprefixed CSS transforms for a while now, Chrome and Safari only support the -webkit-prefixed version of CSS transforms so far. So if you want to do transforms, you have to use -webkit prefixes...
        • masklinn 12y ago
          > That's because this CSS is using CSS transforms. Oh for fuck's sake, the query is specifically looking for -webkit-box-sizing, not for webkit-prefixed properties in general.
          • bzbarsky 12y ago
            Ah, I missed that you were specifically talking about -webkit-box-sizing use there!
  • Isofarro 12y ago
    Smudge raises a valid point. The presence of both the webkit prefixed version and the standardised non-prefix version is adequate. The problem IE Mobile are working around are those developers who have the webkit prefixes CSS properties, but not the standard no-prefix version. Chrome won't remove them because it breaks these sites relying on the webkit prefix remaining - so there's sufficient ground there to indicate developers are failing. But it's not the developers who include the non-prefixed standardised version. Yes, there are lots of developers who don't care - the ones who rely on the webkit-prefix support remaining. That is contrary to the spirit of vendor prefixes - experimental CSS properties that should not be relied on. Those using both the webkit prefixed and the standard non-prefixed versions are using the typical graceful fallback - one that doesn't make other browsers "unsupported"
  • Smudge 12y ago
    Preprocessors often have prefix support baked in. It's not about explicitly testing your site for backwards compatibility. It's about casting that net as far as possible with minimal effort.