- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Sep 2020 16:35:33 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo-4] Add a highlight pseudo-element for find-in-page or scroll-to-text`, and agreed to the following: * `RESOLVED: we're interested and would like chrishtr to pursue and come back with proposal text` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-pseudo-4] Add a highlight pseudo-element for find-in-page or scroll-to-text<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5233<br> <chrishtr> tab go for it, my mic is broken<br> <dael> TabAtkins: I can run with it<br> <dael> TabAtkins: Thread talks about general highlight API. This is about find in page or scroll to text stuff. That they're not exposed is inconsistent and means authors can't have consistent highlight. Proposal is expose those two under same or separate times.<br> <florian> q+<br> <dael> TabAtkins: If same group like UA-selection. Is separate ::find-in-page and ::scroll-to-text<br> <GameMaker> q+<br> <dael> TabAtkins: Opinions? Okay to pursue?<br> <gregwhitworth> TabAtkins: how does this relate to https://drafts.csswg.org/css-highlight-api-1/ ?? As this was created for that if I recall correctly<br> <dael> florian: We talked a month ago. This question doesn't take into account that conversation. If I recall find in page effects by browsers are way beyond highlight pseudo element. Safari does whole page darkening. Not something normal pseudo could do.<br> <fantasai> gregwhitworth, this one hooks into the browser UI<br> <TabAtkins> gregwhitworth: It doesn't, and that's not - that's for a *generic* highlighting mechanism controllable by authors<br> <gregwhitworth> gregwhitworth: ahhh<br> <dael> florian: Conceptually similar but style is very different. We should do some research abotu what browsers do and what authors want to do and if that fits within existing things<br> <smfr> q+<br> <dael> TabAtkins: Browsers do go beyond but they all currently do the same selection-ish highlight. May have other styling but still highlight the selection. It's a pretty basic UX that we feel will be stable across time. being able to customize highlight still seems reasonable to do<br> <florian> q-<br> <astearns> ack GameMaker<br> <dael> GameMaker: My comment is that Safari does darken page. Also I'm not entirely on board where we'd need 2 to do what Chrome does. Highlight whole page in one color and the one you're at is in a different color. this only suggests one thing<br> <dael> GameMaker: Browsers do different things. If we make this a highlight element, elements are styled in more ways. With selection you can do more, but opening to highlight pseudo element there's a whole host of things we can do<br> <chrishtr> q+<br> <dael> GameMaker: I can see why we're considering. I don't know what devs are asking for. I don't know right thing to do it<br> <dael> GameMaker: Summary- Chrome would need 2 colors b/c they highlight all words and the one you're looking at is different. Opening to full pseudo highlight is more than just color and it's opening more than we can do. Need to be cognizant of that and I'm not sure devs are asking for this<br> <emilio> q+<br> <astearns> ack smfr<br> <dael> smfr: One question is if author provides styles does that disable browser built in find highlighting?<br> <dael> TabAtkins: What would be tricky about that?<br> <gregwhitworth> q?<br> <dael> smfr: If styling is simply color no but if more involved later there might be something like appearance where browser decides to turn off built in<br> <dael> myles: Related point where if some elements have pseudo and others don't do we auto-darken the page when at elements that don't have this and when you cmd + G to the next would we change darkening?<br> <gregwhitworth> q+<br> <dael> TabAtkins: I don't think we'd turn off darkening. I was wondering if problems darkening and turning on author supplied highlight colors<br> <astearns> ack chrishtr<br> <emilio> q-<br> <dael> chrishtr: Like to point out there are 2 use cases. Find in page and scroll to text. Chrome has recieved dev desire on scroll to text. When you use this it will highlight bg of selected content in yellow for short period. Many devs find that color doesn't fit with theme<br> <florian> q+<br> <dael> chrishtr: Added find in page b/c thought would be good to think together. Agree find in page is more complex. I think scroll to text is pretty simple<br> <astearns> ack gregwhitworth<br> <una> q+<br> <dael> gregwhitworth: I've likewise heard developer request for this. Having a browser hook would be good. Very valid points on open questions. Feel it warrents a more concrete proposal. As you denoted chrishtr it may vary between the two<br> <astearns> ack florian<br> <dael> gregwhitworth: For a use case there is developer interest and worth exploring<br> <dael> florian: How it would work if it's a highlight is defined. But details on use case would be good to see if they fit. It was mentioned it's a fading yellow highlight. If the fading exposed, timing, control? Knowing this would help us figure out if this is the right thing to do<br> <dael> florian: We know what pseudo highlights do but we kknow less what we're trying to achieve. Good to document. Probably different between find in page and scroll to text. Maybe document both separately. See if it fits the use case<br> <astearns> ack una<br> <dael> una: Bringing this up as opportunity to be consistent. Some browsers highlight all words, some only active. Some difference in colors cross browser. Lots of considerations here. Not jsut contrast but browser experience. And what happens with dark mode, how do we make sure the highlighted word stands out.<br> <florian> q?<br> <dael> leaverou: Another thing is this is a pseudo element that will spawn multiple sub elements. Is there precenent. Is it a special pseudo element?<br> <dael> florian: There's precedent<br> <dael> TabAtkins: Defined in ::selection. Constrained properies that make it hard to tell number of boxes<br> <dael> leaverou: currentColor?<br> <dael> TabAtkins: It's however it works in ::selection<br> <fantasai> See https://drafts.csswg.org/css-pseudo-4/#highlight-pseudos<br> <dael> florian: It's pretty cool, the definition. not tree abiding and weird, but defined weird.<br> <fantasai> The properties supported are not allowed to affect layout in any way<br> <dael> una: B/c contrast issue it might be good to allow this so you can style borders and other parts of highlight to make it stand out. Would help authors make sure text style stands out in their specific design<br> <fantasai> properties currently specified to work is https://drafts.csswg.org/css-pseudo-4/#highlight-styling<br> <dael> chrishtr: dark mode- can't dev proved dark mode style for this?<br> <dael> una: Yes, jsut additional overhead. Good to do b/c author makes sure whatever preference mode these styles have clear visibility<br> <chris> s/will spawn multiple/will span multiple/<br> <dael> TabAtkins: Support that. b/c we all do dark mode I'm of opinion any UA provided color should be under author control to make sure it looks good with both dark and light<br> <dael> florian: I suggest we split the issue in 2. Document what browsers do today and which aspect authros want to control. From there can judge if it's a good fit. Good chance for scroll to text. Find in page, maybe maybe not.<br> <dael> florian: Split the issue, document use cases. Does that sound reasonable?<br> <dael> astearns: Anyone argue it should be a single way?<br> <dael> florian: It might be. If we say highlight pseudo is right that's a single way. That some browsers highlight all and some only active. I think there's also highlight in scroll bar. There's a number of things being done.<br> <dael> florian: If we want to say the find text thing is easy and the other less then we split. But we explore in parallel and if they're easy we do both<br> <dael> chrishtr: Makes sense to split. Scroll to text is much simplier. It's a progressive enhancement of linking property. In Chromium-based it shows a yellow that disappears after user interactions. It's pretty simple<br> <dael> chrishtr: I can file a new issue and go into more detail with examples<br> <dael> florian: Thing I wonder about this is the timeout. Other highlight pseudos aren't timed. Other than that it doesn't sound hard.<br> <tantek> we have examples with much more interaction, such as marginalia, e.g. what Medium does with highlight UI<br> <dael> fantasai: Just like with selection I think UA controls when it exists<br> <dael> florian: Probably<br> <dael> florian: Is this transition out and the transition out is defined by UA? Maybe.<br> <dael> astearns: We'll open at least 1 new issue to separate the two<br> <hober> q++<br> <hober> err, q+<br> <dael> chrishtr: Great to confirm if there's any objection to trying to move forward and spec scroll to text?<br> <astearns> ack hober<br> <astearns> ack +<br> <dael> hober: I don't htink I object. I do think that the find in page one is supported across all browsers and has more complex styling. Tackling harder first means you get easier for free later.<br> <gregwhitworth> q+<br> <tantek> agrees with hober, specify find first since it's more cross-browser<br> <dael> florian: Not sure. At thispoint we're trying to see if the definition fits more problems<br> <gregwhitworth> astearns: my q is an addendum<br> <dael> TabAtkins: The text find thing is a soft problem already. Not jsut easy, it's a none problem once we define it exists<br> <astearns> ack gregwhitworth<br> <tantek> q?<br> <tantek> I don't understand the proposal?<br> <dael> astearns: I think we have a way forward to open another issue<br> <dael> gregwhitworth: Wanted to make sure chrishtr was good with where we're at<br> <dael> chrishtr: Great to resolve that it's useful for scroll to text. Come back with a proposal text to verify with the group<br> <gregwhitworth> ack gregwhitworth<br> <dael> astearns: Prop: We have this facility for browsers that impl scroll to text<br> <dael> astearns: Obj?<br> <tantek> q+<br> <dael> florian: Still curious about how animation works. If we'll come back with a definition of how that works, yes<br> <astearns> ack tantek<br> <dael> tantek: I think framing the scroll to text in terms of highlight is too narrow a framing. Don't object to exploring but object to limiting to juust that<br> <dael> tantek: Medium, for example. If you scroll to a selection of text additional UI occurs where you can annotate. At least couple indy web where you can comment in margins and when you highlight it highlights text you commented on.<br> <dael> tantek: Have in the wild that kind of text that's far beyond simple backgorund highlights. I don't oppose exploring, just want to make sure we're not trying to collapse it with something like find that's mroe limited<br> <dael> chrishtr: Responded to those use cases in github. Those would need script involvement. Similar to how we discussed accent color on form controls this is low hanging fruit. It by no means precludes more customization in the future<br> <dael> tantek: Okay, thanks<br> <dael> florian: From my PoV I would like to know if entire fade in and out is UA controled or if timing is controlled.<br> <dael> chrishtr: I think that's out of scope for resolution and I'll come back with a precise thing.<br> <dael> astearns: Resolution is we're interested and would like you to pursue and come back with proposal text?<br> <dael> chrishtr: Yes<br> <dael> RESOLVED: we're interested and would like chrishtr to pursue and come back with proposal text<br> <florian> s/if timing is controlled./if its timing is UA controlled but the actual fading is controlled from css/.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5233#issuecomment-689678618 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 September 2020 16:35:36 UTC