[Original]
Browsers that use modern operating systems more directly deliver better experiences. Browsers that compromise (by spreading across too many OSes and OS versions) face challenges.
We can't decide if we want IE to drive Windows adoption or Windows to drive IE adoption.
The best HTML5 is native to the operating system, so Web sites have the fewest translation layers to pass through.
The browser is part of the OS. The browser has always been part of the OS. We have always been at war with Eastasia.
Native HTML5 support in Windows with IE9 makes a huge difference in what sites can do.
We're really, really sorry about IE6. Not sorry enough to disable Windows activation and allow all the software pirates in China to upgrade, but sorry nonetheless.
Web sites and HTML5 run best when they run natively, on a browser optimized for the operating system on your device.
I think we can all agree to hate XUL.
We're about three weeks into development of IE10, and based on the progress we've made, we want to start engaging the development community now.
Imagine how much progress we could have made if we hadn't ignored the web for ten fucking years.
Native HTML5 ... native HTML5 ... run natively ... most native ... only native ... native graphics ... native ... Native HTML5 ... Native HTML5 ... native and robust ... native applications ... Native implementations ... non-native ... native HTML5 ... native ...
I am high as a kite.
When this post was initially published, I forgot to include the onerror event handler for the HTML5 video element. This caused the video to not play in browsers that don't support MP4/H.264 video. That has been corrected.
The irony of using the phrase "same markup" nine times while delivering different markup to other browsers is entirely lost on me.
The only native experience of the Web and HTML5 today is on Windows 7 with IE9.
We would like HTML5 better if it were spelled "ActiveX."
§
[Source Distributed Extensibility Submission from Microsoft - 30 September 2009]
It is a common practice for authors, tool vendors, and library authors to want to extend languages to represent additional information that can't be adequately described by the standard grammar. ... Here are a few examples that apply to HTML:
- A JavaScript library processes custom tags in a browser and turns them into custom controls dynamically on the page.
We would very much like our proprietary Custom Tags to validate.
- A browser wants to allow custom behaviors to be defined in one module and attached automatically to custom elements.
We would very much like our proprietary HTML Components to validate.
- An author includes processing instructions in the document that will be processed by a server before delivering the document to a user agent.
We would very much like SharePoint's proprietary InfoPath processing instructions to validate.
- A HTML document editor adds information about tool settings so that a subsequent editing session can continue with the same settings.
We would very much like Word's "export as HTML" output -- which is so proprietary that it has spawned an entire cottage industry dedicated to "cleaning" it -- to validate.
In many cases, the language customizations are used for small niche applications and don't require the burden of centralized standardization. Instead these extensions are defined in a distributed fashion among groups of interested developers or authors.
We like making up our own shit.
A Distributed Extensibility model for standard HTML is desirable because it means that user agents from different vendors that adhere to the standard can be assured of correctly processing mark-up that contains extensions without destroying the integrity of the document.
Other people keep fucking up our shit.
The proposal as stated closely matches behavior that Internet Explorer has had for a number of releases, reducing compatibility concerns.
Supporting distributed extensibility means providing a standard repeatable mechanism for creating these extensions without the need for centralized agreement.
We're going to keep making up our own shit, whether it validates or not.
(with apologies to John Gruber,
who did it first and did it best)
Postscript: I am not "against" extensibility, or distributed extensibility, or decentralized extensibility, or whatever we're calling namespaces this week. I just think it's funny that some people read this proposal and immediately jumped to The Glorious And Infinitely Extensible Semantic Web With Unicorns And Ponies, when it's really just an attempt to get the HTML Working Group to bless a collection of Microsoft-proprietary technologies that they've jammed into Internet Explorer over the years.
§
The more I read about embedded web fonts, the more I crystalize my thinking. Take, for example, this latest "A List Apart" article where Jeffrey Zeldman interviews David Berlow:
Zeldman: Let me put it another way. I want to use your ITC Franklin in a site I'm designing, but I'm not willing to violate my end user licensing agreement. How do we resolve this impasse, from your perspective?
Berlow: The next step is for those who control the font format(s) to define and document a permissions table to be added with all due haste to the OpenType, CoolType, TrueType, and FreeType formats. ...
Zeldman: How can type designers and web designers work together to persuade the engineers who control the formats to modify the code to include a permissions table?
Berlow: [W]eb designers flat-out refused to part with real type, which has filled the web with type as graphic files, scaring the bejesus out of a lot of engineering people. ... How important dynamically rendered type is to design and use on the web must now be clear. In addition, the only other option -- that the type industry cede its intellectual property to the public without permission -- is not going to happen. With no upgrade penalty to any applications, or change in usage by the public, the permissions table is the only invisible (type-like) solution.
I like how he focuses on the publisher's end of the problem -- "gee, all we have to do is define this permissions table, that sounds easy." What he fails to mention is that every font-consuming application on every platform on every computer on Earth will need to be "upgraded" to "respect" this permissions table. Because otherwise they're not really permissions, are they? They're just useless bits taking valuable chunks out of my metered bandwidth plan. Like the bozo bit without the bozo.
This, then, is my current thinking about embedded web fonts:
FUCK THE FOUNDRIES
Seriously. Fuck them. They still think they're in the business of shuffling little bits of metal around. You want to use a super-cool ultra-awesome totally-not-one-of-the-11-web-safe-fonts? Pick an open source font and get on with your life.
I know what you're going to say. I can hear it in my head already. It sounds like the voice of the comic book guy from The Simpsons. You're going to say, "Typography is by professionals, for professionals. Free fonts are worth less than you pay for them. They don't have good hinting. They don't come in different weights. They don't have anything near complete Unicode coverage. They don't, they don't, they don't..."
And you're right. You're absolutely, completely, totally, 100% right. "Your Fonts" are professionally designed, traditionally licensed, aggressively marketed, and bought by professional designers who know a professional typeface when they see it. "Our Fonts" are nothing more than toys, and I'm the guy showing up at the Philadelphia Orchestra auditions with a tin drum and a kazoo. "Ha ha, look at the freetard with his little toy fonts, that he wants to put on his little toy web page, where they can be seen by 2 billion people ha h... wait, what?"
Let me put it another way. Your Fonts are superior to Our Fonts in every conceivable way, except one:
WE CAN’T FUCKING USE THEM
Soon -- and I mean really fucking soon, like "this year" soon -- there will be enough different browsers in the hands of enough different people that can use any possible font on any possible web page. And then a whole lotta people will start noticing fonts again -- not just Your People, just also Our People. People who couldn't tell a serif from a hole in their head, but they're gonna be looking for new fonts. People who are just savvy enough to be tired of Comic Sans will be looking for a new font to "spruce up" their elementary school newsletter, which, in an effort to Love Our Mother (Earth), they now publish exclusively online.
And maybe, just maybe, they'll stumble across Jeffrey Zeldman's excellent interview with highly talented David Berlow and think, "Wow, this guy has over 300 fonts! That's awesome! Where can I download them?" And boy, won't they be surprised to learn that those 300 fonts can only be used offline. Epic fail.
Dynamic web fonts are coming. Actually they're already here, but most of Our People haven't noticed yet. But they will, and that's going to be a huge boon to somebody. I see you've decided that it won't be you. Well, have fun shuffling your little bits of metal around. The rest of us will be over here, using the only fonts we're allowed to use: Everything But Yours.
§
So, hypothetically speaking, let's say you want to design a system where you had absolute control over which applications your customers were allowed to install on your device. Certainly you would want to ensure that you were the only source for applications. But for extraordinary cases, you might also need to create a blacklist of applications.
Each entry in the blacklist would also need a human-readable title -- presumably the name of the app -- and perhaps even a human-readable description to explain why the app was blacklisted. But each entry would also need a unique identifier, of course, so you don't accidentally get confused between six apps named "TODO." Finally, you would probably want to include the date that the entry was added to the list.
Furthermore, since you anticipate continually adding new applications to this blacklist to protect your and your partners' business model, you would need your proprietary non-browser-based client to periodically poll the list for changes.
All of which raises a very serious question: what data format should you use for the list?
If you answered "JSON" then congratulations, you win the Trendy Tech of the Month Award lose! To collect your prize, please proceed through the door marked "This way to the egress." Some restrictions apply.
Update: OK, OK, it's a "Core Location" blacklist. Big deal. I'll see your tree and raise you a forest:
... an independent engineer discovered code inside the iPhone that suggested iPhones routinely check an Apple Web site that could, in theory trigger the removal of the undesirable software from the devices.
Mr. Jobs confirmed such a capability exists, but argued that Apple needs it in case it inadvertently allows a malicious program -- one that stole users' personal data, for example -- to be distributed to iPhones through the App Store.
As I've said before, "protecting users from malicious programs" is code for "cryptographically enforcing restrictions on applications to protect our and our partners’ business model." The bullshit about "stealing personal data" is just a rhetorical sleight of hand, like the RIAA claiming that piracy hurts "artists and other rights holders" when 99% of artists don't own the rights to their own songs. How many apps has Apple de-listed over privacy concerns? Only one that I know of, and it was quickly reinstated after a quick update. How many apps has Apple de-listed (or prevented being written in the first place) to protect their business? Lots and lots.
§
![[duck with its head underwater]](http://wearehugh.com/public/2008/06/ducks-butt.jpg)
ducks butt © Dave Gough / CC
As far as I can tell, the only thing that leading accessibility experts agree on is that nobody listens to leading accessibility experts, especially not the microformats cabal, which has never cared about accessibility, has never bothered to test it, and has never acknowledged those who have tested it. In fact, the BBC recently removed one microformat from their site because one piece of it may be confusing to some screen reader users with a certain non-default configuration. This proves what leading accessibility experts have been saying all along, that all microformats are inaccessible, and we should all just use RDF.
Meanwhile, the devilish cabal is secretly solving the problem on their public wiki page, their public mailing list, and their public IRC channel. But will it be enough for the BBC? Be sure to tune in next week, when we'll drown a leading accessibility expert to see if she's a witch.
§