Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<li> marker is invisible on otherwise empty page #2433

Open
1 task
Psychpsyo opened this issue Nov 19, 2024 · 3 comments
Open
1 task

<li> marker is invisible on otherwise empty page #2433

Psychpsyo opened this issue Nov 19, 2024 · 3 comments
Labels

Comments

@Psychpsyo
Copy link
Contributor

Psychpsyo commented Nov 19, 2024

Summary

When I open data:text/html,<li> in Ladybird, the page looks completely empty.

This might be related to #2432
EDIT: This is to spec, but inconsistent with Chrome and also with quirks-mode Firefox.

Operating system

Linux

Steps to reproduce

  1. Open data:text/html,<li>.

Expected behavior

There should be a single black dot on the page.

Actual behavior

There is nothing on the page.

URL for a reduced test case

data:text/html,<li>

HTML/SVG/etc. source for a reduced test case

<li>

Log output and (if possible) backtrace

Nothing

Screenshots or screen recordings

image

Build flags or config settings

No response

Contribute a patch?

  • I’ll contribute a patch for this myself.
@AtkinsSJ
Copy link
Member

I'm not sure if this is a bug or not, it's inconsistent between browsers, and isn't specced as far as I can tell.

In Firefox, the marker is visible because data:text/html,<li> enables quirks mode, and it has li { list-style-position: inside; } in its quirks CSS file. data:text/html,<!doctype html><li> makes it look like Ladybird, because the marker goes off the left edge of the page.

Chrome somehow has the marker visible always, despite having the default list-style-position: outside.

Ladybird always has the marker off the page, regardless of the doctype being set.

@AtkinsSJ AtkinsSJ added the css label Jan 15, 2025
@Psychpsyo
Copy link
Contributor Author

Psychpsyo commented Jan 15, 2025

I'm not sure if this is a bug or not, it's inconsistent between browsers, and isn't specced as far as I can tell.

Just checked the specs and, as far as I can tell, this is specced:
15.3.7 Lists in the HTML spec says that <li>-elements should have display: list-item; by default.
2. Box Layout Modes: the 'display' property in css-display-4 says that that expands to block flow list-item, meaning the outer display type is block, making the element a block container.
3.5. Positioning Markers: The 'list-style-position' property in css-lists-3 says that the initial value for list-style-position is outside, which, for block containers means that the marker box is placed outside the element's principal box, on the inline-start side.

TL;DR: The marker should be outside of the <li>.

Also, Firefox's quirks stylesheet is the way it is "for backward compatibility", whatever that means.
Chrome behaves the way it does because its parser does some magic to match what internet explorer did back then.

Adding a sufficient margin on the body does reveal the marker in Ladybird, so yes, this is actually to spec and not a bug.
Not sure if we should bother with matching the other browsers on this, especially since Chromium also wants to get rid of their magic and any document that can trigger this is non-conforming anyways.

@Psychpsyo
Copy link
Contributor Author

Psychpsyo commented Jan 16, 2025

One more bit I just stumbled upon:

Microsoft has actually documented their non-standard quirk for this here:
https://learn.microsoft.com/en-us/openspecs/ie_standards/ms-css21/7b7dd76a-ed48-439e-b7b3-939100cb403d

7.2 The effects of quirks mode emulation

  • List item markers. The default value of list-style-position is "inside" if the list-item is outside a <UL> or <OL> element, and "outside" otherwise.

(I'm not saying we should support this, just that I found the source of this nonsense)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants