W3C

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

09 Sep 2020

Attendees

Present
argyle, florian, dael, chrishtr, cbiesinger, futhark, huijing_, bkardell_, faceless, alisonmaher, rachelandrew, GameMaker, jensimmons, dandclark, gregwhitworth, myles, oriol, dlibby, dholbert, hober, dauwhe_, antonp, &, Lea, smfr, una, tantek, faceless2, Chris
Regrets
Chair
SV_MEETING_CHAIR
Scribe
dael

Contents


<scribe> ScribeNick: dael

astearns: I think we have enough people to start
... One extra item is a reminder we're having an extra meeting tomorrow to talk MathML topics
... Same time, just tomorrow

bkardell_: Looking forward to it. invited some CG members

astearns: Any changes to today's agenda?

[css-conditional-3] Let's finish the specification

github: https://github.com/w3c/csswg-drafts/issues/5315

chris: CSS Conditional 3 is almost ready and almost done. Very few open issues
... Test suite is fully passed but API section doesn't have tests. Can write script test easily. 3 must items are untested but fairly easy
... Most open issues don't look hard. Maybe push some until further level.
... One problem, don't currently have an editor. If needed I could do the work and happy to help. if there's a bunch of work we can finalize

fantasai: Vaguely recall 14 or more open issues but not sure if they're in GH

chris: 7 open, 22 closed. I did a bunch of getting out of older requests and putting into GH a year ago

fantasai: Okay
... I think we should invite dbaron as an invited expert if he'd like. If he wants to edit is separate question. I'm happy to help with editing. I think I did make a list of issues at some point

chris: That would help, thank you
... Call for dissenting opinion, help is appreciated. Unless there are dependent issues I think we can finish this topic

astearns: Anyone else volunteering to edit?

TabAtkins: I'm interested in general. I'll be happy to look if you need help on something specific

chris: thanks

astearns: Agree we should get dbaron back as invited if he likes, but I believe he's on parental leave too

chris: This was last published in 2013 so it needs some tlc

astearns: Shall we make fantasai and chris editors?

chris: fine for me

RESOLUTION: Add chris and fantasai as editors to CSS Conditional 3

[css-pseudo-4] Add a highlight pseudo-element for find-in-page or scroll-to-text

github: https://github.com/w3c/csswg-drafts/issues/5233

<chrishtr> tab go for it, my mic is broken

TabAtkins: I can run with it
... 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.
... If same group like UA-selection. Is separate ::find-in-page and ::scroll-to-text
... Opinions? Okay to pursue?

<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

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.

<fantasai> gregwhitworth, this one hooks into the browser UI

<TabAtkins> gregwhitworth: It doesn't, and that's not - that's for a *generic* highlighting mechanism controllable by authors

<gregwhitworth> gregwhitworth: ahhh

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

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

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
... 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
... 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
... 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

smfr: One question is if author provides styles does that disable browser built in find highlighting?

TabAtkins: What would be tricky about that?

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

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?

TabAtkins: I don't think we'd turn off darkening. I was wondering if problems darkening and turning on author supplied highlight colors

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
... 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

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
... For a use case there is developer interest and worth exploring

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
... 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

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.

leaverou: Another thing is this is a pseudo element that will span multiple sub elements. Is there precenent. Is it a special pseudo element?

florian: There's precedent

TabAtkins: Defined in ::selection. Constrained properies that make it hard to tell number of boxes

leaverou: currentColor?

TabAtkins: It's however it works in ::selection

<fantasai> See https://drafts.csswg.org/css-pseudo-4/#highlight-pseudos

florian: It's pretty cool, the definition. not tree abiding and weird, but defined weird.

<fantasai> The properties supported are not allowed to affect layout in any way

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

<fantasai> properties currently specified to work is https://drafts.csswg.org/css-pseudo-4/#highlight-styling

chrishtr: dark mode- can't dev proved dark mode style for this?

una: Yes, jsut additional overhead. Good to do b/c author makes sure whatever preference mode these styles have clear visibility

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

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.
... Split the issue, document use cases. Does that sound reasonable?

astearns: Anyone argue it should be a single way?

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.
... 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

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
... I can file a new issue and go into more detail with examples

florian: Thing I wonder about this is the timeout. Other highlight pseudos aren't timed. Other than that it doesn't sound hard.

<tantek> we have examples with much more interaction, such as marginalia, e.g. what Medium does with highlight UI

fantasai: Just like with selection I think UA controls when it exists

florian: Probably
... Is this transition out and the transition out is defined by UA? Maybe.

astearns: We'll open at least 1 new issue to separate the two

<hober> err, q+

chrishtr: Great to confirm if there's any objection to trying to move forward and spec scroll to text?

<astearns> ack +

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.

<tantek> agrees with hober, specify find first since it's more cross-browser

florian: Not sure. At thispoint we're trying to see if the definition fits more problems

<gregwhitworth> astearns: my q is an addendum

TabAtkins: The text find thing is a soft problem already. Not jsut easy, it's a none problem once we define it exists

<tantek> I don't understand the proposal?

astearns: I think we have a way forward to open another issue

gregwhitworth: Wanted to make sure chrishtr was good with where we're at

chrishtr: Great to resolve that it's useful for scroll to text. Come back with a proposal text to verify with the group

astearns: Prop: We have this facility for browsers that impl scroll to text
... Obj?

florian: Still curious about how animation works. If we'll come back with a definition of how that works, yes

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
... 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.
... 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

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

tantek: Okay, thanks

florian: From my PoV I would like to know if entire fade in and out is UA controled or if its timing is UA controlled but the actual fading is controlled from css/.

chrishtr: I think that's out of scope for resolution and I'll come back with a precise thing.

astearns: Resolution is we're interested and would like you to pursue and come back with proposal text?

chrishtr: Yes

RESOLUTION: we're interested and would like chrishtr to pursue and come back with proposal text

[css-pseudo-4] Standardizing input[type="range"] styling

github: https://github.com/w3c/csswg-drafts/issues/4410

gregwhitworth: I can try and take if it the person isn't on the call

emilio: These people rpoposed standardizing a model similar to Gecko. Subtle differences. Added to get feedback. Modal is fairly simple. Could go one way or other. Would like to hear from WK and Blink if it's interesting to using more Gecko-like model and if there's interest in standardizing.

<fantasai> Proposal:

<fantasai> ::range-thumb { /* Styles the thumb of the input*/ }

<fantasai> ::range-track { /* Styles the track of the input*/ }

<fantasai> ::range-progress { /* Styles the progress/fill below the thumb of the input*/ }

gregwhitworth: To get more specific the proposal is 3 different items. Range-thumb, range-check, and reange-progress. Concrete is missing
... did a decent amount of research b/c I was hesitant we'd design into a corner. These 3 are unanimous. I'm in favor of standardizing. Would need concrete what can/can't they do analysis.

iank_: From blink, I don't know if mason is on. Quick look this is interesting. Would welcome improvement. I don't think we have concept of progress element, but could be wrong. Agree with gregwhitworth and analysis of what properties would/wouldn't be respected would pave way for easier implementation

gregwhitworth: I will note WK you have a concept of tracking. I don't know if you have an element.

iank_: I don't believe we have an element.

gregwhitworth: Okay, okay

iank_: Just purely a paint effect I believe

gregwhitworth: I had requested the research. We can action me and I'll reping the person to know what's interop so we cna get a concrete proposal

iank_: Sounds great

smfr: WK has html progress which is pre-fork. Certainly interested in participating in standardizing
... the range pseudo elements

astearns: Sounds like we have consensus to work in this area

ACTION gregwhitworth respond to commentor on #4410 to see if they can do the research

gregwhitworth: Yep. smfr if you can see what you limit that would be great. I'll compare with Maz in Chromium

iank_: We recently did a bit of work to simplify in this area so may be pretty different to WK

<florian> I wonder if we're painting ourselves into a corner, and excluding alternative designs (dial like, or other things)

gregwhitworth: Got it. I'll definitely test

jensimmons: I want to advocate for a holistic way to get at these problems. Similar space to other conversations. Jumping to we should make pseudo elements. We should look at the whole system, not just this one control. gregwhitworth I think said this in the thread. Terrific we're doing this, but should look at whole thing and not just design separately

leaverou: Agree with jensimmons. We standardize pseudo elements on a piece by peice basis. There was proposal for parts to standardize. What happened to it? Why create different pseudo elements when can make one for all form controls.

<tantek> +1 jensimmons, take a look at the whole system

<una> +1 jensimmons and leaverou as well -- forms need wholistic review

gregwhitworth: I really do think and maybe there's an OpenUI joint meeting that makes sense, I don't want to paint into a corner. OpenUI is holistic appraoch. There's 3 or 4 topics where we talk in meta and go in circles while we do ad hocs. But I don't disagree with accent color and these where it technicallye xists
... We should do the holistic thing but web is the web today. There are valid use cases not supported in UAs that should be documented.
... I'll throw together and ad hoc agenda for joint meeting with OpenUI. There's 3 or 4 topics we could cover. There's enough overlap between the groups. I'm in favor of resolving on these 3 elements but it won't allow you to go to the extent of content swapping
... Also point to explainer that Google, Edge, and Salesforce did which is put together a model definition. I think that's worth exploring in joint meeting. Get opinions on that model because does allow part access instead of one offs

emilio: I think gregwhitworth had good points. I agree to finding a holistic solution is useful and needs to pursue. This is standardizing reality. The prefixed pseudo elements won't go away. Allowing authors to not write same style in 3 selector lists is good

astearns: Agree we should consider holistically and happy to see peoplelike gregwhitworth and Mason are doing the research.
... It seems like we are doing the holisitic consideration. If there are gaps in the analysis it would be great to raise those in the issues

<florian> Doesn't seem that these pseudos would let you do this sort range controls (or style a UA that had them): https://cdn.shopify.com/s/files/1/0017/2972/products/PX5-chromcapsprodcutpage_580x387.jpg?v=1596119507

astearns: For this issue we have the next step of figure out what things could be used on these pseudos.
... Should resolve we do want to make progress on the proposed range pseudos
... Prop: Continue working on standardizing these 3 pseudos
... Objections?

RESOLUTION: Continue working on standardizing these 3 pseudos

astearns: Where it goes, I'm assuming pseudo spec?

fantasai: Yes or do we want a spec of form controls and their pseudo elements?

astearns: Yes, does make some sense to have form control pseudos by themselves

gregwhitworth: We could add that for discussion at joint meeting. I would love to not duplicate. If they're just pseudo elements they go in pseudo. If we spin up a form control spec it goes same patch as OpenUI.

astearns: That okay fantasai ?

fantasai: Okay. If we end up adding lots that's specific to a form control at that point it should move to its own spec. Currently mostly specific to page

gregwhitworth: That's what I was trying to take away from is that overlap. Pseudo elements are a part but ultimately define an anatomy. If we go that route do we spin a new spec for parts? This can be in holistic discussion about where things live. this is part of Open UI anatomy discussion

[css-pseudo] Problems with styling ::first-letter with punctuation

github: https://github.com/w3c/csswg-drafts/issues/2040

<gregwhitworth> florian: that's where the model explainer I referred to as you're correct somewhat but it's primarily due to to the current capabilities of psuedos

github: none

[css-text] 'tab-size' de facto applies to inline boxes

github: https://github.com/w3c/csswg-drafts/issues/5489

florian: Currently applies to block but in impl applies to inline as well. Question is how? Stack or independant? From tests seems independent
... If you have a prserve-tab with a value of 7 you measure frmo edge and push to next independent of if other ones. All browsers seem to do this so would like to spec it

<Zakim> fantasai, you wanted to ask where to put this and to

<chris> sounds like we could standardize reality there

<chris> ok, fair enough

fantasai: Defined to apply to block so when font changes in paragraph tab stops line up. We knew at time impl didn't do that. I think it's not a question about line up with realitiy, there's a reason the spec is different. We can decide we can't do thing that is correct, but there's a reason why it was spec as different.

florian: I did not know that, thank you

oriol: I prop in issue that maybe could go in between current spec and current impl. Could say property applies to inlines and let authors change values in line boxes. If value spec is a number say it refers to advance size of space character of containing block.
... In common cases keep good alignment but closer to current impl

fantasai: Works for me

astearns: And likely more web compat

florian: Works for me

astearns: Prop: Change the spec to say tab size applies to inlines but when that happens the number values apply to advance width from block container
... That would change for all browsers?

oriol: Yeah, right now they use width of space of inline box.

florian: I will add a test for that

astearns: Objections?

RESOLUTION: Change the spec to say tab size applies to inlines but when that happens the number values apply to advance width from block container

astearns: Thanks oriol for the solution

end

astearns: One additional thing, proposed meeting with i18n group during TPAC. Need to have an agenda. Some suggestions for xfq but would like more

chrishtr: Issue #4792

<astearns> https://github.com/w3c/csswg-drafts/issues/4792#issuecomment-689099191

<chris> thanks for that, will review!

chrishtr: Don't have time to talk but got a very detailed update with proposed solution. Has a lot of detail and design doc as well as prototype. In order to make next week discussion useful please look in advance

astearns: Proposal link ^
... Thanks for everyone for calling in. Talk to some of you tomorrow

<tantek> Thanks astearns

Summary of Action Items

Summary of Resolutions

  1. Add chris and fantasai as editors to CSS Conditional 3
  2. we're interested and would like chrishtr to pursue and come back with proposal text
  3. Continue working on standardizing these 3 pseudos
  4. Change the spec to say tab size applies to inlines but when that happens the number values apply to advance width from block container
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/09/09 17:01:17 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/CCSS/CSS/
Succeeded: s/will spawn multiple/will span multiple/
Succeeded: s/if timing is controlled./if its timing is UA controlled but the actual fading is controlled from css/./
Default Present: argyle, florian, dael, chrishtr, cbiesinger, futhark, huijing_, bkardell_, faceless, alisonmaher, rachelandrew, GameMaker, jensimmons, dandclark, gregwhitworth, myles, oriol, dlibby, dholbert, hober, dauwhe_, antonp, &amp;, Lea, smfr, una, tantek
Present: argyle florian dael chrishtr cbiesinger futhark huijing_ bkardell_ faceless alisonmaher rachelandrew GameMaker jensimmons dandclark gregwhitworth myles oriol dlibby dholbert hober dauwhe_ antonp &amp; Lea smfr una tantek faceless2 Chris
Found ScribeNick: dael
Inferring Scribes: dael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]