Articles Tagged ‘Microsoft’

Vendor Prefixes and Evangelism

If you follow any front-end web developers on Twitter today, you’ll probably have come across articles on vendor prefixes and the latest CSSWG fight over Mozilla, Microsoft and Opera wanting to implement -webkit- vendor prefixes. Before I delve into why this is happening, I want to make something very clear – this is wrong and must not happen.

So why is it happening?

The February 2012 face-to-face meeting of the CSSWG [complete transcript] had vendor prefixes on the agenda because:

glazou: Title is: Why and How to Implement Other Vendors' Prefixes
   tantek: This is a specific subtopic of vendor prefixes
   tantek: The problem statement right now, and this is a problem for
           Mozilla and any other non-WebKit browser
   tantek: Sites have webkit-specific content, and serve backup content to
           everyone else. Specifically for mobile content.
   tantek: Non-WebKit browsers face prisoners dilemma
   tantek: similar to quirks in 2003 or so

FYI: glazou is Daniel Glazman, chair of the CSSWG, tantek is from Mozilla. Other parties who appear in quotes are Peter Linss (HP), Florian Rivoual (Opera), Sylvain Galineau (Microsoft) and Simon Fraser (smfr from Apple).

So far, sounds reasonable, then tantek continues:

tantek: At this point we're trying to figure out which and how many webkit
           prefix properties to actually implement support for in Mozilla
   plinss: Zero.
   tantek: Currently we have zero. Zero is no longer an option for us.

Suddenly, everything is turned upside down. Opera and Microsoft start saying the same thing – the argument is that of the top 1000 websites, a significant percentage uses webkit-only prefixes without the other browser prefixes.

glazou: A long time ago, Mozilla had an Evangelism team that would call up
           the website owners and ask them to change.

This refers to developer evangelism, people like Bruce Lawson, Martin Beeby and Rob Hawkes to name just three (Google has a huge team – [Thanks to Michael for the correct link]). All of these people are pioneers in web technology and use vendor prefixes every day, and all of them tell developers to use the other browser’s vendor prefixes too. This is not the opinion of the CSSWG:

 Florian, Sylvain: Evangelism has failed.
   glazou: Have you tried pinging the WASP about that? Other activists of web
           standards?
   sylvaing: If MS can't scale to handle this, you think WASP can?
   tantek: Opposite is happening right now. Web standards activists are teaching
           people to use -webkit-
   tantek: People like Lea Verou.
   tantek: Their demos are filled with -webkit-. You will see presentations
           from all the web standards advocates advocating people to use
           -webkit- prefixes.

These words make me sad indeed. The CSSWG has lost faith in evangelists and the community upon which it relies so much that they are prepared to implement other vendor’s non-standard code and prefixes to help them gain market share back.

Quirks mode all over again

Yes, this is where we’re at. The current dominance of webkit, especially on mobile, is causing developers to adopt non-standard technology and only those bits of technology for webkit. This cannot happen. Daniel Glazman understands:

tantek: What are the thresholds, even approximate, for implementing
           -webkit- properites (or none)?
   glazou: Unbelieveable we are having this discussion.
   Florian: Our job is to solve interoperability. We want to discuss it here,
            because that's our job.
   tantek: Help us minimize the damage.

There are two problems that have been raised: that webkit has an “IE6 style” dominance over mobile, and that developers are making matters worse.

Time for action

The first problem is not a problem at all. It is a symptom of developer knowledge being controlled by the “latest sexy and experimental technology”. Developers are fixated on making all of those great effects that we used to have with Flash work on iPads and iPhones, and because that’s webkit only, they pay no attention to the other browsers that can use their sites. Web standards is going backwards, and it’s our fault. It’s not Apple’s, it’s not Google’s, they simply make technology available, we produce code that only targets them.

The first step is to admit that there is a problem. Look at your code. If there is a vendor prefix for any property ask yourself why you chose to use it. If there’s a good reason (like 2d transforms are cool) then look closer – have you put all of the other vendor prefixes there as well? Have you checked the syntax to make sure it’s the same (because that’s what vendor prefixes are for). One final thing is to make sure you never do it again. There’s tools to help like prefix-free and SASS and LESS CSS pre-processors all do this for you.

Do it.

Change for browsers is harder

I’ll quote directly from Remy Sharp on this one:

Browsers need to:

  1. Fucking drop experimental prefixes. It’s unacceptable and a disservice to the developers working with your browser. You need to give timelines to dropping these things.
  2. Non-production ready browsers should support experimental prefixes, production ready releases should not. If it’s Chrome 16 – the stable version – experimental support should not be baked in. The properties should be full available without the prefix.
  3. Work with the working groups (…Apple).

I especially like item 2 here. Too many developers use dev channels as their main browser (I know I do). This is fine, but by removing prefixes from stable browser versions has the great advantage of breaking for your clients who will be on the stable channel. This will raise bugs and force developers to change their code. It works for me has never been a good excuse, and with this change it never will be.

Make some noise, Internet

None of these changes will be made if we don’t get the evangelism community back on its feet. For too long have we assumed that everything is hunky-dory now that HTML5 has ridden in and saved us from non-standard implementations. I implore you, blog about this, shout about this, tell your friends and make them review their code. Vendor prefixes are here to stay, and so are the five major browsers. You must code for all of them, all the time. Shout it from the rooftops, the only good vendor prefix, is every vendor prefix.

Microsoft’s Design Evolution

Windows 7 Series Phone UI

This is an opinion piece about Microsoft’s Windows 7 Series phones. The opinions are my own and not that of my employer.

I remember the ‘good old days’. Back in 2004 (at uni) I tried to create a Windows CE program for a little mobile device. My friends and I spent months trying to get it to work (at one point resorting to Java, quickly realising our mistake), and in the end all we could produce was a list of menu items and a few forms. The overall user experience (UX) was horrible and it was slow and unintuitive. That was the standard for Microsoft products of the time.

The turnaround began in 2005 when MS hired their new head if UX for Office, Jenny Lam. Jenny revolutionised the tired Office UI with the ribbon, and hence inspired the Windows 7 UI. A few years later, the Xbox team developed the NXE, based on ideas from the Windows Vista media centre interface, which was leaps and bounds better than the XP MCE UI. This “text focused” design, using Jenny’s Segoe UI typeface found it’s way into he Zune, and came to fruition in the Zune HD. From this, we get the next evolution, the 7 series phone.

With such a clear evolutionary path, it’s hard to see why so many people are surprised by the new phone OS. When the Zune HD launched, people cried out for this UX to be made into a phone. Now that wish has been granted and Apple should be scared.

The 7 series UI is everything that the iPhone is not. It’s got a home screen that displays useful information, with integration into multiple web services out of the box. It’s got cloud-enabled apps, not relying on purpose built sites but working with service leaders. It’s got a calendar that’s useful, and a UI paradigm that is consistent, though, as with the ribbon toolbar, will take some getting used to.

And that’s the thing with MS’s UX strategy. They are now prepared to go out on a limb to try new stuff, even if it may require a learning curve.

We had a question go round the office a few days ago: name a MS app that was rubbish at first, and is now a market leader. We named pretty much every product that MS make (except IE). With 7 series phone, MS have completed their line up. Far from being a dead company to the consumer, Microsoft are still the king of the hill.

Where do MS go from here? The evolution will continue, and although it will seem slow, with product releases every 2-3 years, innovation will continue to flourish. MS will never be a trend setter, and will mostly go their own way, but their way is rarely wrong. I predict that MS still have their best work within, and you would be a fool to ignore them.

jQuery to be Integrated with ASP .NET

Fantastic news! Long-time golden boy of the javascript world, jQuery, is to be integrated with Microsoft’s ASP .NET framework.

In an announcement today on the jQuery blog, Scott Guthrie’s blog and Scott Hanselman’s blog, the jQuery library would be distributed AS IS with Visual Studio 2008 SP1 and the free Express editions. The aim is to extend ASP .NET AJAX support and generally make life easier for MS developers. Microsoft would also be contributing tests and patches to the jQuery core, but would not be submitting features etc.

This is a massive boost for a framework that won me and my company over a long time ago. jQuery now has backing from the biggest names in IT and will benefit immensely from the additional support.

The benefits are not only for the jQuery team, they’re also for any web standardistas. This support for jQuery signals Microsoft’s intentions for the ASP framework. I can only hope that from this, Microsoft adopts jQuery in its entirety, having ASP output unobtrusive, cross-browser javascript, not the ‘impossible to debug or follow’ mess that it currently uses.