I have a list of 3 block elements which should stack regularly. The second element in the stack is a box element, for which I used the
display: -moz-box;
-moz-box-orient: horizontal;
The issue is in this box element, as it adds a weird unwanted margin on top of itself. You can check it out at the following link http://jsfiddle.net/frapontillo/ghA5X/.
Correct behavior in Chrome:
Wrong behavior in Firefox/Aurora:
What can cause this? Chrome behaves fine with it, while Firefox (release channel) and Aurora have this issue.
What causes this, at least in part, that -moz-box and -webkit-box mean totally different things and have totally different behavior. The former is a XUL box, with behavior dating back over 10 years. The latter is an implementation of an early CSS flexbox draft from several years ago.
I recommend not using these at all if you can avoid it, since neither one matches the current flexbox draft.
Related
With the Chrome 87 update, I started getting user-submitted bug reports because some of the fieldsets on a form started to overflow overtop of the content below it.
Here is a fiddle that shows the issue in its most reduced form:
http://jsfiddle.net/phanbu/69v1xa5m/21/
Even though the .box has
.box {
// ...
overflow-y: auto;
}
The contents overflow the container down the page. The funny thing is that changing the .box from a <fieldset> to a <div> makes it overflow in the expected way:
https://jsfiddle.net/phanbu/6Lc4wrma/5/
Because this happens in Chromium, the updated version of Edge behaves in the same way. Is this a Chromium bug, or is there a special thing about <fieldset> elements that I'm misunderstanding?
Update:
Based on the comments below, I've decided to set an absolute height on those <fieldset>s. This means that when there are one or two checkboxes, there will be extra empty space in the element.
I could have converted them into <div>s for now. But that would mean more changes in more places, and I want it to be as easy to change back as it can be.
I have a textarea within a parent div. The parent div has 'white-space: nowrap'. Should the textarea be inheriting the 'white-space: nowrap'? In IE11 the textarea inherits the 'nowrap'. Chrome ignores the inherited 'nowrap' and instead uses 'white-space: pre-wrap' from the user agent stylesheet. I know I can fix this by explicitly specifying the textarea's white-space property. Should I have to set the whitespace of the textarea explicitly, or is this an IE11 bug?
The following JSFiddle demonstrates the issue. (Open it in IE11 and Chrome and note the difference).
http://jsfiddle.net/sTAB3/1/
Here is the code in the JSFiddle:
.a {
white-space: nowrap;
}
<div class="a">
<textarea id="log" rows="20" cols="50">If I may... Um, I'll tell you the problem with the scientific power that you're using here, it didn't require any discipline to attain it. You read what others had done and you took the next step. You didn't earn the knowledge for yourselves, so you don't take any responsibility for it. You stood on the shoulders of geniuses to accomplish something as fast as you could, and before you even knew what you had, you patented it, and packaged it, and slapped it on a plastic lunchbox, and now you're selling it</textarea>
</div>
This appears to be an IE 11 bug that allows the white-space property of a parent element to be inherited by a child textarea. This should be considered as unexpected behaviour.
I would apply white-space: pre-wrap to the textarea and treat it as an IE 11 bugfix.
I cannot find an official bug report (sources welcomed), but below are two examples of problems arising from this bug.
Example 1
Example source
From the link:
Ticket description textarea doesn't wrap on whitespace in IE11
Example 2
Example source
Internet Explorer 11 word wrap is not working
It seems that word wrapping no longer works for textarea elements in IE 11. In IE 10 and earlier, FF, Safari, and Chrome word wrapping works as expected.
My goal is to create an element with hidden overflow and an ellipsis, except I want the characters on the LEFT side to be hidden and the ellipsis also to be on the left. This works for most browsers:
CSS:
#mydiv {
overflow:hidden;
white-space:nowrap;
text-overflow:ellipsis;
direction:rtl;
}
HTML:
<div id="mydiv">foobar foobar foobar</div>
Which, when #mydiv is narrower than its contents, should come out as something like:
...obar foobar
However, from what I can tell (and fair warning to anyone else who tries this, since I've seen the direction:rtl solution in several other places), the ONLY major browser that does this correctly seems to be Firefox. Safari and Google Chrome will both place the ellipsis to the left of the text, but then truncate on the right anyway, like this:
...foobar foob
IE9 and Opera get downright confused. IE truncates on the right AND makes the text overlap the ellipsis. Opera, by far the most creative, will make the overflow visible on individual words for a while (as the element gets narrower, that is), then start truncating the leftmost word, but from the right. It also fails to render the ellipsis and, in one experiment I did, even moved a ™ character all the way to the left. Really. So "foobar foobar foobar™" becomes this:
™foob foobar
As an additional note, one (extremely annoying) potential option for webkit browsers might be to set -webkit-rtl-ordering:visual which truncates on the left BUT also literally renders the characters in reverse order:
...boofraboof
So by browser- or some-kind-of-obscure-feature-sniffing one could theoretically set that property and reverse the element's text dynamically.
Is there a simple cross-browser workaround, or even a complex, JS-based one?
There are JS/Jquery based solutions to your problem. The one caveat is they are more expensive. If you are not making a bunch of changes on your page then the following solutions should work just fine.
Dotdotdot:
http://dotdotdot.frebsite.nl/
ThreeDots
http://tpgblog.com/2009/12/21/threedots-the-jquery-ellipsis-plugin/
Edit: Just to be clear, I'm seeing the same problems that you have mentioned.
I've prepared this demo:
https://dl.dropbox.com/u/7224702/lists-bug.html
It works fine in Firefox, Chrome and IE8 but is broken in Opera and IE9.
Oh and I don't want to use list-style-position: inside; because if some <li> is longer then one line the second line is not correctly indented.
This is a problem with lists that isn't really specified by CSS. It just says that the marker is outside the box but doesn't precisely specify where.
You could perhaps solve it with text-indent to move the first line back again.
That's the question that's been bothering me for some time as well.
First of all if we look at the spec describing the list-style-position: outside property we will see that
"CSS 2.1 does not specify the precise location of the marker box or
its position in the painting order".
This actually makes this situation not a bug, merely different implementations.
IMO Opera and IE9 make it closer to the spec - which is to put the marker... well... outside the box. In case of floats the box made by the li element is still full-width, only content is shifted inside of it.
I tried to think of alternative solutions but they still turn out to be inappropriate and cause more problems than they solve. An example of using css3 counter increment can be seen here: http://jsfiddle.net/s3sZS/3/, but visually it looks like list-style-position: inside (your indentation problems remain) and the increment itself is selectable and copyable (at least in Opera).
Actually list-style-position: inside looks like the only appropriate solution to this imo.
If you are interested in future implementations of lists - you may read the CSS Lists and Counters Module Level 3 (currently Editor's Draft).
Little later then planned but here is my final solution.
Use list-style-position: inside;.
To repair the indenting of second and folowing lines, use negative text-indent (thanks Joey!)
It is not easy to determine the right value for the negative text indent as every browser does things little differently. Knowing that we will need to use something where we can set the width of the marker manually. And that something is pseudo-element :before. (thanks skip405!)
With the :before pseudo-element and right value of the content property we can now use list-style-type: none;
Delete the list-style-position from 1. as it's useless now.
You can see working demo here:
https://dl.dropbox.com/u/7224702/lists-counters.html
The only drawback is with content: counter(list, disc); in Opera 12. The disc/circle/square values are not working as they sould, values like decimal are alright. I've already reported it as a bug so hopefully it'll be fixed in next version.
I have a CSS menu setup here:
http://pans.saebermedia.com/
The problem is, I noticed IE doesn't display the menus properly, and now I'm back to using my computer to fix it which has IE8. I'm using compatibility mode.
I've noticed two problems. On the submenu, (Say "Resource Center"), there is extra spacing between each item that when your cursor passes through it closes the menu. This sounds like the IE Whitespace bug but I used PHP to strip out the White-space. If I use float:left;clear:left; it causes the menus to be in-equal lengths in Firefox and IE.
Anybody know what's going on?
I tested my solution only on IE 7.
in elements:
li.menu-item
you have to change
display:block;
to
display:inline;
Wow, that took me a bit. You should really reduce the amount of css that you are throwing at these elements. You are overwriting a lot of cascaded values, etc. However, there are 2 primary values that IE7 is having an issue with.
The first is min-width on #main-nav > ul > li ul a. For some reason IE7 having this value on the a is making it ignore that it is display: block. It's probably something related to the parent being misinteruputed as inline-block (see #2).
Second is the display: inline-block being inherited by the lis in the .sub-menu from the li.menu-item above ul.submenu. When I remove these items IE7 starts acting appropriately.
In all cases this has nothing to do with, what you call, the "IE Whitespace Bug". inline-block elements are treated no different than inline elements when the collapes of whitespace is calculated. This is per the spec. IE does not have a bug, any browser that does not collapse whitespace to 1 single whitespace between inline and inline-block elements (without the use of bikesheding: discard) is in violation of the spec.