Re: @media and browsers conditional statments

On Aug 12, 2008, at 7:16 AM, Tab Atkins Jr. wrote:

> On Tue, Aug 12, 2008 at 8:34 AM, François REMY <fremycompany_pub@yahoo.fr 
> > wrote:
> And stop consider that hacking is for IE only. It's false. Other  
> browsers have
> also some inconsitences. Not as much as in IE5/6/7 but they exists,  
> you can
> trust me. And when you make your sites "by hand", you encounter  
> theses very
> often.
>
> I think you're overstating your case at this point.  I code all of  
> my sites by hand, and have to deal with the marketing department  
> demanding something as close to the reference mockup as possible  
> while maintaining a layout that is flexible in font-size, screen- 
> size, etc.  Yes, there are inconsistencies, but they're very, very  
> minor outside of IE6/7.  As well, the inconsistencies become less  
> and less noticeable with every browser release (this applies to IE8  
> as well, which is shaping up to be a halfway-decent browser, though  
> it's likely it'll still lag behind the others in the newer CSS  
> features).  I think the only noticeable problem I've run into was  
> FF2's lack of inline-block, which I've had to hack around with some  
> nonsemantic markup, but even that's clearing up now.  If I had  
> simple feature-detection (which I'm not opposed to), I'd've been  
> able to get around that without much difficulty.
>
> ~TJ

Its not just bugs, but also differences in interpretation, level of  
support, and how things work in areas that are not defined by the  
spec. The specs are full of places where it says that its up to the UA  
to decide.

Things like how high or wide a text input will be can have a large  
impact on page design when you are trying to have something like that  
in a very limited space, but there are still inconsistencies here. Do  
text inputs accept border width and padding and line-height and how  
does that affect width and height? Inconsistent. What about these  
properties on a SELECT and its menu and its OPTGROUPs? And does the  
pop-up menu of a SELECT get clipped by the SELECT's width like in IE?  
Does any part of its visible or clickable get clipped by its  
overflow:hidden parent's width? Some of these things may be answered  
by the spec without guaranteeing that they are implemented in the same  
way. What replaced elements will have a proper "outline" property?  
What are all the values of "appearance" and which elements can accept  
them? What about all the other -webkit-, -moz-, -o-, etc. prefixed  
properties? Sometimes it is useful to use them, even knowing they may  
change, but it may require differences in the other properties for the  
other UAs. And don't even get me started on how different things can  
be when you print a page from various browsers today.

I know this is the point where David Woolley will say that CSS is not  
PDF, and that is fine for him, but he is not a designer and doesn't  
care about the same sort of things we do. Sometimes it is the  
subtleties that make a difference, and you want certain elements to  
not look ugly or unbalanced, or you want to do whatever you can to  
present an elegant and consistent user interface. In such cases it is  
very useful to be able to tweak the presentation to accommodate the  
differences between major UAs. And as long as CSS continues to  
progress, there will always be differences to work out. We will never  
be at some utopian place where all browsers (or even all but IE)  
render everything in the exact same way and support all the same CSS.