I have span with contenteditable property. Most of the time the span is empty so I set fixed width to the span.
It works good in Opera and chrome I can click on the span and edit data. But with Firefox span behaves like there is no span.
E.g. When the span is empty in Firefox it doesn't appear as editable and I cannot click on it. When only one character is there, like space or something, then I can edit it. I tried to fixed that with html character but nothing.
$comment = ` `
<span class="edit_notes" contenteditable=true onFocus="clear_input('.$data['ID'].')" style="min-width: 1200px; display: inline-block;display:-moz-inline-box;" id="comment'.$data['ID'].'" onBlur="changeComment('.$data['ID'].')"> '.$comment.' </span>
For FF you may use a pseudo element to give it some size or use the :empty pseudo class if there is no white-space in HTML produced by server when there's no data to print.
Example below to test:
span[contenteditable][onFocus]:after, span[contenteditable]:empty {
content:'';
padding:0.5em;
}
<span class="edit_notes" contenteditable=true onFocus="" style="min-width: 1200px; display: inline-block;" id="comment'.$data['ID'].'" onBlur=""> </span>
<hr/>
<span contenteditable=true ></span>
Why would
<div id='dD' class='cs'>
<p class='c cB'>
<span>X</span>
<span>X</span>
</p>
</div>
display like this
in Chrome, Firefox, Opera, Safari
but this
<div id='dD' class='cs'>
<p class='c cB'>
<span>X</span><span>X</span>
</p>
</div>
displays like this
I wouldn't expect a whitespace newline to have any impact on the way HTML is rendered.
I can rectify this by applying
display: block;
or
display: inline-block;
to the spans (not sure which is the better choice)
but don't understand why the browsers render differently because of a whitespace newline.
Apparently, the default behavior is to treat new lines as spaces.
That one space was enough to wrap the text beyond the width and render on separate lines.
Removing the newline removed the space so the Xs get rendered on the same line.
Adding
.c span {
display: block;
}
forces each X to be treated as a block and rendered on separate lines, which is what I want.
Try this
.cB {
word-wrap: break-word;
}
I tried to style a fieldset element with display: flex and display: inline-flex.
However, it didn't work: flex behaved like block, and inline-flex behaved like inline-block.
This happens both on Firefox and Chrome, but strangely it works on IE.
Is it a bug? I couldn't find that fieldset should have any special behavior, neither in HTML5 nor in CSS Flexible Box Layout specs.
fieldset, div {
display: flex;
border: 1px solid;
}
<fieldset>
<p>foo</p>
<p>bar</p>
</fieldset>
<div>
<p>foo</p>
<p>bar</p>
</div>
According to Bug 984869 - display: flex doesn't work for button elements,
<button> is not implementable (by browsers) in pure CSS, so they are a
bit of a black box, from the perspective of CSS. This means that they
don't necessarily react in the same way that e.g. a <div> would.
This isn't specific to flexbox -- e.g. we don't render scrollbars if
you put overflow:scroll on a button, and we don't render it as a
table if you put display:table on it.
Stepping back even further, this isn't specific to <button>. Consider
<fieldset> and <table> which also have special rendering behavior:
data:text/html,<fieldset style="display:flex"><div>abc</div><div>def</div>
In these cases, Chrome agrees with us and disregards the flex
display mode. (as revealed by the fact that "abc" and "def" end up
being stacked vertically). The fact that they happen to do what you're
expecting on <button style="display:flex"> is likely just due to an
implementation detail.
In Gecko's button implementation, we hardcode <button> (and
<fieldset>, and <table>) as having a specific frame class (and hence,
a specific way of laying out the child elements), regardless of the
display property.
If you want to reliably have the children reliably arranged in a
particular layout mode in a cross-browser fashion, your best bet is to
use a wrapper-div inside the button, just as you would need to inside
of a <table> or a <fieldset>.
Therefore, that bug was marked as "resolved invalid".
There is also Bug 1047590 - display: flex; doesn't work in <fieldset>, currently "unconfirmed".
Good news: Firefox 46+ implements Flexbox for <fieldset>. See bug 1230207.
I find out this might be a bug on Chrome and Firefox where legend and fieldset are replaced elements.
Bugs Reported:
Bug Chrome (fixed since v86)
Bug Firefox (fixed since v46)
A possible Workaround:
A possible workaround would be using <div role="group"> in HTML, and applying in CSS div[role='group'] as selector.
UPDATE
In Chrome version 83 button can work with the display: inline-grid/grid/inline-flex/flex, you can see the demo below:
button {
display: inline-flex;
height: 2rem;
align-items: flex-end;
width: 4rem;
-webkit-appearance: none;
justify-content: flex-end;
}
<!--
The align-items keyword should fail in Chrome 81 or earlier, but work in Chrome 83 or later. To see the error, the button needs styles that make it more of an extrinsic container. In other words, it needs a height or width set.
-->
<button>Hi</button>
<input type="button" value="Hi">
Please star the Chrome bug to increase bug priority
This is a bug in Chrome. Please add a star to this issue to increase it's priority to be fixed:
https://bugs.chromium.org/p/chromium/issues/detail?id=375693
In the mean time, I created these three Code Pen examples to show how to work around the issue. They are built using CSS Grid for the examples but the same techniques can be used for flexbox.
Using aria-labelledby instead of legend
This is the more propper way to deal with the problem. The downside is that you have to deal with generating unique IDs applied to every fake legend element.
https://codepen.io/daniel-tonon/pen/vaaGzZ
<style>
.flex-container {
display: flex;
}
</style>
<fieldset aria-labelledby="fake-legend">
<div class="flex-container">
<div class="flex-child" id="fake-legend">
I am as good accessibilty wise as a real legend
</div>
...
</div>
</fieldset>
Using role="group" and aria-labelledby instead of fieldset and legend
If you need the flex-container to be able to stretch to the height of a sibling element and then also pass that stretch onto its children, you will need to use role="group" instead of <fieldset>
https://codepen.io/daniel-tonon/pen/BayRjGz
<style>
.flex-container {
display: flex;
}
</style>
<div role="group" class="flex-container" aria-labelledby="fake-legend">
<div class="flex-child" id="fake-legend">
I am as good accessibilty wise as a real legend
</div>
...
</div>
Creating a fake duplicate legend for styling purposes
This is a far more hacky way to do it. It is still just as accessible but you don't have to deal with IDs when doing it this way. The main down side is that there is going to be duplicate content between the real legend element and the fake legend element.
https://codepen.io/daniel-tonon/pen/zLLqjY
<style>
.screen-reader-only {
position: absolute;
opacity: 0;
pointer-events: none;
}
.flex-container {
display: flex;
}
</style>
<fieldset>
<legend class="screen-reader-only">
I am a real screen-reader accessible legend element
</legend>
<div class="flex-container">
<div class="flex-child" aria-hidden="true">
I am a fake legend purely for styling purposes
</div>
...
</div>
</fieldset>
Legend MUST be a direct decendent
When you are first trying to fix this yourself, you will probably try doing this:
<!-- DO NOT DO THIS! -->
<fieldset>
<div class="flex-container">
<legend class="flex-child">
Broken semantics legend text
</legend>
...
</div>
</fieldset>
You will discover it works, and then you will probably move on without giving it a second thought.
The problem is that putting a div wrapper between the fieldset and the legend breaks the relationship between the two elements. This breaks the semantics of fieldset/legend.
So by doing this, you have defeated the whole purpose of using fieldset/legend in the first place.
Also, there isn't much point in using a fieldset if you don't give that fieldset a legend.
In my experience, I've found that neither <fieldset>, nor <button>, nor <textarea> can properly use display:flex or inherited properties.
As others have already mentioned, bugs have been reported. If you want to use flexbox to control ordering (e.g. order:2), then you'd need to wrap the element in a div. If you want flexbox to control actual layout and dimensions, then you may want to consider using a div, instead of the input control (Which stinks, I know).
<div role="group">
<p>foo</p>
<p>bar</p>
</div>
<div>
<p>foo</p>
<p>bar</p>
</div>
Might need to use role-group because firefox, chrome and i think safari have a bug with fieldsets apparently. Then the selector in the CSS would simply be
div[role='group'], div {
display: flex;
border: 1px solid;
}
Edit: Here are some issues that other people are experiencing as well.
Issue 375693
Issue 262679
you can put additional div in <fieldset> with the following props:
flex-inner-wrapper {
display: inherit;
flex-flow: inherit;
justify-content: inherit;
align-items: inherit;
}
To answer the original question: yes, it is a bug, but it wasn't well-defined at the time the question was asked.
Now the rendering for fieldset is better defined: https://html.spec.whatwg.org/multipage/rendering.html#the-fieldset-and-legend-elements
In Firefox and Safari, flexbox on fieldset now works. It doesn't yet in Chromium. (See https://bugs.chromium.org/p/chromium/issues/detail?id=375693 )
Also see https://blog.whatwg.org/the-state-of-fieldset-interoperability for improvements made in the specification in 2018.
I have been given some html that look like this (I have no control over the html):
<p>Some text</p>
<strike>
<p>This is some text</p>
</strike>
<p>More text</p>
The text shows as strikeout in both IE and Chrome, but not in Firefox. I have added display:inline-block to the <p> tag which fixes Firefox but then breaks IE and Chrome.
Is there a solution to this which will work in all three browsers and does not involve changing the html?
I believe your issue is due to nesting a block element (<p>) inside of an inline element (<strike>).
This CSS gets the line-through working in the nested <p>:
strike p { /* only applies to <p> tags that are children of a <strike> tag */
padding: 0; // remove default spacing from <p> tag
text-decoration: line-through; // fixes missing line-through
}
Note: Only tested in Firefox 3.6.x
Use CSS.
Tailored to your specific HTML example:
strike p
{
text-decoration: line-through;
}
JSFiddle (verified to work in IE9, Chrome 10, FF4): http://jsfiddle.net/hcYVv/1/
That tag is not universally supported. Use the following CSS
.strikethrough { text-decoration: line-through;}
and then accordingly change your html to
<p class="strikethrough">This is some text</p>
I'm making a "sort elements" web game using jQuery, HTML & CSS. While everything works fine in FF, IE8, Opera, Chrome, I'm having problem with IE7 wrapping words inside block elements.
Here's how it looks in IE7 (wrong):
Link (cannot post images as a new user)
In IE8 the box with wrapped text would just expand to fit it whole in one line without any overflows. Sorry, can't give another link as a new user
Don't mind the element order as it's random. Elements are dynamically generated by jQuery.
HTML code:
<div class="ui-sortable" id="area">
<span class="object">: </span>
<span class="object">1998- </span>
<span class="object">ISSN 1392-4087</span>
<span class="object">, </span>
<span class="object">. </span>
<span class="object">nepriklausomas savaitraštis buhalteriams, finansininkams, auditoriams</span>
<span class="object">. </span>
<span class="object">. </span>
<span class="object">. </span>
<span class="object">Vilnius</span>
<span class="object">1998- </span>
<span class="object"><em>Apskaitos, audito ir mokesčių aktualijos</em></span>
</div>
CSS code (irrelevant info like fonts & colors removed):
#area {
min-height: 160px;
width: 760px;
}
.object {
display: block;
float: left;
text-align: center;
width: auto;
}
Any comments on why does IE7 does that? How do I make these spans expand to fit the whole text in one line in IE7 and not wrap the text or make overflows?
I tried it out myself in IE7, and when you just add 'white-space: nowrap' to the span.object, it should solve the problem. Floating the block elements works just fine, so don't change that.
See image for the test result: http://xs.to/image-B3F6_4BDE909D.jpg
You have a problem. Floats and automatic widths just don't mix. You'll also have issues when it comes to something being wider than the width.
Why not leave it inline? If you need a box, add padding:
span.object { padding: 6px; }
Edit: if you don't want them to break across lines add:
span.object { white-space: nowrap; }
Far easier than getting floats to do this particular task.