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.