- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Sep 2020 19:08:19 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Conditional
---------------
- RESOLVED: Add chris and fantasai as editors to CSS Conditional 3
(Issue #5315: Let's finish the specification)
CSS Pseudo Elements
-------------------
- Though they seem similar the discussion find-in-page and
scroll-to-text needs to be separated into two issues (Issue
#5233: Add a highlight pseudo-element for find-in-page or
scroll-to-text).
- There were concerns that find-in-page may be a mis-match with
the highlight pseudo elements because several browsers have
additional styling.
- The original developer request was to style scroll-to-text but
there are use cases for both properties that should be
documented.
- RESOLVED: We're interested and would like chrishtr to pursue and
come back with proposal text [for find-in-page and
scroll-to-text] (Issue #5233)
- RESOLVED: Continue working on standardizing these 3 pseudos
(::range-thumb, ::range-track, ::range-progress) (Issue
#4410: Standardizing input[type="range"] styling)
- There's interest in having a joint meeting with OpenUI to discuss
the more holistic approach to defining parts of controls that
they're working on.
CSS Text
--------
- RESOLVED: Change the spec to say tab-size applies to inlines but
when that happens the number values apply to advance
width from block container (Issue #5489: 'tab-size' de
facto applies to inline boxes)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Sep/0003.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins
Christian Biesinger
Mike Bremford
Oriol Brufau
Tantek Çelik
Daniel Clark
Hui Jing Chen
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Brian Kardell
Una Kravets
Daniel Libby
Chris Lilley
Rune Lillesveen
Alison Maher
Myles Maxfield
Tess O'Connor
Anton Prowse
Florian Rivoal
Jen Simmons
Lea Verou
Greg Whitworth
Scribe: dael
astearns: One extra item is a reminder we're having an extra meeting
tomorrow to talk MathML topics
astearns: Same time, just tomorrow
bkardell: Looking forward to it. Invited some CG members
astearns: Any changes to today's agenda?
CSS Conditional
===============
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
chris: 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
chris: Most open issues don't look hard. Maybe push some until
further level.
chris: 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 in GH. I did a bunch of getting out of
older requests and putting into GH a year ago
fantasai: Okay
fantasai: 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
<gregwhitworth> fantasai if you need help spelunking or split up the
reviews let me know
chris: 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
chris: This was last published in 2013 so it needs some tlc
astearns: Shall we make fantasai and chris editors?
chris: Fine for me
RESOLVED: Add chris and fantasai as editors to CSS Conditional 3
CSS Pseudo Elements
===================
Add a highlight pseudo-element for find-in-page or scroll-to-text
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5233
TabAtkins: I can run with it
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 items.
TabAtkins: If same group like UA-selection. Is separate
::find-in-page and ::scroll-to-text
TabAtkins: 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
<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: 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.
florian: Conceptually similar but style is very different. We should
do some research about 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
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
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
GameMaker: Summary- Chrome would need 2 colors because 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 received dev desire on scroll
to text. When you use this it will highlight bg of
selected content in yellow for short period then fades.
Many devs find that color doesn't fit with theme
chrishtr: Added find in page because 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 requests for this.
Having a browser hook would be good. Very valid
points on open questions. Feel it warrants a more
concrete proposal. As you denoted chrishtr it may
vary between the two
gregwhitworth: 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
florian: We know what pseudo highlights do but we know 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 just
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 precedent? Is it a special
pseudo element?
florian: There's precedent
TabAtkins: Defined in ::selection. Constrained properties 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: Because of the 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 prove a dark mode style for this?
una: Yes, just additional overhead. Good to do because author makes
sure whatever preference mode these styles have clear visibility
TabAtkins: Support that. Because 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 authors 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.
florian: 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.
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
chrishtr: Makes sense to split. Scroll to text is much simpler. It's
a progressive enhancement of linking property. In
Chromium-based it shows a yellow that disappears after
user interactions. It's pretty simple
chrishtr: 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
florian: 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
chrishtr: Great to confirm if there's any objection to trying to
move forward and spec scroll to text?
hober: I don't think 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.
florian: Not sure. At this point we're trying to see if the
definition fits more problems
TabAtkins: The text find thing is a soft problem already. Not just
easy, it's a non-problem once we define it exists
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: Proposal: We have this facility for browsers that impl
scroll to text
astearns: Objections?
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 just that
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.
tantek: Have in the wild that kind of text that's far beyond simple
background highlights. I don't oppose exploring, just want
to make sure we're not trying to collapse it with something
like find that's more 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 controlled 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
RESOLVED: We're interested and would like chrishtr to pursue and
come back with proposal text
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 proposed standardizing a model similar to
Gecko. Subtle differences. Added to get feedback. Model 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-track, and range-progress.
Concrete is missing
gregwhitworth: Did a decent amount of research because 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 re-ping the person to know what's interop so we
can get a concrete proposal
iank: Sounds great
smfr: WK has html range 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 commenter 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
gregwhitworth: Got it. I'll definitely test
<florian> I wonder if we're painting ourselves into a corner, and
excluding alternative designs (dial like, or other things)
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 piece 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 holistic
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 approach. 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 technically exists
gregwhitworth: 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.
gregwhitworth: 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
gregwhitworth: 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
people like gregwhitworth and Mason are doing the research.
<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: It seems like we are doing the holistic consideration. If
there are gaps in the analysis it would be great to raise
those in the issues
astearns: For this issue we have the next step of figure out what
things could be used on these pseudos.
astearns: Should resolve we do want to make progress on the proposed
range pseudos
astearns: Proposal: Continue working on standardizing these 3 pseudos
astearns: Objections?
RESOLVED: 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
<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 pseudos
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 implementations it
applies to inline as well. Question is how? Stack or
independent? From tests seems independent
florian: If you have a preserve-tab with a value of 7 you measure
from edge and push to next independent of if other ones.
All browsers seem to do this so would like to spec it
<chris> sounds like we could standardize reality there
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
reality, 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.
<chris> ok, fair enough
florian: I did not know that, thank you
oriol: I proposed 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.
oriol: 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: Proposal: 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: 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?
RESOLVED: 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
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
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: Thanks for everyone for calling in. Talk to some of you
tomorrow
<tantek> Thanks astearns
Received on Wednesday, 9 September 2020 23:09:03 UTC