Browser news.
| Browser Wars | Chrome | Chromia on Android | IE | Mozilla | Opera | Safari |
2020 is only three weeks old, but there has been a lot of browser news that decreases rendering engine diversity. It’s time for some good news on that front: a new rendering engine, Flow. Below I conduct an interview with Piers Wombwell, Flow’s lead developer.
Today it’s time for an old-fashioned browser detective story about the Miui Browser, the current state of non-Google Chromia on Android, and assumptions about browsers and UA strings. In addition, this article will highlight a few principles of mobile browser research, one of which was vindicated rather nicely.
Update: severe vulnerability discovered in Miui/Mint Browser.
21 March 2019
Yesterday the European Commission fined Google for almost €1.5 billion for unfairly favoring some of its online advertising services over those of its rivals — and it appears the EC isn’t done yet.
One of the ongoing antitrust cases is about Android, and more specifically about Google Services, the package of Google apps such as Play, YouTube, and Chrome that Android-using hardware vendors must either adopt completely, or not at all.
So Microsoft is going to retire EdgeHTML and use Chromium instead for Edge while not really answering the question if the web [is] better off with less engine diversity. This upset people, and Mozilla, especially, is worrying about the future:
During the introduction of the iPhone X a hilarious gif made the Twitter rounds, showing a list scrolling past the new notch.
I asked the question any web developer would ask: “Hey, is this even possible with web technology?” Turns out it is.
(We should probably ask: “Hey, is this a useful effect, even if it’s possible?” But that’s a boring question, the answer being Probably Not.)
So for laughs I wrote a proof of concept (you need to load that into the iPhone X simulator). Turns out that this little exercise is quite useful for wrapping your head around the visual viewport and zooming. Also, the script turned out to be quite simple.
With the iPhone X’s notch came viewport-fit=cover and safe-area-inset, as explained here. It turns out that safe-area-inset is 0 on iOS11 devices that are not the iPhone X. This may sound logical, but I wonder if it is. Also, the value remains static, even when you zoom in.
Thanks to the good offices of Dees and his Indian colleagues at Mozilla I finally received three Indian test phones two weeks ago. This is the remarkable story of how Indian phone makers are weird in some respects — even weirder than the Chinese ones. Nobody but me cares about this sort of stuff, but this is my blog, so I’ll write my piece anyway.
Recently Scientia Mobile sent me their Android WebView stats over the first quarter. I edited them slightly and put them online.
11 February 2016
Last week I found out that as of Chrome 48 window. no longer exposes the dimensions of the visual viewport. Instead, it now exposes the dimensions of the layout viewport, and is thus a copy of document..
I’m not happy with this change. So it’s time for me to don my ceremonial robes as Guardian of the Viewports and ask the Chrome team to revert this change and restore the visual viewport to its rightful place.
There are three reasons why I think Chrome is making a mistake here:
After my recent post about updating Chromium WebViews I was contacted by Scientia Mobile, the company behind the WURFL database, and was offered actual real-life stats!
The situation is less dire than I assumed. About 90% of the users do in fact use the latest Chromium WebView. This number is based on several hundred million hits in December 2015, primarily from North America and Europe.
This week I received my first gift phone in ages, and since the sender wants me to test it I had to go through all my dozen Android phones and update them as well, so that I can run tests against the latest installed Chromia.
During this process I began to have serious doubts about the update process of the Chromium WebView especially, though the same problems also crop up with regular Google Chrome.
TL;DR: Although, as promised, the Chromium WebView can be updated as a stand-alone app from Android 5 on, I doubt if consumers actually do so because Android’s update process is badly broken. Thus a wide variety of WebViews may be in use right now.
Fair warning: if you are unable to contemplate the simultaneous existence of several Chromium versions running on the same device without suffering from existential angst the reading of this article is discouraged until you’ve consulted your psychiatrist.
16 September 2015
Yesterday I stumbled upon one case in which some mobile Chromes change the font size of elements without having been ordered by the CSS. This article gives a quick overview.
My test is incomplete and will likely remain so, since these changes only occur in fairly unusual circumstances, and spending days and days of research time seems wasteful. Nonetheless I want to leave a note for researchers who come after me.
Last week Niels Leenheer of HTML5 Test told me he’d released a simple Android app that mimics a browser but runs in the device’s WebView. This is ideal for testing WebViews, a topic I’ve ignored so far.
I downloaded the app to all my Android 4/5 phones except for the Huawei C8813 (Chinese firmware) where Google Play won’t run, and the LG L5, where the app crashes when you try to load a page, and catalogued which browser the WebView is (or purports to be). Here are the results:
In my Chrome post I bewailed the lack of stats that doesn’t allow me to figure out how important non-Google Chromia are. Today, however, I received 100K Chromium hits from a Dutch mobile ad network. Although these numbers are not representative for the entire world, any data is better than no data, so here it goes.
Google Chrome is not the default browser on Android 4.3+. There are now at least eight Chromium-based Android default browsers, and they are all subtly, though not wildly, different.
The number of Chromium family members has recently risen from nine to eleven with the addition of HTC and LG Chromium, default browsers for modern HTC and LG high-end devices.
Moreover, LG uses at least two different versions (30 and 34) concurrently, while HTC replaced Android WebKit by HTC Chromium over the air. As far as I know none of this has been done before — so far.
In order to prove that they’re different we will study zoom reflow, a feature that HTC and Xiaomi support, but the others, including Google, don’t.
Recently the news broke that Microsoft may be working on another browser instead of IE. After reviewing the available evidence I’ve come to the conclusion that, although Microsoft is making a few adjustments, and a name change for IE might be a good idea, the new browser will essentially be IE12. Still, I think we web developers should support the “new browser” narrative.
This week I finally gathered the courage to run the media query test suite I wrote over a year ago in the latest crop of mobile browsers. The results are moderately interesting, especially when it comes to Chromium-based browsers. I discovered a new one: Xiaomi Chromium. It’s the ninth I identified, and the first one I had to work really hard on in order to get a version number.
25 September 2014
For at least a year now I’ve held to the theory that the huge uptake in Chrome we’re seeing on the mobile web is mostly due to Samsung using its own version (based on Chromium 28) in its high-end smart devices from the Galaxy S4 on.
Yesterday Krijn started tweeting about mobile stats he had, and it turned out he was willing to share. He gave me data on about 100K mobile and tablet hits in Q2 on a project of his he’s worked on for ages five years. I took the data gratefully and created a table.
Conclusion: Of Chrome users, 25% uses Samsung Chrome — this amounts to about 5% of all mobile visits to the site. On the one hand this proves that Samsung Chrome is a Thing — on the other hand I had expected a much higher percentage. So my theory isn’t right, but Samsung Chrome is still important.
I wanted to know which IE versions my readers test on, so I held a survey. The results are below.
By default, if you tap on a touchscreen it takes about 300ms before a click event fires. It’s possible to remove this delay, but it’s complicated. I investigated it.
Today, quite by coincidence, I found out that the Samsung Galaxy S3 and S4, as well as the LG L5, have Chrome pre-installed next to their default browsers. I have no clue what’s going on and would like a clarification from the Chrome team.
Three weeks ago I used modern.ie to equip myself with the latest old IEs (if that makes any sense). I advise you to do the same.
During recent sponsorship talks a Microsoft representative pointed out the existence of this resource, and asked me to spread the word. I studied it, downloaded the IEs and used them in my recent tests, and now I’m convinced. So here I am spreading the word.
A few more Blink-related links. (This article’s title was stolen borrowed from Thomas van Zuijlen.)
So Google created Blink, the new rendering engine for Chrome and Opera. What exactly is going on, and what will the consequences be?
13 February 2013
Permalink | in Opera, Opera Mobile/Mini
OK, so Opera is going to move to WebKit. I didn’t see that coming, despite the recent news about a WebKit-based browser on iOS (can’t port Presto there, so of course it’s WebKit).
What does all this mean? Hard to tell. Here are a few thoughts and guesses.
Over the past six weeks or so I ran a poll about the use of old IE versions among web developers. It’s time to publish the results.
I’m working on a major update of the CSS section, and one thing I need to decide is whether to continue to show compatibility data for older IEs (say up to 7).
In order to find out what my readership wants, I’d like to ask you to fill out this quick Old IE poll. I’ll use the results for my decision.
Old IE useThanks!
Oh my God, oh my God. Apple thinks it has a bright idea, but craps all over your beautiful responsive sites. Even worse, it’s being inconsistent from iPhone to iPad. I don’t know what they were smoking when they thought this up, but I want some.
OK, so what’s going on? This morning a follower pointed out an article that describes how Safari iOS makes a total fucking mess of the meta viewport when the site is hosted on a .mobi domain.
OK, so now we have the rumour that Facebook is going to buy Opera. That would be unexpected. And interesting.
In this entry I’m going to pretend the news is true, even though that’s not certain yet, because it is a good starting point for some serious strategic thinking.
Yesterday Horace Dediu tweeted:
A browser is an infinitely flexible interface, but is it the best interface for everything? Apps allow experiments in new interaction models
The browser is not the most advanced interface there is. It’s too easy to build the wrong features into something as flexible as a browser, and once a badly-designed feature gains traction it’s impossible to get rid of it. (See HTML5 drag and drop.)
I’m currently seeking to make a complete list of WebKit-based desktop browsers, and I’d like to crowdsource it.
Below is the list I have so far; if you know of any other WebKit-based browsers that run on a desktop OS, please leave a comment and a link. I’m especially looking for Windows browsers. I'd like to hear about Linux browsers, but cannot install them.
2 November 2010
OK, I’m totally stumped. On my computer (Win7), disabling iframes in IE9 or Opera 10.53 doesn’t actually disable iframes. (I do not know how to disable iframes in Chrome or Safari.)
Firefox does honour the request, but only if I open a new window. (Wish they’d say so somewhere.) Restarting IE or Opera does not make any difference.
See this page that contains the test and explains what I’m trying to do.
Could you please disable iframes in your IE or Opera (instructions on the test page) and do the test? In theory the input field should read No because ... well ... your browser doesn’t support iframes. In practice it reads Yes because even with iframes disabled the browser executes the script in the iframe.
Does anyone know what’s going on? Is this a serious security bug in two browsers or am I overlooking something? (Currently I’m guessing the latter.)
Thanks.
In recent weeks Firefox 4 beta 1 and Opera 10.60 were released, and I could also put my hands on a working Chrome 4. I added all these browsers to the compatibility tables, which are now all updated, except for the Events one.
29 June 2010
Well, I’ve revised the DOM CSS and the DOM CSS OM tables, too, and IE9 continues its march. It supports the standards!
28 June 2010
In the past few days I’ve been revising the CSS compatibility table with information about the latest crop of browsers. There’s no doubt about it: this is IE9’s show. It just supports nearly everything. No hassle, no buts.
Besides, CSS3 selectors are now fully supported by all browsers but one. And that one browser is not IE. It’s, curiously, Opera.
I recently came across a post about border-radius by the IE team, that said IE9 supports
border-radius (cool!) without vendor prefix (even cooler!)
The post continues:
While a number of web pages already make use of this feature, some [...] do not render properly in IE9 or Opera 10.50 because they lack an unprefixed declaration of the border-radius property.
As the specification nears Recommendation and browser vendors are working on their final implementations and testcases for submission to the W3C, we recommend that new content always include a border-radius declaration without vendor prefix.
I’d like to go one step further.
It’s time to abolish all vendor prefixes. They’ve become solutions for which there is no problem, and they are actively harming web standards.
Vendor prefixes force web developers to make their style sheets much more verbose than is necessary, while also running the risk of accidentally forgetting one set of vendor-prefixed declarations.
Besides, why do we need to use several declarations for obtaining one single effect? Weren’t web standards supposed to prevent that sort of thing?
Guys, let’s stop the vendor prefix nonsense. Enough’s enough.
Update: Although the problem is real, my solution is not the best one possible. See the redux for more discussion.
13 October 2009
Permalink
| in Apple, Chrome, Google, Safari, Samsung
12 comments
(closed)
When I reviewed the reactions to my There is no WebKit on Mobile post, it became pretty clear that few had expected its conclusion that there is no single WebKit on Mobile. Overall, it seemed that most people were pretty surprised, and hurried to revise their ideas of the mobile browser market. That was the point of the article, so I was happy.
The most-often heard criticism was that I was unclear about the browser version numbers. That’s true, and I have updated the table to include them. I also split out the tests into Acid, CSS2, CSS3, HTML5, and JavaScript, and calculated separate scores for each browser. The results are interesting for some browsers. Konqueror sucks at JS but is very good in CSS, while Android is exactly the opposite. Interesting data.
(I’m still tinkering with the interface, by the way, and I didn’t have the time to finish my current revision. So the coloured bars are temporarily gone, but they’ll return in the future.)
7 October 2009
Permalink
| in Apple, Chrome, Google, Mobile, Safari, Samsung
32 comments
(closed)
Last week I spent a lot of time on WebKit in order to produce a comprehensive comparison of all WebKits. My purpose was to prove there is no “WebKit on Mobile,” and to gain some more insight in the complicated relations between the various WebKits.
Therefore I now present the Great WebKit Comparison Table. In it I compare 19 different WebKits on 27 tests.
28 September 2009
Well, Google Chrome Frame has certainly taken the web dev world by storm. It’s almost as if people are fed up with Internet Explorer and welcome an alternative.
Many useful things have already been said about Frame. I’d like to add a few technical notes I haven’t yet encountered anywhere else.
Recently I held a presentation at a local Microsoft conference in the Netherlands. Slides are here. Fanatical followers will recognise most of the topics I discussed from earlier slide shows, but the last one, about the changes to the market share of IE6, 7, and 8, is new.
Basically, IE6 will continue to exist when IE7 has all but disappeared, and, contrary to what you might expect, this situation will create exciting opportunities for Microsoft’s competitors.
Besides, last week the news came that Microsoft is going to voluntarily de-bundle IE from all Windows 7 machines that will be sold in Europe, and I continue to have my doubts about that affair.
So it’s time for a special State of the Browsers IE edition.
3 February 2009
Permalink
| in Browser Wars, Chrome, Content, IE, Safari
35 comments
(closed)
There’s some browser news to discuss, and I thought I’d bundle it all in one entry. Maybe I’ll even do this more often; it seems a good feature for this blog. But I’m not promising anything!
This weekend I started testing some new browsers, and meanwhile I’ve updated the HTML and CSS tables. There were no surprises. I’m continuing with the Events tables, but they’re so large and sometimes so complicated that I’m not sure when I’ll finish.
In this installment we’ll take a look at IE8RC1 and some reactions to it, Safari 3.2, Chrome’s lack of a “Check for updates automatically” feature and Opera’s antitrust complaint.
Last Friday a press release announced that the European Commission has sent a “Statement of Objections” to Microsoft. This is a formal notice that the EC is investigating objections made to Microsoft’s trade practices; in this case the tying of Internet Explorer to the Windows operating system.
The latest EC vs. Microsoft fight has entered its second round. Since browsers are involved, this conflict is important to web developers. If Opera gets its way, new Windows computers in the EU will have either zero or five browsers installed on them.
In case you’re wondering why this blog is updated so rarely; I’m taking a slight break from web development, and I’m working on a major upgrade of my Dutch politics section. It’s not ready yet; I’ll let you know when it is.
However, while working on it I found a few browser peculiarities, and I thought I'd let you know. There’s one IE bug; one case in which IE does the right thing and the other browsers don’t; the third is a Chrome peculiarity (not a bug); the fourth is an undocumented property in Opera.
During my Ajax Experience session I talked about browser detects and how almost nobody knows how to do them right. I’d like to repeat the main outline of my solution here.
I’d also like to ask you to participate in a little research project by spending two minutes of your time on checking whether your stat package or farm reports any Google Chrome hit. It should, by now. If it doesn’t, it’s likely broken or badly maintained.
This little test will allow us to distinguish between good and bad stat packages/farms.
Please participate. It takes about two minutes. Thanks.
Just downloaded Google Chrome and did some very brief tests. Rendering engine seems equal to Safari 3.1, as expected. There will be a few minor differences somewhere; I’ll let you know when I find them.
Feels light, quick.
It features a quite slick-looking Firebug clone that includes a YSlow clone. Right-click and select "Inspect element" to access it. Haven’t tried to actually debug with it yet, but it looks promising.
The important points in the Google Chrome story, however, are not about DOM and CSS compatibility, and not even about debugging tools.
John Resig and Alex Russell discuss some ways in which this release could be the start of a new browser war. (Contrary to what Opera states, it hasn’t quite started yet.) I also have a few points to make, but that’ll have to wait for another time.
In order to find out which effect on the market it has, Chrome’s share will have to be measured. Updated browser detect. Detect it by searching for Chrome in navigator.userAgent.
Note to Google Chrome team: please make navigator.vendor read "Google" instead of "Apple".
Which version number does it have? I can’t put a browser without a version number in my Tables. navigator.userAgent
says 0.2
Come to think of it, I haven’t yet found any way of disguising it as another browser to get around browser detects written by clueless web developers.
Come to think of it, I haven’t yet found a Preferences menu.
0.2 sounds about right.
But it’s definitely a promising start.
Right. Now that IE8b2 has been out for five entire days, it’s time for a round-up. Exactly what has the progress been? Any regressions? And what about the <meta> switch. How exactly does it work?
All in all I’m quite happy with the progress being made. In addition to a few stunning JavaScript additions, there’s gradual progress across the spectrum. CSS and DOM support has become better; not stunningly so, but still quite important.
IE8 beta 2 has been released. Go get it; let's see what works and what doesn't. See also the release notes.
I'm currently downloading it; more news when I have it.
Update: CSS compatibility table updated. I'm especially enthousiastic about the support for box-sizing without the -ms- prefix.
Update 2: Core, HTML, and CSS OM View tables also updated. Analysis will follow later, but I'm quite happy with the progress.
Sometimes browser vendors are appallingly insensitive. Despite my clear announcement that I’d be on holiday for two weeks, all four vendors saw fit to release major updates or important news items exactly in that period. Now I have to scramble to keep up with all the news, and the worst part is that I don’t really have any time until after An Event Apart Boston.
So this entry is mainly meant as a quick summary for myself. Without it I’d probably remember less than half of these important developments when I’ll restart my testing in a month or so.
2 April 2008
Permalink
| in IE, Opera, Safari, Theory
24 comments
(closed)
Currently I'm working on a big revision of the Events Compatibility Tables. And no the new table is not yet online because I'm not ready yet.
Testing event support is really awesomely complicated. I've been working steadily for two weeks now, and I still find new bugs and oddities daily, and twice on Sundays.
In any case, I discovered something remarkable when I studied the mousemove event. It sheds light on the way browser vendors keep track of each other's implementations nowadays, and on things that can go wrong.
Update: The bug described in this entry is an OS problem, and not a browser bug.
As everybody and his dog know by now, Microsoft has made IE8 beta 1 available. First impression: decent progress, but a lot of work remains to be done. And, in all fairness, this is merely a first beta, and its main purpose is to show where Microsoft is headed, and not to get every little thing right on the first try.
There's a lot to be said about its CSS and JavaScript support, and I'm going to say it all. My readers, as well as the IE team, expect that.
3 March 2008
Just now the IE team announced that it's reversing its policy on the default behaviour of IE8, which shows that it has been paying close attention to the discussion of its versioning proposal. I admit that I hadn't expected this reversal, but I welcome it.
28 January 2008
Even clinically dead web developers will by now have seen the announcement of IE8's new versioning switch, and many bloggers I read have already reacted—most of them negatively. See the IE page of my linkblog for an overview.
All in all I am in the Yes camp, and in this entry I'd like to offer a few arguments in favour of the current default of the switch. In my opinion, defaulting to IE7 in the absence of a switch is the correct behaviour.
I won't be offering practical arguments, since these are not received too well right now. Instead, I'm hoping to appeal to our collective sense of honour.
23 January 2008
Now that the versioning switch debate is in full swing (see the IE page of my linkblog for a partial overview), I'd like to move attention from lofty goals and aspirations that may or may not be trampled by the new switch to everyday practicalities.
So here's a quiz for you. Please assume that at some point in the future the following will be the case:
22 January 2008
The announcement of IE8's new versioning switch is generating heated debate—and nobody could have expected otherwise. Whether you feel this is a great or a terrible idea, it will change the way we web developers work. I encourage everyone to form his or her own opinion on this matter.
However, there's one point that has to be made right away. Eric Meyer already touched on it in his opinion piece, but repeating it won't hurt.
One argument used by detractors of the new switch is that it's nothing more than a browser detect. This comparison is factually false and it shouldn't be allowed to cloud a debate that promises to be complicated enough even without false arguments.
3 January 2008
Permalink
| in Browser Wars
21 comments
(closed)
Opera's antitrust complaint against Microsoft has become the talk of the town. Right now everybody focuses on Opera's anti-Microsoft stance and the effect Opera's action may or may not have on W3C Working Groups. Jeremy provides a useful summary.
What's lacking in the current discussion is an appreciation of the potentially disastrous consequences of "asking the European Commission to require Microsoft to follow fundamental and open Web standards accepted by the Web-authoring communities."
I found only one article that clearly points out this danger, but the author seems to think that the European Commission is a court of law. It isn't. It's a political body peopled by politicians.
The advanced state of institutional chaos at European Union level has required the Commission to take on some judicial powers in order to get anything decided, but in the end its functions are political, and its members are guided by political considerations—most notably the careful hoarding of powers they have been granted.
So Opera is asking a political body to take control of web standards in the name of "Web-authoring communities" I'm part of—but without considering the consequences of its actions and without consulting said communities.
Opera's request is putting us all in appalling danger. Therefore I'd like to ask Opera to drop it. Now.
Well, I've been using Safari Windows for a few weeks now, and I though it's time for a report. This report is only about the Windows version, because I can't install the Mac one. Why not? Because I don't have the right OS X version.
Yesterday I downloaded Safari 3.0 Windows as soon as I found out it was available. It looks fine. Below you find a list of CSS changes, as well as a curious bug that appears on a minority of Windows systems.
The MSIE team has asked for input on features that the next version of Internet Explorer should support. Please take a moment to help them out.
Recently Erik Arvidsson lamented the lack of JavaScript progress in IE 7. Strictly speaking he's right, of course: there are few JavaScript bug fixes in the new release, because Microsoft has made CSS fixes its priority. Microsoft has done what it's promised, and it never promised us JavaScript fixes for this release.
That said, everybody knows there are a few things lacking in IE's JavaScript support. The point of this entry is to start creating a list with specific wishes for JavaScript improvements in IE. When it's done and when Microsoft starts thinking about the next version we can present it.
27 April 2006
Permalink
| in Coding techniques, IE
13 comments
(closed)
In a project I'm currently working on I encountered an Explorer bug that depends on the window you open a page with.
I post it here because I know that MSIE team members occasionally read my blog, and I have the faint hope that can they solve this bug, especially since it's messing up one of my projects (and, after all, what in the world is more important than my projects going smoothly <grin>, particularly when I have another important and exciting project that should be finished quickly but is held up by this bug).
Yesterday Microsoft released a new beta version of IE 7, confusingly called "IE 7 beta 2 preview - released on March 20th". I wish they'd named it beta 3.
Download it here. I haven't done any tests yet and I don't know when I'll be able to.
Despite being terrifyingly busy I found the time for some basic IE 7 beta checks this weekend. In general all CSS issues that Microsoft promised to solve have been solved, with the partial exception of the [attr] selector. The beta refuses to honour p[align=right] {font-style: italic;}. I updated my CSS compatibility table for the second time in two weeks.
I also went through all Explorer Windows bug reports and determined whether they were solved in the beta or not. I found that 58 old bugs have not been solved. See the Explorer 5-6 Windows and the Explorer 7 beta 2 category pages for more information. I also took the opportunity to remove a few reports that were orphaned for more than two months.
Finally, in JavaScript nothing much seems to have changed, although the crash on the normalize() method has been solved. I haven't yet done the rigourous DOM tests, that'll have to wait for another time.
The release of Explorer 7 beta 2 has raised some questions, especially about maintaining the various IE versions you may have on your computer. Basically the beta overwrites IE 6, and Joe Maddalone's Multiple IE instructions don't work, but you can uninstall the beta quite easily and IE 6 is restored to you.
I suppose I do a few people a favour when I write down clear installation and uninstallation descriptions and instructions. Here it goes:
Explorer 7 beta 2 seems to be available. I'm currently downloading it, so I have no test data yet.
I added an "Explorer 7 beta 2" category to the Bug Report. Please report any bug you find; the MSIE team needs you.
27 January 2006
Permalink
| in Coding techniques, Mozilla
13 comments
(closed)
One of my minor irritations with Mozilla is that it doesn't support a few DOM methods and properties that, though not officially a part of the spec, are nonetheless extremely useful and supported by all other browsers. I'm especially thinking of the contains() method and the children[] nodeList. While going through the more abstruse parts of the Level 3 Core spec today I found a way to add contains() to Mozilla.
24 January 2006
iCab 3.0 is a surprisingly good, independent Mac (OS X and 9!) browser created by Alexander Clauss. It has good (though not perfect) CSS1 and DOM1 support, and to my surprise it even contains a speech browser. More than enough reason to recommend iCab to all Mac users that read my site, and to update my CSS compatibility table.
6 September 2005
Permalink
| in Coding techniques, IE
21 comments
(closed)
In a recent article on the IE Blog, Justin Rodgers talks about further CSS improvements in the ever more impatiently awaited IE 7 beta 2. His message is that CSS hacks will start to break in IE 7, and I fully agree.
Nearly two years ago I warned against the excessive use of CSS hacks, because I envisioned a situation like this. Web developers who rely on CSS hacks are going to have serious problems.
Apple just released Safari 1.3.1 without fuss. I found one important improvement over 1.3: the unload event, which was badly broken in 1.3, is now restored to its ancient reliability.
I didn't find any other significant updates in the CSS or JavaScript handling, but I did only a few very quick tests. If you found a change, please leave a comment.
Update: Safari used to download images with display: none only when they, or their parent element, were toggled to display: block. Unfortunately version 1.3.1 (and maybe 1.3) reverted to downloading the images anyway. Test page.
30 July 2005
As everybody and his dog know by now, IE 7 Beta 1 has been released. Read Chris Wilson's entry over on the IE Blog for the details. Since I do not have a copy of it, I will not discuss it in detail. It is my strict policy to discuss only browser features and bugs I've actually seen for myself. Expect a full report as soon as I've got it installed on my computer, but not before.
The MSIE team seems to have used my site for bug testing, although almost all discussed bugs come from Position is Everything, and rightly so, since Big John and Holly Bergevin have far more interesting and detailed bug reports than my own CSS section.
Meanwhile this good news is being overshadowed by an apparently quite vicious campaign against Molly Holzschlag, who seems to have had the temerity to suggest that the IE 7 beta is actually good news for web developers and the standards movement in general, a message that encounters quite a bit of resistance among web standards fascists.
Over on the IE Blog Chris Wilson gives a few details on the upcoming Explorer 7 beta.
Two months ago I said that I didn't expect the Explorer 7 beta to contain solutions to CSS problems. Clearly I was wrong: Wilson announced support for alpha PNG channels and a solution for the Peekaboo and Guillotine bugs, and he indicated more goodies are to come.
So the Microsoft team is taking the opportunity to not only beef up security, but also CSS support. I'm curious, for one. Expect a full report on this site when the beta is available; and let's hope the CSS solutions we found for the Peekaboo and Guillotine bugs won't misfire in the new Explorer 7.
Opera 8 has been released. I tested it and found no differences with the beta I studied earlier.
Two days ago Apple's team launched Safari 1.3, being part of the OS X.3.9 upgrade (once again named after a fierce predator, but I forget which one). Despite numerous bug fixes, the new release is marred by extremely serious onunload problems.
In an interesting post in the IE Blog, lead program manager Chris Wilson explains the current state of affairs in the touchy realm of "IE and standards support". It's an interesting read, and he makes a few cogent points. He also calls for specific requests about standards IE should support, and I'm happy to oblige.
Today Microsoft, in fact Bill Gates himself, has officially announced Explorer 7, the fabled successor to Explorer 6 that everybody seems to have been talking about since 2002. Before jumping in the air from joy, let's see what Microsoft says and what it doesn't say.
24 January 2005
I did the W3C DOM tests in Mozilla 1.75 and Opera 8b and updated the tables. Mozilla doesn't show much progress (then again, it doesn't have to show much, it's already the browser that supports the W3C DOM best). Opera is on the move again.
10 January 2005
I just downloaded Opera 8b (from this location), and since I now have two new browsers I updated a few compatibility tables.
I just downloaded and installed Mozilla 1.7.5, which, as far as I was able to determine, is the latest non-beta release. Over the next few weeks I'm going to go through the unenviable chore of updating all compatibility tables yet again. You may note that I did not download Firefox. In fact, I've downloaded it months ago and within a few minutes decided it's not going to become my default browser.
I thought I'd give you the current visitor stats for this site, gathered through the Reinvigorate system. Of course these figures are only valid for this site, and should never under any circumstance be used for any other site.
This is the blog of Peter-Paul Koch, web developer, consultant, and trainer.
You can also follow
him on Twitter or Mastodon.
Atom
RSS
If you like this blog, why not donate a little bit of money to help me pay my bills?
Categories:
