This works in Chrome, Safari and Firefox, but not in IE9
style='height:100'
IE9 just ignores it. But this DOES work:
style='height:100px'
Unfortunately, i really truly do not want to have to go around adding a "px" to all my values. It makes doing any sort of manipulation (for example, multiplying the width by two, adding 100 to it, etc.) incredibly troublesome. Is this expected behaviour, and is there any special flag somewhere i can set to get IE9 to accept the first example?
(i know inline styles are generally considered incredibly bad, but i have reason to use them anyway in some special cases)
style='height:100' may work in some tolerant browsers, but is actually invalid CSS, so IE has every right to refuse to parse those.
That (width:100) doesn't actually work in any of those browsers due to being invalid CSS:
http://jsbin.com/ovewus
<div style="width:100;background:red">test</div>
..unless your page is in Quirks Mode due to not having a valid doctype, like this:
http://jsbin.com/ovewus/2 - width:100
works!
Intentionally writing pages for Quirks Mode is doubly incredibly bad, just don't do it.
I don't see "naked" numbers here :) http://www.w3.org/TR/CSS21/visudet.html#the-width-property as 100 can be px,em..
" Specifies the width of the content area using a length unit."
As Gruikya said, it is invalid CSS to have non-unit numbers (unless the number is 0, or the style is line-height), so I would definitely recommend adding the correct units. If you need to do mathematical operations on those units, (I presume in Javascript) then you should be using parseInt or parseFloat anyway, and these will happily ignore the trailing units.
You shouldn't define any size without actually defining the unit. You're making browsers guess what unit you want to use, because you're not telling them.
Depending on what CSS standard is followed by the browser, different browsers may handle it differently.
The CSS2 specification defines rules without units should be ignored. It also mention this behavior may (theoretically) change in future specification.
Related
There are a number of asterisk (*) types as you can see here:
http://www.eki.ee/letter/chardata.cgi?search=asterisk
Even now, we can see that some of these characters like the one with the code: "204E" also known as "low asterisk" is not rendered in HTML (at least while using Chrome anyway).
You can see the character here:
⁎ -> ⁎
Other similar types work however:
✢ -> ✢
✣ -> ✣
✤ -> ✤
Of course out of all the possible types, the authors of my input data have chosen ⁎ to work with.
It makes me think it should be somewhat general, because I saw solutions where a tiny image was used instead of this character in the entire HTML document. Needless to say I do not like that approach even a bit.
Is there a way to make this work in HTML? Is this possibly a browser specific issue?
UPDATE:
Internet Explorer 9 and Google Chrome also fail to render this special character.
Firefox and Chromium (Ubuntu) seem to be able to render it.
Please note, that I would like to find a general solution if possible.
My HTML code:
<html>
it works in chromium though ⁎
</html>
I use Chromium in Ubuntu, and it works fine in it.
and here goes screen shot of IE, in case you want to see it.
Furthermore: for those looking for a middle asterisk ∗ -> ∗
This primarily depends on the fonts installed in the user’s system, not on browser (though some browsers, most notably IE, might be unable to utilize all the fonts in the system, as they should). Regarding e.g. U+204E, font support is relatively limited: no font shipped with Windows contains it, whereas Linux systems probably have some font that contains it.
Using #font-face for some suitable free font, you could make the character display in most computers (excluding basically just those that have font loading disabled). See my Guide to using special characters in HTML.
In this case, that would probably be overkill, if you just need e.g. a low asterisk. A normal asterisk, in a lowered position, should be sufficient – at least compared with the overall typographic quality of HTML documents. Example:
<style>
.low {
position: relative;
top: 0.55ex;
}
</style>
Compare: *⁎<span class=low>*</span>
(Using relative positioning is safer than using vertical-align, directly or via the sub element, since vertical-align usually messes up line spacing.)
Some strange bug I came accross today when creating a generic button class to style everything from divs to inputs. It seems that most browsers use a different box model when it comes down to input[type=submit].
Most modern browsers (ie9+, ff, chrome, etc) use the content-box box model for all inputs except submit which uses border-box if im not mistaken.
Basically, if I set a height of 100 and padding of 10 all around, the height of all inputs except submit would be 120 where as the height of submit would be 100.
This is easily fixed using box-sizing and its browser prefixes. But my problem is with IE6/7 which do the same thing but do not support box-sizing...
so now all my inputs display full height except for submit which is cut in half. What options do i have to force content-box or another fix apart from conditional comments?
IE's old "broken" box model is essentially content-box. In IE>5 the document needs to be in quirks mode for IE to use it. You can trigger quirks mode by doing one of the following (according to wikipedia):
When the document type declaration is absent or incomplete;
When an HTML 3 or earlier document is encountered
When an HTML 4.0 Transitional or Frameset document type declaration is used and a
system identifier (URI) is not present
When an SGML comment or other
unrecognized content appears before the document type declaration
When there are errors anywhere in the document
Now of course, this probably makes more trouble than it's worth because it would make everything use the IE box model (content-box). I could see this being useful, but if your layout wasn't built this way, it's probably too much work to go back and change it.
I did some searching around and didn't find anything that would enable the old box model on certain elements, and not others.
Having dealt with IE6/7 in the past, there's really no way to get around it's buggy behavior without using something like conditional comments or css hacks. It's rendering engine is just fundamentally broken compared to other browsers. Trying to get it to behave without any hacks is just asking for headaches.
The only other thing I can think of is to surround each form element with a span or div, and use them to help size your form elements. This also sucks, but it has the advantage of at least working in every browser.
I just uncovered this little gem of an IE9 bug. It seems that IE9 does not recognize a space preceding a period as a breaking point. As in a list of domain or file extensions. Open the following fiddle in IE9.
http://jsfiddle.net/cssguru/nNnzM/1/
I tried using escape characters, but it didn't help. Any suggestions on a workaround?
It is an annoying feature, but it is probably intentional and not regarded as a bug by the vendor. Instead, it is regarded as implementing Unicode line breaking rules (which are partly rather odd). According to those rules, the period (or FULL STOP as they call it) has line breaking class IS, infix numeric separator, and “When not used in a numeric context, infix separators are sentence-ending punctuation. Therefore they always prevent breaks before.”
To deal with such issues, it is probably best nowadays to insert U+200B ZERO WIDTH SPACE between a normal space and a period, e.g.
.web .shop .blog .nyc ...
U+200B is a control character that allows line breaks in a place where they would not otherwise be allowed.
Old IE versions (IE 6) may have difficulties with this, displaying a symbol of unrepresentable character in place of U+200B. An alternative method, the <wbr> tag, would not have this problem, but it seems that IE 8 and newer often fail to honor this age-old tag (perhaps because it never made its way to any standard, despite its usefulness).
I added a declaration for word-wrap in this update to your Fiddle, and that seems to have resolved the issue.
Generally, what's the best way to tackle a layout bug in IE6? What are the most common bugs or problems that one should look for when trying to figure out why your page suddenly looks like a monkey coded it?
First Things First
Get yourself the Internet Explorer Developer Toolbar. It's a life saver and works great with IE6 and/or IE7. It's no replacement for Web Developer Toolbar or Firebug for Firefox, but it's better than nothing.
Know Thy Enemy
Read up on the quirks of IE — particularly hasLayout and overflow and the like. There are also many CSS niceties that you'll have to either do without or find alternatives. Look into how many of the popular JavaScript toolkits/frameworks/libraries get around different issues.
Rome Wasn't Built in a Day
The more you have to work with it, the more you'll remember off hand and won't have to lookup as often. There's just no replacement for experience in this. As several have pointed out, though, there are great resources out there on the net. Position Is Everything is certainly up there.
http://www.positioniseverything.net/ will certainly address your problem.
It provides comprehensive and in-depth descriptions of browser bugs along with options to work around them. A must read, in my opinion,
One good way to start learning about how IE happens to be mangling the page is to turn on red borders on different elements with CSS (border: 1px solid red;). This will immediately tell you whether it's a margin problem or a padding problem, how wide the element really is, etc.
The box model is usually the culprit. Basically what this means is that any div you are trying to position and use unsupported CSS with will cause this problem.
You may find it happens if you are using min-{width,height} or max-{width,height}.
this provides a great reference for checking compadibility with different versions.
http://www.aptana.com/reference/html/api/CSS.index.html
Noticed that Marc's post is at a -2 =D. He's only saying "resort to tables" even though they blow, because in sucky browsers like IE6, some of the broken CSS commands work in tables only (who know's why... dam you Bill Gates!!!). Here's a good reference to see what works and doesn't work as far as CSS goes. http://www.quirksmode.org/css/contents.html . It's a great reference to check on what cool effects work/don't work with various, widely used browsers. Also, always have a go-to plan for users who browse with IE6 (even though it's just about as old as mechanical dirt) as many businesses still use older browsers (including non-profits/3rd world countries etc.) So by all means, create the bugged out drop-down menu that looks WAY better than a standard horizontal menu, but create a secondary one specifically for IE6 that becomes the default when the page receives a request from an IE6 browser.
how do you define layout bug? the most frustrating layout implementation (i don't know if this should be defined as bug) in IE is we need to always specify style="display:inline" in the HTML <form> tag so that a blank line won't appear to disturb the form layout.
This question I believe has far too much scope.
Validate your code, and if pain persists, well, good luck.
The only real solutions, as with any other ballpark bug type are to google for a solution, or ask somebody who knows, ( ie: give the exact problem to us here at stackoverflow ).
You can use the IE Dev toolbar to glean an Idea, but many of the bugs are random, inexplicable, and esoteric. IE: the guillotine bug, the random item duplication bug, etc etc, the list goes on, and you can spend hours literally goofing with stupid variables everywhere and achieve nothing.
I have a simple strategy that works every time.
First, I develop the site using commonly accepted CSS to look good in Safari and Firefox 3. See w3schools.com for details on browser support.
Then, I go into IE6 and IE7 and alter the CSS using conditional includes.
This is hack free and lets you handle different browsers (IE6 and IE7 have separate issues).
Most of the issues you'll find come from unsupported features in IE (like min-width), errors in the box model (IE adds unseen extra padding (3px) to some boxes), or positioning issues. Go for those first as they are often the issue.
A common problem is padding not getting added to the width of a block element. So for layout div's, avoid using padding and instead use elements within them to define the padding.
I use Rafel Lima's Browser Selector when I need to tweak differences between IE/Standards browsers. It greatly reduces using "hacks" in your HTML to solve common problems.
You can target CSS statements for different browsers, or even different versions of browsers (Hello IE 6). It's very simple to implement, but requires the user has JavaScript turned on (most do).
.thing { ....}
.ie .thing { ....}
.ie6 .thing { ....}
We had a floating div issue that was only evident in a particular version of IE6. It was fixed by downloading the latest service pack.
In theory, use CSS compatible with IE6 layout bugs, utilise only well known workarounds (css and html filters) and code for them in a way that wont break forward compatibility, test for quirks/strict mode.
In reality, resort to tables.
Do you know of any differences in handling HTML tags/properties in different browsers? For example, I once saw a page with a input tag with a maxlength field set to "2o". Firefox and Opera ignore the "o", and set the max length to 2, while Internet Explorer ignores the field altogether. Do you know of any more?
(Note: seeing as this will probably be a list, it would be great if the general name of the difference was in bold text, like: Different erratic value handling in tag properties)
Bug Lists
Web developers have already compiled some pretty comprehensive lists; I think it's better to compile a list of resources than to duplicate those lists.
http://www.positioniseverything.net/
http://www.richinstyle.com/bugs/table.html
http://www.quirksmode.org/ (as mentioned by Kristopher Johnson)
Javascript
I agree with Craig - it's best to program Javascript using a library that handles differences between browsers (as well as simplify things like namespacing, AJAX event handling, and context). Here's the jump to Craig's answer (on this page).
CSS Resets
CSS Resets can really simplify web development. They override settings which vary slightly between browsers to give you a more common starting point. I like Yahoo's YUI Reset CSS.
Check out http://www.quirksmode.org/
If you are programming in javascript the best advice I can give is to use a javascript library instead of trying to roll your own. The libraries are well tested, and the corner cases are more likely to have been encountered.
Scriptalicious - http://script.aculo.us/
jQuery - http://jquery.com/
Microsoft AJAX - http://www.asp.net/ajax/
Dojo - http://dojotoolkit.org/
Prototype - http://www.prototypejs.org/
YUI - http://developer.yahoo.com/yui/
Do you know of any differences in handling HTML tags/properties in different browsers
Is this question asking for information on all differences, including DOM and CSS? Bit of a big topic. I thought the OP was asking about HTML behaviour specifically, not all this other stuff...
The one that really annoys me is IE's broken document.getElementById javascript function - in most browsers this will give you something that has the id you specify, IE is happy to give you something that has the value in the name attribute, even if there is something later in the document with the id you asked for.
I once saw a page with a input tag
with a maxlength field set to "2o".
In this specific case, you're talking about invalid code. The maxlength attribute can't contain letters, only numbers.
What browsers do with invalid code varies a great deal, as you can see for yourself.
If you're really asking "what do all the different browsers do when faced with HTML code that, for any one of an infinite number of reasons, is broken?", that way lies madness.
We can reduce the problem space a great deal by using valid code.
So, use valid HTML. Then you are left with two main problem areas:
browser bugs -- how the browser follows the HTML standard and what it does wrong
differences in browser defaults, like the amount of padding/margin it gives to the body
Inconsistent parsing of XHTML in HTML mode
HTML parsers are not designed to handle XML.
If an XHTML document is served as "text/html“ and the compatibilities guidelines are not followed you can get unexpected results.
Empty tags is one possible source of problems. <tag/> and <tag></tag> are equivalent in XML. However the HTML parser can interpret them in two ways.
For instance Opera and IE treat <br></br> as two <br> but Firefox and WebKit treat <br></br> as one <br>.