Hey everyone, Hope your all well. Ok so ive pretty much covered CSS.. but now getting onto the "joys" of browsers. Can anyone recommend a site that covers css browser issues/bugs? I have done a few searches but the majority of the results are links to forum threads with people displaying their "love" for ie Thanks in advance, _Super_SambrooK_
http://www.quirksmode.org/ is pretty good. The "browser compatibility tables" : http://www.quirksmode.org/compatibility.html can quickly let you know what code is safe to use, and what's just not going to fly. In general I would say that includes almost ALL of HTML5 and CSS3, there is no point in even TRYING to use those until Microsoft is on-board for it. We can bitch and moan, we can write fat bloated workarounds, we can write the code twice - once for modern, once for legacy - or we can just accept what is real world deployable and get down to the matter of building a page with what WORKS. That said, usually there are only a handful of major issues you need to be aware of. Off the top of my head here's the list of what I encounter the most doing layouts. TRIDENT/INTERNET EXPLODER Haslayout - IE will often not calculate the position of elements that change size or reflow after the page loads properly unless their 'parent' element 'haslayout' - or uses properties like width, height or zoom that make IE double-check it's calculations. http://www.satzansatz.de/cssd/onhavinglayout.html will tell you more. Some unique errors like the '3 pixel jog' fall under haslayout's umbrella for fixes, so if an element is not working right compared to , add zoom:1; to it and/or it's parent and see if that fixes it. A number of things like wrapping of floats can also be tripped in IE using haslayout. Doubled Margins - When floating elements sometimes IE will double any margins around it. The fix to this is kind of wierd, but it works. Floats are INHERENTLY display:block, and nothing you set display to will change that... however for some weird reason setting display:inline; on a float makes IE render the margins normally. This is safe to send to all browsers because as I just said, it's ignored by standards compliant browsers. Double Render/Disappearing Content This one can drive you NUTTERS, and it's cause is so counter-intuitive most people wouldn't even THINK to test for it... What it does is exactly what the title says - entire sections of your content will render twice, or just flat out disappear. The cause is the presence of comments between floats. I kid you not, COMMENTS in the HTML. Best way to avoid that is a bit of 'thought' in regards to your commenting. First, don't waste time declaring the 'start' of a section with a comment, and instead give that section a meaningful classname or ID. You'll often see code like: <!-- start content --> <div class="con"> Code (markup): No shit, opening a DIV is the start of a section? CON is a little vague, we could skip that down to a simple <div class="content"> Code (markup): - that's one useless comment down, but what about the end. Same thing, where people will do </div> <!-- end content --> Code (markup): That's another 'no shit' moment - </div> means we're ending a section, so you don't need to say end... Though it IS nice to know WHAT we are closing. Solution? Remember how above I said it occurs when comments are BETWEEN floats? Move the comment INSIDE the DIV. Eliminates even the CHANCE of that error popping up. <!-- .content --></div> Code (markup): Notice I also use a period to indicate it's a class like you would in the CSS. Little bit of extra information, and makes for more useful code formatting. My 'good code bad code' post may also be of use to you in this regard... there's a link in there to a really good article on IBM's linux developer site about writing clear, concise code. Missing CSS2 - There are a handful of CSS2 properties that IE lacked prior to version 7. It is still a wee bit too early to be dismissing IE6 outright, so it's important to know how to implement these missing bits. First, min- and max- properties. IE prior to v7 doesn't know what these are! I'm not aware of any layouts that actually warrant the use of max-height, so we can skip that one, but min-height can be damned useful - see 100% min-height layouts. Thankfully IE6 incorrectly treats 100% height as min-height on all elements if overflow is not set to hidden or auto... Problem is that 100% height can screw up other browsers, so we need to hide it from other browsers. The method I prefer for this is the "* html" hack. It puts our extra CSS into the same file as the rest, and prevents us from resorting to any of that IE conditional bullshit in the markup. When the choice is between bloating out the CSS or bloating out the markup, choose the CSS - at least it can be cached across pages. So for example on a 100% min-height design you would have (this is from one of my sites): html, body { position:relative; /* fix some opera quirks */ height:100%; } #pageWrapper { overflow:hidden; /* wrap floats */ min-height:100%; } * html #pageWrapper { /* IE6/earlier has no min-height, but will incorrectly treat height as such when overflow is visible - thankfully the height trips haslayout, so floats will still be wrapped */ overflow:visible; height:100%; } Code (markup): Min-width and max-width also require workarounds for IE6/earlier. The best solution is to use a scripted 'expression' - IE allows you to use javascript inside your CSS thus: #container { min-width:752px; // 800 - 32 scrollbar - 16 padding max-width:968px // 1024 - 32 scrollbar - 16 padding margin:0 auto; // center } * html #container { /* if .js is off, set fixed width */ width:752px; /* otherwise use expression for min-width */ width:expression( (document.body.clientWidth>1024) ? "968px" : ((document.body.clientWidth>800) ? "auto" : "752px") ); } Code (markup): The first width declaration we have hidden in our * html hack is for if scripting is disabled, fix the width at the smallest size. From there we just test the width of the browser rendering area and send the appropriate value. The only other major glaring omission in IE6 is the ability to 'hover' on any element, the cornerstone of CSS menus. You WILL have to use javascript to get around that... Most people will use scripts like suckerfish to do it, I dislike it since it adds a wee bit too much to the CSS and in the markup - so I prefer to use peterned's 'whatever:hover' http://www.xs4all.nl/~peterned/csshover.html You add * html body {behaviorcsshover3.htc);} To your document, put the csshover3.htc in the same directory as the CSS, end of problem. A handful of improperly configured servers will choke on .htc files with the wrong mime type - my answer to that is NOT to use another technique but to say "Hey dumbass, fix your server"... though in most cases a simple entry in a .htaccess file can be used to fix it. All of the above fixes are NOT valid CSS2 or 3 - but that's often the reality of backwards supporting older browsers. While I see ZERO EXCUSE for invalid markup, I am a billion times more lenient when it comes to the realities of deploying CSS. Broken box model - In 'quirks mode' or versions of IE prior to version 6, IE puts padding and borders INSIDE any width or height declarations instead of outside it. In IE6 'standards mode' or any modern browser if you declared "border:2px; padding:5px; width:300px;" if you measured outside the borders edge to edge you'd get 314px... With the old broken IE box model the same box would render as 300px - the content area pushed down to only 286 pixels wide. Solution to this? Use a doctype, with no XML prolog to put IE6/newer into standards mode. If you require supporting IE 5.5 for god knows what reason, then you have to make certain you never declare borders and padding at the same time you declare widths or heights... Which is actually easier than it sounds - but really who cares about IE 5.x anymore? If you are willing to kick IE 5.x to the curb, and use a doctype without a XML prolog, this is a non-issue. display:inline-block - In a number of ways IE supported inline block for a decade before anything from netscape or mozilla did... on the other hand IE never actually supported inline-block, it just incorrectly treats ALL display:inline elements as such, allowing you to set widths and heights when by the specification you aren't supposed to be able to. What this means is that prior to IE8, you can only use inline-block on inline-level elements in IE, though you can TRICK other elements into working by setting display:inline on them. Growing LI's on hover - This one is kind of tricky, but generally I've found the best solution is to just set the LI's to display:inline and don't even TRY to style them, then set display:block on an element inside it (like an anchor) to which you apply your styling. That's pretty much it though for IE. I rarely encounter any problems apart from those I just listed. Now I'm about to commit a major bit of heresy. GECKO/FIREFOX The poster child of the web community is not immune to glitches, glaring specification omissions, and similar need for workarounds. Some of these even look familiar. display:inline-block - until VERY recently (FF 3.0) Gecko based browsers had ZERO support for the inline-block declaration, but instead had TWO -moz properties you had to call to implement the same functionality. With FF3 the support was still kind of buggy, though 3.5 squashed most of the remaining issues. Still, since a lot of 'forked' versions like K-Meleon, Iceweasel, Flock, etc are often built on older versions of gecko and since many people still refuse to update, I still declare the two -moz whenever I want to use inline-block thus: display:-moz-inline-block; display:-moz-inline-box; display:inline-block; Code (markup): Wee bit of extra code, but at least you won't have some jackass still running Firefox 1.8 on AIX complaining about the site being broken. COL and COLGROUPS - Ah, the legendary Bugzilla 915. Rapidly approaching the eleventh anniversary for this bug (if we haven't already). This is a gaping hole in the table implementation in firefox that can make working with actual tabular data a royal pain in the ass and take two or three times as much code as neccessary. Basically when you set properties on a COL tag like font, color, align - it is supposed to be inherited down the column to all the TH and TD. Unfortunately Gecko pretty much ignores this part of the specification - you can kind-of work around this using nth-child, but IE doesn't recognize that CSS3 property, so that's a no-go unless you want to write everything TWICE - at which point you may as well just say screw it and slap classes on every damned TH and TD - it's LESS WORK! It's actually one of my biggest complaints about Gecko is the DECADE OLD bugs that nobody is even working on, while they have people slaving away on HTML5/CSS3 bullshit. Rounding 'errors' - Most every other browser engine rounds off numbers for rendering, then uses those rounded off values for calculating the position of elements that follow. Gecko keeps all fractional numbers as fractions - leading to rounding off issues making elements not only render diffently between Gecko and EVERYBODY else, but even with ITSELF. It is entirely possible in Firefox to make a DIV 3em tall floated left, then put three 1EM tall DIV next to it, and not have them actually render the same HEIGHT! Serious holy **** territory. This is why when making a footer for a 100% min-height layout if you don't want scrollbars when the page is too tall, you have to declare it's height in pixels, since depending on the total screen-height the negative top-margin or the definition of 'bottom' could end up not the same as the height. %/EM and even PT cannot be relied upon for footers in 100% min-height because of this! 1 pixel position/background jog - This is actually a continuation of the previous error. As I just mentioned you could end up with a extra pixel on the vertical - on the horizontal it even effects backgrounds, which can end up one pixel off from what 'center' or 'margin:0 auto;' means depending on the screen width! In theory adding half a pixel of padding to the right side of the screen fixes this for body and a 'wrapper' type element, but it does little for dynamic elements inside the page. Where it can REALLY screw you is in the design of 'sliding doors' type layouts when making them transparency friendly. The best bet in this case is to make your smaller element overlap the larger area by 2px, giving you a bit of 'play' for if FF decides to add that little unwanted 'gap'. Position:absolute, top and display:inline; - the default position of an absolute element if you do not declare 'top' in Firefox is usually incorrect, being as much as twice the line-height off. The solution is to always declare 'top' when using position:absolute inside an inline or inline-block element... BUT, well... Let's look at another browser. PRESTO/OPERA Position:absolute, top and display:inline; - setting top can often make absolute positioned elements fail to erase properly when unhovered. This commonly a problem with certain tooltip type issues. The solution is to use margin instead of top to position it, not declaring top - the problem with the solution is it breaks gecko/FF... This is one of the few cases where I would actually use the "html:not([lang*=""])" hack to target JUST gecko for the "top:0;" declaration. 100% min-height calculation failure - here's a gem. Just declaring "height:100%" on HTML and BODY still won't make a 100% min-height child element stretch to full height in Opera. It just refuses to see it. Solution? Declare position:relative on both HTML and BODY. Position:relative items are ALWAYS supposed to allow heights inside them to base off of the parent. Browser support for that detail of the specification is sketchy, but it fixes opera without hurting any other browsers, so good enough. WEBKIT/KHTML/SAFARI/CHROME/KONQUEROR I rarely have problems with these, but one thing sticks out: word-spacing to collapse inline-blocks - Inline-block and inline-level elements are SUPPOSED to have white-space between them. You have whitespace between the elements, one 'space' should be inserted between them based on word-spacing. When building inline-block lists so you can center a menu this can be a real annoyance. The old school solution to get rid of that space was to either strip all the white-space from the menu in the markup, or put the white space inside the tag elements themselves - like before the closing > - so it didn't effect the layout. Turns out in every browser EXCEPT Webkit/KHTML based ones a large negative word-spacing will collapse the white-space, without collapsing the actual elements over each-other (unlike cdata which will collapse). The workaround for Webkits shortcomings in this regard are to either use the HTML formatting tricks, or use letter-spacing instead. Webkit INCORRECTLY obeys letter-spacing between elements allowing you to collapse them... the problem is it's an EXACT amount, so you will have to play with exactly how many pixels or EM to collapse it (usually it's around 0.4em, +/- 1px). Thankfully letter-spacing is ignored in every other browser. You can see this technique in action on one of my dropdown menu pages, which is special because it's dynamically centered without resorting to a table. http://battletech.hopto.org/html_tutorials/cssMenu/template.html That's about all I can think of for now... Really if you keep the above in mind, write clean semantic minimalist markup with separation of presentation from content, you shouldn't encounter anywhere near as many layout problems as the 'pioneers' in the industry did while figuring all of this out - meaning you can skip right past bullshit like 'clearfix', IE conditionals in the markup, and other outdated nonsense. Good luck, hope this helps. Any questions fire away.
Good lord. There are not only bugs, but also... not features, but I'd call them characteristics. Konqueror has lots of these, which I call bugs and hate with a passion. What a shit browser (it wouldn't be if they updated it as much as the webkit folks did). A-fucking-men. People would rather spend time writing extensions and stuff, okay I don't blame them, those are more fun, but this is what happens in open source if everything is volunteer, who do you send down to the basement tunnels to fight the zombies and things that go bump in the night??? After learning C or whatever to fix trunk bugs, what, are you given an old lantern and told "if the light goes out, you might get eaten by a grue"? Depends. I just saw these nifty (if bloated) buttons using the alpha characteristics of rgb in css. Looks pretty cool— in Safari and Chrome. Looks mostly good in FF (can't do text-shadow yet). Looks square but shadowed and alpha'd in Opera. But good ol IE, well, it just looks like a regular button without anything special. Still hovers, still works, fine. So you can use some things if you want to play, so long as what you see in the crap browsers is stil acceptable from a functional standpoint. IE Haslayout link: http://www.satzansatz.de/cssd/onhavinglayout.html ------ Opera: here's something I've been hitting recently: Opera has limits on screen size, at least when it comes to margins and the coords of abso-po'd elements. The magic limit seems to be somewhere around 32000px or whatever. You'll see this if you have something abso-po'd (at least in a 100% height page) -9999em to the top. Which was something I used to get around a stupid Konq bug (pulling something insanely to the left to move it offscreen would actually wrap it in Konq, making the page a bazillion units wwide, and the element you were trying to hide ends up appearing on the right of the page). Konq may also have a limit there. You'll also see this if you try a negative-right-margin on floated overflow containers of undefined-length children. Opera will let you go just so far with your negative right margin, and beyond that will wrap the items in the overflow box. http://stommepoes.nl/erikgallery.html Opera also sometimes will not let you style hover/focus styles on VERY CLICKABLE ELEMENTS if you dick with them. For instance, styling a submit to look like a link, at least in Opera9.5 (haven't checked back cause I don't care) leads to total ignore of the cursor (doesn't change), hover and focus styles. The thing is still clickable of course, but the user gets no feedback that it is. --- Firefox until recently could not deal with the soft hyphen (&# 173 at all, and the very first instance of FF3 couldn't deal with it in a table or a display: table element. This is finally fixed for current FF3. Gosh, even IE5.5 could do soft hyphen. Firefox has never been able to let developers position a legend element... and in fact, although there's a Bugzilla on it, the fine folks at Mozilla don't even really believe it's a bug... even though they're the only browser in the universe with a problem with it. Use spans inside your legends. Worse: I was trying to do image replacement for FF2, but on an element who was inline-block instead of block. So of course that didn't work, I needed to either use -moz-inline-block or -moz-inline-box. One of them (forget which) would not let me keep height and width set, and acted too "inline". However it did let me set top and left for the span holding the image (image simply couldn't cover the text due to its parent's height and width collapsing). The other one (box I'm pretty sure) let me keep the blocky dimensions of the element, but could no longer do top and left correctly. The span holding the image could suddenly only see the body/viewport as its nearest positioned ancestor. Bleh. I really ought to start writing down all the garbage I see coming out of Konqueror just so when I feel like bitching about it, I can prove/show it. Usually I just go, oh, it's Doing It Wrong, oh well it's Konqueror, thank god nobody but a few Linux nuts use it (it's damn fast and has some good support for CSS3 stuff, but I swear, I want to take a large wrench to it and knock its head off). Of course there's no reasonable way to hack for it, and why waste the time and code? Saffy Chrome love, for some reason, to shrink fonts a bit and position everyone higher than every other browser. I haven't found a hack or a cause, so I just live with things like buttons sitting higher in SaffyChrome. SaffyChrome have issues with rtl pages. Saffy can't use the correct direction for select drop-downs, and cannot properly use text-align in some elements on pages you are trying to do rtl in. Major f*cking bug in my opinion. Epiphany, I dunno about anyone else, but it doesn't seem to understand the whole idea behind calculating text size. Text in buttons are always twice as large as in "normal" text. em-widthd boxes are strange, incorrect widths in Epiphany. Thankfully they are in the process of moving from the Gecko engine to the webkit engine. I will be the first to download a stable webkit version of Epiphany. Another link: http://www.positioniseverything.net/explorer.html and brunildo's tests... http://www.brunildo.org/test/index.html Those help. and... learning terminology of bugs will help immensely when trying to use The Googles.
Ah, I just today ran into another one... it says "resolved fixed" at the top of the bug report but this either isn't true, or is only true of Firefox 3.5 (which I don't have a .deb of yet): You can't set min-height on fieldsets in Gecko browsers. At least as of Firefix 3.0.12, I'm downloading 3.5.1 for Winblows right now... Edit yes, fixed in 3.5.1, which is not yet available for all OSes. If you wait a bit you can possibly assume all FF users are upgraded, though I've heard Open Solaris ships with FF2 still :/