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.
Related
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.
I've been working with contenteditable recently within a HTML5 page and encountering bugs when using it with certain elements, and I'd like to know where and how I can actually safely use it.
I've discovered that making a span element contenteditable results in some buggy behaviour in both Firefox1 and Chrome2. However, making a div or section contenteditable appears completely safe3.
A guideline a couple of people have mentioned is that only block-level elements should be made contenteditable. However, the Mozilla Developer Network lists the heading elements h1 through to h6 as block-level elements, and making a heading element contenteditable is buggy in Firefox4 and can crash the page in Chrome5.
I'd like to be able to use more than just divs and sections, but I'm not clear on what elements I can actually safely make contenteditable. By safely, I mean that using the element under normal conditions, I should be able to perform normal editing tasks without it doing unexpected or buggy things. I should be able to write in it, delete content, cut, copy, paste, and move my text cursor about and highlight text without unexpected or strange behaviour.
So, which elements can I really make contenteditable safely? Is there a specific category? Are there certain criteria the safely-contenteditable element must match?
Bug notes:
Firefox 21 w/ span: Element loses focus if the text cursor is brought to the beginning or end of the element, but not if it got there by deleting content. Highlighting part of the element, cutting and then pasting will split the element in two at that point then insert a blank element between the two parts - without actually putting the text you were trying to paste anywhere.
Chrome 27 w/ span: If the span covers multiple lines e.g. by being wordwrapped, cutting and pasting content will often insert a linebreak after the pasted content.
Unless you make the div display:inline, in which case it can still lose focus as in 1, but apparently only if you bring the text cursor to the end. I don't consider this "normal" usage of the element though.
Firefox 21 w/ heading: Selecting part of the content then cutting and pasting will, similarly to 1, split the heading element in half at that point, and insert a third heading element between the two halves. It will, at least, have your pasted content inside it, but now you have three heading elements where there was originally one.
Chrome 27 w/ heading: Select some content and cut and paste. The page crashes. You get an "Aw snap!" message. That's it.
Demo code
Here's a demo for reproducing the above. It's pretty simple, though at the moment the only thing it isn't reproducing is the lose-focus bug.
[contenteditable=true] {
border: 1px dotted #999;
}
<article style="width: 100px">
<h1 contenteditable="true">Heading</h1>
<p>
<strong>Some adjacent content</strong>
<span contenteditable="true">Span! This is long enough it will spread over multiple lines.</span>
</p>
<div style="display: inline" contenteditable="true">An inline div also with multiple lines.</div>
</article>
In my opinion, I'd say div is the safest bet across the board. Any element you wish to truly edit (be it a span, header, etc), you can place inside the div and edit as if it were just that element. Also, to account for the display:inline issue you mentioned, you could always use float:left or float:right on your editable div to give it an "inline feel" without having it actually be inline.
Hope that helps!
Since this is an evolving feature with, apparent, low priority from the browser vendors support has been sketchy and regressions not uncommon. The current state of affairs is evolving, so check the Googles, CanIUse etc and make sure support is there for your sites visitors, everything else is moot ...
Support in Firefox seems to be solid, at least for some elements, now https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
It works well in Chrome as well as far as my testing goes.
And CanIUse looks good: http://caniuse.com/#feat=contenteditable
There are a number of different bugs related to the feature in the different browsers though, but for simple use cases it should be ok now, as of August 2016.
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 been setting up a very basic Wordpress site. All of the pages have a lot of empty space at the bottom. Pages with more placeholder content have more space at the bottom than the others.
I have been reading other threads from people with similar problems, and I can't fix the problem on my site using suggested fixes (the margin property in a certain div was often the culprit).
Check it out: http://www.hairofthedogproductions.co.nz/?page_id=5
My client wanted a totally minimal bare-bones site so I have collapsed post/page metadata, comments, and the sidebar. I just can't for the life of me get rid of the big empty space at the bottom.
Your main problem is in the comments template. I see you're using visibility: collapse to hide elements, but collapse is just for table elements, and if used in other tags it'll default to hidden. Plus, keep in mind that visibility: hidden hides elements but keeps them in flow. You might want to use display: none instead.
This will solve your problem, try it out.
#comments { display: none; }
Validate your page: http://validator.w3.org
I validated it and found about a dozen errors (some of them potentially serious enough to break the layout of the page, such as an unterminated tag).
When inspecting the source in Chrome, the element in the blank area was the HTML tag itself, which might indicate an overall failure to determine the correct document structure--the parser tries but can't always determine what you want it to do when there are malformed tags.
Just apply overflow:hidden on your main wrapper then it will remove all blank space at the bottom
#main {
overflow: hidden;
}
I know this kind of question must get asked all the time but I haven't found a solution for my problem yet.
Using FF, Opera and the IE that is on Windows 7 (can't remember what it is), the page looks exactly as it should, but using IE7 on Windows Vista, there is a gap between my navigation bar and the rest of the page which frankly makes it look stupid, and the illusion of tabbed pages is lost.
I have a reset stylesheet to reset all the elements to have no padding, margins etc and FF, Opera and the IE on Windows 7 produce the page as they should, it's only IE7 (and I'm guessing earlier versions of IE) that don't.
Here are 2 screenshots showing the problem, the first from FF/Opera/IE on Windows 7:
This one is from IE7 on Windows Vista:
alt text http://img43.imageshack.us/img43/7558/figarosiegap.jpg
And here is a link to the actual website in question: Figaro's Ristorante
Any ideas anyone?
Thanks for your time.
I've run into this problem a bazillion times. Add this to your CSS:
#header img { vertical-align: bottom }
There's a funny bug in IE up to and including version 7 where it will treat some whitespace (an empty text node, really) as a real text node, and align the image as if there was text in the element as well.
Another option would be to declare the image as a block level element:
#header img { display: block }
This CSS is safe to add to your global file, it will not interfere with how other browsers render the page.
The IE on windows 7 is IE8
I've taken a look at it using IE7, and the gap appears to be because of the image in the 'header' div. If you look at it with a tool like IE Developer toolbar you can see the boundaries around the objects on the page.
Sorry i cant paste an image but i'll try to describe it:
there is a #text element after the image which is being forced onto a new line by IE7.
if you change the style on the img to include
float: left;
This fixes the problem for me.
Hope this helps!
(Let me know if you need more clarity)
The gap is part of the text line where the menu image is, because the image is an inline element so it's placed on the baseline of the text line. The gap is the distance from the baseline of the text to the bottom edge of the line, i.e. the space used by hanging characters like 'g' and 'j'.
Simply adding display:block; to the style of the image solves the problem. It turns the image element from an inline element to a block element so that it's not placed on a base line of the text but as a separate element.
I've run into this problem a thousand times, and finally, after using overly complicated fix after fix, the answer is simple! (At least when <img>'s are involved.) In the div that is producing a gap under it, add 'overflow: hidden;' to its css; you will need to set its height, of course. So, if your div is 39px high, this will keep it at 39px high, ignoring the extra whitespace IE loves to put under <img>s
Hope it helps.
There's not much useful information (html or pictures that work) in this question. So, here's a random guess.
I've had situations where a line-break or spaces between elements can cause vertical space between elements. Try placing the closing and opening tags immediately next to each other and see if this corrects the issue.
Different browsers all have different default margins and padding. In this case, I'm guessing IE7s defaults are throwing you off. There are two general solutions to the problem. You can set your own margin and padding at the html, body level:
html, body {
margin: 0;
padding: 0;
}
or you can use IE conditional comments to load sepearte stylesheets for different versions of IE. Last I checked, the conditional comments were considered a better solution because browser defaults do provide some usefulness.
Jason is correct that it's a bug in how IE handles whitespace in the html... treating it as a text node. Though I don't think it's unique to images. I believe I've seen this behavior with divs as well. As a global change you may try applying vertical-align:bottom to both images and divs. Though I don't know what mayhem that may produce.
But the quick and dirty fix is to just remove the whitespace. Kinda sucks, but change stuff like this:
<img src="blah" alt="" width="5" height="5" />
<div>blorg</div>
To this:
<img src="blah" alt="" width="5" height="5"
/><div>blorg</div>
I warned that this is quick and dirty. But it works.