Why are default select's options unaffected by overflow: hidden? - html

For starters, check this fiddle -> http://jsfiddle.net/xV4s3/
As you can see, we have a wrapper with overflow: hidden and inside there is a native select with three options and an ul styled to look like a select with three items. Now, when you click on the ul, you can see its height changes (due to the script), but nothing beyond the wrapper is seen, because of the overflow: hidden. And that works as expected.
My question is about the default select's options, since I couldn't find anything in the specifications. Why are they not affected by overflow: hidden ?

This is probably nothing more than an implementation detail. The only thing CSS2.1 says about overflow control is that the overflow property controls overflowing of content according to the containing block to which the property is applied. It does not define the behavior and rendering of form elements and such with respect to this property.
As I commented, it's clear that the drop-down menu isn't being created as a descendant of the wrapper, or even the select element. In fact, it's possible that most browsers choose to render it completely independently of the canvas and as an application-level or system-level UI element in its own right (likely for usability reasons). Note that while you can apply CSS to the option elements to influence the way the drop-down menu displays, you cannot actually style the drop-down menu itself.

Related

CSS content-visibility: auto inadvertently hides overflow

I'm finally getting around to implementing content-visibility: auto in my project to improve render times and general performance. I have a component that has some inset on the page but, under certain conditions, I allow the children of the component to overflow out of the container to make the component full bleed.
Now, when I try to add content-visibility: auto to this parent component, my component gets cut off at the inset boundary of the parent (it is effectively acting like overflow: hidden). I've tried adding overflow: visible to my styles which is having no effect at all.
Codepen example (Uncomment the content-visibility line to see the issue; you will need Chrome for content-visibility support)
Can I use content-visibility: auto without having my overflow hidden?
I am not good at English so this answer is through the translate engine. Sorry if you can not understand this answer.
And this answer is includes my speculation.
The contains-visibility: auto; document states.
Turns on layout containment, style containment, and paint containment for the element.
So If you add contains-visibility: auto;, you will see that layout containment , style containment , and paint containment are turned on.
Since these containments indicate that outside of the element not render, so I think that overflow: visible did not work.
Can I use content-visibility: auto without having my overflow hidden?
As far as I tried, it could not be done.

Determining which DOM element is causing the dimensions to increase for a parent element

I run into this problem sometimes when a site is not contained inside the mobile viewport, and I need to determine what is causing the width to exceed.
Usually I do this by trial and error of hiding different elements until the elements resets to the desired 100% width. Then I repeat for each child element until I find the one that is causing it.
Is there a way in Firefox or Chrome devtools (or using a plugin) to see which DOM child element is deciding the current elements dimensions?
Determining what is defining an element's calculated width and height can be quite tricky. And neither the Chrome nor the Firefox DevTools provide an easy way to get that information in all cases. And to my knowledge, there are also no extensions available that make this easier. The Firefox DevTools team started a discussion on this some time ago, though.
There are two reasons why an element might be wider or higher than expected: Some CSS or some text on the element itself or on one of its descendant elements.
When there is no other solution, the one with hiding or removing the elements is probably the fastest one.
Nonetheless, here are some tips how to use the DevTools to determine what's defining an element's width and height:
Select the element and check in the Computed side panel whether the computed value is defined via a CSS rule. Expand the entries for width or height to see what CSS rules applied. Also check min-width and max-width or min-height and max-height and the other layout related properties like margin, border, and padding but also `line-height, etc.!
Check the text within the element influences its width or height. Long words with no break opportunities like spaces can be the culprit but also CSS property definitions like white-space: nowrap.
When you've checked the above for the element itself and couldn't find the reason, the width or height is influenced by one or more descendant elements. So you need to repeat those two steps for them.
a) To quickly see the dimensions of the direct child elements, first press → to expand the element if it isn't already, then ↓ to toggle through them. While stepping through them, check their CSS and text as noted in steps 1 and 2.
b) When you see one that is as wide as the element you are observing, repeat the previous step to get one more level down in the DOM structure.
The steps mentioned above can also be automated by using some JavaScript to walk through the tree and check the element widths or heights. A relatively simple snippet for that (which can be executed in the DevTools console) is
rootElement = $0;
rootWidth = rootElement.getBoundingClientRect().width;
walker = document.createTreeWalker(rootElement, NodeFilter.SHOW_ELEMENT, {
acceptNode: element =>
element.getBoundingClientRect().width === rootWidth ?
NodeFilter.FILTER_ACCEPT :
NodeFilter.FILTER_SKIP
});
currentNode = walker.currentNode;
while (currentNode) {
console.log(currentNode);
currentNode = walker.nextNode();
}
Where the $0 refers to the currently selected element.

IE offsetting and ignoring height/width of anchor focus outlines?

I've got a scenario where focus outlines are not being represented correctly in Internet Explorer 10 when focus is given to an a element.
Nested inside each a element is a series of div elements and within the lowest-level div is an img element.
When I tab to each a element (via IE10), focus outlines show up offset to the right of the group of a elements. When I view the page in Chrome, focus outlines show up perfectly.
I've been able to reproduce this in a JSFiddle.
CSS is bloated with styles from the existing project I'm having the issue in.
You haven't adjusted the display property for your a elements, so they're still displaying inline, even though they're "containing" block-level div elements. The result is in accordance with this section of the CSS2.1 spec which has a description on how inlines containing block children should behave.
None of the browsers are automatically adjusting the display modes, but what Chrome appears to be doing is guessing the location of its default outline and drawing it according to its best guess. The really weird thing about this, though, is that it doesn't always do this. The moment you adjust the outline style, the outline behavior immediately reverts to something similar to what you see on other browsers:
a:focus{
outline-style: dashed;
}
Unfortunately, because outline rendering is poorly defined, it's not possible to judge if any of the browsers are buggy in this aspect. And although HTML5 explicitly allows a elements to contain most any other element, it does not state how their display mode should be adjusted, if at all, so it looks like browsers just don't do anything about it. The main issue here, though, is with outlines.
The easy solution to the original problem is of course to set the display style of your a elements explicitly to something other than the default inline. This will at the very least improve outline rendering by making it more predictable. You may or may not wish to move the styles for your div elements to your a elements instead as well, depending on what sort of role those divs play in your layout and whether they are necessary. As it is, most of the styles that you do have on a aren't actually taking effect because of what I've described from the spec.

Fill dynamic <div>'s with content. But how to show it?

My intention is to have 4 main Nav-bars at a site. If the user hovers one, it expands and should show content. But how should I do the content part?
#bottom-menu:hover #contact{
visibility: visible ;
}
If I make it visible when the box is fully expanded, it works but there is an issue: The content, while not visible, is still there and needs room which causes the layout to collapse.
I would like to do that with pure CSS, allthough i'm aware of jQuery.
http://jsfiddle.net/RbZwx/1/
visibility: hidden causes the element to continue to consume layout space.
display:none causes it to take up no layout space.
Think "spoilers" vs "hidden".
https://developer.mozilla.org/en/CSS/visibility
The visibility CSS property is used for two things:
The hidden value hides an element but leaves space where it would have been.
The collapse value hides rows or columns of a table. It also collapses XUL elements.
https://developer.mozilla.org/en/CSS/display
The display CSS property specifies the type of rendering box used for an element. In HTML, default display property values are taken from behaviors described in the HTML specifications or from the browser/user default stylesheet. The default value in XML is inline.
In addition to the many different display box types, the value none lets you turn off the display of an element; when you use none, all child elements also have their display turned off. The document is rendered as though the element doesn't exist in the document tree.
I would still encourage you to read both of these, and to learn how they affect the page more than just for this particular case.
Use display: none. See CSS 2.1: 11.2 Visibility: the 'visibility' property:
The 'visibility' property specifies whether the boxes generated by an element are rendered. Invisible boxes still affect layout (set the 'display' property to 'none' to suppress box generation altogether). Values have the following meanings: [...]
hidden The generated box is invisible (fully transparent, nothing is drawn), but still affects layout. Furthermore, descendants of the element will be visible if they have 'visibility: visible'.

Making a class invisible

I'm want to have a div with class "a" to be invisible. I've tried already to give it the display: none; line in the CSS file but what it does is hide it, yet it doesn't catch any space and so all my other boxes don't stay in place.
Is there a way to do this using CSS?
add .a{visibility: hidden} to your CSS. More about it here:
http://reference.sitepoint.com/css/visibility
visibility:hidden should hide the element, while keeping it's space so as not to move your other elements around.
You can use visibility css property. From sitepoint reference -
This property specifies whether an
element is visible—that is, whether
the box(es) that are generated by an
element are rendered.
Note that even if a box in the normal
flow is hidden, it still affects the
layout of other elements, unlike the
behavior that occurs when we suppress
box generation altogether by setting
display to none. Descendant boxes of a
hidden box will be visible if their
visibility is set to visible, whereas
descendants of an element for which
display is set to none can never
generate boxes of their own.
More information can be found here.