Bug 204937

Summary: Support for resolving highlight pseudo element style
Product: WebKit Reporter: Antti Koivisto <koivisto>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: allan.jensen, commit-queue, esprehn+autocc, ews-watchlist, glenn, gyuyoung.kim, kondapallykalyan, macpherson, megan_gardner, menard, pdr, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 204903    
Attachments:
Description Flags
patch
simon.fraser: review+
patch none

Antti Koivisto
Reported 2019-12-06 01:12:39 PST
::highlight(foo)
Attachments
patch (12.65 KB, patch)
2019-12-06 01:34 PST, Antti Koivisto
simon.fraser: review+
patch (14.00 KB, patch)
2019-12-06 10:35 PST, Antti Koivisto
no flags
Antti Koivisto
Comment 1 2019-12-06 01:34:08 PST
Simon Fraser (smfr)
Comment 2 2019-12-06 08:25:33 PST
Comment on attachment 384996 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=384996&action=review > LayoutTests/ChangeLog:9 > + * highlight/highlight-pseudo-element-style-expected.txt: Added. > + * highlight/highlight-pseudo-element-style.html: Added. OK for now but the tests should really all be web platform tests. > LayoutTests/highlight/highlight-pseudo-element-style.html:7 > +::highlight(green-range) { color: green } > +span::highlight(blue-range) { color: blue } Would be good to test a style that ::highlight sets but span::highlight does not. > Source/WebCore/ChangeLog:25 > + * css/SelectorChecker.h: > + * css/parser/CSSSelectorParser.cpp: > + (WebCore::CSSSelectorParser::consumePseudo): > + * rendering/style/RenderStyle.h: > + * style/ElementRuleCollector.cpp: > + (WebCore::Style::ElementRuleCollector::ruleMatches): > + * style/ElementRuleCollector.h: > + (WebCore::Style::PseudoElementRequest::PseudoElementRequest): > + > + Add the requested highlight name. How does code discover the names of all the applicable highlights for a given element?
Antti Koivisto
Comment 3 2019-12-06 08:31:20 PST
> How does code discover the names of all the applicable highlights for a > given element? The spec connects styles with CSS.highlights.set("example-highlight", highlightRangeGroup); and then you would query for "example-highlight" for all elements within the range. As far as I see there is no need to ever enumerate highlight names.
Antti Koivisto
Comment 4 2019-12-06 10:35:18 PST
WebKit Commit Bot
Comment 5 2019-12-06 11:18:24 PST
Comment on attachment 385026 [details] patch Clearing flags on attachment: 385026 Committed r253210: <https://trac.webkit.org/changeset/253210>
WebKit Commit Bot
Comment 6 2019-12-06 11:18:26 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 7 2019-12-06 11:19:24 PST
Simon Fraser (smfr)
Comment 8 2019-12-07 08:39:41 PST
(In reply to Antti Koivisto from comment #3) > > How does code discover the names of all the applicable highlights for a > > given element? > > The spec connects styles with > > CSS.highlights.set("example-highlight", highlightRangeGroup); > > and then you would query for "example-highlight" for all elements within the > range. As far as I see there is no need to ever enumerate highlight names. I meant how does our text painting code find the list of highlights that may apply to an element?
Antti Koivisto
Comment 9 2019-12-08 00:18:03 PST
> I meant how does our text painting code find the list of highlights that may > apply to an element? Details depend on how you are representing ranges in the rendering side and who is caching styles, but basically 1) look up which highlight ranges containing the element being painted 2) with the range/element pairs look up the styles (via getUncachedPseudoStyle) 3) cache the style somewhere (maybe in the range itself, maybe extension of getCachedPseudoStyle). This is a sort of combination how marker and first-line painting currently works.
Antti Koivisto
Comment 10 2019-12-08 00:19:06 PST
It would be nice to generalize the existing concepts on rendering side rather than writing yet another separate thing.
Note You need to log in before you can comment on or make changes to this bug.