Thomas Fuchs:

My advice: better do away with ALL raster graphics for your web app or site.

I agree. He suggests SVG, custom fonts, or other CSS 3 features, while keeping in mind the need for accessibility (which I think weakens the viability of solutions like custom fonts, like pictos).

Ultimately, whatever the solution, we’re approaching a time when the majority of our web designs will become dynamically rendered vector graphics, not unlike Flash. Which, while problematic, was extremely successful because it solved real problems like resolution independent interfaces.

In response to Mozilla seriously considering implementing -webkit prefixes in Firefox, Remy Sharp is calling out Browser makers and saying that vendor prefixes need to die.

My Idea

Before I decide to agree or disagree with either of those possibilities, I wanted to put forth my idea that browsers should add vendor prefixes to everything. I realize this is a rather asinine and eccentric idea, but I consider it useful in the way the now defunct conditional comments worked for me to solve Internet Explorer challenges.

For example, Firefox had an annoying rendering issue with buttons that required me to use this “elegant” solution (with brevity added):

@-moz-document url-prefix() { button { padding: 3px; } }

I would have much rather written: button { -moz-padding: 3px; }

I’m willing to hold the opinion that this could be awful in practice, but it would have solved that particular problem with much less bullshit. It might even be useful to do something along the lines of button { -moz-9.0-padding: 3px; } to specifically call out the version of Gecko I wanted to target, because the exact issue I mention above was fixed in a version after I wrote my hack and now I’m in the unfortunate position of having CSS that works in old browsers, but breaks in newer ones. Fuck.

So… Do I agree? Should Mozilla adopt the -webkit vendor prefix?

In my opinion, if Mozilla adopts the -webkit prefix within Gecko then they may as well kill Gecko and adopt WebKit itself. At which point, why do they even exist?

Should vendor prefixes die?

In principle, yes. But I sincerely doubt we’ll ever see a world where browser vendors and the various working groups get their shit together well enough to actually solve the standards problem. In the mean time designers and developers will continue to use and abuse what’s available to them because that’s how people work. If it’s there, its theirs.

"How do you know it’s a priority? Because it got done."

"How do you know it’s a standard? Because it’s in the Browser."

In reality, I still have to work around that damned Internet Explorer. Furthermore, I’m of the opinion that IE6 being the standard we worked with and fought against for so long was the best thing to ever happen to Web Design, as it became a craft during that era. Now? We’re spoiled.

What will happen is that this whole kerfuffle will collapse into a better solution within the next year or two. WebKit is already the standard — it’s just not very evenly distributed.

I’m currently working on some rather awesome stuff with SproutCore and it’s shiny new Template Views. They’re an excellent solution for the most part, but being only a few months old they’re still somewhat buggy.

Originally in sproutcore-1.6.0.beta.(1|3) the touch events in the template view didn’t bubble properly which prevented the iPhone view from scrolling at all. That’s been fixed in 1.6.0.rc.1, however I ran into a new issue. When the window orientation changes from portrait to landscape, or vice-versa, I change the classes on a couple divs so that I can show a UI that’s most appropriate for the perspective. This was working excellently until this morning. For whatever reason the view isn’t actually updating until I touch the screen. Obviously this isn’t good enough.

Fortunately, the fix, with props to Stoyan Stefanov, is rather simple in principle. I’ve simply added a helper function to my app that adds a junk style to a stylesheet.

  bruteForceRepaint: function() {
    var ss = document.styleSheets[0];
    try { ss.addRule('.xxxxxx', 'position: relative'); }
    catch(e) {}
  }

There’s probably a better place to put this, but for now I’ve added it directly to the Application object itself. Then I simply call this within the statechart’s portrait and landscape events after the classes are updated. The whole snippet looks like:

Landscape: SC.State.design({
  enterState: function() { 
    MyApp.LandscapeView.set('isActive',true);
    MyApp.bruteForceRepaint();
  }

I had initially written this up using Thomas Fuchs’ technique, but I found that it wasn’t reliable enough. Sometimes it worked, sometimes it didn’t and I don’t know why. The above script, while polluting the stylesheet, is far more reliable. I haven’t seen it fail yet.