20 Jan 2015
SASS, as it stands, will not permit us to use a placeholder to extend a selector from inside a media query, due to scope conflicts. That’s really annoying. Let Hugo Giraudel show you a way around it.
There is currently a heated debate within the web design & development community. It concerns the relative merits of Adobe Flash and HTML5, and which technology should hold the crown for rich content on the web (by rich content we’re talking about things like video, complex animation, and so on).
The most recent trigger for this opinionated to and fro was Apple’s decision to leave Flash off the iPad. I’ll come back to that, but for now suffice it to say that it divided people into two camps: those who find the absence of Flash to be a pain in the arse, and those who are glad to see the back of it.
The anti-Flash argument goes (and, yes, I’m paraphrasing) that Flash is a proprietory format controlled by Adobe, is less than perfect from an accessibility or SEO standpoint (albeit better than it used to be, on both counts), causes computers to crash, and is generally not a very Web Standards-friendly technology. HTML5, on the other hand, is destined to be fully browser-native, semantic in nature (which is good for assistive technology, search engines and standardistas in general), and can do most of what Flash is generally used for.
“Flash must die” has been the recent cry; “HTML5 is the future!”
And, for my money, therein lies the crux of the matter. HTML5 probably is the future. But it’s not the present, not yet. It’s not finished. And I don’t mean in the sense that CSS 2.1 is not ‘technically’ finished; I mean in the sense that most of HTML5 is still in flux, with even the precise semantic meaning of various elements still being debated.
The main Flash-killing aspects of it are, essentially, the Canvas and Video elements. Of those two, Canvas — which permits developers to generate Flash-like animation in the browser with no plugins — has a lot of potential. However, it still feels pretty ‘fresh out the lab’ and I have a hard time imagining anyone feeling comfortable about using it for a regular client project just yet.
The Video element, by contrast, seems fairly production-ready and, indeed, YouTube has built an HTML5 beta version of their site using it. Currently, however, different browsers support different video codecs; some (eg. Safari) support the proprietary H.264, whilst Firefox is sticking with the open-source Ogg Theora codec. Until that issue gets resolved developers wanting to use HTML5 for video need to encode all their content twice — hardly an ideal situation. And should we really be replacing one proprietory format with another?
One party that seems feel that we should is, of course, Apple, which brings us full circle. Many, however, saw the absence of Flash on the iPad as a deal breaker; after all, the iPad is being marketed, to a large degree, as a device intended to allow browsing the web in convenience and comfort. Whether Apple likes it or not, a huge number of sites use Flash and plenty of people find the lack of Flash support on the iPhone — and, soon, the iPad — extremely inconvenient. Although it’s fair to say that a lack of Flash browsing hasn’t exactly harmed iPhone sales, the iPad is designed to provide a slightly different lifestyle service, and it remains to be seen whether making a big chunk of web content inaccessible will reduce its appeal.
The real issue here is not whether HTML5 and standards-based web apps are the future (they probably are). The issue is that they aren’t quite ready yet, and this fact is being glossed over.
In recent years the government in the UK has been imposing various taxes and penalties on motorists with the intention of encouraging people to use public transport more. Okay, fine, no problem with that per se. The mistake, however, was that the penalties were handed down before the necessary improvements had been made to make public transport a truly viable, user-friendly option and to permit it to take the strain of the additional traffic.
The same is true here. Apple is playing the ‘No Flash for you!’ card before the necessary alternatives are either sufficiently mature or widely distributed. Furthermore, whilst London commuters could, if push came to shove, get on a bus or train rather than drive to work, people who wish to view a particular flash-based web site on their iPhone or iPad have no such option. Presumably Apple feels that its stance will encourage a sea change in the way people build rich content web sites; however, clearly this is not going to happen overnight. In the meantime users of iPhone and iPads are the ones locked out of content that they might really want to see, because Apple wants to make a stand.
Of course, whilst Apple’s position is ostensibly about standards, it would not be unreasonable to speculate whether it is perhaps equally about promoting the proprietary and patent/license-encumbered H.264 (which it had a hand in developing) and ridding its own browser of semi-dependancy upon a corporate rival, ie. Adobe.
As far as the debate about HTML5 or Flash is concerned, of course, Apple’s motives are neither here nor there. The point is that whilst HTML5 may oust Flash in the medium-long term, it’s not going to do so in the next few days, and probably not for a little while yet. In the meantime, those designers and developers who are taking a strongly partisan, black-and-white stance in favour of one camp of the other are doing their clients a disservice. They should look at both options objectively and decide, in the context of the project at hand, which is the right tool for the job.
I think that it is still just slightly too early to do otherwise.