The HTML below specifies a button and a div that have identical class and contents.
<div class="root"><!--
--><button class="outer"><div class="middle"><div class="inner">label</div></div></button><!--
--><div class="outer"><div class="middle"><div class="inner">label</div></div></div ><!--
--></div>
In this example, I have explicitly set every CSS property1 for the classes outer, middle, and inner2.
This means that both the button.outer and div.outer sub-trees of the DOM should have completely identical CSS settings. Presumably, as well, no CSS properties for these elements are getting their values from anywhere else besides the provided stylesheet.
As the example shows, the side-by-side button and div look quite different. Specifically, in the button, the label appears at the bottom of the element, whereas in the div it is vertically centered. (The label is centered horizontally in both cases. Also, note that all the classes have the setting vertical-align: middle.)
I have observed this difference with all the browsers I've tested so far (Chrome and Firefox).
Since there is no difference in the stylesheet settings for the button.outer and div.outer elements, and their descendants, I figure that the difference in their appearance is due to some CSS property with a value (such as auto or normal) that gets interpreted differently by the browser depending on the whether the context is a button or a div element.
My immediate goal here is to understand sufficiently well why the button and the div are being rendered differently so that I can adjust the CSS intelligently.
My longer term goal is to make CSS coding more predictable. Currently I find that my CSS is completely unstable due to gross inconsistencies like the one shown in the example.
My question is:
how can the difference in appearance between the button and the div be explained?
1 As reported by Chrome's devtool.
2 I took the vast majority of the values for these settings from Chrome's devtool's listings. The point was to ensure that both the button and the div elements had the same setting (whatever it may be) for each CSS property.
This is likely due to different meanings for the value of auto for the position of elements inside of a button. If you expand the size of a div, the content by default will be in the top-left corner. If you do the same for a button, the content will be centered horizontally and vertically.
Since the button's top and left values for auto is to be centered and not in the top left corner, you can reset top and left to always act like a typical div would. These are the properties to change on .middle:
.middle {
top: 0;
left: 0;
}
Here's the forked JSFiddle with those changes to .middle.
Different elements have different default settings. There is an enormous amount of CSS in your demos, and it's largely overkill and very hard to determine where exactly the differences in rendering are coming from.
Have you tried a CSS reset instead? These will resolve most of the discrepancies between elements and browsers, giving you a blank slate to add your own styles.
how can I determine the property (or properties) that account for the difference in appearance between the button and the div?
By clicking through them one by one and toggling them on and off in Dev Tools. If you turn off position:absolute on the middle class, you'll see what you're probably expecting in layout. I found this by clicking through all the properties in the Elements > Styles panel. See:
https://jsfiddle.net/vfdd9p8L/
This is probably a bug that you're encountering. Browsers have lots of them! By layering on so many styles at once, you're probably backing into a weird corner case with respect to the layout algorithms. To isolate the bug for help and/or reporting, try to create a reduced test case, which creates an unexpected discrepancy, but using the minimal number of elements and declarations.
(Also note that your fiddle is including jQuery CSS, which includes Normalize, which is a whole other layer of styling.)
I have HTML like below and all is displaying grand, the problem is that due to a problem with Sharepoint 2013's editor your unable to edit the link text but as soon as I remove display: block I can edit the link text, the same happens using float.
My question is there a way to emulate the affect of display: block where it will span the whole width that is available to it without using display or float?
<div class="button">
Link Text
</div>
There is one option to make an inline element to be like a block by using position:absolute without using display or float.
But I hope absolute positioning doesn't fit your want. Thus, the final conclusion is that you must use display or float property to render it correctly.
If you even use absolute then don't forget to keep position:relative to your parent element from which you want to be the element as absolute.
You could try display: inline-block; width: 100%;. You might need to alter the width to take into account any padding or border you've set.
(In the past I've used an edit mode panel and other tricks, so these hacky styles only apply when the page is being edited.)
SharePoint 2013's editor is so utterly awesome isn't it? :-(
The opposite of visibility: hidden is visibility: visible. Similarly, is there any opposite for display: none?
Many people become confused figuring out how to show an element when it has display: none, since it's not as clear as using the visibility property.
I could just use visibility: hidden instead of display: none, but it does not give the same effect, so I am not going with it.
display: none doesn’t have a literal opposite like visibility:hidden does.
The visibility property decides whether an element is visible or not. It therefore has two states (visible and hidden), which are opposite to each other.
The display property, however, decides what layout rules an element will follow. There are several different kinds of rules for how elements will lay themselves out in CSS, so there are several different values (block, inline, inline-block etc — see the documentation for these values here ).
display:none removes an element from the page layout entirely, as if it wasn’t there.
All other values for display cause the element to be a part of the page, so in a sense they’re all opposite to display:none.
But there isn’t one value that’s the direct converse of display:none - just like there's no one hair style that's the opposite of "bald".
A true opposite to display: none there is not (yet).
But display: unset is very close and works in most cases.
From MDN (Mozilla Developer Network):
The unset CSS keyword is the combination of the initial and inherit keywords. Like these two other CSS-wide keywords, it can be applied to any CSS property, including the CSS shorthand all. This keyword resets the property to its inherited value if it inherits from its parent or to its initial value if not. In other words, it behaves like the inherit keyword in the first case and like the initial keyword in the second case.
(source: https://developer.mozilla.org/docs/Web/CSS/unset)
Note also that display: revert is currently being developed. See MDN for details.
When changing element's display in Javascript, in many cases a suitable option to 'undo' the result of element.style.display = "none" is element.style.display = "". This removes the display declaration from the style attribute, reverting the actual value of display property to the value set in the stylesheet for the document (to the browser default if not redefined elsewhere). But the more reliable approach is to have a class in CSS like
.invisible { display: none; }
and adding/removing this class name to/from element.className.
Like Paul explains there is no literal opposite of display: none in HTML as each element has a different default display and you can also change the display with a class or inline style etc.
However if you use something like jQuery, their show and hide functions behave as if there was an opposite of display none. When you hide, and then show an element again, it will display in exactly the same manner it did before it was hidden. They do this by storing the old value of the display property on hiding of the element so that when you show it again it will display in the same way it did before you hid it.
https://github.com/jquery/jquery/blob/740e190223d19a114d5373758127285d14d6b71e/src/css.js#L180
This means that if you set a div for example to display inline, or inline-block and you hide it and then show it again, it will once again show as display inline or inline-block same as it was before
<div style="display:inline" >hello</div>
<div style="display:inline-block">hello2</div>
<div style="display:table-cell" >hello3</div>
script:
$('a').click(function(){
$('div').toggle();
});
Notice that the display property of the div will remain constant even after it was hidden (display:none) and shown again.
you can use
display: normal;
It works as normal.... Its a small hacking in css ;)
I use
display:block;
It works for me
Here's an answer from the future… some 8 years after you asked the question. While there's still no opposite value for display: none, read on… There's something even better.
The display property is so overloaded it's not funny. It has at least three different functions. It controls the:
outer display type (how the element participates in the parent flow layout, e.g. block, inline)
inner display type (the layout of child elements, e.g. flex, grid)
display box (whether the element displays at all, e.g. contents, none).
This has been the reality for so long, we've learnt to live with it, but some long-overdue improvements are (hopefully!) coming our way.
Firefox now supports two-value syntax (or multi-keyword values) for the display property which separates outer and inner display types. For example, block now becomes block flow, and flex becomes block flex. It doesn't solve the problem of none, but the explicit separation of concerns is a step in the right direction I think.
Chromium (85+), meanwhile, has given us the content-visibility property, and announced it with some fanfare. It aims to solve a different problem—speeding up page load times by not rendering an element (and its child layouts) until it approaches the viewport and really needs to be seen, while still being accessible for 'Find' searches, etc. It does this automatically just by giving it the value auto. This is exciting news in itself, but look at what else it does…
The content-visibility: hidden property gives you all of the same
benefits of unrendered content and cached rendering state as
content-visibility: auto does off-screen. However, unlike with
auto, it does not automatically start to render on-screen.
This gives you more control, allowing you to hide an element's
contents and later unhide them quickly.
Compare it to other common ways of hiding element's contents:
display: none: hides the element and destroys its rendering state. This means unhiding the element is as expensive as rendering a new
element with the same contents.
visibility: hidden: hides the element and keeps its rendering state. This doesn't truly remove the element from the document, as it
(and it's subtree) still takes up geometric space on the page and can
still be clicked on. It also updates the rendering state any time it
is needed even when hidden.
content-visibility: hidden, on the other
hand, hides the element while preserving its rendering state, so, if
there are any changes that need to happen, they only happen when the
element is shown again (i.e. the content-visibility: hidden property
is removed).
Wow. So it's kind of what display: none should have been all along—a way of removing an element from the layout, gracefully, and completely independently of display type! So the 'opposite' of content-visibility: hidden is content-visibility: visible, but you have a third, very useful option in auto which does lazy rendering for you, speeding up your initial page loading.
The only bad news here is that Firefox and Safari are yet to adopt it. But who knows, by the time you (dear fellow developer) are reading this, that may have changed. Keep one eye on https://caniuse.com/css-content-visibility!
In the case of a printer friendly stylesheet, I use the following:
/* screen style */
.print_only { display: none; }
/* print stylesheet */
div.print_only { display: block; }
span.print_only { display: inline; }
.no_print { display: none; }
I used this when I needed to print a form containing values and the input fields were difficult to print. So I added the values wrapped in a span.print_only tag (div.print_only was used elsewhere) and then applied the .no_print class to the input fields. So on-screen you would see the input fields and when printed, only the values. If you wanted to get fancy you could use JS to update the values in the span tags when the fields were updated but that wasn't necessary in my case. Perhaps not the the most elegant solution but it worked for me!
I ran into this challenge when building an app where I wanted a table hidden for certain users but not for others.
Initially I set it up as display:none but then display:inline-block for those users who I wanted to see it but I experienced the formatting issues you might expect (columns consolidating or generally messy).
The way I worked around it was to show the table first and then do "display:none" for those users who I didn't want to see it. This way, it formatted normally but then disappeared as needed.
Bit of a lateral solution but might help someone!
You can use display: block
Example :
<!DOCTYPE html>
<html>
<body>
<p id="demo">Lorem Ipsum</p>
<button type="button"
onclick="document.getElementById('demo').style.display='none'">Click Me!</button>
<button type="button"
onclick="document.getElementById('demo').style.display='block'">Click Me!</button>
</body>
</html>
opposite of 'none' is 'flex' while working with react native.
To return to original state put:
display=""
Use display: revert
From the documentation stated on https://developer.mozilla.org/en-US/docs/Web/CSS/revert
The revert CSS keyword reverts the cascaded value of the property from its current value to the value the property would have had if no changes had been made by the current style origin to the current element. Thus, it resets the property to its inherited value if it inherits from its parent or to the default value established by the user agent's stylesheet (or by user styles, if any exist). It can be applied to any CSS property, including the CSS shorthand property all.
It supported accross all major browsers - https://caniuse.com/css-revert-value
visibility:hidden will hide the element but element is their with DOM. And in case of display:none it'll remove the element from the DOM.
So you have option for element to either hide or unhide. But once you delete it ( I mean display none) it has not clear opposite value. display have several values like display:block,display:inline, display:inline-block and many other. you can check it out from W3C.
display:unset sets it back to some initial setting, not to the previous "display" values
i just copied the previous display value (in my case display: flex;)
again(after display non), and it overtried the display:none successfuly
(i used display:none for hiding elements for mobile and small screens)
The best answer for display: none is
display:inline
or
display:normal
The best "opposite" would be to return it to the default value which is:
display: inline
You can use this display:block; and also add overflow:hidden;
Hi i am using twitter bootstrap. I have used typeahead in my model window. My Problem is when I type in textbox the dropdown is coming perfect but its coming at very bottom of textbox. I have observed that there is attribute top set when drop down is coming. But I don't know how to change that at run time.
Here is the Image:
I am not good in CSS. Can anybody tell me that what should do to resolve this problem ?
You need to override some of the default styling of the typeahead class in bootstrap. Specifically, I am able to get it to appear properly by setting the position to relative and the z-index to 10000. The position property requires that you use the !important declaration.
.typeahead {
position:relative !important;
z-index:10000;
}
See my working fiddle at http://jsfiddle.net/technotarek/Msttw/.
Note that my typeahead values are the color of the rainbow in case you're having trouble triggering it.
Also, depending on your exact form layout, you may have to adjust the positioning of the typeahead element for your own situation by using the top/bottom or left/right CSS properties.
I'm having this really strange problem with the CSS of my custom validator.
I have a custom validator with the display property set to dynamic and the CSSclass property set to a CSS class I wrote.
In this CSS class I have a padding property. My problem is that the left and right values of the padding just reverse for no reason when I view my website in IE7 or IE8 with compatibility view set to on.
The values just flip, the amount of pixels set to the left padding appear on the right and the other way around.
Sorry for not posting the code, I'm writing this from my phone because we don't have Internet access in this network.
Any ideas?
Had the same problem with span containing arabic text within an anchor tag - padding was inverted. Changing text to latin was one way to fix it :) Another one was to add zoom:1 to that span.
Without seeing any code...I can only assume that the default margin and padding values are being interpreted differently by each of the browsers. I'd recommend adding a css reset stylesheet just above your other stylesheet to see if that changes anything?
CSS RESET STYLESHEET: http://meyerweb.com/eric/tools/css/reset/
Hope that helps a little. :)