I am using checkboxes and labels to build an accordian menu. I have it working on andriod devices and in the most browsers when it is resized but for some reason it isn't working on Safari on desktop or iOS devices. Last Friday it was working and now it isn't, even though I can't find anything that would conflict. Here's the necessary code.
HTML
<input type='checkbox' class='hide' name='custom_tailored' id='custom_tailored' />
<h1 class='dot-bor'><label for='custom_tailored'>Custom Solutions</label></h1>
<ul class='drawer'>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
<li>Item 4</li>
</ul>
CSS
.drawer {
display: block;
height: auto;
max-height: 0;
overflow: hidden;
transition: all 500ms ease-in-out; /* plus vendor prefixes */
}
.hide:checked + .dot-bor + .drawer {
max-height: 2500px;
}
As I said... this code works without any problems on all of the browsers if they're resized down to the right media query, as well as on andriod. When I plug my iPhone up to the computer and look through the console I can find where the CSS is getting applied (the max-height changes) but in the computed section it still shows max-height: 0;
EDIT:
I didn't realize it until today, but this problem is on Safari for Desktop as well. The weirdest part is that I can see in the inspector the max-height is being applied but computed still says max-height: 0; but then if I uncheck max-height and then check it again in the inspector suddenly the style gets applied.
The issue can be seen at voicepad.com.mm-dev.net at a responsive browser size in safari.
This link pointed me down the road towards a possible answer to my problem. My code is "working" but because of a bug with webkit, it wouldn't work (previously) on any webkit browser. Now apparently this was fixed but I'm thinking the bug is still out there. So I decided to try to skip out on the adjacent sibling selector + and just use the general sibling selector ~ (which is what changed between last friday when it was working on iOS and now when it isn't). The problem (and why I originally switched to adjacent selectors) is that I have more than one of these on each page. To remedy that, I am using a general selector along with the :first-of-type pseudo class to make sure I only get the first element in the list. In this case it happened to have the .drawer. class.
tl;dr
input.hide:checked ~ label.trigger ~ .drawer:first-of-type,
input.hide:checked ~ .dot-bor ~ .drawer:first-of-type {
max-height: 2500px !important;
}
Related
I have a problem with very simple HTML markup, which is rendered different in Chrome and Firefox. I'm wondering whether it is a bug in one of them.
The code is as simple as:
<ul>
<li>
<img />
</li>
</ul>
The problem is that in Chrome the <li /> element has some padding at the top, but only if its content is an image. There is no problem with e.g. text.
Example fiddle: https://jsfiddle.net/8c4rujvu/1/
img {
display: block;
width: 500px;
}
li {
border: 1px solid #f00;
}
<ul>
<li>
<img src="http://www.w3schools.com/css/trolltunga.jpg">
</li>
<li>
<img src="http://www.w3schools.com/css/trolltunga.jpg">
</li>
<li>Some text</li>
</ul>
This is how it displays in Firefox (50.0.2):
And in Chrome (55.0.2883.75 m):
What seems to be a problem here?
This is due the default browser / user agent styling difference for display: list-item.
As a fix, you can use inline-block and vertical-align:top (or even just vertical-align: top) for the img to get common behaviour - see demo below:
img {
display: inline-block;
vertical-align: top;
width: 500px;
}
li {
border: 1px solid #f00;
}
<ul>
<li>
<img src="http://www.w3schools.com/css/trolltunga.jpg">
</li>
<li>
<img src="http://www.w3schools.com/css/trolltunga.jpg">
</li>
<li>
Some text
</li>
</ul>
A related question you may want to look at: Why alignment mark list is different on WebKit when using :before height?
Why this happens?
Given that other browsers do not agree with chrome on this, this clearly looks like a bug and it is. See this open bug documented in Chromium Bug Tracker:
Table inside list item rendered at wrong position(Example URL: http://jsfiddle.net/P8Ua7/)
See excerpts from one of the comments in the bug:
Not limited to tables. Putting a flexbox inside a list-item gives the
same result. It also happens if you have replaced content displayed as
block.
The OP has an image (which is an inline replaced element) displayed as block!
Here is another bug you may want to check out.
This issue can simply fix float:left property too , check this fiddle
https://jsfiddle.net/9wp619xz/
check with the bug details Fixing Google Chrome compatibility bugs in websites - FAQ
https://www.chromium.org/Home/chromecompatfaq
img {
float:left;
width: 500px;
}
li {
border: 1px solid #f00;
float:left;
width:100%;
}
<ul>
<li>
<img src="http://www.w3schools.com/css/trolltunga.jpg">
</li>
<li>
<img src="http://www.w3schools.com/css/trolltunga.jpg">
</li>
<li>Some text</li>
</ul>
It is usually due to browsers default styling. In order to fix this issue, i recommend using a normalize css stylesheet or by adding your own css for the element.
The solution is two-fold.
Setting the image to display: inline solves the empty line above the image. This empty line is a nasty bug in Chrome. This bug makes it effectively impossible to use/start with a non-inline element in a default list item. A very big deal if you ask me.
Adding vertical-align: top places the list marker on the top (which is where you probably want it to go). This also removes the unwanted space below the inline image. The list marker placement and the white space below the inline element are not bugs. This is expected behaviour.
This would result into the following (simple) work-around for the OP:
img {
width: 500px;
vertical-align: top;
/* display: inline; *//* This is default, thus can be omitted */
}
li {
border: 1px solid #f00;
}
https://jsfiddle.net/8c4rujvu/3/
This is caused by the two different approaches these two browsers take while rendering a UL / LI element. I think that is clear from the start :)
The issue here is not how inline elements behave!
The issue here is how list-style properties behave in these two browsers!
If you notice that, the size of gap is 18px, which is default line height in chrome! If you increase the font-size for the li then size of dot marker will also increase so as the distance of image from top edge of div.
If Firefox, that dot marker, or list-style-type component act as the absolute positioned element, thus any element after simply begin from the li top-left edge as expected.
But in Chrome, that dot marker, or list-style-type component act as the inline element, and like any other inline element will allow an inline/floating element to get in same line as itself. Thus text which is inline by nature began next to the dot! This applies also for image, button, link, span or any such elements!
Now what you feel as an issue is perfectly normal behaviour for those elements. Even If two elements are floating or inline, if they can not get in horizontal width of parent, the latter element fall down to next line! Similar is the case with display:block elements as they by default start on a new line!
In your example images have display:block, thus they will always begin on new line! But even if you remove that property, still image are quite big to fit in parent, thus it'll fall down & show a gap. (This is for smaller screens only, on larger screen this won't be an issue for inline-block image)
Again, weird part is that, div acts a inline element in this case, even if you give the width above 100%! From this I concluded that, if wrapping of content is possible then that element begin on new line but if content can not wrapped then it starts on a new line!
Note:
This is based on my observations & past experience! If anybody have links to official documentation for this case please paste if here. Also any suggestion to improve this answer are welcome.
I've updated your JSFiddle with more examples: https://jsfiddle.net/8c4rujvu/5/
Try this code for you HTML
ul li {
display:block;
}
img {
display: block;
width: 500px;
}
li {
border: 1px solid #f00;
display:block;
}
<ul>
<li><img src="http://www.w3schools.com/css/trolltunga.jpg"></li>
<li>
<img src="http://www.w3schools.com/css/trolltunga.jpg">
</li>
<li>
Some text
</li>
</ul>
I'm trying to build an equal horizontal menu in CSS which is still supported in older browsers like IE9. (Yes, I know....)
Been testing in FF and Chrome with newer CSS3 techniques and working excellent! Tried in IE9, as we still need to support it.... and failed.
I searched around, and found some of these links which did the trick...
http://lea.verou.me/2011/01/styling-children-based-on-their-number-with-css3/
horizontal menu with auto width and same dimension of the tabs
...However if the number of menu items change you need to either change you CSS or cater for X number of menu items with multiple declarations...
Is there a simple one case covers all that will support IE9 and still be compatible with newer browsers without affecting them? (ie: special stylesheet for IE9)
Thanks.
If I understood your question correctly, you could make use of display: table and display: cell, as in:
.menu {
display: table;
padding: 0;
width: 100%;
}
.menu-item {
display: table-cell;
list-style: none;
margin: 0;
}
<ul class="menu">
<li class="menu-item">Option 1</li>
<li class="menu-item">Option 2</li>
<li class="menu-item">Option 3</li>
<li class="menu-item">Option 4</li>
</ul>
The issue is quite simple really. Here is my CSS:
.fixed-body {
position: absolute;
}
And my HTML:
<div class="fixed-body">
<ul class="breadcrumb">
<li class="active">Name with spaces<span class="divider">/</span></li>
<li>Home<span class="divider">/</span></li>
<li>Library</li>
</ul>
</div>
Everything looks all right in all browsers apart from Internet Explorer 8. This is how it renders the Breadcrumb:
You can see it for yourself in this jsfiddle. This is just the resulting frame because jsfiddle doesn't render on IE8 properly. The whole fiddle is at this address (it's the same address without the "show" part in the URL).
There are two reasons why it doesn't render properly:
The CSS directive position: absolute in .fixed-body
Spaces in the first section of the breadcrum Name with spaces
If the first section doesn't contain spaces or the position of the parent node isn't set to absolute then Internet Explorer 8 renders the breadcrumb properly.
I tried to wrap the breadcrumb in another div and reset its position to static but it doesn't help. Is there any specific limitation of Internet Explorer 8 that shows in that way? And most interestingly, is there any way of fixing or working around this problem?
EDIT (copied from my response):
Just found by accident the proper fix. Overriding inline-block with inline for li in the breadcrumb gives the desired effect without any side issues (AFAIK):
.breadcrumb > li {
display: inline;
}
See also the new version of my fiddle, or open just the show frame in IE8.
This is because of "breadcrumb" width...
Check this in IE8: http://fiddle.jshell.net/azm53/12/show
I have changed breadcrumb width to 400px and it's ok.
<div class="fixed-body">
<ul class="breadcrumb">
<li class="active">Name with spaces<span class="divider">/</span>
</li>
<li>Home<span class="divider">/</span>
</li>
<li>Library
</li>
</ul>
</div>
And CSS
.fixed-body {
position: absolute;
}
.breadcrumb {
width: 400px;
}
Actually, setting the display to inline-block gives a similar result as the answer gave by ITChristian:
.breadcrumb {
display: inline-block;
}
However, both solutions have some problems. In case of setting width to a fixed value the site ceases to be responsive (the breadcrumb will not size with the window). When setting display to inline-block the gray background shrinks to only cover the links, leaving a white strip to the right. If after setting display to inline-block the width is set to 100% then it overflows the right border (since the width is to take 100% of the parent's element). Maybe the simplest solution would be to just get rid of the spaces?
EDIT:
Just found by accident the proper fix. Overriding inline-block with inline for li in the breadcrumb gives the desired effect without any side issues (AFAIK):
.breadcrumb > li {
display: inline;
}
See also the new version of my fiddle, or open just the show frame in IE8.
I want to apply CSS to a sibling div when an a link is :active
.navigation-menu:active ~ .container-menu,
left: 0;
}
I know IE9 and below don't support this but does IE10?
No it doesn't work in IE10. I tested with the following fiddle: http://jsfiddle.net/uYsXP/
HTML:
<div>
Click me
<div class="container-menu">Bacon!</div>
</div>
CSS:
.navigation-menu:active ~ .container-menu {
color: green;
}
To use the general sibling selector with a pseudo class, you run into some bugs, but this can be fixed. Refer to this article:
http://css-tricks.com/webkit-sibling-bug/
body { -webkit-animation: bugfix infinite 1s; }
#-webkit-keyframes bugfix { from { padding: 0; } to { padding: 0; } }
This should work IE8+
The :active state of a child is not propagated down from the parent (at least in IE 10)
There's a JS workaround posted on this SO answer: Make a whole div clickable with working :active css rule in IE10
It's worth noting that the IE dev team has classified this issue as won't fix
Propagating the active state to ancestor elements can significantly
degrade the responsiveness of web pages due to the large number of
elements that may be impacted by the state change. As a result, this
makes interactive controls feel sluggish to an end user, particularly
in touch interaction where tiny delays are easily perceptible.
source: https://connect.microsoft.com/IE/feedback/details/757765/ie10-active-psuedo-class-should-be-triggered-by-child-elements-too
http://testing.ipalaces.org/ looks different in IE9 where the 2nd LI in sub-navigation makes the top border. It seems the width it's at now works for every major browser but IE9. If I set it to exactly 3px less, it works good in IE9.
Is this a known bug? can I get around this without doing a conditional IE9 CSS call?
The problem is that without an explicit width, #sub-navigation li.selected renders a few pixels wider in IE 9 because of font rendering, interrupting the next floated element. Forcing a width will fix it.
Also, Verdana in bold renders relatively wide so you should consider dropping it from the font-stack.
#sub-navigation li { font:700 16px/1 geneva, sans-serif; }
#sub-navigation li.selected { width:105px; }
How about text-overflow?
+css:
#sub-navigation li span {
white-space: nowrap;
width: 100%;
overflow: hidden;
text-overflow: ellipsis;
}
Try this, anyway I don't have IE (Mac rulz) but in my workplace we usually optimize sites for IE too. I'll check it tomorrow if this is not going to work.
Can I ask, why do you have all the dropdowns featured as a nested list inside the last <li> in the navigation?
If it was me, I'd have each dropdown inside it's own list, as a sub-item fo the parent link.
This way, you can inherit the horizontal boundaries of the drop-down item for the parent-item, and it should be more straightforward to match widths.
Also, the code will read more logically, and expand more easily in future.
You should set a fixed width to all your li's for the submenu depending on the number you want. right now the first list element should be set to width: 107px.
to test it, just add style="width:107px" to <li class="selected">
Good luck :)