I've prepared this demo:
https://dl.dropbox.com/u/7224702/lists-bug.html
It works fine in Firefox, Chrome and IE8 but is broken in Opera and IE9.
Oh and I don't want to use list-style-position: inside; because if some <li> is longer then one line the second line is not correctly indented.
This is a problem with lists that isn't really specified by CSS. It just says that the marker is outside the box but doesn't precisely specify where.
You could perhaps solve it with text-indent to move the first line back again.
That's the question that's been bothering me for some time as well.
First of all if we look at the spec describing the list-style-position: outside property we will see that
"CSS 2.1 does not specify the precise location of the marker box or
its position in the painting order".
This actually makes this situation not a bug, merely different implementations.
IMO Opera and IE9 make it closer to the spec - which is to put the marker... well... outside the box. In case of floats the box made by the li element is still full-width, only content is shifted inside of it.
I tried to think of alternative solutions but they still turn out to be inappropriate and cause more problems than they solve. An example of using css3 counter increment can be seen here: http://jsfiddle.net/s3sZS/3/, but visually it looks like list-style-position: inside (your indentation problems remain) and the increment itself is selectable and copyable (at least in Opera).
Actually list-style-position: inside looks like the only appropriate solution to this imo.
If you are interested in future implementations of lists - you may read the CSS Lists and Counters Module Level 3 (currently Editor's Draft).
Little later then planned but here is my final solution.
Use list-style-position: inside;.
To repair the indenting of second and folowing lines, use negative text-indent (thanks Joey!)
It is not easy to determine the right value for the negative text indent as every browser does things little differently. Knowing that we will need to use something where we can set the width of the marker manually. And that something is pseudo-element :before. (thanks skip405!)
With the :before pseudo-element and right value of the content property we can now use list-style-type: none;
Delete the list-style-position from 1. as it's useless now.
You can see working demo here:
https://dl.dropbox.com/u/7224702/lists-counters.html
The only drawback is with content: counter(list, disc); in Opera 12. The disc/circle/square values are not working as they sould, values like decimal are alright. I've already reported it as a bug so hopefully it'll be fixed in next version.
Related
We wanted some numbered lists and found this cool counter thing you can use in you css to have the browser calculate numbers for you:
ol.instructions {counter-reset:instructions-section;}
ol.instructions > li:before {
content:counter(instructions-section);
counter-increment:instructions-section;
}
The html we're making contains pages of instruction sets, each set numbered from 1,2,3 and so on. Only one set is visible at a time, when you click a header you show that set and hide the others.
It worked like a treat and we were sitting there with smiling faces until someone thought of testing it in Internet Explorer 8, where we ran into some epic Microsoft-style weirdness. When a set was brought up by clicking, all the numbers were zero (0).
I googled around and found this page - it describes the problem fairly well (it's a combination of using :hover and css counter logic used in hidden content), but gives a solution that is less than satisfactory - I would love to be able to keep using the css counters and just implement some ie8-specific hack that somehow makes the page update the numbers. I'm having a hard time finding other stuff on the internet about this problem.
My particular page will describe zeroes until I move the mouse pointer into the div that contains the numbered list, at which point the numbers will magically fix themselves. Is there something I could to "nudge" the page into believing that a mouse is hovering over the element? Or is there a more proper solution?
Ive had the same issue. I was able to fix it by using JavaScript to apply inline CSS of padding-left 0 (there was already no left padding) once the element was visible. This seems to make IE 'redraw' the element.
If, as is suggested, the "hidden" is causing a problem then you could try "hiding" the content by instead moving it off screen with this piece of CSS:
.hide {
position:absolute;
left: -1000px;
}
I've used the code example from the linked to document to show a possible solution here: http://codepen.io/akademy/pen/LDhGl
I've set the padding of the li element to 0 but there is still about 10 pixels worth of padding. How do I shorten the amount of padding provided?
Don't want to be boring :) But in my opinion negative declaration text-intend:-5px; a kind of wrong trick. I know it does trick the browser default styles. But basically it just moves the text outside of the parent element, making something like a hanging intend.
I've tried to find those browser inherited styles, but there are none of them that would create such padding around bullets/discs.
I did some research and found out that CSS3 has special pseudo-element ::marker to address this issue. The idea is great, but unfortunately it is still not implemented in any browser :(
Mozilla has own temporary trick to better style bullets :-moz-list-bullet - https://developer.mozilla.org/en-US/docs/CSS/:-moz-list-bullet
No other vendors that either support or have implemented such hack
CSS3 also has new value for list-style-position: hanging, that may help. But it's still not well defined.
Another solution is to use pseudo-element ::before (no support in IE7)
li:before {
content:"•";
margin-right:1px;
}
After all seems there is no any interest or need to address this issue. Everybody happy with text-intend.
In fairness in the end of the day why the heck would you want to remove that space between bullet and text :)) I think that's the case they called - accidental implementation
In my website, there are lots of buttons. When viewing in Chrome, the button width just fit on the dynamic button text, but in IE, I can see extra padding are produced on both left and right...
Would there be any CSS rule that can allow me to take away these padding? Thanks.
Might be a bit late, but when I searched SO for the very same problem today I found this question. Obviously, this is no real padding (in a sense that it cannot be turned off by padding:0px), but rather one of those weird oddities that we all love so much about IE. (Note how the false padding scales with button text length O_o). Fortunately, there is a simple solution to it, as described here.
Basically you only add overflow:visible; to the button (I did not need the extra width:auto;as described there). Don't ask - it's absolutely not what you'd have thought this should do, but well... It's IE Land and the rules are different over there. Just note that this apparently does not work when your buttons are inside a table cell.
I guess the CSS reset might have solved this, because someone already included this in some global declaration. Just adding this answer to shed some more light on the how and why.
Never give up, people - our children will see a world without IE quirks... One can hope.
You can use reset css as it avoids browser inconsistencies.
Please refer http://sixrevisions.com/css/css-tips/css-tip-1-resetting-your-styles-with-css-reset/
Visit http://www.cssreset.com/scripts/html5-doctor-css-reset-stylesheet/ for reset.css
Managed to avoid extra spacing in IE with extra statement display:block; in CSS like so:
.menu button{
display:block;
width:100%;
padding:0;
}
Note that I didn't use width:auto as it wasn't an option in my case - buttons are empty, width is taken from parent div.
See the picture above. Each navigation tab needs to have 2 pixels separation on either side and line up exactly with the header image on the edges.
Now they would like to introduce a 5th navigation tab (and possibly a 6th). Is it possible to code this in a way where you could stick a 5th or 6th tab in there and everything would resize appropriately with lists or tables or some other solution? Still keeping the 2 pixels separation and lining up with the edges exactly? I wasn't sure if it was possible or you would just have to define the widths each time for each tab based on the math involved to line it all up correctly flush with the edges.
I think the best way is to emulate table behavior with CSS. So you can use a list, and still get table behavior.
ul {
display:table;
}
li {
display:table-cell;
}
Here is a demo displaying this with CSS and proper markup. Here's a demo of how it looks with an actual table. I'm not certain on IE<8 support for this CSS, so it may be something to be aware of.
UPDATE: Confirmed: This is not supported on IE6 or 7 natively. You may be stuck with tables or hard-coded widths if you want to support those browsers. There may be a javascript fix to support these display values but I'm not aware of it.
EDIT: I realized my demos were sloppy, so I made another that actually addresses your point about the margins, it uses the :first-child selector to remove the margin from the first link, giving the evenly distributed appearance. http://jsfiddle.net/wesley_murch/pe6wd/3/
It may not be easy. One of the requirements in most implementations of css horizontal menu type displays is setting a fixed width for each element. If you try and do percentages, things start to come apart. However, any thing is possible.
Have you tried looking at LESS or SASS so you can do simple math in CSS?
I'm not sure that this will be easy to explain without just showing you so here is an example -
http://jsfiddle.net/46gL8/1/
When viewed in FF, Chrome, and IE8/9 the example works as expected. When viewed in IE7 the nested UL is rendered inside of the parent despite both being positioned absolutely. Things like z-index make no difference and the only fix was to remove the filter: line from the shadow class.
I suppose it would be fine to just render a regular border or something in IE7 but it would be awesome if anyone had any insight!
It looks like the filter cuts off all content that falls outside the filtered box. If you remove the submenu from the hierarchy of the main menu, it does work. See: http://jsfiddle.net/wyDTQ/
Of course, I don't know how you're constructing your menu, so that might not be what you want. It does fix your issue, though.
Seem you only need an explanation rather then a solution. Everything you need to know about the filter property is explained by Microsoft at http://msdn.microsoft.com/en-us/library/ms532847%28VS.85%29.aspx, no further details is given to why or how it works in certain scenarios.