Hacker News Reader

Comment by potch | Hacker News Reader

My complaint is not that -webkit CSS extensions are bad. I love how fast the browsers move. It's that people aren't careful to make sure they use all the prefixes when they're available. It's an education problem, but people using CSS preprocessors such as LESS and SASS have no real excuse.

View on HN

That wouldn't be a problem if the non-vendored variants of the CSS attributes didn't take so god damn long to become proper standards.

The problem is not the webkit vendor attributes, the problem is that proper standards aren't able to keep up.

HTML5 is still not a proper W3C standard (or "recommendation"), it's still just a working draft, and was last updated in May of 2011. It's been six years. So far.

100% agreed. The process has to move faster.

I don't really understand this objection. Sure, HTML 5 isn't officially a standard, but neither is -webkit-whatever; in both cases, you can use whichever non-standard you like, subject to browser support. The advantage of the W3C draft is that it is a non-standard that the browser makers are all working towards.

The objection is that the standardization process is too slow. Not a little bit too slow, but so glacially slow it's almost indistinguishable from abandonment. So, progress of key web technologies needs to be put into vendors's hands.

CSS border-radius is still not a W3C recommendation. It's been a draft for nine and a half years. So far. It was last updated one year ago.

With a standardization process that broken, vendors need to take things into their own hands, and them doing so, especially webkit doing so, has been an astounding success, IMHO.

Yes, but why does it matter that the standardization process is slow? What is the practical relevance of something moving from "Candidate Recommendation" to "Recommendation" status? Why are draft standards any worse than vendor extensions?

Prefixed attributes bring features to developers while they are still experimental, which means we don't have to wait a decade before trying them out.

HTML is a living standard and was last updated yesterday:

   http://whatwg.org/html

The W3C Recommendation process is obsolete.

This is something that the discussion hasnt touched yet, but I don't know that you can assume that devs are omitting the vendor-specific prefixed border radius out of laziness. I'm frequently guilty of coding base lowest-common-denominator CSS, then enhancing the WebKit experience -- not because I'm not aware of the vendor-specific attributes for other rendering engines or because I'm too lazy to type them out, but because only the WebKit rendering is satisfactory.

I'm not entirely certain about this approach though, so what is the real harm in a web where boxes have slightly rounded corners in one browser and not another? I'm also curious if anybody has examples of WebKit-only sites (that don't actually function in other browsers) that don't fall under the heading of "look at this cool new CSS thing that this site exists to demonstrate."

Here are some examples. I have a lot more. It's hard to develop a new browser when everyone has a "must have" site that serves degraded or broken markup to everything except WebKit.

Google Maps in WebKit: http://dl.dropbox.com/u/2128410/maps-webkit.png

Google Maps in Firefox: http://dl.dropbox.com/u/2128410/maps-firefox.png

Gmail in WebKit: http://dl.dropbox.com/u/2128410/gmail-webkit.png

Gmail in Firefox spoofing a WebKit UA header: http://dl.dropbox.com/u/2128410/gmail-firefox-webkit-ua.png

Gmail in Opera or Firefox normally: http://dl.dropbox.com/u/2128410/gmail-opera.png

Twitter in WebKit: http://dl.dropbox.com/u/2128410/twitter-webkit.png

Twitter in Firefox: http://dl.dropbox.com/u/2128410/twitter-firefox.png

These are just some of the big-name sites that I knew off-hand. At least these high-budget sites usually have some sort of fallback. Some sites just have degraded styles; some have parts that are unreadable. Some provide partial functionality to non-WebKit browsers; others won't work at all (like Bing web search in Opera).

This is becoming more common on the desktop too, with sites like Tweetdeck that just lock out non-WebKit browsers using UA sniffing: https://web.tweetdeck.com/web/unsupported.html

Developers are ambitious. We want to build better apps now not in 6 years time when the W3C have finally moved on this or that issue. Right now webkit is enabling developers so it wins. Supporting every browser is either economically not viable or not possible without sacrificing features. If mobile firefox wants to compete it needs to step up. If developers are voting with their feet and actually using webkit features in the wild then they are defacto standards. Firefox better pull its finger out or it will die.

It's true, and since everyone upgrades their phones every two years it's not like there's a chance of older versions of a hegemonic browser haunting developers' dreams, right?

In all of the above cases, Firefox actually does support the features used by these sites, and has for a long time (years, in some cases). In most cases the developers would just need to tweak their UA sniffing, or add some -moz properties alongside the -webkit properties in their styles.

For some technical details, see for example http://bugzil.la/668218

Mozilla does need to "step up" -- but work required to fix cases like these is not technical. It's about gaining user marketshare, developer mindshare, and improving the standards process.

Great examples. I think even the WebKit touch events version of Google Maps is broken, but, not being a Gmail user, I had no idea they were blowing it that badly. I use both Maps and Twitter every single day, but -- and here's another facet of the problem -- always through applications. I encounter Maps embedded in (WebKit) pages only enough to be annoyed by them, and I haven't been to twitter.com in at least a year. This is eye-opening. Clearly we're not just talking about drop shadows.

Reply on news.ycombinator.com