Chaps, I have come across something really really odd. I won't bother you with too many details, what happened on the website I am working on, but I have managed to recreate the issue in a very simple page. Basically, it seems to me that chrome doesn't handle list-style-position very well. Let's look at an example.

<!DOCTYPE html>
<html>
    <head>
        <style>
            .wrapper ul{
                border:1px solid red;
                list-style: inside disc none;
                color: blue;
                float:left;
                margin-right:11.189%;
                margin-left:8px;
            }
            .wrapper{
                margin:0 auto;
                border:1px solid blue;
            }
            .clear{clear:both;}
        </style>
    </head>
    <body>
                <div class="wrapper">
                        <ul>
                            <li><a href="#">Product1</a></li>
                            <li><a href="#">Product2</a></li>
                            <li><a href="#">Product3</a></li>
                            <li><a href="#">Product4</a></li>
                            <li><a href="#">Product5</a></li>                           
                        </ul>

                        <ul>
                            <li><a href="#">Product1</a></li>
                            <li><a href="#">Product2</a></li>
                            <li><a href="#">Product3</a></li>
                            <li><a href="#">Product4</a></li>
                            <li><a href="#">Product5</a></li>                           
                        </ul>

                        <ul>
                            <li><a href="#">Product1</a></li>
                            <li><a href="#">Product2</a></li>
                            <li><a href="#">Product3</a></li>
                            <li><a href="#">Product4</a></li>
                            <li><a href="#">Product5</a></li>                           
                        </ul>
                        <div class="clear"></div>
                </div>

    </body>
</html>

Right. if you save this and open it in chrome, bring up the development tool with f12, let's find the ul and disable float:left. As you expect the lists don't float anymore, but now enable the floating property again, and see what happens: you will see that the list is now broken, the bullet points are actually above the text. Repeat this making sure you first disable list-style: inside disc none; in the console: you will see that when you toggle the float property the list doestn' break anymore. And it's not just the float property, it is everything - even toggling the color when list-style: inside disc none; is enabled will break the list.

Now if in the console you change list-style: inside disc none; to list-style: outside disc none; and repeat the experiment, you will see the list won't break anymore.

"So what?" I hear you saying. Well, the reason why I am saying this is because something really weird happened to me today. I am working on a site where I have the list-style: inside disc none; applied to some of the unordered lists: well, today, all of a sudden all those lists broke, at the same time, and the bullet points are actually above the text, as you might have seen in the above experiment. That rule list-style: inside disc none; in my case has been there since day 1 (a few months ago) but today, chrome decided it didn't like it anymore. Oh, and it happens only in chrome, it works on any other browser.
One way around this is to change list-style: inside disc none; to list-style: outside disc none;: the list doesn't break anymore, but it means I have to redo all the padding work, and it's quite a bit.
I am not sure whether this is a bug or not, but it's weird
Has anybody ever come across this?

Dani AI

Generated

Short diagnosis and why it’s not your HTML: the behaviour reproduced (markers jumping out of place and returning when you open DevTools or hover) strongly points to a Chrome paint/invalidation bug — the marker for an li rendered with the inside position is part of the list-item’s inline content, so a missed repaint or compositing mismatch can make the marker draw on the wrong line. ’s note that opening DevTools forces the layout to correct is the classic symptom of a repaint-reflow bug. (See the browser docs on paint/ layer debugging and a real engine bug report for the same marker/inside area of CSS layout.) (developer.chrome.com)

What’s happening under the hood: ::marker/the marker box is treated as inline content for list-style-position: inside, so changes in float/compositing or incomplete paint invalidation can separate marker placement from the text baseline. Modern UAs expose ::marker and the list-marker model; that semantic helps explain why repainting vs layout recalc matters here. (developer.mozilla.org)

Practical, low-risk workarounds (try them in this order):

  • Force a repaint/compositing change on the list so Chrome repaints the marker correctly without reworking layout:

    ul.your-list,
    ul.your-list li {
      will-change: transform;            /* hint: create compositing layer */
      transform: translateZ(0);         /* common repaint/composite hack */
      backface-visibility: hidden;      /* optional */
    }

    Note: will-change should be used sparingly (remove it after the condition or apply dynamically). (developer.mozilla.org)

  • If you want a stable, layout-preserving fix that avoids engine quirks, replace the native marker with a controlled one (hide native marker, inject your own). Example pattern:

    ul { list-style: none; padding-left: 1.2em; }
    ul li::before { content: "•"; margin-right: .5em; color: currentColor; }

    Or use ::marker styling where supported. Both give you full control and avoid relying on list-style-position: inside. (developer.mozilla.org)

How to debug further: enable DevTools → Rendering → “Paint flashing” and “Layer borders” to confirm whether the marker is being repainted or composited incorrectly; record a Performance trace to capture paint/invalidations around the toggle/hover. If you can reproduce with a minimal test page, file a Chromium bug with steps and the testcase (the WebKit bug linked above is an example of what a good report looks like). (developer.chrome.com)

Short takeaway: the symptom you described is almost certainly a renderer repaint bug rather than a semantic CSS error. Try the compositing/repaint hint first (least intrusive), and use the pseudo-marker approach if you need a robust cross-browser layout.

Recommended Answers

All 2 Replies

What's really strange, is when I load the google developer tools and refresh, it corrects itself.

That's right. Not only that: sometimes - unfortunately I can't replicate that all the time - when the list is broken, if you hover on the text, it resets itself...

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.