Specify the bare li element "list-style-position:inside" quirk

[dholbert]

What is the issue with the Quirks Mode Standard?

There's a longstanding list-style-position quirky behavior that browsers have to varying degrees, where they set list-style-position: inside (instead of the initial outside value) on bare li elements (those with no ul parent node) under certain conditions.

In Firefox, this quirk is fairly limited, and it lives here in the quirks-mode UA stylesheet.
https://searchfox.org/mozilla-central/rev/0b1543e85d13c30a13c57e959ce9815a3f0fa1d3/layout/style/res/quirk.css#8-23
(Since it's in the UA stylesheet, the effects of this behavior are shown in the computed styles, and authors can override it if they want.)

For a long time, Chrome and Safari have had a different & broader version of this behavior that's (a) not quirks-mode specific and (b) not overridable by authors; more details/investigation in https://bugzilla.mozilla.org/show_bug.cgi?id=1799724 . But I think they're moving away from that -- WebKit trunk recently aligned with Firefox on the approach here (and that's already in Safari TP, though this change hasn't made it to a Safari official release yet). And I suspect/hope Chromium will change soon as well (maybe here based on current discussion on web-platform-tests/interop#857 (where it sounds like the use-counter's results make this uncontroversial).

So: given the browser alignment here, we should probably specify the quirks-mode-specific behavior that we seem to be aligning on; then we can add WPT tests about the quirky behavior that reference this spec text.

[zcorpan]

If it can be a quirks-mode UA stylesheet rule, it should be defined in HTML's Rendering section. See e.g. https://html.spec.whatwg.org/multipage/rendering.html#flow-content-3:quirks-mode

I'll transfer this issue to whatwg/html.

[domenic]

I'm surprised we're moving in the direction of adding more quirks to the platform, if Chrome and Safari had a non-conditional version of this.

Was it considered to have an author-overridable, but mode-independent, version of this?

[dholbert]

I'm surprised we're moving in the direction of adding more quirks to the platform, if Chrome and Safari had a non-conditional version of this.

Well, we're not so much adding here... This is unequivocally already a bizarre behavior in the platform, no matter how it's implemented/conceptualized. The only question is whether we're able to declare it to be a legacy quirk and quarantine it in the quirks-mode UA stylesheet (which I view as a positive bit of "legacy-weirdness-containment", especially when that weirdness can be implemented with just a few lines of CSS), or whether we need to broaden it to apply everywhere as you might be proposing.

The Chrome/Safari behavior has been to apply it everywhere, but not in a way that we should really draw inspiration from; it's some nonstandard C++ dark magic that's not reflected-in or overrideable-via CSS.

In Firefox, it's always been a few lines of CSS in the quirks-mode stylesheet (as it now is in WebKit trunk now too), which seems much more nicely contained and trivially implementable/understandable.

Was it considered to have an author-overridable, but mode-independent, version of this?

I think that would just be a version of this same proposed UA-stylesheet-rule, but with the change going in the regular UA stylesheet rather than in the quirks stylesheet, right?

I don't think that's been proposed; I suppose it's an option, but this feels like enough of a corner-case-with-bizarre-behavior that I feel a lot better quarantining it in quirks-mode (which is where this has been in Firefox ~forever) rather than adding a new chunk of default styles for all of these elements.

[dholbert]

Historical note: in Mozilla code at least, this behavior (as a quirks-mode-specific thing) goes back to the year 2000 - it first originated here...
https://bugzilla.mozilla.org/show_bug.cgi?id=38026#c9
...and it was part of the contents of the very first copy of "quirk.css" UA stylesheet when that file was first added to the mozilla codebase (presumably for compatibility with IE at the time). Here's a view of that commit (originally CVS) in the gecko-dev git archive:
mozilla/gecko-dev@a8b538c#diff-470ba314359b985be68b6be2601d9c8c0efb5ed5dd64bb4950bfb3b6f75c90c1R42-R49

[domenic]

You say "quarantining to quirks mode", I say "adding another quirk to the platform". I think it's been a goal to try to remove as many such quirks as we can over time, so that developers don't need to worry about things changing when they mistype or forget their doctype. I thought we had somewhat broad cross-browser agreement on that, but maybe not?

[annevk]

cc @whatwg/css @nt1m

[nt1m]

I agree with @dholbert, given this is very bizarre behavior, I'd rather have it behind quirks mode, or entirely removed from the web platform.

[dholbert]

I think it's been a goal to try to remove as many such quirks as we can over time

I definitely agree we shouldn't be coming up with new ideas for quirks (and we should remove existing quirks when the web no longer depends on them).

That's not what's happening here; I'm simply proposing that we standardize something that's been shipping as a quirks-mode thing in Mozilla for 25 years, dating back to the creation of Mozilla's quirk.css file. I'm simply proposing that we formalize that. (Blink/WebKit have also been shipping this behavior as a bit of dark magic, though they happen to not be shipping it in a quirks-mode-specific way.)

so that developers don't need to worry about things changing when they mistype or forget their doctype.

I appreciate that concern; on the other hand: this proposal is trying to mitigate a very-analogous problem: things unexpectedly changing when a developer mistypes or forgets a <ul> wrapper around their <li> elements. The goal here is to quarantine that unexpected-change to only happen in quirks mode.

[dholbert]

(If formalizing this as a quirks-mode behavior is too controversial, I'm not entirely opposed to putting these new styles in the standard UA stylesheet. But on the whole, I'm much more inclined to making this quirks-mode-specific, for reasons discussed above.)

[nt1m]

I'd be more in favor in putting this in quirks mode, to formalize the behavior that Firefox is shipping, and that WebKit is about to ship

[zcorpan]

@dholbert adopting the "quirky" behavior in all modes has happened in the past as a way to "remove a quirk" (i.e. remove a difference between quirks mode vs other modes). This can be preferable because it makes the behavior more consistent between rendering modes.

li not in a list is invalid, so it doesn't matter so much that the behavior is weird also in standards mode.

However, I realize now that li in menu will get list-style-position: inside, which is not good and doesn't match Firefox's original behavior (which included menu and dir). menu is a conforming element. I think we should add menu and dir again.

Demos:

• https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13452
• https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13453

[AtkinsSJ]

I'd appreciate this becoming standardised in one way or another, just because it's recently caused confusion when developing Ladybird. (See LadybirdBrowser/ladybird#2433 ) When different major browsers handle this differently, it's very unclear what we should be doing to be compatible.

Cc: @Psychpsyo

[dholbert]

li not in a list is invalid, so it doesn't matter so much that the behavior is weird also in standards mode.

That's fair I suppose. I guess I don't have a strong preference as to the direction here; I still lean towards the proposed quirks-mode-only thing, but I'll accept whatever the decision is.

(Note that I recently added WPTs in https://bugzilla.mozilla.org/show_bug.cgi?id=1944384 that are testing the standards-mode behavior -- those tests expect that there is no special list-style-position behavior in standards-mode. But I'm happy to update those WPTs as-needed if we decide to promote the li { list-style-position: inside } etc. rules to the standard UA-stylesheet, making this special case active for all modes.)

[Loirooriol]

I prefer not to put this behavior into standards mode. list-style-position is an inherited property, so this implies a testcase like

<!DOCTYPE html>
<div style="margin-left: 40px; border: solid">
  <li>
    a
    <div>
      <p>
        <span style="display: list-item">b</span>
      </p>
    </div>
  </li>
</div>

where we currently have interoperability that the <span> has an outside list position, would change to have an inside position just because some random ancestor happened to be a <li> with no <ul> or <ol> ancestor. That seems very weird, and could affect websites.

So I would prefer to restrict this to quirks mode, which matches Firefox, so we already know the risk of other browsers changing is small.

[domenic]

To be clear, I'm not insisting on anything, or representing Chromium as an implementer. I'm acting in role as spec editor to try to represent the portion of the community that wants to have as few quirks as possible. (Which might be smaller than I thought.)

If even after considering that point of view, the majority of implementers would prefer a quirk, e.g. for compat reasons, then we should spec a quirk.

[zcorpan]

The web compat argument could be made both ways: web sites might expect the inside behavior of Chrome and Safari in standards mode.

https://bugzilla.mozilla.org/show_bug.cgi?id=1891045 currently lists one web compat bug in "Blocks": https://bugzilla.mozilla.org/show_bug.cgi?id=1891048 which points to this website which renders with bullet points (for "TelVerde", "Formular de contact online") in current stable Chrome and Safari, but missing bullets in Firefox.

I think this situation seems more likely than the example @Loirooriol gave.

I can dig into httparchive to find more cases of listless <li> to find out which approach is more compatible.

[Loirooriol]

Yes it's true that Firefox has that compat bug so the change is not free of risk for WebKit and Blink. But my point was that applying the quirk in standards mode doesn't match the behavior of any browser, so it seems a bit more risky for me. So OK, let's check httparchive.

[zcorpan]

Method

I queried httparchive.response_bodies.2024_11_01 for pages that have <li> but not <ol> or <ul>, and recorded the page url, rank, whether the page contains <menu> or <dir>, and whether it starts with a standards mode doctype. Then I had ChatGPT write a script to fetch each url, parse it with jsdom, and reduce the list to pages where an <li> has computed display === "list-item" and listStylePosition !== "none". (This reduced the list somewhat, but seemingly not as much as doing the same in a real browser.)

I then manually checked top-ranked pages, sorting by standards mode, then contains_menu_or_dir, and also checked a few quirks mode pages with contains_menu_or_dir. In total I looked at 190 pages.

Results

• 5 pages have better rendering in stable Chrome/Safari (expects inside in standards mode)
• 5 pages have better rendering in stable Firefox (expects outside on li in menu/dir)
• 8 pages have minor visual difference but I couldn't tell if one or the other was better/intended.
• The rest had no visual difference.

Details: https://docs.google.com/spreadsheets/d/1MeanhyFVs2-eglZ8A5ZoV5IQ2Jtjw5MVeFdGGc66TrE/edit?gid=749028501#gid=749028501&range=A1

Conclusion

• The quirk should apply in all rendering modes, to improve compat for 5 pages (regressing none).
• The UA style rule should include menu and dir, to improve compat for 5 pages (regressing none).

[fantasai]

Aligning on Firefox's behavior makes more sense to me than standardizing on a quirky HTML-dependent rendering behavior that is not reproducible or overrideable in CSS... It's better for authors and for implementers to keep our quirks to things that can be expressed in a UA style sheet, if possible.

[dholbert]

Emilio's got a noteworthy observation over in #10959 (comment) (which I'll repeat over here since this is mostly where we've been discussing the tradeoffs) - there may be a performance cost to moving these selectors into the standards-mode stylesheet.

We can continue taking that performance hit on quirks-mode pages, but it's nice to avoid taking it in standards mode if we don't have to.

[zcorpan]

OK, it seems the preference is to only apply the styles in quirks mode.

In terms of compat impact, if the numbers are representative, it impacts on the order of ~0.001% of pages. But the performance cost of the selector in standards mode affects the vast majority of pages and li is the 4th most frequently occurring element. https://almanac.httparchive.org/en/2024/markup

I think we should still include menu and dir in the selector (in quirks mode), since HTML's other UA rules include them and menu is not obsolete.