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.

Sign up for GitHub

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

Jump to bottom

[css-inline] When does an empty inline suppress the whole line when in a list? #5276

Open
emilio opened this issue Jul 1, 2020 · 7 comments
Open

[css-inline] When does an empty inline suppress the whole line when in a list? #5276

emilio opened this issue Jul 1, 2020 · 7 comments
Labels
css-inline-3 Current Work css-lists-3 Current Work

Comments

@emilio
Copy link
Collaborator

emilio commented Jul 1, 2020

Consider these examples, extracted from a real website.

  • data:text/html,<!doctype html><ul><li><span></span><p>bar</p></li>
  • data:text/html,<ul><li><span></span><p>bar</p></li> (same as above, but quirks instead of standard mode).
  • data:text/html,<!doctype html><li><span></span><p>bar</p></li> (same as the first example, but with a wrapping <ul>)
  • data:text/html,<li><span></span><p>bar</p></li> (same as above, but quirks)

Browsers seem to disagree on whether the <span> should take space:

  • WebKit thinks the <span> should never take space.
  • Gecko changes depending on the quirks mode.
  • Blink differs depending on whether there's an <ul> or not (lol). I suspect there's a better explanation for this, cc @kojiishi.

So... It's not clear to me the spec defines this case, but I may be wrong... Browsers clearly disagree even in standards mode.

I think I like WebKit's behavior more, as it's more consistent with how layout works when markers are not involved... I can dig on why Gecko only behaves like this in Quirks mode if needed. But people may have different opinions?
@emilio emilio added the css-inline-3 Current Work label Jul 1, 2020
@Loirooriol
Copy link
Contributor

Blink differs depending on whether there's an <ul> or not (lol).

That's because Blink has an ugly quirk (even in standard mode) that if you have a <li> element (other elements with display: list-item are fine) which is not a descendant of an <ol> or <ul> element, then the marker is forced to have an inside position (this doesn't affect the computed value of list-style-position). See https://crbug.com/590094

@fantasai
Copy link
Collaborator

fantasai commented Jul 1, 2020

But people may have different opinions?

I mean, I think we want the least hacky thing that doesn't break Web-compat. :)

@Loirooriol
Copy link
Contributor

I don't like what WebKit does for inside markers. Inside markers are supposed to be a normal inline, and then if you have a block box, it should appear below. This is what Firefox and Chromium do, but not WebKit (regardless of quirks mode):

data:text/html,<ul><li style="list-style-position:inside"><p>bar</p></li>

Then, if you insert and empty span between the marker and the block, since there is already some inline content (the marker), the result should be the same, which seems to be the case for all browsers (regardless of quirks mode):

data:text/html,<ul><li style="list-style-position:inside"><span></span><p>bar</p></li>

Outside markers are kind of out-of-flowish so I would expect these to be equivalent (except for the ::marker):

data:text/html,<ul><li><span></span><p>bar</p></li>
data:text/html,<ul><li style="display:block"><span></span><p>bar</p></li>

That's already the case in quirks mode. But not in standards mode for Firefox. So I prefer what Chromium and WebKit do.

@emilio
Copy link
Collaborator Author

emilio commented Jul 2, 2020

Yeah I had not tested inside markers but I agree with you that WebKit is wrong tehre.

@fantasai fantasai added the css-lists-3 Current Work label Jul 6, 2020
@kojiishi
Copy link
Contributor

kojiishi commented Jul 8, 2020 •
edited
Loading

Thank you @Loirooriol for the analysis. So two separate issues result in this differences?

  1. Whether to make markers inside or not when not in <ul>/<ol>.
  2. Whether to break or not for inside marker + <span></span> + <p>.

?

For 1, this WIP has the history, quoting:
https://codereview.chromium.org/2463573002/

The history of this change would help, by the way.
I see that it goes back to the KHTML days.
:
Venkat reached out to Lars, the original author of the change and he actually
responded. :)
He says it was probably done to match Internet Explorer at the time.
I just checked Internet Explorer 11 using previous document modes. Internet
Explorer 7 and earlier render like Chrome.
So, yes, KHTML matched old Internet Explorer at the time, but while Microsoft
fixed that quirk, KHTML derivatives remained quirky.

The only remaining question is whether sites depend on this behavior...

@fantasai
Copy link
Collaborator

fantasai commented Jul 8, 2020

@kojiishi Inside markers are supposed to behave the same as any other inline box with the corresponding content. So I think the original issue here is about outside markers only?

@kojiishi
Copy link
Contributor

kojiishi commented Jul 9, 2020

So I think the original issue here is about outside markers only?

Trying to sync. So, case 3 and 4 (without wrapping <ul>) were raised only to understand the behavior. Now we understood they are from https://crbug.com/590094 thanks to @Loirooriol, and it is a separate topic, so we want to discuss only case 1 and 2. Am I in sync now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-inline-3 Current Work css-lists-3 Current Work
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@fantasai @kojiishi @emilio @Loirooriol