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

Implement ::marker #700

Closed
Smylers opened this issue Oct 2, 2018 · 1 comment · Fixed by #922

Comments

@Smylers
Copy link
Contributor

commented Oct 2, 2018

Currently I can't find a reliable way to specify custom style for the numbers (markers) in numbered lists of paragraphs in WeasyPrint — that is, for HTML like this:

<ol>
  <li><p>Urkkk!
  <li><p>Clank!
  <li><p>Glurpp!
</ol>

<ol>
  <li>Biff!
  <li>Ooooff!
  <li>Bang-eth!
</ol>

being able specify styles for the numbers.

  • The spec defines the ::marker pseudo-element ... but that's a draft which says it isn't ready for implementation yet.
  • Putting a counter in li::before and setting some margins and padding is suggested by some, but that only works for short list items that directly contain text; for list items that contain paragraphs, <p> starts a new line, under the li::before. (This isn't a WeasyPrint bug; it's a defect in this approach.)
  • Floating or absolutely positioning the li::before avoids that limitation and works fine in browsers. But in WeasyPrint, if the list item starts near the bottom of a page, sometimes the <li> gets bumped on to the next page, leaving the pseudo-element hanging on the previous page. Chrome appears not to do this (though possibly the page-break simply wasn't being triggered in quite the right spot.) I fear that this is related to #36. I see also there are other issues involving list marker positions (such as #287 and #55), but I'm not sure if they are relevant once the marker has been positioned or floated.
  • For lists with paragraphs in, a workaround could be to apply the desired number styling (such as colour and font) to the entire list, then undo that for li > p. That obviously wouldn't work for lists that don't contain paragraphs. Handling both types of list would require applying different styling to an <li> depending on whether or not it contains any <p>s. The :has() pseudo-class would allow determining that ... but is also a draft, and not implemented by any browsers either.

So I don't know what specifically the bug is here — but surely WeasyPrint should provide some way of achieving this.

@liZe liZe added the CSS question label Oct 2, 2018

@liZe

This comment has been minimized.

Copy link
Member

commented Oct 11, 2018

  • but that's a draft which says it isn't ready for implementation yet.

I think that it's implemented in other browsers, it may be a good idea to implement it. Even if it's a draft, it better than the very little things defined in CSS 2.

  • This isn't a WeasyPrint bug; it's a defect in this approach.

You're right.

  • Chrome appears not to do this (though possibly the page-break simply wasn't being triggered in quite the right spot.)

I think that's an open question, one of the many undefined behaviors with page breaks. It's not directly related to #36, but definitely is with the CSS fragmentation spec that could solve #36 when implemented.

  • For lists with paragraphs in, a workaround could be to apply the desired number styling (such as colour and font) to the entire list, then undo that for li > p. That obviously wouldn't work for lists that don't contain paragraphs.

Looks like a really bad idea 😄.

So I don't know what specifically the bug is here — but surely WeasyPrint should provide some way of achieving this.

Implementing ::marker is the way to go. That would probably help #55 and #287 too.

@liZe liZe changed the title Custom List Markers Implement ::marker Oct 11, 2018

@liZe liZe added feature and removed CSS question labels Oct 11, 2018

@liZe liZe added this to the 49 milestone Aug 7, 2019

liZe added a commit that referenced this issue Aug 7, 2019

@liZe liZe closed this in #922 Sep 3, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.