Tags: fix

5

sparkline

iOS Six Fix

Last Christmas I gave you my bug report. Well, more of a whinge really. Scott put together a much better bug report and test page:

When the meta viewport tag is set to content=”width=device-width,initial-scale=1”, or any value that allows user-scaling, changing the device to landscape orientation causes the page to scale larger than 1.0. As a result, a portion of the page is cropped off the right, and the user must double-tap (sometimes more than once) to get the page to zoom properly into view.

Yes, it’s the old orientation and scale bug in Mobile Safari.

I’m pleased to report that as of iOS version 6, this bug seems to have finally been squashed. Hallelujah!

Given the relatively rapid upgrade path for iPhone, iPod Touch and iPad users, it won’t be long until we can remove our clever solutions for working around this problem.

Stand down, hackers, stand down. This bug has been taken care of.

Jeremy caught the mantis

South by CSS

South by Southwest has become a vast, sprawling festival with a preponderance of panels pitched at marketers, start-ups and people that use the words “social media” in their job title without irony. But there were also some great design and development talks if you looked for them.

Samantha gave a presentation on style tiles, which I unfortunately missed but I’ll be eagerly awaiting the release of the audio. I also missed some good meaty JavaScript talks but I did manage to make it along to Jen’s excellent introduction to HTML5 APIs.

Andy’s talk on CSS best practices was one of the best presentations I’ve ever seen. He did a fantastic job of tackling some really important topics. It’s a presentation (and a presenter) that deserves a wider audience, so if you’re involved in putting together the line-up for any front-end conferences, I highly recommend that you nab him.

Divya put together an absolutely killer panel called CSS.next, all about how CSS gets specced and shipped, and what’s coming down the line. All of the panelists were smart, articulate, and well-informed. The panel was very enlightening, as well as being thoroughly enjoyable.

And then there was the Browser Wars panel.

This is something of a SXSW tradition. Arun assembles a line-up of representatives from browser makers—Mozilla, Google, Microsoft, and Opera—and then peppers them with some hardball questions. Apple is invited to send a representative every year, and every year, Apple declines.

There was no shortage of contentious topics this year. The subject of Google Dart was raised (“Good luck with that,” said Brendan). There was also plenty of discussion about the recent DRM proposal submitted to the HTML working group. There was a disturbing level of agreement amongst all the panelists that some form of DRM for video was needed because, hey, that’s just the way things go…

As an aside, I must say I found the lack of imagination on display to be pretty disheartening. Two years ago, Chris was on the Browser Wars panel representing Microsoft, defending the EOT format because, hey, that’s just the way things go. Without some form of DRM, he argued, we couldn’t have fonts on the web. Well, the web found a way. Now Chris is representing Google but the argument remains the same. DRM, so the argument goes, is the only way we’ll get video on the web because that’s what the “rights holders” demand. And yet, if you are a photographer, no such special consideration is afforded to you. The img element has no DRM and people are managing just fine, thank you. Video, apparently, is a special case …just like fonts. ahem

Anyway…

The subject of vendor prefixes also came up. Specifically, the looming prospect of non-webkit browsers parsing -webkit prefixed properties was raised.

I saw a pattern amongst all three subjects: the DRM proposal, Dart, and browsers implementing another browser’s vendor prefix. All three proposals were made to address a genuine problem. The proposals all suffer from varying degrees of batshit craziness but they certainly galvanised a lot of discussion.

For example, Brendan said that while Google Dart may not stand a hope in hell of supplanting JavaScript, some of the ideas it contains may well end up influencing the development of ECMAScript.

Similarly, Mozilla’s plan for vendor-prefixing certainly caused all parties to admit the problem: the W3C was moving too slow; Apple should have submitted proprietary properties for standardisation sooner; Mozilla, Microsoft, and Opera should have been innovating faster; and web developers should have been treating vendor-prefixed properties as experimental features, not stable parts of a spec.

So the proposal to do something batshit crazy and implement -webkit-prefixed CSS properties has actually had some very positive effects …but there’s no reason to actually go ahead and do it!

I tried to make this point during the audience participation part of the panel, but it was like banging my head against a brick wall. Chaals kept repeating the problem case, but I wasn’t disputing the problem; I was trying to point out that the proposed solution wouldn’t fix the problem.

It was a classic case of the same kind of thinking we saw in the SOPA proposal:

  1. Something must be done!
  2. Implementing -webkit prefixes is something.
  3. Something has been done.

The problem is that it won’t work. Adding “like Webkit” to the user-agent string will probably have much more of an effect and frankly, I don’t care if any of the browsers do that. At this point, a little bit more pissing into the bloated cesspool of user-agent strings is hardly going to matter. A browser’s user-agent string isn’t an identifier, it’s a reverse-chronological history of the web. Why not update the history booklet to include the current predilection amongst developers for Webkit browsers on mobile?

But implementing -webkit vendor prefixes? Pointless! If a developer is only building and testing their sites for one class of device or browser, simply implementing that browser’s prefixed CSS is just putting a band aid on a decapitation.

So I was kind of hoping that Mozilla would just come right out and say that maybe they wouldn’t actually go ahead and do this but hey, look at all the great discussion it generated (just like Dart, just like the DRM proposal). But sadly, no. Brendan categorically stated that the proposal was not presented in order to foment discussion. And in follow-up tweets, he wrote that he actually expected it to level the mobile browser playing field. That’s an admirably optimistic viewpoint but it’s sadly self-delusional.

And what will happen when implementing -webkit prefixes fails to level the playing field? We’ll be left with deliberately broken browsers.

Once something ships in a browser, it’s very, very hard to ever remove it. During the Dart discussion, Chris talked about the possibility of removing Dart from Chrome if developers don’t take to it. Turning to the Microsoft representative he asked rhetorically, “I mean, do you guys still ship VBScript?”

The answer?

“Yes.”

Prix Fixe

A year and a half ago, Eric wrote a great article in A List Apart called Prefix or Posthack. It’s a balanced look at vendor prefixes in CSS that concludes in their favour:

If the history of web standards has shown us anything, it’s that hacks will be necessary. By front-loading the hacks using vendor prefixes and enshrining them in the standards process, we can actually fix some of the potential problems with the process and possibly accelerate CSS development.

So the next time you find yourself grumbling about declaring the same thing four times, once for each browser, remember that the pain is temporary. It’s a little like a vaccine—the shot hurts now, true, but it’s really not that bad in comparison to the disease it prevents.

Henri disagrees. He wrote a post called Vendor Prefixes Are Hurting the Web:

In practice, vendor prefixes lead to a situation where Web author have to say the same thing in a different way to each browser. That’s the antithesis of having Web standards. Standards should enable authors to write to a standard and have it work in implementations from multiple vendors.

Daniel Glazman wrote a point-by-point rebuttal to Henri’s post called CSS vendor prefixes, an answer to Henri Sivonen that’s well worth a read. Alex also wrote a counter-argument to Henri’s post called Vendor Prefixes Are A Rousing Success that echoes some of the points Eric made in his ALA article:

The standards process needs to lag implementations, which means that we need spaces for implementations to lead in. CSS vendor prefixes are one of the few shining examples of this working in practice.

Alex’s co-worker Paul disagrees. He recently wrote Vendor Prefixes Are Not Developer-friendly:

  1. Prefixes are not developer-friendly.
  2. Recent features would have been in a much better state without prefixes.
  3. Implementor maneuverability is not hampered without prefixes.

All of this would have remained a fairly academic discussion but for a bombshell dropped by Tantek at a face-to-face meeting of the CSS Working Group in Paris:

At this point we’re trying to figure out which and how many -webkit- prefix properties to actually implement support for in Mozilla.

The superficial issue is that web developers have been implementing -webkit- properties without then adding the non-prefixed standardised version (and without adding the corresponding prefixes of other vendors). The more fundamental problem is that while vendor prefixes were intended to introduce experimental features until those features became standardised, the reality is that the prefixed version ends up being supported in perpetuity. Nobody is happy about this situation but that’s the unfortunate reality.

Among the unhappy voices are:

Once again, Eric sought to bring clarity to the situation in the form of an article on A List Apart, this time publishing an interview with Tantek. Alex also popped up again, writing a post called Misdirection which addresses what he feels are some fundamental assumptions being made in the interview.

Finally, Mozilla engineer Robert O’Callahan—who I chatted with briefly at Kiwi Foo Camp about the vendor prefix situation—wrote about Alternatives To Supporting -webkit Prefixes In Other Engines in which he makes clear that evangelism efforts like Christian’s, while entirely laudable, aren’t a realistic solution to the problem.

It’s all a bit of a mess really, with lots of angry finger-pointing: at Apple, at Mozilla, at web developers, at the W3C…

My own feelings match those of Eric, who wrote:

I’d love to be proven wrong, but I have to assume the vendors will push ahead with this regardless. … I don’t mean to denigrate or undermine any of the efforts I mentioned before—they’re absolutely worth doing even if every non-WebKit browser starts supporting -webkit- properties next week. If nothing else, it will serve as evidence of your commitment to professional craftsmanship.

New Year’s Resolution

In a comment on Roger’s post about fixed and liquid layouts, Cameron wrote:

This issue seems to generate a heated debate every time it’s mentioned. I imagine one could pen an article with the headline “Fluid or fixed?” and nothing else, and yet dozens of comments would inevitably appear.

But rather than use that title, I couldn’t resist borrowing a pun from Andy, prompted by a post from Scrivs called What Resolution Will You Design for in 2007? (a classic example of the fallacy of many questions).

Now, firstly, we need to draw a distinction between monitor size and browser size. In other words, the difference between screen resolution and the viewport size:

There’s a real danger in thinking that “the numbers speak for themselves.” Numbers don’t speak for themselves; numbers need to be interpreted.

The numbers clearly show that monitor sizes and resolutions are getting bigger. The most common interpretation of that is more and more people have bigger displays. But an equally valid interpretation of the numbers is the range of displays is bigger than ever. It’s a subtle but important distinction. One interpretation focuses solely on the size of the highest numbers; the other interpretation focuses on the range of all the numbers.

The way I see it, the range is growing at both ends of the spectrum. Yes, desktop monitors are getting wider (though that doesn’t mean that viewports get any wider above a certain size) but handheld and gaming devices are likely to remain at the lower end of the scale. The Wii, for example, has a resolution of 640 x 480.

Mind you, the iPhone turns the whole question on its head with its scalable browsing. At MacWorld, Steve Jobs demonstrated this by visiting the New York Times, an unashamedly wide fixed-width website. On the Apple site, Wikipedia—a liquid layout— is shown fitting nicely on the display. The iPhone deals with both. Still, rather than letting my liquid layouts scale down to the iPhone’s width, I should probably start putting a min-width value on the body element.

Speaking of which…

A common argument against using liquid layouts is the issue of line lengths. On the face of it, this seems like a valid argument. Readability is supremely important and nobody likes over-long line lengths. But it’s not quite as simple as that when it comes to readability on screen compared to print, as Richard noted:

Surprisingly, I find short line lengths tiresome on screen; I don’t really subscribe to the empirical prescription of 7–10 words per line for comfortable reading. Most novels have 10–15 words per line and I think the upper region of that range is more appropriate for screen.

In any case, the idea that liquid layouts automatically means long line lengths on large screens is, I feel, a misconception. The problem is that a lot of the examples of liquid layouts aren’t very good and line lengths do expand without limit. But it doesn’t have to be that way.

In my opinion, the most important addition to Internet Explorer 7 is the max-width property. It means that we can now really start to look at creating fluid layouts within defined parameters, as demonstrated by Cameron in Andy’s book. In fact, I think we’re just scratching the surface of what’s possible in creating seamless adaptive layouts (and, more importantly, seamless adaptive page elements) using the dual power of max-width and min-width.

That still leaves Internet Explorer 6 and below. Should they get unbounded fluid layouts or should they get a fixed width fallback? The second is certainly an option using conditional comments, which is the Microsoft-approved way of dealing with rendering inconsistencies. I think that the lack of support for max-width certainly falls into that category. Call it transcending CSS if you will; I call it routing around damage on the designer’s network.

I want to hear what you have to say… if you’ve got something new to say. Let’s not just rehash the same old arguments that would inevitably appear had I simply asked “Fluid or fixed?”

Fixtorati

Technorati has been redesigned, or realigned if you prefer. It’s gone a bit gradient happy but overall, it’s quite a pleasing visual aesthetic.

For some reason though, they’ve chosen to lock the pages into a fixed width of 1024 pixels.

Now, I understand the reasoning behind fixed-width layouts. I can see the justification for wide fixed-width layouts on content-heavy sites like A List Apart (even if I disagree with it). But forcing users of what is fundamentally a web app to set their browser to a certain width seems counterproductive to me.

The content on Technorati is user-generated. Usually, that user is me. It has my favourites, my watchlist, and my search terms. I should be able to interact with that content in my way.

This is something that, as with so many things, del.icio.us gets just right. Upcoming is on the right track too. These sites allow me to interact with my data without putting me in a straitjacket.

Flickr is still avowedly fixed but the image-based, rather than text-based, nature of the data I store there makes this somewhat understandable.

Now, don’t misconstrue this as a tirade against 1024 pixel wide layouts. The problem would still exist in an 800 pixel wide design. Choosing an arbitrary number of pixels in which to serve up user-generated content is the issue here. On the one hand, Technorati is a very Web 2.0 sort of site, based on user-generated distributed content and collective wisdom. On the other hand, its visual design is grounded in a very Web 1.0 idea of top-down control and inflexibility.

I like Technorati a lot. It’s come on in leaps and bounds in the past couple of years. I’d like to use it every day. I’m even willing to put up with the oversize ads. But I resent the feeling that I should adjust my browsing environment to the needs of the site, rather than the other way around.