I have an <ol> (ordered list) and in FF, Safari, Chrome it is rendered correctly. However in IE9 it is showing all zeros. It is not a spacing/padding issue because I am able to see the zeros.
My HTML is as follows:
<ol>
<li>Enter basic company information</li>
<li>Select from our portfolio of products</li>
<li>Attach your employee census</li>
<li>Review your selections and submit your request.</li>
</ol>
Anyone run into that problem and hopefully a solution?
This regression has been fixed in Internet Explorer 10 (all document modes). Microsoft has deleted the Connect entry, so you cannot review its status. Since Microsoft now pushes IE10 down automatically, it should be working for all your regular customers.
This is a known IE9 regression, which has been reported on Microsoft Connect:
Ordered list numbering changes from correct to 0, 0
Type: Bug
ID: 657695
Opened: 4/6/2011 12:10:52 PM
Access Restriction: Public0 Workaround(s)
5 User(s) can reproduce this bug
Update:
Posted by Microsoft on 6/14/2011 at 3:20 PM
Thank you for your feedback.We were able to reproduce the issue and are investigating it.
Best regards,
The Internet Explorer Team
HTML page that reproduces bug:
<!DOCTYPE html>
<HTML>
<HEAD>
<TITLE>IE9 Ordered List Zero Bug</TITLE>
<SCRIPT type="text/javascript">
setTimeout(function ()
{
document.getElementById("dv1").innerHTML = "<ol><li>XXX</li><li>YYY</li></ol>";
var container = document.createElement('span');
container.style.cssText = "display:none";
document.getElementById("dv2").appendChild(container);
}, 1000);
</SCRIPT>
</HEAD>
<BODY>
<DIV id="dv1">
<OL>
<LI>AAA</LI>
<LI>BBB</LI>
</OL>
</DIV>
<DIV id="dv2"></DIV>
</BODY>
</HTML>
A workaround is to place an empty element after your DIV:
<div id="one">
<ol>
<li>one</li>
<li>two</li>
</ol>
</div>
<div id="two" style="display:none">
<ol>
<li>three</li>
<li>four</li>
</ol>
</div>
<div id="empty"></div>
Internet Explorer 9 (9.0.8112.16421)
Internet Explorer 8 (8.0.6001.19048)
Internet Explorer 7 (7.0.6000.16982): Works
Google Chrome 10 (10.0.648.134): Works
Another solution :)
Show the element:
el.show();
Then:
setTimeout(function(){
$("ol").css("counter-reset", "item")
}, 1);
<li> elements but not all of them. –
Shippee The empty div workaround did not work for me. Here is some simple jQuery that did the trick.
// Workaround for IE list display bug
$('ol').hide().delay(1).show();
This appears to be a bug in certain scenarios, specifically those that involve AJAX. This article runs through steps to reproduce but does not give any resolution:
http://blog.darkthread.net/post-2011-03-19-ie9-ol-bug.aspx
Note that the article is in Chinese; I translated it with Chrome.
Here is a working fiddle that shows it is possible to dynamically update a list without issue:
Unfortunately, this doesn't rectify the problem when there is a need to combine AJAX/IE9/Ordered Lists, which is probably the case if the OP is using SharePoint.
After wasting several hours on this problem myself, I can confirm that (outside of SharePoint) this is definitely a problem on IE 9.0.8112 on Windows 7. It also appears to impact the CSS counter-increment methodology for implementing ordered lists as well (i.e. it doesn't work; list items are still all numbered with zero).
I will update my answer if I find a better solution than "deal with it"/"remove AJAX".
EDIT: Here is my "better answer".
This code has only received preliminary testing, and involves hooking into the AJAX client-side API. It may break in other versions of IE, or in other browsers. Use at your own risk.
That said, it fixes the behavior of ordered lists displaying all zeros in IE9 with both implicit and explicit start numbers defined (via the start attribute). Note that the start attribute is no longer deprecated in HTML 5.
function endRequest_OL_Fix(sender, args) {
var ols = document.getElementsByTagName("ol");
for (var i = 0; i < ols.length; i++)
{
var explicitStart = ols[i].start;
if (explicitStart > 0) {
ols[i].start = -1;
ols[i].start = explicitStart;
}
else {
ols[i].start = 1;
}
}
}
Sys.WebForms.PageRequestManager.getInstance().add_endRequest(endRequest_OL_Fix);
Once a request completes (including an async request) all OL tags on the page are examined. If they have an explicitly defined start attribute, it will be preserved, reset, and reassigned. Otherwise, start will be explicitly assigned.
This forces a redraw and--with the aforementioned caveats--fixes the problem.
I came across this issue myself recently and came up with a different solution than including an empty div. Could definitely use more testing in different scenarios but this worked for me, even when the list was hidden and shown again.
var ieTimeout;
var selectorWrapperSet = $(selector);
selectorWrapperSet.css("display","none");
ieTimeout = setTimeout(function() {
selectorWrapperSet.css("display","block");
}, 1);
@Alex Kleshchevnikov - http://choosedaily.com/2481/ie9-bug-ordered-list-zeroes-ajax-request/
I was using that code; but, I was still getting zero's. I have modified it to add another OL after the offending one and then hide it shortly afterwards.
"windows_instructions" is the OL that I'm fixing zero's for. "ie_fix" is the dummy OL I'm hiding. I tried using 2 ms as the second timeout; but, it wasn't enough time. Since my ajax content is fading in, I'm not getting a FOUC with 100 ms.
If it's helpful to future fixes, it seems like the issue is always with the last OL on the page.
Here's the code:
if($("#windows_instructions").length>0)
{
$("#windows_instructions").hide();
ieTimeout = setTimeout(function()
{
$("#windows_instructions").show();
}, 1);
ieTimeout = setTimeout(function()
{
$("#ie_fix").hide();
}, 100);
}
First, it's possible to see this bug with nothing but CSS. It happens any time an <ol> is hidden and shown. Example jsfiddle that shows bug.
It's also possible to fix the bug with nothing but CSS in some circumstances. The fix is consistent, but the code is delicate and not the nicest. Lots of things that shouldn't make any difference in CSS do here, so code it carefully. Example jsfiddle that works.. The basic idea is: toggling the line instead of the list, then re-creating the list numbering with counter-reset on the (visible but sometimes empty) <ol> and counter-increment on the <li>.
Advantage: everything here can be tucked away inside an IE-only stylesheet. If the :hover doesn't make sense in your case and you use something like jQuery .show(), consider something based on .addClass() instead.
Talking of adding classes, as if this bug wasn't strange enough already, it seems that <ol>s work in IE in conditions like the first example if Javascript adds a class to the wrapper element - even if the class doesn't do anything. Here's a jsfiddle example. Can't guarantee that'll work anywhere else, but it works here.
If you're trying to understand the bug, a) good luck, and b) take a look at this jsfiddle here. It's what happens if you do the CSS counter option (plus regular numbering), but toggling the <ol>s not the <li>s. You get the crazy situation where, what's shown is completely different depending on whether you mouse over in from the previous sibling, the next sibling, or neither. Makes no sense... but it's probably a clue as to what on earth this bug really means.
I've also got a situation I can't replicate where the numbering is all 1s, all 2s, all 3s etc depending on which <ol> it is: the first on the page becomes 1,1,1,1,1, the second becomes 2,2,2,2,2, then 3,3,3,3,3, etc. Can't isolate what causes that quirk.
From your screenshot, it looks like you're using SharePoint. I'm guessing that there is some CSS interference resulting from exisiting CSS settings in SharePoint.
As a test, try declaring your ol style inline and see if it helps.
<ol style="list-style-type:decimal;">
<li>Enter basic company information</li>
<li>Select from our portfolio of products</li>
<li>Attach your employee census</li>
<li>Review your selections and submit your request.</li>
</ol>
You probably need the following snippet of mark up in your style sheet -
ol {list-style:decimal}
What this does is declare the type of ordered list you would prefer if you haven't yet declared it in your stylesheet.
The numbering issue occurs after revealing a hidden ol element and can be addressed by modifying or adding a class attribute to an element containing the ol element via JavaScript after the ol element has been revealed. The following code does that in a way that doesn't modify existing class attributes in any substantial way, doesn't leave an empty class attribute in the DOM, doesn't require jQuery, and only allows Trident 5.0 browsers (such as IE9) to execute the code:
if (/Trident\/5.0/.test(navigator.userAgent)) { // Windows Internet Explorer 9 Bug Fix
// Official Bug Report: https://connect.microsoft.com/IE/feedback/details/657695/ordered-list-numbering-changes-from-correct-to-0-0
// Bug Fix: https://mcmap.net/q/443959/-ordered-list-showing-all-zeros-in-ie9
if (listContainerElement.hasAttribute("class")) {
listContainerElement.setAttribute("class", listContainerElement.getAttribute("class"));
}
else {
listContainerElement.setAttribute("class", "");
listContainerElement.removeAttribute("class");
}
}
The issue can also be addressed by setting the display property via JavaScript:
listContainerElement.style.setProperty("display", someDisplayPropertyValue);
In my case, I was showing and hiding the list by removing and adding an HTML5 hidden attribute on an element containing the ol element (with [hidden] { display: none; } for IE9 compatibility) rather than directly manipulating the display property, so I ran into this issue.
Had a similar problem with Edge on Windows 10. It was showing 0s next to list items within an on a mobile menu that opened using a css transition. Felt like I tried a hundred variants of list-style: none; and list-style-type: none; on the ol, its parents and descendants.
Ended up with this to fix it in Edge / IE but not mess with the styling that worked for every other desktop and mobile browser:
/*
Hack for Edge browser. Some things never change...
This is definitely dirty, hacky and overkill.
Without this, Edge on windows 10 shows a 0. next to every list item in a mobile menu that is animated with a css transition on our site.
Using technique for targeting Edge from https://mcmap.net/q/224042/-how-to-identify-microsoft-edge-browser-via-css
Answer by KittMedia: https://stackoverflow.com/a/32202953/
*/
@supports (-ms-ime-align: auto) {
.element-im-targeting ol,
.element-im-targeting ol li,
.element-im-targeting ol * {
list-style: none;
list-style-type: none;
}
}
© 2022 - 2024 — McMap. All rights reserved.