Posts in the Browsers Category

There’s been some speculation that Microsoft’s recent browser moves may actually be good for Web standardization, not bad.  It’s a side of the issue I hadn’t considered, and it does make a certain degree of sense.  Suppose you’re a large bank and you want a browser that you can rely on to protect your data.  You might well decide that adopting an open-source browser, one which you can influence and even improve if your staff programmers contribute to the project, makes more sense than being beholden to a glacially developing and poorly secured product.  Ditto for companies who care about security—and now that spam-filtering’s built into at least one product’s mail client, ditching Outlook and IE for Mozilla or a variant makes a lot more business sense.

But there’s a down side to the whole situation, which is effectively that the adoption of standards is limited by the available browsers.  If IE/Win stays in its present state for the next two or three years, then use of CSS, XML, XSLT, RDF, P3P, PNG, and pretty much everything else will be constrained by the support IE/Win embodies—not totally beholden to it, but still definitely affected, in the same way the poor CSS support of NN4.x retarded CSS adoption for years.  When IE7 comes out in 2005 or 2006, it will help determine the standards-use landscape by how far its support advances (or doesn’t).  Maybe that’s a good thing.  Maybe having bigger updates less often is better than smaller updates all the time.  It just feels a little too much like stagnation, especially for an industry as drunk on change as ours has been.

Then again, if we’re lucky and Microsoft’s Web competitors don’t fold their cards just when they have a chance of winning back some of the pot, maybe in a couple of years IE/Win won’t be as weighty a gorilla as it is today.

• Salvation in the Storm? was published on Wednesday, July 2nd, 2003.
• It was assigned to the Browsers, Standards, and Web categories.
• There have been no replies.

Chris Hester wrote earlier to point out the CSS2 Test Suite’s main page was completely unreadable in Internet Explorer 6 if you had the “Text Size” set to “Smaller.”  This was news to me; I’d set my text to “Medium” the day I installed IE6 and never looked back.  So I went to the page, changed my text size, and winced.

The problem’s since been worked around, but to see the problem as well as read about the trigger and the solution, try this testcase.  Note that if you’re using IE6 and your browser is set to “Smaller” the testcase will start out completely unreadable.  Set it to “Medium” first and then go to the page and follow the directions.

The flaws in IE6 continue to amaze me, and now we’re stuck with it for another three years, minimum.  Great, just great.

Dave Hyatt recently made some observations about standards-support charts (starting with Standards Charts and continuing into three posts the next day).  I agree with most of what he has to say, actually.  Charts like the “master grid” are by their nature coarse.  They can do no better than provide support information for whichever tests the chart author happened to run.  In presenting an overview and comparison of CSS support, for example, depth-of-implementation testing is sacrificed.  It has to be.  The CSS support charts I published on Web Review for years, and now on DevEdge, are basically the work of one person: me.  I wrote most of what became the W3C’s CSS1 Test Suite in the creation of the original charts, back in late 1996 and early 1997.  Back then, it was easier—bugs were more obvious, and all implementations were shallow.  The charts could afford to be as shallow.

Now, thanks to years of experience, implementations are getting much, much better, and the bugs harder to find.  To fully test modern CSS implementations requires a far more complex set of tests than I could author in a lifetime of evenings (which is when I wrote the tests and the charts).  To be really comprehensive, you’d need to test every property and value combination on every element in HTML (or a markup language of similar complexity), which I think was once calculated to run into a few trillion combinations.  It’s a lot harder to create tests, to run tests, and to chart results than it used to be.  This fact was driven home to me recently as I worked on (finally!) updating the CSS charts.  For the tests I have at hand, most browsers score perfectly, or close to it.  I know that’s not true: every browser has bugs in its CSS support, some worse than others (*cough*WinIE*cough*).

(Aside: I feel either amused or gratified that there’s support for the concept of penalizing browsers for having bugs, a concept I used in compiling the “CSS leader board,” back in the day.  “Full” support earned a point, partial support got half a point, no support got zero, and a bug lost you half a point.  It was a touch crude, perhaps, but it worked.)

But I only have so many hours in every day, the same as anyone else.  It’s not reasonable to expect one or even five people to meet this challenge.  The only way to handle it is to find a moderately large crowd of CSS experts, all of whom trust the others completely, and distribute deep-test creation among them.  In a few months, they may have gotten far enough to run browsers through their tests.  A month or so after that, they could start compiling results, and eventually publish them.  But even assuming all of that data could be collected and presented, how useful would it really be to the Web community?  One of the keys to the original CSS support charts’ success was that they were easy to comprehend: their very shallowness made them useful.  Authors don’t have time for much more.

Implementors have different needs, of course.  If those needs are strong enough, they’re going to need to fund positions (and I do mean more than one) to coordinate the work necessary to fulfill their needs.  The money could come out of the Quality Assurance budget, even.  In any case, if standards support testing is a serious problem, then we’ll need a serious commitment to address it.  Who’s going to step up to the plate?

• Testing for Flaws was published on Tuesday, June 24th, 2003.
• It was assigned to the Browsers, CSS, and Standards categories.
• There have been no replies.

I would have posted about this yesterday, but frankly it was too depressing.  As others have noted, Internet Explorer for Macintosh is, effectively, done.  There will not be another major version: I’ll never get to write about CSS support in IE6/Mac, because there won’t be one.  As I said on Webdesign-L yesterday, and Zeldman quoted in part, I said:

[The IE/Mac team] was truly committed to the best standards support they could muster while working for a corporation that did not always share their ideals.  I wish everyone on the IE/Mac team the best of luck in their future projects, whatever they may be.  They not only paved the way for many of the things we now take for granted, but they fought the good fight, fought it hard, and in many respects they emerged victorious.  It’s tough to imagine a better legacy than that.

I was a beta tester for IE5/Mac, and it’s long been a favorite of mine.  There may be some personal bias stemming from the fact that I know bug reports and suggestions of mine are reflected in the final product, but the wider truth is that it was a groundbreaking browser.  I know DOM scripters find it annoying and substandard, but for those of us on the content-authoring side, it was rarely the worst of our troubles.

Others will analyze this development in light of the recent Microsoft/AOL settlement, the cessation of IE/Win as a standalone product, and so on.  I’m not really interested in all that right now.  Instead, I’d like to take a moment to run down a list of innovations and features that IE5/Mac introduced back in 2000:

• DOCTYPE switching—some would call this a bug, but in my view they’re missing the bigger picture.  DOCTYPE switching was the first mechanism that allowed authors to decide whether their document rendering should look to the past, or to the future.  It permitted browsers to fix bugs in standards support, instead of forever enshrining them for the sake of “backward compatibility.”  This quickly spread to Mozilla, and eventually made its way into Opera and IE/Win.
• Display resolution setting—there’s a preference dialog where you can set your monitor’s PPI value, literally by holding up a ruler to the screen and using a slider to match the ruler.  Some Windows display drivers had this before, but IE/Mac was the first major browser to build the feature into the browser itself.
• Text Zoom—don’t like a site’s font size?  Override it with a simple keyboard combination, scaling all the text up or down, depending on what you need.  Mozilla quickly followed suit and Opera introduced Page Zoom, arguably a better solution.
• Excellent CSS1 support—it’s easy to forget how revolutionary a reasonably complete and bug-free implementation of CSS1 really was.  Yes, there are some bugs, as with anything.  It’s still better than IE6/Win’s CSS1 support.
• Decent (if limited) CSS2 support—not quite as robust as the CSS1 support, IE5/Mac still made good forays into CSS2.  Remember the browser was shipped about two years after CSS2 went final, which means it was being written maybe a year after CSS2.  That may sound weak, but consider that in addition to fixing all its CSS1 bugs and finishing off CSS1 support, the team found the resources to look at CSS2 and take a stab at doing it right.  That’s pretty impressive, what with them also having to do all the other stuff a browser has to support besides CSS.
• XML source tree view—if you load up an XML file, you get a “pretty-printed” view of the document and its source, with collapsible element views.  Mozilla got this ability only recently, and I’ve always guessed that IE6’s similar ability only exists because IE5/Mac gave them an example to follow.
• Full PNG support—including alpha channels and gamma adjustment.  Sure, it was years after PNG was published, but who else was doing it at the time?  Even today, people are still signing petitions to get Microsoft to do the same for IE/Win.
• Customizable toolbar—you could define your own toolbar buttons, create PNGs (with alpha) to represent the buttons, and customize your browser.  It isn’t quite “skins” but it was still pretty darned cool.  Oh, and the toolbar configuration data was stored in XML.
• Page holder—eventually Mozilla came along with the sidebar, into which almost anything can be installed.  IE5/Mac was doing it long before, albeit with a somewhat different feature set.

There was more, I’m sure, but that was all that came to mind.  When it shipped in 2000, IE5/Mac had a feature set that would be respectable if the browser were released today.  I’d always hoped that one day it would be followed up with a similarly impressive new version.  Sadly, not so.

Just to add an extra layer of melancholy to the whole thing, when Tantek says he found out from folks pointing it out to him, I was one of those folks.  It’s at once difficult and all too easy to believe that the man who created such a good layout engine, and put in so much effort to improve the Web, found out about the end of his own project from friends and the press.

• Hail and Farewell was published on Saturday, June 14th, 2003.
• It was assigned to the Browsers and Standards categories.
• There have been no replies.

Do you still avoid PNG images because IE/Win doesn’t support the alpha channel?  If you’re like most Web designers, the answer is “yes.”  Thanks to Owen Briggs, I came across a petition asking Microsoft to change that.  Will it change anything?  Who knows?  We can but try.  You will have to allow a cookie (to prevent petition stuffing) and give them an e-mail address, but you can withhold your e-mail address from public exposure.  If you want to see real and widespread PNG support on the Web (and any designer should, once they fully understand what PNGs can do) then you should go sign the petition.  It’s quick, it’s easy, and it’s important.

• Be Heard was published on Thursday, May 22nd, 2003.
• It was assigned to the Browsers category.
• There have been no replies.

The Amaya team has recently said they’re very willing to accept contributions of redesigned icons and color choices for the browser.  So those of you with talent in that area, get to it!  Since the WThRemix contest closes today, you should have plenty of time to devote to Amaya, right?  Right?  Right.

I recently had a very interesting conversation with Ian Hickson about fonts and font-sizing.  Both of us have thought a lot about fonts in CSS and Web typography over the years, but I think we both realized that we had more thinking to do.  When you get right down to it, there is no good solution regarding font sizing on the Web today.  Every authorial choice has a drawback for some visitors, and every choice has a lot of benefits.  Pixels penalize high-resolution visitors who can’t (or won’t) use text zooming.  Percentages and ems can penalize visitors who have changed their default font size.  Leaving the text at user default looks stupidly big for visitors who haven’t changed their default font size.

It doesn’t help matters that there are huge differences in how serif and sans-serif fonts look at the same value of font-size, and that the commonly-available fonts on the Web today are not suitable for really nice typography.  I know some people think typography isn’t something we need to worry about, but it’s critical to good visual design and our current capabilites are laughably crude.  In fiddling with some test pages, I rapidly came to the conclusion that there just isn’t a good answer.  I’m not entirely thrilled with how this site’s typography is handled, for example, but I was even less thrilled by the other approaches I tested.

Is waiting for a downloadable-font mechanism our only hope?  I wish there were another answer, but right now, I don’t see one.  It seems we’ll have to accept and work with what little typographic control we have, and cede the rest of our textual desires to future improvements in both specifications and the browsers that implement them.

• Upgrading Designs was published on Friday, February 28th, 2003.
• It was assigned to the Browsers, CSS, and W3C categories.
• There have been no replies.

Fabian Valkenburg sent in e-mail letting me know that my comments on Opera 7’s CSS support got used in the talkback to an evolt.org article, and that I’m wrong about Opera 7’s display of the dates on this page being a bug.  As it turns out, the answer to that is “maybe.”

First, a word on how I set up the title and date styling in the basic site theme.  Both are contained in successive h5 elements, each with an appropriate class value (title and date, in fact).  I make the title inline so I can wrap a border around it that “shrink-wraps” the text.  Then, since I want to move it upward, I relatively position it upward two-third of an em.  Since it has been relatively positioned, for the purposes of laying out other elements, browsers should act as though the element wasn’t positioned at all.  (See CSS2:9.4.3 for details.)  So, in that sense, the relative positioning should have no impact on how the date is laid out, and in fact it doesn’t in the browsers I tested; I only brought it up to show that the title wasn’t floated.  On the other hand, I float the date to the right and right-align its text.  Since I’m floating the date to the right from below the place where the date’s h5 would have been (because the date comes after the title), I give it a negative top margin to pull it upward, so that it sits just below the top border on the entry.

Now here’s where things get fuzzy.  According to CSS2:9.5.1, the outer top edge of a float may not be any higher than the top of preceding float or block boxes.  It doesn’t say anything about inline boxes.  Remember that with CSS, it’s possible to have inline and block boxes for sibling elements.  So the effect of that portion of CSS2 is to allow floats to ignore preceding inline boxes when they float.  Or not ignore them, as the case may be.

Let me frame it another way: here’s a testcase that shows h3 and h4 elements in the normal flow, and then with the h4 elements floated.  To my way of thinking, both floats should sit below the h3 elements that precede them, regardless of the type of box those h3 elements generate.  This is because my conception of floats is that they start from their place in the normal flow, and then move to the right (or left).  From there, they move downward if they must, but not up.  Unless I give them a negative top margin to move them up, of course.

The behavior I just described is what IE5.5/Win and Gecko-based browsers do, to pick two examples.  But what Opera 7 (and, in many cases, IE5/Mac) does is not a bug, because it doesn’t violate the CSS specification, so I retract my earlier statement.  I believe that what it does is not what  site authors would want, but it isn’t wrong.  Thanks to the wording in CSS2:9.5.1, neither are the browsers that don’t agree with Opera 7 wrong, although I would accept that they’re further away from the letter of the specification.  Whether or not they violate its spirit isn’t clear, and it’s in cases like this that browsers tend to do whatever their programmers thought best.

So what we have here is a gray area in which I believe the letter and spirit of CSS are pulling in different directions, and browsers are splitting over which path they choose.  Hopefully CSS2.1 will be clarified to address what should happen, and we won’t have to bother arguing about who’s doing what better in which way for whom.

As for css/edge, yes, I hear you.  Opera 7 gets most or all of the demos correct, and may in fact reveal some erroneous assumptions on my part in the pure CSS menus demo (or maybe not; I don’t know yet).  When I get time to actually run Opera 7 through all the demos and evaluate its behavior, I’ll see if I can get the support information updated.  Unless of course I finally decide that the support information is becoming too much trouble to have around, in which case I’ll update it into oblivion.  It never really helped prevent people from misrepresenting what the demos were supposed to do anyway.

Personally, I like Opera 7 (or did once I switched its skin to the classic look), and my comments weren’t meant to cast it into the junkbin of bad browsers.  If I were a Windows user, I’d probably use it a lot more than I do.  There are rough edges, as with any browser, but overall it’s quite good—I think I said that already, but some people don’t seem to have heard that part.  Opera 7 handles a site redesign project I’m working on a lot better than Opera 6 does, I’ll say that much.

• The Silence of the Fat Lady was published on Saturday, February 8th, 2003.
• It was assigned to the Browsers, CSS, and Standards categories.
• There have been no replies.

Imagine the ability to spread a bunch of sub-millimeter sensors around and then collect the data.  Now go read “Companies test prototype wireless-sensor nets” at EE Times Advanced Technology.  Then, assuming you haven’t, go read A Deepness In The Sky by Vernor Vinge.  It goes on rather longer than I might have liked, but it’s still full of interesting ideas, including the use of a “smart dust” sensor network.  It would seem that privacy as we know it really will be over.  David Brin touched on this topic in Earth, and apparently addresses it directly in The Transparent Society, which I haven’t read.  Is the only defense against technological invasion of privacy the ability to detect the invasion, and the ability to counter-invade?  I don’t see too many other options, frankly.  It might be possible to jam some forms of invasion privacy, but who could afford the gear to detect and defeat all possible forms of invasion?

Along similar lines, the more I hear about the things that can happen to IE/Win users, the happier I am about being a Macintosh user who works for Netscape.  The very idea that a Web browser can be taken over, and seriously mess up the operating system in the process, makes my eyes cross.  I’m starting to wonder how any company with the slightest shred of concern over security could possibly justify running IE/Win.  Here’s a scenario:  a high-level manager wanders past a site that does a drive-by download of a toolbar which then does its own download of a small program that quietly transfers all of the hard drive contents to another system.  Hey, were those your corporate secrets leaving the building just now?  Yeah, I think they passed a virulent data-eating virus on its way in.

Then again, if said company is also running Outlook, I suppose getting upset over virus infections became passé a long time ago.  In any case, the only defense against this sort of thing is the ability to find out that it’s happening and put a stop to it.  If there were a way to inflict similar damage on the original perpetrators, we’d all be mini-Cold War actors: don’t mess with my data and I won’t mess with yours.  In that kind of situation, how long would it take someone to decide a first strike was a good idea, and how much damage could they inflict?

• Stay in View, Please was published on Thursday, January 30th, 2003.
• It was assigned to the Browsers and Personal categories.
• There have been no replies.

I’m feeling better, thanks.  About most things, anyway.

If you’re seeing layout or other rendering bugs on this site in Safari, as some people have said they are, please use the bug icon in the browser to report the problem.  I can’t run Safari or else I’d report problems myself.  Apparently there are some weirdnesses with the navigation links in the sidebar, if nothing else.  Whatever problem you see, it’s worth reporting, so please do.

Most of you probably already know that Mark Pilgrim is upset with XHTML 2.0, and many of you may be aware that Tantek and Daniel Glazman are in agreement.  I’m broadly sympathetic with their frustrations, but since I was never that thrilled with XHTML in the first place, I can’t get too worked up about the breaks between 1.x and 2.0.  I never really got why HTML had to be reformulated as XML.  Yes, I’ve read all the arguments about later ease of conversion and all that.  I suppose there was some good in easing authors into XML authoring habits using a language they mostly recognized.  That just didn’t seem like enough.  This site has been, and continues to be, HTML 4.01 Transitional for a reason.

I do broadly agree that XHTML 2.0 is way too unrealistic for its own good.  It outright drops too many things authors find useful, like the style attribute (although I admit I’m biased there) and heading elements.  For that matter, yes, Virginia, there is a difference between abbr and acronym, so dropping either one seems like a mistake.  On the other hand, if this stuff was deprecated instead of eliminated, I’d have many fewer points of concern about XHTML 2.0.  I’d be worried that the deprecated stuff would be dropped in the next version of XHTML, but XHTML 2.0 would bother me less.

Then again, given that you can take XML and CSS and create your own documents out of whatever markup language you can invent, and use XSLT to bridge the gap between old browsers and new ones, I find XHTML to be of minor import.  If it gets too ivory, then it will be ignored, and some other XML-based language will take it place.  Or, more likely, lots of markup languages.  Either way it will be interesting, and the XHTML 2.0 advocates won’t be able to blame anyone else for the explosion of non-interoperable languages.  Which, I suppose, is the point of all the sturm und drang of late.  If XHTML 2.0 were interoperable with XHTML 1.1, people wouldn’t be nearly so upset.

Wow… all this concern over making things work together.  Can it be that the Web is getting all growed up?

• Agony and Ivory was published on Tuesday, January 14th, 2003.
• It was assigned to the Browsers, Standards, and Web categories.
• There have been no replies.