Front-End Architecture: Browsers

Good points! I am, unfortunatly, a recovering css hackaholic. Got to work on that in the future. Keep it up.

I continue to read about css hacks being evil, but rarely does someone offer an alternative.

I try to keep my own code as hack free as possible, but I inevitably run into the same types of bugs, namely box model rendering issues and the float escape bug. I place these hacks in a separate style sheet and I generally only need 3-5 rules to get everything working in IE/Win 6.0-5.x, but I certainly don’t see myself doing away with hacks completely.

So, what alternative do we have? Could someone suggest what we should be doing to be as future-ready as possible and keep the hacks to a minimum? Should we be using conditional comments? What is the best solution at this time?

Regarding the “hacks are evil” point, there still seems to be a lot of discussion about what “CSS filters” can be found for IE7, which (unless I’m completely missing something) strikes me as being a complete waste of time and effort.

Conditional comments do the job just fine, and rely on official, supported, standardised IE behaviour, unlike the “filters” that rely on parser bugs or yet-to-be-implemented selectors.

Am I missing something…? I’m starting to worry now…

Why not use the child selectors, Derek? html>body works just fine and it’s not exactly a hack. I think it’s a clean solution without any problems, in fact it’s proven that it works, now that IE7 beta 2 is out.

Just a note, the only place I believe something like this is required is specifying the width of blocks where padding and border is present, I don’t use html>body anywhere else. And no, DIV is not an option—it’s no better than a hack.

In fact, I have a question for you Garrett, if you think that it’s OK to use as many DIVs as you like to avoid hacks, why do you think that it’s ok to use image replacement method which doesn’t work with images off? Every proper coder should get used to image replacement methods that respect the images-off scenario. Or is code more important than your user?

Garrett: I suppose I use hacks because I’m not familiar enough with browser differences and how to write code to avoid them. I appreciate the box-model example. Perhaps you could write more about how you avoid certain CSS hacks with various coding methods?

I try my best to use as few hacks as possible (I generally use the * html hack and the Modified Simplified Box Model Hack), but I’m always interested in how others work around various browser inconsistencies. I do see how your methods could be “cleaner and more long term than a hack”. I also understand what Anatoli is saying, but I think I would prefer to use a few extra bits of markup than CSS hacks if that is possible, especially after reading Dave Shea’s article and hearing all the talk regarding IE7.

The comments following Dave’s article contain some pretty good arguments. What I came away from it with, was that in the end the clients are demanding (near) pixel perfect layouts, but the various browsers are incapable of allowing us to do this without some “workarounds”. Many of the arguments presented by the commenters regarding pure methods or demanding more of the browser manufacturers are great in theory, but can’t always be applied to real-world situations or are just not going to be a reality in the foreseeable future.

I posted my original comment because I wanted to be exposed to more real-world applications of how NOT to use hacks because I wasn’t very familiar with them myself. I found myself agreeing with articles such as Dave’s and yours, but not knowing how to actually implement the ideas presented.

Garrett: You know splash page is a bit different (I don’t care if people get to see that bullshit there or not) from an actual site… but whatever. You can be sure that all the real sites I produce are accessible with images off.

As for the DIV, I won’t argue, but I just don’t agree with you. To each his own, you’re right.

Derek: I just don’t see how declaring an extra rule for width in IE6- is any worse than having extra DIV for every element that has width + (padding || border) declared. You should be able to take care of everything else without need for extra element or hacks, I know I can. I also know that all my sites work just fine on IE7.

No particular target: But why learn CSS properly, when you can dump DIVs all over the place and get away with it, right? That’s where all our great celebrities are setting the wrong trend, maybe it’s because they’re too busy to learn CSS properly. We’re starting to go the wrong way again… we used tables because they’re easy, now we’re using DIVs because they’re easier than learning advanced CSS and browser support.

Like Garrett I don’t use any CSS hacks, and used to use the same nested div trick as a work-around for the box-model bug. Then I noticed using a strict doctype fixes the problem (along with some other quirks), so unless I’m maintaining someone else’s code I just use strict doctypes. This seems to make it easier when you have to support the dreaded MacIE as well.

Garrett, in response to your post in the 16th, ‘We Don’t Support Your Browser,’ the problem (for GMail at least, I’m surprised by Yahoo) may be this: http://www2.writely.com/info/WritelyOverflowFAQ.htm#faq5

.”It’s not surprising that the sites I come across with custom-designed forms often have significant usability problems.”

Just to bring some light on the matter…;-)

best

Customizing the look and feel of form fields is absolutely not one of them.

I don’t know if I necessarily agree with that. I can see how flimsy code could break and therefore affect usability, but form controls such as select boxes and buttons look different from browser to browser and can seriously affect a site’s look and feel. Especially sites that have advanced designs. So if the JavaScript/CSS is done right then I don’t see how it can be a problem. By “right” I mean of course that it’s unobtrusive so that the controls work when the visitor doesn’t have either JS or CSS and also that it’s robust enough not to break outside of Firefox. An option to “turn off form control skinning” would be a plus too.

Otherwise, where do you draw the line? You might as well tell people not to use JS or CSS for anything that’s usability critical because of the chance that something might break.

Just my 2 cents…

@Ara Pehlivanian

No, we tell people by drawing the line at HTML first. You start by NOT using `strong` or `em` elements where they would be appropriate but instead introducing `span` and class=”highlight”?!
[endSarcasm]

(With all due respect, I’m refering to this page’s source)

I truly believe you should not mess with user expectations. Form widgets should look pretty much like whatever form widgets the user’s browser/os combination gives him. Scroll bars should look like the default scrollbars. I cannot believe the number of times I’ve opened a page in IE and found (more like had a hard time finding) the scroll bars so “color coordinated” with the page they were almost invisible! Some form designs have also left me wondering where and how stuff should be entered.

Good design helps the user do what it is he’s trying to do.

Now to hacks. To date, I’ve seen nothing but crying wolf or otherwise specious arguments. As long as one major(ity) browser is something like 4 years behind the rest in css support, and as long as that browser is so buggy in what it does manage to implement, there will be and must be hacks. Hacking the html is still hacking and adds needless complexity. Hacking css has safe hacks and less safe hacks. It is not bad by some simple definition. Do you use {position: relative;} so that IE will render floats with negative margins? That’s a hack. What the Sam Hill is wrong with it? Nothing. What about the Peekaboo bug? There are 4 separate fixes, only one of which requires filtration. So don’t use that one. Do you need to trigger hasLayout? We’ve been using the Holly Hack which uses the Tan Hack for filtering—OK, that’s maybe bad (but not proven to me), but Claire Campbell’s studies have given us the hasLayout tripswitch, which requires no filtering. It’s a pure-D hack, and a good one. It appears implicitly in Tony Aslett’s clearfix/easy clearing hack, and now that we’re aware of it, we can simplify his hack a bit.

As long as IE doesn’t support css to the extent that modern browsers do, and as long as we have that evil construct, hasLayout, we will be hacking.

For some reason there seems to be a movement toward filtering the hacks with conditional comments. Hell, that’s adding browser sniffing on top of hacks. Not only that, but it’s moving the hacks away from the selectors being hacked, making for two separate stylesheets to keep maintained and synchronized. Now that’s just silly.

gary

I was merely emphasizing the importance of unobtrusive methods to handle the matter as Ara suggested (read: progressive enhancement?) and the irony in giving up semantic markup for the sake of “making things pretty� as you point out in your article.

With all due respect Garrett, would it be fair for you to suggest that the same markup should be given to the traditional browser, and the RSS reader as you currently do; perhaps to further dodge a server-side complication?

I believe a balance can always be reached given the real-world requirements and cutting edge in Standards.

The only browser one needs to work around, rather than with, is Internet Explorer. For the most part, Opera, Safari, and Firefox render very similarly. Reliance on CSS hacks leads to future breakage, as with IE7—the hack is fixed, the bug your hack was wrapping is not.

For IE, conditional comments are by far the best choice. You can target any version of IE, and you can put in different workarounds for different versions. Best of all, grownup browsers like Mozilla, Safari, Opera, etc., don’t have to deal with invalid/bizarre CSS.

So why not conditional comments?

Hey Garrett,

They were so busy trying to figure out if they could, they didn’t stop to think if they should.

First off, that’s one of my all time favorite quotes. I can see the reasoning behind your point of view. I will however counter it with a quote from the grand Zeldman himself in DWWS where he says (and I’m paraphrasing big time b/c it’s been about a year since I’ve read it) that “sometimes, in the real world, you just need to get the job done”. And when working on contracts that run in the the upper six figures and the client is adamant about having skinned dropdowns and/or other “non-skinnable” elements, you do what you have to to make the client happy.

But believe me, I agree with you that it’s time well spent elsewhere and that it is error prone. It’s just that sometimes it’s a necessary evil. Plus, I’m always up to the challenge of getting difficult stuff to work.

I agree — more care and respect for the front-end architecture would be a good thing. The user’s chosen browser (or reader, or …) is a personal choice and that is something to embrace, not fight.

Form styling is interesting. I think there is room for some styling (note that the comments form on this page is styled, and I think it works well) but recognition that such styling does impact on the user interface is a key to being a better designer.

In the case of form controls, browsers do style them by default. Sometimes (often?) these styles are lifted from the underlying OS. There are also additional styles applied to some form controls by tools—like those popular browser toolbars that support autofill.

A user should know and trust the UI of their browser. If that means form controls look like the OS and some are coloured yellow because they can be autofilled, well, be wary of styling them in a manner that affects those user expectations. I’m not saying you shouldn’t style them. I’m saying you should consider this aspect when making those decisions.

Consistent styling across different browsers isn’t something users want or need. It may be something designers or clients want — and I agree that might be vital to you if they’re paying the bills :)

I read this at lunch time and it suddenly occured to me do you mean don’t style form elements at all or don’t create pointless replacement select elements.

I agree with the second idea but not the first. It’s almost like saying don’t change any of the default styles that a browser may have. Things have changed a lot since I started doing this stuff. If the car industry had done a similar thing all cars would be black.

Quoted from e-mail (sorry but it helps put my response in context):

Really, my position just boils down to the fact that there isn’t any
real value gained from replacing those form elements with JavaScript.
Even if executed perfectly and accessibly for all user agents, which
is unlikely, there still is no real benefit beyond the perceived
benefit of the design improvements. Of course, while minimal, there
is additional JavaScript overhead in doing this as well. In my
opinion, the supposed design improvements aren’t even improvements at
all. They hinder the experience because users are given something
different than what they expect.

The fact remains that users spend most of their time on other web
sites (http://www.useit.com/alertbox/20000723.html, see Rule #1), and
good usability is based on whether or not the visitor is getting what
they expected. Given that the browser-rendered drop downs and input
fields look the same across all web sites in a given user-agent,
that’s what people expect. That’s what they are comfortable using. If
the drop down on your site looks different, some group of people WILL
be confused. Changing that simply because a designer, or client, is
obsessed with aesthetics is ignoring the much more important aspects
of the experience. In my opinion, this is just as bad as making a web
site purple because that’s the CEO’s daughter’s favorite color.
There’s just not a good reason to do it.

It’s really about using the right tool for the right job and not using
a chainsaw when a pair of scissors does the job just fine.
Browser-based drop downs are easier to code, more reliable, more
accessible, and simply better. To say that aesthetics alone is more
important than all of those factors would be a hard argument to
support.

I concede, you’re right. My stubborn side wants to push the idea that re-working controls in JavaScript to make them look prettier is a valid enough reason but in all fairness, the risks and time spent are not worth the robustness of standard controls as well as keeping the user experience consistent with what visitors expect from site to site.

I’ve written this article which might interest you: Where are my Web Standards It highlights some of the issues regarding Web developers and their real-world projects.