Bug 61426 - summary::before renders in wrong position
Summary: summary::before renders in wrong position
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Web Components Team
URL:
Keywords: InRadar
Depends on:
Blocks: 72352 252223
  Show dependency treegraph
 
Reported: 2011-05-25 00:53 PDT by Roland Steiner
Modified: 2023-02-13 18:51 PST (History)
14 users (show)

See Also:


Attachments
Test case (517 bytes, text/html)
2011-05-25 00:53 PDT, Roland Steiner
no flags Details
All browsers differ from each other (622.76 KB, image/png)
2022-09-02 14:00 PDT, Ahmad Saleem
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roland Steiner 2011-05-25 00:53:15 PDT
Created attachment 94749 [details]
Test case

Generated content with a selector equivalent to "summary::before" renders before the expand/collapse triangle for the parent <details> element. Given that <summary> contains the text that is to be displayed after the triangle, it would probably be more correct to render it directly before that text (i.e., after the triangle) instead.

Cf: "li::before" is also rendered directly before the contents of the list items, not before the list item bullet or ordinal.
Comment 1 Dominic Cooney 2011-05-25 01:23:21 PDT
Does shadow DOM need a way to specify where the :before/:after content goes? (Something like <content> that can select :before or :after?)
Comment 2 Dimitri Glazkov (Google) 2011-05-25 08:27:42 PDT
In this particular case, our implementation needs to start using CSS3 Lists ::marker semantics for details marker (http://www.w3.org/TR/css3-lists/). This is, of course, is blocked in implementing CSS3 Lists spec.
Comment 3 Hajime Morrita 2011-12-05 00:01:10 PST
Tree reforming: Unblocking 72352 because 59827 is already blocking it.
Comment 4 Ahmad Saleem 2022-09-02 14:00:53 PDT
Created attachment 462105 [details]
All browsers differ from each other

As can be seen from the attached screenshot that all browsers differ from each other. Just want to share updated testing screenshots. Thanks!
Comment 5 Radar WebKit Bug Importer 2022-09-02 15:15:15 PDT
<rdar://problem/99506326>
Comment 6 Ahmad Saleem 2022-10-13 07:39:19 PDT
Firefox Nightly 107 is now matching Chrome Canary 108 and Safari Technical Preview 155 is just different now. Thanks!