Articles in the ‘Web Standards’ Category

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.

Adobe’s Acquisition of Nitobi and TypeKit: Great for them, not so much for us

Adobe has done the unthinkable, it’s actually bought two companies worth giving a crap about. Nitobi, makers of PhoneGap, and TypeKit, pioneers of the CSS3 web-font game, have been acquired by Adobe.

Adobe should be thrilled.

It’s now got two sets of highly skilled developers with great ideas and good products to work with. TypeKit is an obvious acquisition as it’ll be part of Adobe’s Creative Cloud offering that gives them the ability to use (and sample) a huge range of fonts across their apps.

Adobe have also promised that PhoneGap will remain open source, being donated to the Apache Software Foundation. This feels strange, as then Adobe just gets the developers at Nitobi themselves (who are obviously very good). This begs the question: why did Adobe bother with it?

Well, Adobe is a tools company – they make programs that we make other cool things with. Nitobi was also a tools company, making PhoneGap, that lots of people made cool things with. Alongside the PhoneGap framework, there were two smaller projects, PhoneGap Build and Cordova.

PhoneGap Build

PhoneGap Build takes the pain out of making PhoneGap apps for multiple platforms. If you’ve ever tried to do a build for iOS, Android and Blackberry, you know it’s a world of pain and about 10GB of tools and frameworks. PhoneGap Build takes this all away from you, and is a service that Adobe can integrate into their Cloud offering.

Cordova is the stand-alone desktop equivalent of PhoneGap Build. It’s creator, Brian LeRoux, recently said:

All the cli tooling prototyped in Cordova now first class in phonegap/[ios|android]. Time to update Cordova.

I take this to mean that Cordova is back in focus, and Adobe will be actively looking to integrate it into DreamWeaver, in the same way it integrated jQuery Mobile.

We should be wary

Adobe’s track record for mergers is not great. The Macromedia merger led to a focus on Flash and Photoshop, whereas other products like DreamWeaver and Fireworks were not given the time that they deserved. Lots of people lost their jobs in that merger too and I’d hate to see that happen to the guys at Nitobi or TypeKit.

We have to watch out for rising prices and being forced to buy products that we don’t need. I can see it already: with PhoneGap integrating with DreamWeaver, the easiest way to build a PhoneGap app will be with that product or Build. Yesterday, those in the PhoneGap Build program were sent a pricing structure:

PhoneGap Pricing Announcement

PhoneGap Pricing Announcement

I can see these prices going up, and up (and they’re not that cheap to begin with). One build a day with the free package probably isn’t enough. I hope the same doesn’t occur with TypeKit, or people will just move to one of the other services that exist (Fonts.com for example).

The other danger is that somewhere down the line, these products that many have come to rely upon will simply cease to exist. Merged so deep into Adobe’s pipeline, the one thing that made them great, their independence, is stripped from them and the revolutions that they make simply slow down and stop. With the core of PhoneGap, we’ve been promised that they’ll actually have more time for it and I hope this continues for as long as possible. What I’d hate to see is the core being neglected in favor of tools for products that I don’t want to buy.

Fingers crossed that Adobe will really make something good this time, and that their commitment to the web and web standards continues, but I won’t be holding my breath.

Sketchnotes from #LWS3D – A 50-line WebGL app

After a summer break, London Web Standards was back with an evening of WebGL with Ilmari Heikkenen from Google and a short demo from Carlos Ulloa of HelloEnjoy. Sketchnotes are below

Carlos Ulloa of Brighton-based HelloEnjoy showed off two demos that he made using Three.js and WebGL. The first was HelloRacer, an interactive look at the 2010 Ferrari F1 car that you can even drive and do handbrake turns in. The second demo got it premiere at LWS, an interactive music video for Ellie Goulding’s “Lights”. Honestly, it was extremely cool, on a Ro.me “3 dreams of black” scale. It’ll appear at the linked URL in the next week or so. There’s a great Q&A session on the London Web Standards blog of the event for more detail on how they did it.

Ilmari Heikkenen showed the gathered crowd how to make a basic WebGL app using Three.js in about 50 lines. He showed off all of the components that you need: a renderer, scene, camera, mesh and lights (and shadows). He went into more depth about vertex shaders and fragment shaders, the GPU effects that make everything look a lot more real.

Ilmari gave examples of a few uses, including games, 3D bar charts and scatter graphs. He then started animating all of these, including a 10,000 point scattergraph that moved in real-time. Finally, he demonstrated a loader for Collada meshes (supported by Maya) and brought in a monster that with a few lines of code started walking around the screen.

Overall, it was a great introduction to the subject, one worth a lot more of your time.

Ilmari’s slides can be found on his blog.

Tips and Problems when Enhancing SharePoint with JavaScript

If you’ve developed for Microsoft’s SharePoint before (I’m talking about 2007 here, but this applies to WSS2 and 2010 as well) , then you’ll know that you can reach the limits of it’s functionality very quickly. This is a big problem if you’re making a zero-code solution, i.e. you have no access to Visual Studio and can’t create web parts. This is more common than you’d think, especially in large organisations that use SharePoint extensively. For this, the only choice is to use SharePoint Designer 2007 (SPD), but it’s not pleasant because, frankly, SPD sucks. I’ve not found a program that crashes as much as SPD, or that performs so poorly when presented with the most basic tasks. If you make a page that is too complex, has too many web parts, large data sources or lots of conditionals, connections and filters, it can take anywhere up to 20 minutes to perform a single action.

SharePoint crash

Very quickly, you have to start looking at alternatives to complex data views. These days, the go-to technology is JavaScript, which is very powerful and can allow developers to access almost every SharePoint function through web services. However, this functionality comes at the cost of accessibility. So, the first piece of advice: if you can avoid using JavaScript, do so because otherwise the site won’t be accessible. See these links for why accessibility is a good thing.

Unfortunately, SharePoint is so limited that often a JavaScript is the only way to add functionality in or to correct formatting. In this case, use of simple SPD functions and <noscript> tags can keep your content accessible, allowing you to progressively enhance the user’s experience on top.

The final hurdle to cross before you can create great JavaScript-based interfaces in SharePoint is IE.

Internet Explorer, especially IE6, has appalling developer tools for JavaScript debugging. There’s no console, inspector, breakpoint facility, no nothing. It’s almost impossible to debug your problems because they all manifest themselves as runtime errors on some arbitrary line on the page.

The best way that you can debug JavaScript in IE, is with Google Chrome. It doesn’t sound right, but I promise it’s the easiest way to make your code work. Both Chrome’s Web Inspector and Firefox’s Firebug work very well with SharePoint, though my personal preference is for Chrome as it works better with Windows’ NTLM authentication system (it doesn’t ask you for your login details, just takes them from Windows). They allow you to check and validate your code so that it works well and runs as expected. You should be able to achieve this in half the time that you would if you were just developing for IE, using alerts to work out what’s going wrong.

There’s another benefit for working this way around: your code will work on standards-compliant browsers, and any that come along in the future. This is always a good thing as you don’t know when the organisation will roll out IE8/9 to its users, nor can you always guarantee that a user will be using a IE. It’s important that sites are ready for these changes and best-practice development is maintained.

In summary, if you have to use JavaScript, ensure the page content will work without it. If you are doing any major development work, do it in Chrome and reap the benefits of its debugger, then make it work in IE.