Posts in the Browsers Category

Running on :empty

Published 17 years, 3 months past

While kicking around some ideas at the CSS workshop I led in London, I ran into some interesting problems with :empty.  If you’re not up on what that one does, it’s a way of selecting elements that have no children, including text.  To quote the formal definition:

The :empty pseudo-class represents an element that has no children at all. In terms of the DOM, only element nodes and text nodes (including CDATA nodes and entity references) whose data has a non-zero length must be considered as affecting emptiness; comments, PIs, and other nodes must not affect whether an element is considered empty or not.

So kindly consider:

*:empty {
   padding: 0.25em;
   outline: 1px dashed red;
   background: yellow;
}

We (re)discovered something very strange right there in the workshop: given the preceding rule, Firefox applies it to the body element—which is, quite clearly, not empty.  You can check out the fun on my bare *:empty test page.  From there, we realized that if you prepend a body to the selector, yielding body *:empty, the problem vanishes, as you might expect.

As it turns out, this is a known bug in Gecko.  It’s been known for about 18 months, in fact.  So that’s why I was confused by Firefox’s behavior.

The other problem is that :empty in Firefox matches img elements, whether or not they cause an image to successfully load.  You can see this happen on the same test page.  While it’s true that img is an empty element, it’s still bringing in content, so from a common-sense point of view it seems that :empty ought not to match.

In re-reading the description from the specification, though, I can’t justify my common-sense interpretation—an img element has neither element nodes nor text nodes, so far as I’m aware.  The same is true for form inputs, even text inputs that have pre-filled value text; but not for textareas that have pre-filled content text.  But then br elements should also be selected by this rule, and they apparently don’t get matched at all, as the test page shows.  Bwuh?

Well, maybe it’s a bug.  What concerns me here is that the definition of :empty basically requires that things like images and inputs always be selected, which strikes me as kind of useless.  After all, if I wanted to select all images, I’d write img into my selector; ditto input for inputs.

My thinking is that the description should change to state that application of :empty is restricted to non-replaced elements.  Alternatively, it could be redefined to only apply non-replaced elements and to empty replaced elements that don’t either cause something to load or have values associated with them.

Which seems a better solution to you, and why?  Or, if you see a better approach than either of those, what is it?


The Veteran’s Charge

Published 17 years, 3 months past

“This page best viewed in…”

If that phrase doesn’t provoke a shudder of horror and loathing, it should.  It’s the battle cry of the Browser Wars, those terrible and ultimately futile years at the end of the last milennium.  It’s the rallying cry of those who would take the open ubiquity of the web and fragment it into a collection of gated communities, where entrance to each is predicated on running a specific browser.

“Your browser is not compatible and must be upgraded…”

All too often, because developers are too fearful or prideful or just plain lazy, they put up unnecessary barriers to entrance.  They prevent people from using their sites based on choice of browser.  Of course there are situations where the experience will be different—nobody expects Netscape 4 users to be able to see all 2007’s pretty CSS effects, just like table-based sites look beyond bizarre in Mosaic.  That’s no excuse for sites that intentionally lock users out just because their choice of browser doesn’t line up with the developer’s expectations.  It’s regressive, short-sighted, and just plain unprofessional.

“This site is for iPhone users only.”

STOP IT.  Stop it right now.

The fact that optimizing pages for an iPhone makes the development of such specialized pages attractive in no way excuses lockout of other users.  I might be willing to entertain the argument if the iPhone’s browser were some specialized non-web contraption.  It’s not.  It’s a full-fledged XHTML+CSS+DOM browser that happens to lag a bit in some implementation areas and won’t run some plugins.

Besides, if you’ve developed a version of your site (or application or whatever) that works well on the iPhone, then why in the name of Tim Berners-Lee would you deny other people that optimized experience?  You might find that they prefer to interact with the site that way no matter what platform they’re using.  You might find that you don’t need a separate iPhone version after all.  The iPhoned version might be the only version you need.

Designers will argue that pages optimized for the iPhone screen will look bad on a desktop browser.  Maybe, and maybe not, but stop preventing your users from making that decision for themselves.  Nobody says you have to convert your whole site to be iPhoney.  But your lockout of non-iPhone users is worse than rude.  It’s stupid.

We finally learned, after much sweat and a fair number of tears, that “best viewed in” is a fool’s errand.  Are we so eager to rush back into that morass and fight the war all over again?

Please.  Just stop.


Windows Safari

Published 17 years, 5 months past

Because the world needed another browser/platform combination to test, Apple has released a beta version of Safari for Windows.  Why?  Arguably, it’s to make sure that Windows developers have access to the browser in the iPhone, so they can make sure that their Web 2.0 sites work on the iPhone without having to buy new computers.  (Though this also robs them of the primary justification for getting an iPhone on the company dime.  Haven’t they suffered enough, Steve?)  On that note, I hope this new foray will expand the pool of people contributing ideas to Greg‘s post about cool new apps for the iPhone.  (There’s already a truly brilliant idea in there, albeit with a name I can’t use here due to readers behind content filters.  Who’s going to make it happen?)

It will also be interesting to see if the presence of another highly standards-compliant browser (joining Firefox and Opera) on the Windows platform spurs more Windows-based web developers to pressure Microsoft to maintain their momentum on the issue, so as not to see IE fall behind all the competitors.  As you might expect, I certainly hope so.

Remember: this is a beta!  There’s going to be weirdness.  PPK, for example, ran into layout problems that may or may not be related to the video card in one of his systems.  Other people are reporting crashes; though many of them are reporting crashes on CNN‘s site, which crashes my OS X copy of Safari from time to time.  Interesting to see that kind of cross-platform crash consistency.

The beta’s certainly worth checking out if you’re interested, but—as with the IE7 betas—do not start reworking your site to address layout problems in this beta.  Report them to the WebKit team instead.  When the final version (or a feature-frozen RC version) is released, it’ll be time for testing, charting, and possible reworking.

Interesting times indeed.  If you’ll excuse me, I have to go make some changes to my browser-release timeline slides.


Praise IE, Go to Jail

Published 18 years, 7 months past

A week or so back, the shattered remains of a wasps’ nest appeared in our driveway.  Despite the fact that it’s clearly vacant—even wasps know when it’s time to find new digs—I still tread carefully whenever I walk past, avoiding them out of some latent respect for the threat they once contained.

You’d think I’d behave in a like manner in the rest of my life, but no.  For example: I recently spoke well of the IE team and their efforts.  Kind of an obvious goof, really, but I’d hoped for a different outcome.  It’s the incurable optimist in me.  And when I say “incurable”, I mean that in the sense of “disease that can’t be purged from my body and will no doubt one day kill me”.

While the enraged buzzing took many forms, the comment that seemed to distill the bulk of people’s anger was this:

“How am I supposed to trust a smiling face of some developer at Microsoft when the company as a whole was charged with being an illegal monopoly not too long ago?”

Because one is a person, and the other is a corporation.  I realize that American law moronically (and, in a certain sense, unlawfully) equates the two, but they really are distinct concepts.

You can dismiss my attitude as the biased perspective of someone who personally knows members of the IE team.  That would be a major miscalculation, because it’s those personal relationships that make my observations different than what you’ll find elsewhere.  Think what you will of Microsoft, but there are actual people working on IE, and they’re by and large people who care about the same things we care about.  They are part of this story.  If you think they’re minor nodes in a monolithic collective consciousness, then boy, do you ever have a lot to learn about how large organizations function.

Allow me to draw an analogy, if I may.  While at Mix 06, I was talking with one of the senior IE team folks about improving standards and the browser market.  He said to me, “So what is it the Web design community wants?”—as if there is a single such community, and it always speaks with a unified voice on all matters.  Does that sound like the Web design community you know?  Does that even sound like any arbitrary collection of five Web designers you know?  (Aside to WaSP steering committee members: feel free to take a ten-minute laughter break.)

So why do we assume that Microsoft, a company with tens of thousands of employees working in hundreds of teams and units, would be any more unified?  Sure, the PR department speaks with a single voice.  To take that as representative of every Microsoft engineer is like ceding all authority for your thoughts and opinions on Web development and design to the Web Standards Project.  Anyone volunteering for that?

Not me, thanks.  Not even when I was a member, back towards the end of the last millennium.

This is what I said to him, by the way, except I compared the Web community to Microsoft, with all its subunits and competing voices and priorities and goals.  He got what I was saying instantly, even though it let him down a bit.  His job would be easier, after all, if the Web design community were a unified collective.  It’s certainly less mental effort to think of “the other camp” as being a Borg-like hive, isn’t it?

A few people accused me of being lulled into missing the Great Looming Threat of Microsoft’s non-standards efforts.  For example:

“…Microsoft spent those years planning and building WPF, to lure Web developers into its proprietary and patent-protected embrace. And that should have you most concerned.”

Been there, done that, got the T-shirt, wore it threadbare, and repurposed it as a cleaning rag.  I was openly expressing precisely that concern back in October 2003, which as you may recall was near the middle of said years.  The aggregate response of the community was a disinterested shrug.  This was largely true whether I posted publicly or talked to people one on one, as I’d done in several cases in the months before October 2003.  The only place I found any similar concern was with some folks at Macromedia, thank you very much.  Everyone else seemed to think I was on crack.  So sorry, but I pretty much wore out my concern back then.  You can have it now.

Besides, over time I’ve come to see WPF (as it’s now called) as being very much like Flash, which it clearly wants to supplant.  Despite all these years of Flash being very widely installed, and all the years of Flash being able to do XML data exchange with servers to cause dynamic updating of pages—you know, like Ajax does—the Web has not become an enormous Flash application.

I thought the most interesting observation was this one:

“Dave Shea pointed out… a few months ago that one reason [for IE7] may be that Microsoft, in developing things like live.com, are finally having to eat their own dogfood, struggling to get things working on their own browser, and that as such there may have been internal pressure to get things up to scratch.”

That makes a certain amount of sense, though I’m not about to accept it as the sole reason for IE7’s development path or even its existence.  I think there were a whole lot of factors that drove IE7 into being, and standards support was honestly pretty far down on the list.  I, for one, am deeply grateful that the IE team seized on the opportunity to build better standards support into the browser, whatever the internal rationale they used to justify it to the higher-ups.

I’m also impressed with the CSS and other advances in IE7, and with how the IE team is managing the development process to accommodate the needs of Web developers and designers.  They didn’t have to do any of that.  After all the crap they’ve had dumped on them the last decade or more, they have every reason not to care about what’s best for the Web.  Despite this, they still do.  Recognize and respect that, if nothing else.


IE7 Improvements and Bug Tracking

Published 18 years, 8 months past

Over on IEblog, Markus Mielke has a great IE7 post with screenshots of a CSS Zen Garden-inspired layout showing off fixed positioning, PNG alpha channels, arbitrary-element hover, and so much more.  There are those who have called for its inclusion into the Zen Garden, but as Dave points out, it would break in IE6 and so couldn’t qualify as an official design.  Oh, the irony.

Getting back to Markus’ post, he has this to say near the end:

…we are now layout complete with the release of the MIX build – we don’t plan to add more layout features or drastically change layout behavior. This gives web developers a chance to test and prepare your pages for Vista Beta2 and the final release of IE7.  There are still bugs and missing features (display tables, generated content to name a few) we would have liked to do for IE7 but based on your requests to have some lead time to test your pages we need to lock it down now to be able to ship IE7.

So there you go: no more CSS functionality will be added to IE7.  Anything that isn’t there, like CSS table properties and the like, will have to wait for a future version.  As has been publicly stated, though, we won’t have to wait five years for the next version.  There’s no solid guarantee of how long or short a wait there will be, but Bill Gates himself said that new versions would come out more frequently.  The IE team reiterated this.

So will current bugs in IE7’s CSS handling be fixed?  I give that a solid “maybe”.  Markus has left the door partway open by saying that there are no plans to make drastic changes to layout behavior.  That could mean that if a bug fix only causes minor changes, then it might get in.  On the other hand, it could mean that unless existing behavior causes massive problems (or crashes), no bug fixes will be taken until after IE7.  Personally, I wouldn’t count on it, but I’ve been wrong before.

Then, in the same post, Markus drops an entirely new bombshell:

The good news is that we are in the progress of building up a public bug database where you can submit your issues, track their progress and see when we internally fix an issue – Al is going to post about this soon.  Your participation will help us greatly to improve IE and also help us to prioritize what bugs to fix for the next releases.

Sweet fancy Moses—a Bugzilla for IE?  There was no mention of this within my earshot at Mix 06, so I’m as surprised as anyone else.  Did I fall down a rabbit hole and quaff a bottle labeled “DRINK ME”?  If this is a dream, I don’t ever want to wake up.

The Redmond-haters will claim that this is just a lot of catch-up, played years late, and amounts to little more than aping what Mozilla and other browser makers have been doing—better standards support, a tabbed interface, open bug databases, and so on.  It happens that they’re right, but what’s wrong with that?  The IE team has looked over what happened while they were in hibernation and is emulating the best of it.  That’s not lame, that’s smart.  And it should have other browser makers a little bit worried.  A lot of their success has been due to Microsoft’s complacency.  They’re going to have to be a lot sharper and more nimble now that the 800 pound gorilla is actually awake and paying attention to its surroundings.

No, I don’t think IE will wipe everyone else off the map, but I do think the browser space is getting a lot more interesting.  What makes it particularly interesting is that the competition is not going to be over who can add the coolest non-standard geegaws, but who can deliver the best product based on the same standards as everyone else.

I’ve wondered what that would be like ever since I got seriously into standards back in mid-1996.  I almost can’t believe that there’s a chance I’ll get to find out.


Mixed Impressions

Published 18 years, 8 months past

Actually, I shamelessly used that title simply because it’s a little play on words.  By and large, my impressions of Mix 06 and what I’ve seen here are positive.  This isn’t my last word on everything going on here, but I wanted to share.  Enjoy!

  • You can drag-rearrange tabs in Firefox just by click-and-dragging the tabs.  Seriously, I had no idea.  Thanks to Dan Short for setting me straight on that score.

  • In his keynote, Bill Gates said “we need microformats”, which I didn’t even know was on his radar.  For more about that, head on over to microformats.org.

  • Microsoft is coming out with a new Windows-only Web design tool called Expression.  It’s pretty slick, with features like visually illustrating margins and padding in the design view and what seemed like smart management of styles.  Unfortunately, I had a little trouble following what it was doing, mostly because I saw it presented in a talk and didn’t have hands-on time.

    Basically, Expression seems to be FrontPage done right, with a relentless focus on standards-oriented design principles. It has its own rendering engine for the design view, and the whole thing was built from the ground up, which means it isn’t trapped by legacy rendering concerns, but it made several of us wonder why that isn’t what they use in IE7.

    I also had trouble mentally distinguishing it from other visual Web design environments like Dreamweaver, but that’s probably because I don’t use a visual design environment.  BBEdit 4-evah, baby!

    Speaking of which, there are no plans to port Expression to the Mac.  Whether that’s good or bad probably  depends on your worldview.  Look for public betas of Expression somewhere in the June 2006 time frame.

  • It was publicly stated that the current build of the IE7 beta available from Microsoft is rendering-behavior complete.  In other words, the only changes to IE7 from now until it goes final will be fixes to security holes, crash bugs, and browser chrome/UI stuff.  Whatever its CSS support does or doesn’t do, that’s how the final version is expected to behave.

    Ladies and gentlemen, start your engines.

I’ll take a few minutes on that last point.  A little while ago, I said that designers should remain calm and not hack their sites to fix them in the IE7 beta because it was a moving target.  That is no longer the case.  It’s now time to start testing sites in the IE7 beta and identifying any layout problems that may occur.  (And there will be problems.  No browser is perfect.)

I’ll be doing this as soon as I can, and I encourage everyone who can to do the same.  Here’s the other key point: IE7 is scheduled to go final in the second half of 2006 (I couldn’t get anything more specific), so we have a calm period of at least three months in which to find out how things stand before IE7 goes final.  This isn’t an accidental circumstance, either.  The IE team has deliberately done this in order to give Web developers time to figure out what’s coming and how to deal with it.

This is entirely in keeping with the new spirit of the IE team, which has impressed me again and again at this conference.  Once upon a time, upgrades to standards support were blocked by the cry “We have customers!”, which was maddening both because it impeded progress and because it was true, as I wrote back in 1998.  The usual counter-argument was that Web designers and developers are customers, too.  We just weren’t (often) treated that way.

Now we are considered customers of the IE team—not the only ones, but important ones.  Not every decision will go our way (even if we had a single “way”, which of course we don’t) but our needs and concerns will be considered.  As further proof besides the “grace period” built into the IE7 timeline, the IE team is creating tools and resources meant to make it easier to update sites for IE7.

I’ll have a good deal more to say about all this in the near future, but those are the big points in my head right now.  I expect to hear Dave‘s, Andy‘s, and Molly‘s takes on all this, and hopefully others will add their thoughts as well.


IE7 Revs Up

Published 18 years, 8 months past

I don’t think I can say this without sounding smug, so I’ll just say it: this is what I was talking about.  If you went ahead and tried to hack your site so it worked in the previous beta, I’m sorry, but I tried to warn you.

It’s also why I said CSS hacks weren’t necessarily dead yet, or even likely to cause real problems, because there’s every chance that IE7 will be close to being another Firefox (in the standards-support and layout-behavior senses).  We can’t be sure of that yet, of course, but the results described by Molly are pointing in that direction.

Sure, we’d like to see a hack-free Web, but that point will not come until a few years after IE7 finally ships.  No, that’s wrong: we’ll never have a hack-free Web.  But we might reach a time where cross-browser presentation has become not only commonplace, but subconsciously assumed, like our current expectation that a browser will know how to handle hyperlinks.


Charting IE7b2

Published 18 years, 9 months past

So IE7 beta 2 is out.  As you might expect in a beta, it has some things that don’t work as one might hope, whether due to long-standing behaviors or brand new bugs.

I’ve said it before, and I’ll say it again: don’t panic.  Trying to fix a site that’s “broken” in IE7b2 is kind of like deciding to raze your profitable gas station just because you heard car companies are experimenting with hydrogen fuel cells.  When the final version of IE7 comes out, then you can worry about what to do.  Maybe your site won’t be “broken” any more, and you won’t have to do anything.

In the meantime, what you should do is figure out what’s causing the problem you’re seeing in b2, create a very minimal test case that causes the problem, and submit that to Microsoft.  By doing that, you give them a chance to identify the problem and fix it before IE7 goes final… at which time, you won’t have to do anything about your site, because it won’t be broken.

That’s if they fix the bug in question.  They might not; they don’t have infinite time and energy.  But I can absolutely guarantee that they’ll never get around to fixing a bug nobody told them about.

In the CSS world, there are some points of concern, including bugs that are new to IE7b2.  The css-discuss community has started collecting information over on the wiki, and if you have test cases that demonstrate CSS bugs in IE7, you should feel free to add information and links to that page.

Before you do, though, make sure to observe the following (adapted from my post to css-discuss):

  1. Make absolutely certain you’re testing IE7 beta 2.  IE7b1, which is available for download on various sites, had no known CSS enhancements.  It did not support CSS2.1 selectors, or fix any bugs on which CSS hacks depend, or just about anything else.  If you test with IE7b1, you’re wasting your time.  Again, be SURE you’re testing with IE7b2.

  2. If you’re testing property, value, or behavioral support in IE7, make absolutely certain that your test case uses no hacks, filters, conditional comments, or other measures.  If you’re testing float margin-doubling, for example, but you still have in a CSS hack targeted at IE6, you might get completely spurious results. Make your tests as simple as humanly possible while still showing the problem.

  3. If you’re testing support for hacks, filters, or conditional comments in IE7, try to make sure you’re testing using simple effects. For example, here’s how I’d test for IE7 support of a child combinator:

       p {color: red; font-style: italic; font-weight: normal;
          text-transform: none;}
       div>p {color: green;}
       div > p {font-style: normal;}
       #test>p {font-weight: bold;}
       #test > p {text-transform: uppercase;}
    
       <div id="test"><p>Bold uppercase green</p></div>
       <p>Italic normal case red</p>
    

    This approach uses property/value combinations that we all know IE/Win has supported for a long, long time.  If I tried to test with widths and margins and padding, I’d be concerned that a box model bug was sneaking in and making me think there was a selection bug.  With the color-font-text approach, this is far less likely.  (Not non-zero, but close.)

    Similarly, to test arbitrary-element hover, I’d do nothing more exciting than:

        p:hover {color: green; background: cyan;}
    
  4. If you find a new bug, as Al Sparber has with the a:hover/@import problem, absolutely document it with a basic test case (as Al did) and feel free to ask others for confirmation.  But remember the previous points when you construct your test case.

The goal of all this isn’t just to make sure Microsoft knows about every CSS bug under the sun, though that certainly wouldn’t hurt.  What I also hope to see happen is that we get an idea of what’s new, what’s broken, and what absolutely must be fixed.  To pick a hypothetical example, suppose it was discovered that in fixing float margin-doubling, IE7 broke clearing behavior.  That would absolutely have to get fixed before IE7 final.  Doing so would be far more critical than, say, adding support for generated content, or even fixed positioning.

Again, don’t panic, but please do help find any bugs or other problems in IE7b2, so that we have a chance of seeing the problems corrected.

Addenda: so just after I posted this, I found out about the IEblog post What’s New for CSS in Beta 2 Preview? and the in-progress MSDN technical note Cascading Style Sheet Compatibility in Internet Explorer 7.  Those might come in handy as a baseline of “here’s what I should see” while you work to find out what you actually see.


Browse the Archive

Earlier Entries

Later Entries