WebKitbits

WebKit for Developers

9-bits — Thu, 28 Feb 2013 09:06:25 -0800

Paul Irish educates us: What is WebKit? What isn’t WebKit? How is WebKit used by WebKit-based browsers? Why are all WebKits not the same?

Ten years ago today, which was actually a Tuesday, Steve Jobs...

9-bits — Mon, 07 Jan 2013 10:18:49 -0800

Ten years ago today, which was actually a Tuesday, Steve Jobs introduced Safari to the public at MacWorld in San Francisco.

Don Melton

Enabling new classes of applications with Pointer Lock

9-bits — Thu, 27 Sep 2012 09:50:42 -0700

Enabling new classes of applications with Pointer Lock:

The Pointer Lock API just landed in Chrome 22.

Adobe’s CSS Shaders Now an Official W3C Editor’s Draft

9-bits — Thu, 06 Sep 2012 10:39:43 -0700

Adobe’s CSS Shaders Now an Official W3C Editor’s Draft

Stick your landings! position: sticky lands in WebKit

9-bits — Thu, 06 Sep 2012 10:25:26 -0700

Stick your landings! position: sticky lands in WebKit:

HTML5Rocks:

position: sticky is a new way to position elements and is conceptually similar to position: fixed. The difference is that an element with position: sticky behaves like position: relative within its parent, until a given offset threshold is met in the viewport.

Great, native replacement for a simple scroll hack. Until this becomes an adopted standard, you may want to check out the Affix plugin in Twitter Bootstrap.

Google Chrome Grabs 1/3 Of Global Browser Market: StatCounter

9-bits — Wed, 08 Aug 2012 12:39:59 -0700

Google Chrome Grabs 1/3 Of Global Browser Market: StatCounter

Google Chrome Blog: New senses for the web

9-bits — Wed, 01 Aug 2012 17:42:06 -0700

Google Chrome Blog: New senses for the web:

Google releases a new stable version of Chrome:

Chrome now includes the getUserMedia API, which lets you grant web apps access to your camera and microphone without a plug-in. The getUserMedia API is the first step in WebRTC, a new real-time communications standard which aims to allow high-quality video and audio communication on the web.

What’s New in Safari 6

9-bits — Wed, 01 Aug 2012 12:41:28 -0700

What’s New in Safari 6:

New docs are up at the Apple Developer site. Some of the most notable new features include the Web Audio API, CSS Filters (hooray!), and HTML5 Web Notifications.

Google I/O 2012 - The Web Can Do That!? Great presention by Eric...

9-bits — Thu, 05 Jul 2012 12:33:34 -0700

Google I/O 2012 - The Web Can Do That!? Great presention by Eric Bidelman, covering some of my favorite new features in CSS3, some super-interesting bits of HTML5 like and the download attribute, and some amazing A/V demos at the end (getUserMedia FTW). A fantastic preview of the next stage of web applications.

What iOS 6 Mobile Safari Offers Front End Devs

9-bits — Tue, 12 Jun 2012 11:42:29 -0700

What iOS 6 Mobile Safari Offers Front End Devs:

taitems:

Here’s what we know about Mobile Safari in iOS 6 so far, and what it brings to the table for front end developers. I expect there’s more to come in future betas and as people experiment with the current beta more.

Great roundup of some serious improvements to Mobile Safari. I’m not breaking NDA if I just link to this stuff, right? RIGHT?!

"I would hate to think that we could be paving the way for countless errors just because img set is..."

9-bits — Thu, 17 May 2012 14:38:56 -0700

“I would hate to think that we could be paving the way for countless errors just because img set is easier to implement in browsers. Implementation on the browser side takes place once; authoring will take place thousands of times.”

- Mat Marquis in a special edition of A List Apart, discussing the two options emerging for responsive images and the recent collision between the WHATWG and the Responsive Images Community Group.

WTFWG

9-bits — Thu, 17 May 2012 14:37:52 -0700

WTFWG:

Tim Kadlec does a great job at breaking down the process which has led to the recent community disappointment in the WHATWG over the srcset attribute.

What message does it send when developers try to contribute their time, energy and effort to help solve a problem only to have it so casually dismissed?

Subpixel layout coming to WebKit

9-bits — Wed, 16 May 2012 11:43:24 -0700

Subpixel layout coming to WebKit:

bricss:

If you’ve ever tried to get precise em-based values of letter-spacing to work in a WebKit browser, you’ve probably wondered why that isn’t really possible, while Firefox or Internet Explorer 10 for example do allow fine-grained control.

Chromium has added experimental support for the Web Intents API...

9-bits — Wed, 16 May 2012 10:43:55 -0700

Chromium has added experimental support for the Web Intents API to Chrome stable.

Chrome DevTools Timeline has a new Frame Mode, making it even...

9-bits — Sat, 05 May 2012 11:23:00 -0700

Chrome DevTools Timeline has a new Frame Mode, making it even easier to see where your layout/rendering bottlenecks are. I look forward to even more improvements to this feature soon — it can be a bit vague at the moment, but it has incredibly useful information. Currently only available in Chrome under about:flags.

WebKit is the most popular mobile browser in the world. I...

9-bits — Thu, 03 May 2012 10:45:00 -0700

WebKit is the most popular mobile browser in the world. I alluded to this a bit in my article yesterday, but here are several reasons I think the chart above is misleading:

The breakdown

The first, most obvious, reaction I have is: The iPod Touch and the iPhone have the exact same browser. So already, “Mobile Safari” is the most popular browser in the world – My friend Hans was even kind enough to demonstrate. And what about Android? Android’s default browser has been notorious for not being quite as smooth as the iPhone’s, but generally, the two are kept quite consistent. In fact, even BlackBerry, since BB6, has used WebKit, and even that is pretty on par with the others. They all even use the same browser prefix, -webkit-.

But then what about Opera? It sure seem fortunate that there’s only one version of Opera out there, except…

Opera Mini

As an organization, Opera has done a great job at blurring the line between Opera Mobile and Opera Mini. For those who don’t know, these are very different browsers (much more different than, say, those found in iOS, Android, and BlackBerry). I have yet to see a chart showing geographic and traffic breakdowns between the two with real world numbers, so some of this is speculation, but I imagine Opera Mini makes up the vast majority of Opera’s userbase. Look at it this way: The only places where Opera has maintained a significant amount of traffic is Africa (where it simply dominates the competition) and Asia.

Opera Mini is the browser Opera installs on most feature phones, or, as I like to call them, “phone” phones. As Opera mentions, for many people, this is their only access to the internet. It uses a proxy system that basically creates an “image” of a website, server-side, sends that image down the wire, which is great, as it’s both faster and cheaper for feature phone users, especially on limited data plans. It is, essentially, the IE6 of the mobile web — A browser with an unfortunately high number of remaining users and a sadly minimal feature set.

Opera Mini does not support: HTML5 Video, Audio, new form fields, drag and drop, Session history, app cache, geolocation, orientation (though feature phones are generally vertical), any local storage option, or, on the CSS side: border-image, any gradients, the content property, transitions, animations, transforms (2D or 3D), and most text controls like text-transform, text-align, and text-indent. Let’s not even get into what it supports in regard to interactive JavaScript.

Interesting to note, that, if my theory is correct (“Mini” being more popular than “Mobile”), the prefix alias solution that they are recommending will only fix the CSS3 UX issues for the minority of their users.

Tablets matter (a lot)

The chart above also doesn’t take tablets into consideration. Now consider this comScore report from last year:

In August 2011, iPads delivered 97.2 percent of all tablet traffic in the U.S. iPads have also begun to account for a higher share of Internet traffic than iPhones (46.8 percent vs. 42.6 percent of all iOS device traffic).

In addition to the fact that over 97% of all tablet traffic is from the iPad, it’s important to note that it’s also higher than the iPhone when looking at iOS as a whole. You can practically just double the iPhone bar above.

But WebKit isn’t a browser!

And that’s not really crab in your maki roll. So what? It’s a rendering engine. It supports HTML5 and CSS3. Still, as noted above, it’s far more consistent in its capabilities and features, in all the different versions of all the different browsers it’s used in, than something like Opera Mini compared to Opera Mobile.

Why is this important?

The point is this: Don’t let people tell you where your values should be.

Most developers reading this post don’t care about how their sites look on Netscape Navigator 4 or Internet Explorer 3, or even half of the “still active” browsers listed here. Lots of services and apps are even moving away from IE6 (which, according to NetStats has just about marketshare as Opera on the desktop). How do we deal with all these browsers? We don’t. We pick a subset which represents the majority of our users, and usually spend a little extra time making sure the page looks extra spiffy for the modern ones (especially the modern ones with lots of users and amazing features). For older, but sadly still relevant, browsers like IE7 and IE8, we make sure our pages aren’t “broken.” For everyone else, we cross our fingers and hope this “web standards” kinda works like it said on the box.

This is how I treat Opera Mobile/Mini. I do my best to be a responsible developer. I always craft CSS with all the vendor prefixes (thanks Compass!), and I’m finally starting to get more and more into media queries.

By no means do I think any browser should ever get a blank page or a “This browser is not supported” message. But does that mean I need to test in every single browser? No. Does this mean I should spend time optimizing my sites for feature phones, which are most popular in Africa and Asia, and the minority of my web traffic? No. Would it be a terrible idea to build a progressive horizontal carousel, for iOS and Android, when they make up over 98% of my mobile audience. Of course not.

Work everywhere, absolutely — but don’t be afraid to go a step further for WebKit. It’s insanely powerful, fun to build with, and most likely represents a strong majority of your existing mobile web traffic.

CSS layout gets smarter with calc()

9-bits — Wed, 02 May 2012 10:54:43 -0700

CSS layout gets smarter with calc():

Didn’t even know about this feature, but it’s brilliant. A quick idea of what you can do:

#bar {
  height: calc(10em + 3px); 
}

And regarding current support:

The calc() property for lengths is available now in Chrome 19 (Dev channel build) by use of the ’-webkit-calc’ property, in Firefox since version 8 using the ’-moz-calc’ property and in Internet Explorer since version 9 unprefixed.

Why O, why? Thoughts on Opera's Implementation of WebKit's Prefixes

9-bits — Tue, 01 May 2012 16:14:00 -0700

For those new to the discussion, Opera recently implemented aliases for -webkit- CSS prefixes in its mobile emulator, potentially with plans to follow on the desktop as well. This means that Opera will now treat -webkit- prefixes the same way it treats -o-. Bruce Lawson, an evangelist at Opera, told .Net magazine:

Opera, along with Microsoft and Mozilla, announced at a CSS Working Group meeting that we would support some WebKit prefixes. This is because too many authors of mobile sites only use the WebKit-prefixed version, and not even the standard, unprefixed one, when it is available.

Microsoft actually followed up:

A Microsoft spokesperson has provided a comment to .net on that company’s position: “A passing comment made in a working group meeting has clearly been misinterpreted. Microsoft won’t support –webkit prefixes in Internet Explorer.”

I highly encourage you to read the actual transcript, though. It’s important to note that the conversation is equally led by Tantek Çelik, from Mozilla, and the healthy conversation/debate that follows. It is clear that this move is part of a larger conversation about browser share and mobile usage.

A little context

Here’s my thirty second rundown of the mobile web: iOS and Android are killing it (Note, iPod Touch is a separate line), especially in North America, South America, Europe and Australia. Opera maintains a strong presence in Africa and Asia, most likely thanks to Opera Mini, and even that dominance is starting to come under attack. BlackBerry use continues to generally decline, though locale plays a big role here. WebOS is dead. On the horizon, Microsoft seems to be on a decent path with IE in Windows Phone and similarly Mozilla has got some great stuff in the works — that said, neither has traffic even worth mentioning at the moment.

To get specific, mobile WebKit currently accounts for about 50.58% of worldwide mobile traffic, with Opera in second at 20.93% (May 2012, excluding tablets). So it’s easy to see why developers are using features they find in WebKit: The browser is becoming incredibly popular with consumers and has great features. This also hopefully illustrates why Opera was the first to implement this idea of aliasing WebKit’s prefixes — in a certain light, they are the only browser remaining that poses a threat to Mobile WebKit’s advance.

The stated problem

It’s clear that implementing another browser’s prefixes is a solution — but what problem is it solving, and for whom? The next line from Bruce Lawson’s quote:

This leads to a reduced user experience on Opera, Mobile Firefox and Mobile IE, which don’t receive the same shiny effects, such as transitions, gradients and the like, even if the browser supports those effects.

Let’s break this down. In fact, even if Opera pushes -webkit- support into production, most features will still not be accommodated by Opera Mini, only Opera Mobile. So the web is slightly less “shiny” for some browsers — some browsers are getting flat, square buttons when they could have round, bevelled ones. Certainly, though, this is not a new concept to web developers or browser vendors, nor is it “broken” by most modern web developers’ definition. There is a small exception to this, noted below.

The real problems

So what, then, are the real problems that aliasing WebKit’s properties solves?

Usability issues that arise from poorly implemented CSS3. Really, the only case in which I see these effects “blocking content” is with gradients: When web developers fail to declare a backwards-capable background-color. I would think this is rare, however it is a very real UX issue hitting users that vendors have an opportunity to fix.
Non-WebKit mobile browser vendors are losing mindshare, especially among developers. Aside from “the gradient issue”, I don’t believe having a few fancier effects will help vendors here. It would appear that mobile mindshare, for both consumers or developers, is now heavily dictated by hardware, hardware integration with the browser, and platform (operating system).
Browser vendors are tired of answering support requests for features they know they support. From this specific example, I don’t think Mike and I are on the same page about “regular users.” (I would imagine most don’t even know what border-radius means). Again, this is not a problem for users as much as it is for browser companies, nor is it a new problem in any way.

My problem

So there you go. We have real problems, for both the browser vendors and the users.

If it isn’t already clear, I’m not a fan of this solution, and we’ve finally arrived at the crux of why: It is a short-sighted solution, primarily for the benefit of browser vendors, which contradicts an existing standard.

For the first problem noted above, regarding usability and gradients, it acts as a Band-Aid. Though it will fix the usability for their own latest browsers, it does not educate users, sends the wrong message, and leaves the site broken in older browsers.

This last FAQ from the announcement highlights what I mean:

So I only need to use -webkit- prefixes now? w00t! Absolutely not. We’re doing this now to ensure that there is compatibility with the 13 features we’re aliasing. We hope we never need add any more and that we can drop support for these. It remains vitally important to make sure that you code for all browsers, even if they don’t have support for a certain feature while you’re coding.

This is a bit of a, “Do as I say, not as I do,” type of answer. Performance-minded users will consider dropping -o- prefixed rules in order to save precious bytes in their CSS, especially for stylesheets with a lot of rich gradients. This idea could gain popularity if other browsers follow suite (Mozilla is clearly interested, even if Microsoft is backing out). In essence, Opera is saying, “Code the same best practices that have always been around,” while gently pulling you aside to say, “But if you don’t, no worries, we got you covered… for now.”

Faruk Ates sums it up best:

What this results in, however, is that “lazy web devs” now have even less incentive to do the right thing and test their work in Opera, because the onus has now fallen to Opera entirely to make sure their browser is doing everything right.

The problem leads to a solution that reinforces the problem.

A small technical consideration

Most of my objection thus far has been conceptual. There is also one small issue with the implementation I should note, though it is fairly nuanced:

In order to send a rule with different values to Opera, it must be after the -webkit- rule in the cascade… We discussed having the -o- prefixed version always trump a -webkit- version, but that breaks the cascade mechanism of CSS, which make it much harder for authors to debug sites and could have many unforeseen consequences. Therefore, we ask you to make a once-only check.

Essentially, I do think that -o- should always trump -webkit- in Opera, for what I hope are fairly self evident reasons. Opera cites the “cascade” here, but the CSS cascade has never been applied to separate vendor prefixes like this — in fact, this seems counterintuitive as it runs the chance of “breaking” existing sites. If one is supplying separate versions to WebKit and Opera, they now have to check the order of these declarations across all of their stylesheets.

Again, the aliases solution is a bit of a hack meant to improve UX for these browsers — I don’t believe it should mandate that browsers who implement multiple prefixes necessarily treat them “equally.”

Take a deep breath

I’ve had the pleasure of meeting several Opera employees at various conferences, and pretty much every one has been a good-hearted, uber-talented developer. The engineering team at Opera does an amazing job at implementing and, to some degree, leading web standards. I, personally, do not test on it enough — and subsequently silently carry my shame like most other US-based web devs I know. I’m sure they have done wonderful research leading up to which properties they chose to alias, and I am sure, to their word, they handle those properties just fine. No cities will explode and no kittens will be harmed.

In fact, contrary to popular belief, it is my respect for Opera which has led to this post. For better or worse, the CSS WG, and Opera’s browser development, operate in the public. If this were a silent upgrade — and didn’t disturb current behavior as noted in the technical section above — none of us would know, let alone care. Unfortunately, though, all of this does happen in the public, and so the choices they make send a message.

I simply believe that at best, this solution acts as a Band-Aid, and at worst, it adds new incompatibilities, sends the wrong message to developers, and sets a loose, subjective guideline for other browsers to follow suit.

Some other potential solutions

To avoid being accused of taking the easy road, I have compiled a list of other possible ways Opera could try to improve our situation:

Fix Vendor Prefixes

Revise the purpose and implementation of vendor prefixes. I understand the need for browsers to implement each others’ prefixes, because we’ve made a bit of a mess — I just think we should do it in a more global, thought-out approach, with rules. One example: What if browsers could identify -anything- in addition to the unprefixed rule, once it has been accepted as a Candidate Recommendation? This is slightly similar to what Opera is doing, except they would have to leave out Transitions, as it is still a draft.

Also, let’s drop the “we hope we can one day remove this” from the messaging. Find a backwards compatible, permanent, solution and let’s move on.

Evangelize

Send an email to the CTOs and CMOs at Microsoft and Mozilla and use the subject line, “APPLE N GOOGLE R GOIN DOWN!!!” That’s attention grabbing. Anyway, tell them you want to run a campaign to get web devs using all the CSS prefixes. Pool your money and hire some badass web designers. Create demos that rock our faces — Except, on Mobile WebKit, create an interstitial: “We noticed you’re visiting on a WebKit browser.”

Bam — immediately, this will bring up strong emotions from the dark days in most developers. “While this demo also work in your browser, it looks equally fantastic in Opera Mobile, Firefox for Android, and Internet Explorer. This matters. There are currently XXX,XXX,XXX people who browse the mobile web every day, who don’t have iOS or Android. Learn more.” Then, in your learn more, explain why this matters, and link to resources like Can I Use, Prefix the web, and CSS Prefixer and great tools like Sass/Compass, Less, and Stylus.

In short, continue evangelizing: It’s the most important part of making sure this issue is not just fixed in your latest browser, but across the web.

Realize you can’t win them all

Make a page on the internet that says, “Sorry, not all pages on the web look exactly the same.” Then, when someone emails you saying, “Hey, this button looks more round on my laptop,” you can just reply with the link. Actually, it already exists! (thanks Jay)

If they send a more substantial error, like the gradient example above, say, “Sorry, this is a bug on the website’s part, you should contact them.”

And finally

If you’re a web developer, use CSS prefixes responsibly. They mean “experimental.” If we didn’t screw this stuff up so much, the browsers wouldn’t have to consider this hack. That said, if we are going to do something about it, let’s think it through to its logical conclusion: A global, backwards-compatible, change to the current implementation of vendor prefixes.

Adobe & HTML Adobe has released a new site to showcase all...

9-bits — Tue, 24 Apr 2012 09:25:00 -0700

Adobe & HTML

Adobe has released a new site to showcase all of its recent work with HTML5, like CSS Regions and Shaders. Definitely worth checking out.

Modern Web Development, Part 1 - The WebKit Inspector

9-bits — Tue, 24 Apr 2012 09:16:41 -0700

Modern Web Development, Part 1 - The WebKit Inspector:

Amazing and thorough rundown of the features in the WebKit inspector, including some of the newer features in Chrome Canary.