IE Blog Video “Fallback”

I’m very appreciative of the IE team’s attempts to make IE 9 more standards-compliant and implement some of the new stuff. But I don’t think they’ve quite got the hang of this “fallback” thing yet. This is their latest blog post on my Linux machine:

Screenshot of MS blog, with Install Silverlight button, then 'Note this video uses the HTML5 video tag (with the H.264 codec) if your browser supports it, and falls back to other methods otherwise. It’s a good example of same markup in action.'

No, suggesting I install Silverlight is not within the spirit of HTML 5, standards and correct fallback. Certainly not without first providing Ogg or WebM versions of the video.

If I click the “Install Microsoft Silverlight” button, it gives me a big scary message about Silverlight not supporting my browser, and sends me off to install Moonlight. To see what would happen, I did install the latest stable Moonlight. That worked, but then I got a warning about this being a Silverlight 3 app which Moonlight may well not support properly yet. After that, I got a prompt to download the Microsoft Media Pack of codecs (presumably H.264, and proprietary software). So I stopped there. Hardly the seamless web experience that <audio> and <video> are supposed to provide… <sigh>

Do they really think that it will be some sort of earth-shattering precedent-setting or some sueable event if they were to provide Ogg or WebM versions? Come on, guys, flex a little bit.

IE 6 User Wanted

Believe it or not, I am looking for someone who uses (or perhaps, has access to for testing purposes :-) a copy of Windows XP running the standard IE 6 it shipped with – before XP SP2, which made a number of changes. If you are that person, and would be willing to help me with a little research (5 minutes) then please get in touch. Thanks!

IE 8 and the Public Suffix List

It has become important in recent years for web browsers to know something about the de facto ‘shape’ of the DNS – e.g. to tell the difference between co.com (someone’s domain) and co.uk (a registry-specified suffix under which people register domains). This is used to stop cookie leakage between domains, to highlight the important parts of a domain name, and for other things too.

To do this, Mozilla started the Public Suffix List project, a cross-browser initiative which tries to maintain such a map. This list is used by Opera and Chrome/Chromium. Thanks to some heavy lifting at the start of the project by some very hard-working volunteers, the list is pretty comprehensive (although we tweak it regularly).

IE 8 also needs to know this type of information, to power things like its domain highlighting in the URL bar. The excellent Eric Lawrence’s post on the IE blog details what they use it for and how their code works. You can see there the algorithm that IE used in all versions prior to IE 8.

In IE 8, they made changes to improve the accuracy of the algorithm. Sadly, although the licensing on the data is designed to enable them to, they have chosen not to switch to using the Public Suffix List. Instead, they have kept their old heuristic but added a set of exceptions – ietldlist.xml, which is bundled with IE 8. (If you have IE 8, you can see it by visiting the URL res://urlmon.dll/ietldlist.xml).

This is sad a) because it makes the browsers inconsistent with one another and b) because IMO their algorithm and list combination does not produce results as good as the Public Suffix List. Here are some issues:

  • The IE list contains typos (I’m fairly sure about most of these):
    • aeroport.ci (aéroport.ci)
    • ciesqyn.pl (cieszyn.pl)
    • golgow.pl (glogow.pl)
    • udmautia.ru (udmurtia.ru)
    • prindipe.st (principe.st)
    • edunte.tn (edunet.tn)
    • cherrnigov.ua (chernigov.ua)
  • The .aero, .pro and .museum gTLDs have a large number of reserved subdomains; these aren’t recognised.
  • There is likewise no attempt to deal with the subdivided complexities of Italy (.it), Japan (.jp) and Norway (.no).

That’s not to say we don’t have things to look into either; I’ve filed a bug to follow up the places where IE has an entry that we don’t.

I’ve written a Perl script implementing both algorithms (PSL courtesy of the regdom-libs project) so people can see the differences for a particular domain. Note that I can’t redistribute ietldlist.xml, so you’ll need to obtain your own copy of that before the script will run.

I hope Microsoft will consider using the PSL for the next release of IE, so we gain cross-browser consistency and can all work together to maintain a single map of the DNS. We are happy to work with them to make that possible.

OpenAjax Alliance Runtime Initiative – Voting Results

The OpenAjax Alliance is “an organization of leading vendors, open source projects, and companies using Ajax that are dedicated to the successful adoption of open and interoperable Ajax-based Web technologies.” MoCo is a member, along with a lot of other companies

Their “Runtime Advocacy” taskforce has spent the last six months canvassing opinion on features they think should be added to browsers, and getting votes on which are the most important. The Summary Report was published today. Here are the top ten feature requests, with a quick analysis of where the Mozilla project is on each:

  1. 2D Drawing/Vector Graphics. This is basically a cry for IE to support SVG. They also ask for SVG 1.1 Full support (I’m not sure what our current state is; perhaps roc can comment?) and text support in <canvas>, for which we have an experimental API in Firefox 3.
  2. Better Security for Cross-site Scripts. We’re proposed Site Security Policies (which may undergo a name change) for feedback; bsterne is currently ingesting it all in order to update the proposal. I’ve also proposed Script Keys.
  3. Better APIs about positioning and styling. This seems to be another “please fix IE” request. The only API mentioned, getBoundingClientRect, is in Firefox 3.
  4. HTML DOM Operation Performance In General. It doesn’t say what version of Firefox they tested, but even if it was 3.0 alphas, the performance numbers for this request were done in January, before the Firefox 3 performance push around beta 4. We still smoked IE in every test they did, splitting first place with Safari. If the author of the page (“Cwei”) could redo the tests against 3.0, that would be useful.
  5. Better Support for Rich Text Editing. As the Summary document notes, “various people in the Ajax community want to move desktop-like document editing into the browser. However, the contributors to this feature request did not outline a detailed strategy for how to accomplish this in future browser.” The page has some useful feedback from Frederico Caldeira Knabben (of FCKeditor) on what he found difficult; we should take note of that. Otherwise, define your requirements more specifically :-)
  6. The Two HTTP Connection Limit Issue. Both IE 8 and Firefox 3 have raised the limit here from 2 to 6, which helps. Having the server specify how many connections it would like is an interesting idea; perhaps our network team could comment.
  7. Better UI Layout Support. They want something like XUL hbox and vbox in HTML. David Baron recently reintroduced the CSS flexbox spec on the W3C CSS mailing list.
  8. Native JSON Parsing. Done for Firefox 3 (docs).
  9. Persistent Connections Issue. Increasing the HTTP connection limit helps to avoid lockup in the short term. We also have offline events and state detection. Exactly what to do in the longer term is still being worked out – it may involve the WHATWG WebSockets spec.
  10. Video and Audio. Patch checked in – should be in Firefox 3.1 :-)

Language Coverage – Version 1.1

I have released an updated version of my language coverage data – its home is now a web page rather than a blog post.

Among the new features are:

  • Several bug fixes and data improvements; the Firefox percentages have gone up but, sadly, so have the IE ones.
  • Information on Opera.
  • A new line showing how IE fares if you don’t include LIPs.
  • A new line for “registered l10n teams”
  • A tab which shows that if a browser team were using this data to guide where to put l10n team effort, what languages they should be focussing on. This data is provided for Firefox, IE and Opera.

Thank you to everyone who gave me useful feedback. Please let me know of any further improvements I could make, within the general parameters of the method.

No JS/No CSS Browser Detection

[Browser detection removed as it broke the validation of my RSS feed. Check the author's site if you want to try it out.]

This browser detection uses pure HTML 2.0, without any JS or CSS. Here’s how it’s done. It even distinguishes Firefox 1.5 from Firefox 2. Can any parser hackers extend it to further distinguish Firefox 3?

Anchor Markers

We’ve had a bug open for quite a long time about implementing the W3C Common User Agent Problems recommendation from 2001 to highlight the target of intra-page named anchors.

Someone recently posted their ideas in that bug; I don’t think much of their UI, but I think it would be great if Firefox had a solution for this. (It would be nice also to style internal links slightly differently, perhaps with a dotted underline, so people don’t do “Open In New Tab”, and end up with five copies of the same large page.)

Is there an extension which does this? If not, does anyone feel like knocking one up?

One implementation method would be to highlight and then fade out the elements contained in the <a name=””> tag. However, this might not work everywhere because of the following pattern:

<a name=”heading”></a>
<h3>Heading</h3>

People do this a) to make sure the heading is visible on the page, and b) because people used to write bad CSS which caused hover effects to apply to anything within an <a> tag, whether it had an href or not. But maybe this problem isn’t a showstopper.

Only Browser Geeks Need Apply…

The Alliance and Leicester Building Society’s “3D Secure” secure internet shopping service has the following requirements:

What are the system requirements for 3D Secure?

3D Secure requires the use of Windows Microsoft® Internet Explorer 5.5 and 6.0, Windows Netscape® 7.1 and 7.2, Windows AOL ® 9, Windows Firefox® 1.0 and Macintosh Safari®.

Wow. It’s a pretty small and exclusive clientele who can run all of those at once. I guess you’d need a Mac (for Safari) running at least two copies of Parallels (one for each version of IE)…

Styling Internal Anchors

Ever seen an interesting link on a large page, middle-clicked it to open it in a new tab and then realised that it was an internal anchor, and you are just loading another copy of the same large page?

To have every internal anchor marked with a small “#” symbol after it, add the following to your userContent.css:

a[href^="#"] {
padding-right: 6px;
background: url("data:image/png,%89PNG%0D%0A%1A%0A%00%00%00%0DIHDR%00%00%00%06\
%00%00%00%08%08%06%00%00%00%DA%C6%8E8%00%00%00%09pHYs%00%00\
%0B%13%00%00%0B%13%01%00%9A%9C%18%00%00%00%07tIME%07%D7%03\
%1D%10%0D*T%0FgN%00%00%00!IDAT%08%D7c%F8%0F%05%0C%0C%0C%A84\
%8C%83%81A%12%BF%FF%FE%23Q%07N%3B%B0%01%D2%25%00N4%8Fj%C7U\
%97%89%00%00%00%00IEND%AEB%60%82") center right no-repeat;
}

IE Plays Catchup

Is it just me, or could the “IE Add-ons Contest” have been renamed the “IE Add-the-features-Firefox-has-that-we-don’t Contest”? Of the four top addons, three implement Firefox features for IE. And the last is an extension we had first.

Even the description page for the grand prize winner admits as much:

Inline Search is an add-on for Internet Explorer that mimics Firefox’s search behavior…

Imitation is the sincerest form of flattery :-)

IE 7 Cripples IDN

Microsoft’s policy about how IE 7 will handle IDNs has changed slightly in beta 3, but unfortunately as it stands will still have a serious detrimental effect on IDN take-up. Here’s why.

IE 7 displays all IDN domain names as punycode (e.g. http://www.xn--caf-hya.com), unless the copy of IE has the “language” of that domain name configured as one of its Accept Languages.[0] If it displays the ugly and indecipherable punycode, it also presents a yellow security bar, saying “We can’t display this domain name; click for options”, where presumably the user might have the option of adding to the whitelist whatever language IE thinks the domain name is in.

This will cripple IDNs in almost any international market, simply because domain owners are not going to want an unknown percentage of users visiting their domain to have that horrible user experience. You are a German company – will you choose an IDN domain name containing a ß as your primary domain name if you know you might one day want to expand into the European market and sell goods outside Germany? And that almost all your European customers will have to go through this?

IDNs might be perhaps used when the site owner can guarantee that all their visitors will have a particular language configured – but how common is that? Even aside from the situation above, this is the “World Wide” Web, and people use the browser of a friend, or an Internet café. The browser doesn’t really know what languages its user speaks, and it’s unlikely that the user will take time to tell it. When was the last time you configured the Acceptable Languages in a browser you were using? And if you did, when you stopped using that browser, did you remove them and reset the setting?

The sad thing is that this measure by itself doesn’t improve security. A particular domain name is either dangerous or it isn’t – that is, it’s either a homograph of another domain registered to a different person, or it isn’t. If the domain name is a homograph then all those people who, by default or by configuration, have that language configured are at risk. And if it’s not a homograph, why not display it to everyone from the start?

The other measure IE 7 is taking, which is to forbid most script mixing, will improve security. But here they have gone the other way – this measure is too draconian. Script-mixing by itself is not dangerous, as long as your registry is on the ball.

Firefox has a system based on a whitelist of TLDs whose registries have sensible anti-homograph policies. Only they can tell if a domain name is dangerous or not; browsers just don’t have enough information. Our policy allows many more safe domain names.

Unfortunately, as domain owners will only pick names which work everywhere, IE 7 is further restricting the set of names that can be used in practice. Having worked for a long time on making IDN safe and usable in browsers, it’s very sad to see its uptake stunted in this way. :-( I hope they change their minds and remove that first check, but I fear it’s too late.

[0] There will also be a host of problems caused by the fact that domain names use characters from particular scripts, or perhaps multiple scripts, and IE has a list of languages. Languages and scripts have a really complex relationship – in which language is the letter é? What Accept Language do I have to have configured to correctly view www.café.com? I haven’t covered this further because it’s secondary to the even bigger problem mentioned above.

IE 7′s Effect On Firefox Market Share

rebron’s IE 7 Competitive Analysis is worth a read. I’m glad that printing has been picked out as an area where Firefox needs future work.

It’s nice to think, as rebron suggests, that IE 7 won’t take away share from Firefox. Perhaps it won’t by converting users back directly. But it could have indirect effects; where today, if people get a new computer with IE 6, they think “Ick! Install Firefox now!”, if it comes with IE 7, they may just live with it. Also, people often install Firefox for their relatives or friends – will they be as eager to do so when the feature/usability gap is smaller?

I guess the answer to that is, let’s keep that gap wide :-)