Technology Review wrote of their experience “The future of media on mobile devices isn’t with applications but with the Web.” in Why Publishers Don’t Like Apps.”Like almost all publishers, I was badly disappointed. What went wrong? Everything … We sold 353 subscriptions through the iPad. We wasted $124,000 on outsourced software development. We fought amongst ourselves, and people left the company. There was untold expense of spirit. I hated every moment of our experiment with apps, because it tried to impose something closed, old, and printlike on something open, new, and digital.”
Lea Verou on Text masking — The standards way. I have a lot of sympathy with the view expressed by Matt Wilcox – SVG is much harder to write than a line of CSS (and I feel a bit ewww at mixing presentational SVG with my HTML). But at least this works everywhere, which is Lea’s point.
When a browser vendor implements a new css feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade.
Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser.
If a large amount of content accumulates using the a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.
The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set. That would drastically reduce the problems on the Web.
Here are some of the most useful commentaries (both for and against). Mostly I haven’t commented, except for Andy Clark’s piece which contained factual inaccuracies which could mislead readers.
Opera confirms WebKit prefix usage – the .net magazine article that broke the story, based on a leaked email and catching me unawares as I was heading out for the airport
Why O, why? by David Kaneda. This is more balanced than I expected, as the author works for a only-works-in-webkit-woo! mobile framework/ library thing, although one of his 3 pieces of practical advice is to detect WebKit browsers and block them from Opera’s demos, thereby opening the Web by closing the Web, and helping users by hurting users
and the one that neatly sums up my personal ambivalence, and then acceptance of our move: Opera, -webkit-, and the purpose of browsers: “The secret to reaching “Acceptance” is to simply ask yourself, “What are web browsers for? What is their absolute primary purpose? The answer: A web browser’s primary function is to display web content.”
My favourite commentary has been Daniel Davis‘ interview with Dr Stanley Dards, wise old man of the web:
Mobile
How we use our mobile devices “more people have mobile phone subscriptions than have electricity or safe drinking water”
Reponsive News – a blog by the team making the BBC News website responsive
Today, intellectual property rights for H.264 are broadly available through a well-defined program managed by MPEG LA. The rights to other codecs are often less clear, as has been described in the press. Of course, developers can rely on the H.264 codec and hardware acceleration support of the underlying operating system, like Windows 7, without paying any additional royalty.
There is no truth in alleged “leaked emails” that our business plan reads 1) Publish photos of loads of multi-ethnic hipsters in glossy report 2) alias -webkit- prefixes 3) profit!
placezombies.com – a quick and simple service for getting pictures of zombies as placeholders in your designs.
Heartwarming stuff
This is why I love working with Norwegians. The ultra-nationalist terrorist mass-killer Anders Behring Breivik hates the children’s song “Children of the Rainbow” that describes a “World where – every sister and every brother – shall live together – like small children of the rainbow”. So 40,000 Norwegians got together to sing it, just to annoy him.
It’s a great example. The UK and USA are intent on showing how much we value democracy and liberty by clamping down on what people can say, see, think, and clap them in prison without trial. Norwegians, conversely, reaffirm their values of tolerance and open-ness when they’re under attack.
Lyrics of Lillebjørn Nilsen’s Barn av regnbuen (Children of the Rainbow), lifted from theworld.org:
En himmel full av stjerner (A heaven full of stars)
Blått hav så langt du ser (Blue seas as far as you can see)
En jord der blomster gror (A world where flowers grow)
Kan du ønske mer ? (Can you ask for more?)
Sammen skal vi leve (We shall live together)
hver søster og hver bror (Every sister and every brother)
Små barn av regnbuen (Small children of the rainbow)
og en frodig jord. (And a blossoming world.)
Noen tror det ikke nytter (Some don’t think it matters)
Andre kaster tiden bort med prat (Others waste time with small talk)
Noen tror at vi kan leve av (Some thing we can live on…
plast og syntetisk mat. (…plastic and synthetic food.)
Og noen stjeler fra de unge (And some steal from the young)
som blir sendt ut for å sloss (who are sent off for a fight.)
Noen stjeler fra de mange (Some steal from the masses)
som kommer etter oss (who come after us.)
Refrain:
Si det til alle barna! (Tell all the children)
Og si det til hver far og mor: (And tell every father and mother)
Ennå har vi en sjanse (That we still have a chance)
til å dele et håp på jord. (to share hope for the world.)
Adaptive Images by Matthew Wilcox: “This is a run-through of a talk I originally gave at Standards Next a few weeks ago. It’s not as smooth as that talk as I’m a few weeks out of practice and pretty tired right now; but hopefully it’s useful to you (it’s also 10min longer than the real talk was, sorry!).”
Step away from the localStorage. Flame-haired FOSS pinup guy, Stuart Langridge, asks “Is being easy to use suddenly a bad thing?”
Stop solving problems you don’t yet have. Rachel Andrew writes, “Make sure every bit of code added to a project is there for a reason, not just because it is part of some boilerplate”
Please add -o- prefixes to your CSS keyframe animations, as we at Opera have released a build containing prefixed support (and also HTML5 Drag and Drop and other goodies) so it’ll be in the wild soon.
Note too that CSS Gradients is soon going to be standardised and so will drop prefixes. This doesn’t mean you should take out your prefixed rules, but rather add non-prefixed rules eg linear-gradient, radial-gradient, repeating-linear-gradient, repeating-radial-gradient.
If you’re the owner of one of those very useful gradient generators that I use all the time, could you please add non-prefixed rules to the output, and retire any creaky old pre-standardised webkit-only output?
Polyfill for getUserMedia by Addy Osmani, uses Flash as a fallback. Not production ready – more IE testing required, and anyway, the spec is shifting again (events rather than callbacks anyone?)
sendthemyourmoney.com: “The MPAA & RIAA claim that the internet is stealing billions of dollars worth of their property by sharing copies of files. They’re willing to destroy the internet with things like SOPA & PIPA in an attempt to collect that money…Let’s just pay them the money! They’ve made it very clear that they consider digital copies to be just as valuable as the original…Take a picture or scan an image of your money. Send digital copies to the MPAA & RIAA in whatever quantity you feel you can afford.
localstorage
There has been much discussion that localstorage is dead and we should all stop using it because IndexedDB is much better. It’s also 676% harder to learn. I initially wrote “Not sure that localstorage is broken. But “localstorage-for-big-data-eg-images-because-vendors-can’t-agree-on-a-DB-API” is certainly so.”
So localStorage is slower than using an in-memory object. Cars are slower than airplanes. What does that tell us? Not a whole lot. …The reason localStorage is popular is partly due to its simplicity… The proposed alternative, IndexedDB, is perhaps one of the worst API designs I’ve ever seen.
People have asked me to explain the vendor prefix problem. This is me (Bruce) explaining what I believe to be true (a couple of details are fuzzy to me, so forgive any errors – I’m trying to explain the concept). This is NOT a statement of Opera’s position or intents, so don’t be a dick and blame them for my opinions or mistakes.
Right.
On Monday at the CSS Working Group, Microsoft, Mozilla and Opera announced that each are considering supporting some -webkit prefixed CSS properties. (Search the minutes for “Vendor Prefixes”. Florian is from Opera, Tantek represents Mozilla, Sylvaing is Microsoft’s glamorous rep, and Tab is from Google. Glazou is Daniel Glazman and Plinss is Peter Linss, the two co-chairs of the Working Group.)
Lots of developers, despite evidence to the contrary, have assumed that mobile Web = WebKit browsers, because that’s the rendering engine in Android and iThings.
Suppose a developer made site a while ago and used the experimental, pre-standardised code -webkit-border-radius and didn’t use the cross-browser future-proof method.
The real CSS property border-radius has been long been standardised and supported without prefixes in all the major browsers. But the -webkit- prefixed version still lingers on in Safari and Chrome, so that legacy code looks fine in the webkit browsers, but broken in Opera, Firefox and Internet Explorer.
The webkit team have said that they won’t remove such legacy properties for compatibility reasons, and I haven’t heard howls of indignation about this. So the recent proposal is that non-webkit browsers will support -webkit-border-radius as if it were border-radius and thus won’t look “broken”.
I imagine that sites that only use -webkit-transition and -webkit-text-size-adjust etc will be similarly supported.
The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set.
Exactly which prefixes would be supported in this way and whether they would be the same in Opera, Microsoft and Firefox, I don’t know.
Personally – PERSONALLY – I’m pretty depressed about all this. I’ve spent 10 years – pretty much since IE6 came out – evangelising cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around like a vindaloo fart in a windowless loo. And now we’re doing the same again.
Daniel has put out a call to action for developers to fix their sites and mend their ways: CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*. Chris Heilmann of Mozilla has launched a community action called Pre-fix the web!. Read them. Join in. I truly hope they work (although fear it’s too late).
Comment if you like, but I won’t be able to moderate them for a few days, so better to write your own blog posts!
(added 18:45)
I should add that we will still need responsible developers using vendor prefixes right – this is not the end of vendor prefixes. From those who teach, from those who developers look up to, from those selling frameworksWe still need better, responsible evangelism and demos.
The proposal is to support a subset of -webkit- prefixes, especially the archaic stuff like -webkit-gradient, so that those sites don’t look dreadful in non-webkit browsers. The plan is not to support everything that the webkit devs pull out of their hats, every time they get the urge to extend CSS.
So, we still need to use cross-browser future-proof vendor prefixes if we decide to let experimental, pre-standardised code out on production sites.
(Article updated to correct some typos noticed by commenters, and clarify some aspects.)
Avid HTML5 watchers will know that the <time> element was dropped from HTML, then re-instated, with more New! Improved! semantics.
As before, you can put anything you like between the opening and closing tags – that’s the human-readable bit. The machine-readable bit is contained within a datetime attribute. Dates are expressed YYYY-MM-DD.
Previously, you could only mark up precise dates. So, 13 November 1905 could be expressed in HTML <time datetime="1905-11-13"> but November 1905 couldn’t be. This is a problem for historians where sometimes the precise date isn’t known.
Now, “fuzzy dates” are possible:
<time datetime="1905"> means the year 1905
<time datetime="1905-11"> means November 1905
<time datetime="11-13"> means 13 November (any year)
<time datetime="1905-W21"> means week 21 of 1905
As before, times are expressed using the 24 hour clock. Now, you can separate the date and time with a space rather than a “T” (but you don’t have to). So both of these are valid:
<time datetime="1905-11-13T09:00">
<time datetime="1905-11-13 09:00">
You can localise times, as before. Appending “Z” to the timezone indicates UTC (a way of saying “GMT” without it being comprehensible to normal people). Otherwise, use an offset:
<time datetime="09:00Z"> is 9am, UTC.
<time datetime="09:00-05:00"> is 9am in the timezone 5 hours behind UTC.
<time datetime="09:00+05:45"> is 9am in Nepal, which is UTC + 5 hours and 45 minutes.
Durations
In New! Improved! HTML5 <time>, you can represent durations, with the prefix “P” for “period”.
The datetime attribute “D” for days, “H” for hours, “M” for minutes and “XQ” for seconds. Just kidding – that’s “S”.
You can separate them with spaces (but you don’t have to). So <time datetime="P4D"> is a duration of 4 days, as is <time datetime="P 4 D">.
Using a “T” after the “P” marker allows you to be more precise: <time datetime="PT23H 9M 2.343S"> is a duration of 23 hours, 9 minutes and 2.345 seconds.
Whichever you choose, it’s represented internally as a number of seconds. Because of this, you can’t specify a duration in terms of months, because a month isn’t a precise number of seconds; a month can last from 28 to 31 days. Similarly, a year isn’t a precise number of seconds; it’s 12 months and February sometimes has an extra day.
You still can’t represent dates before the Christian era, as years can’t be negative. Neither can you indicate date ranges. To mark up From “21/02/2012 to 25/02/2012″, use two separate <time> elements.
pubdate
The pubdate attribute (a boolean that indicates that this particular date is the publication date of the parent <article> (or, if there is none, the whole document) is currently missing from the W3C version of the spec, but is still current in the WHATWG version. Its status is unclear to me (but I’m still using it).
It’s been whispered about for some time, but only now can the truth be revealed. The Large Hadron Collider at CERN was built in order to produce enough Higgs Bosons to turn ordinary ninjas into an elite squad of standards-avenging attack ninjas under the sole command of Sir Tim Berners-Lee, previously from CERN (co-incidence? I think not!).
Unnamed sources tell me that, as the Mayans nearly predicted, 2012 will be the year when misusing vendor prefixes will no longer be tolerated and manufacturers bastardising CSS Media Queries to do UA-sniffing will not go unnoticed.
Don’t believe me? Here is an artist’s impression of an actual photo of Tim Berners-Lee summoning his standards-avenging attack ninjas.
Adding Islamic calendar support in HTML5 – a request from IBM to add new types of HTML <input> to cater for the three Islamic calendars. I agree with Lars and Lachlans’ comments that this is a browser enhancement and not an addition to the language.
EcmaScript 6 versioning. Dutch Specmeister Anne van Kesteren writes “this still strikes me as a slippery slope towards the mess Internet Explorer is dealing with (and Word has in the past). Not very webby, ECMAScript”
Backbone.js mini-book by Addy Osmani, who says "any contributions welcome. Plan to keep adding more everyday".
MPEG-DASH is the first International Standard for dynamic adaptive streaming of multimedia content over HTTP. It will be interesting to see what the royalty/ licensing situation will be.
I don’t agree with everything Faruk says in The Threat Against the Web, but wholeheartedly applaud “The web will only thrive as long as the web is not owned by any one entity; not owned, not controlled, and not defined”.
On the subject of the constantly-embattled Open Web, Google offered patches to allow their super-whizzo! invented-in-secret Dart language to be in WebKit. Oliver Hunt of Apple objected: “As the 90s demonstrated such “features” are bad for developers, and bad for the open web. This may not be apparent to people who have not spent years working in the environment but random additions frequently cause significant pain down the road” and adding adding “it fragments the web” and risks “turn[ing] webkit into the engine that everyone hates because of all its unique “features” that break the open web, a la certain browsers in the late 90s”.
