- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Aug 2017 19:26: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.
=========================================
Intrinsic sizing algorithm seems to produce 0 for many common cases
-------------------------------------------------------------------
- RESOLVED: Change the spec to treat width and height as input for
the max content size.
Definiteness of flex items' main size depend on flex-basis's
definiteness
------------------------------------------------------------
- RESOLVED: Allow percentages to resolve, re-open issue if
dholbert or others want to re-discuss.
Spec for cursor during selection?
---------------------------------
- RESOLVED: Add the proposed text from the github issue
https://github.com/w3c/csswg-drafts/issues/1691
(Text: "User agents may also ignore the cursor
property and display a cursor of their choice to
indicate various states of the UA's user interface,
such as a busy cursor when the page is not responding,
or a text cursor when the user is performing text
selection.")
fit-content() vs 'stretch' alignment
------------------------------------
- There was initial leaning toward having 'stretch' affect
fit-content() up to the max size, but several people wanted
more time to review before resolving.
Clarify that ::before/etc allowed after ::slotted()
---------------------------------------------------
- RESOLVED: Allow ::before/after after ::slotted() but not opening
it to general stacking of elements.
===== FULL MINUTES BELOW ======
Agenda: http://lists.w3.org/Archives/Public/www-style/2017Aug/0025.html
Present:
Rachel Andrew
Tab Atkins (IRC only for most of the call)
David Baron
Bert Bos
Alex Critchfield
Benjamin De Cock
Elika Etemad
Tony Graham
Dael Jackson
Brad Kemper
Myles Maxfield
Anton Prowse
Melanie Richards
Florian Rivoal
Jen Simmons
Greg Whitworth
Regrets:
Rossen Atanassov
Alan Stearns
Lea Verou
Scribe: dael
Bert: Let's get started
Bert: Extra items. Anything we need to talk about?
myles: The set of people on the call is small.
Bert: It is August, but we do normally have more people.
[discussion about quorum, more people arrive]
Bert: I don't hear extra topics.
Spec Rec Next Steps
-------------------
Florian: Question. Based on recent resolution I sent transition
for MQ4 to CR. I know it's possible to do it myself or
ask staff contact. I tried to do myself, but I haven't
heard back. If you know something, let me know. If not
can you look?
Bert: It's making its way. It's not often the editor sends the
request so people are looking at it as odd.
Florian: We'd done that in the past. I was mandated to do it for
CSS UI and document it. I forgot to document so I figured
I'd do it this time and document.
Bert: It's fine. plh is on holiday and he assigned his role to
other people who aren't as experienced. They found the
resolution.
Florian: As long as it's not lost we're good.
Bert: I have news: scroll snap is going to publish tomorrow.
Bert: Anything else?
Intrinsic sizing algorithm seems to produce 0 for many common cases
-------------------------------------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/1435
fantasai: There is an issue filed by dholbert pointing out
max-content of a flex container is only defined by
max-content size of its content and flex-basis isn't
taken into account. Empty elements in flex with a basis
it shrinks to 0.
fantasai: dholbert pointed out this is unintuitive. We did give it
a size.
<fantasai> Options:
https://github.com/w3c/csswg-drafts/issues/1435#issuecomment-321098718
fantasai: We have options here. No one has a good argument for one
over another. We need WG or community opinion. We could
do nothing and leave as-is. We could treat specified
width or height as a size that needs honor and ignore
flex-basis. We could do flex-basis and ignore width and
height. We could take max(flex-basis, width/height) as a
floor on the max-content size. And this would all be
inflated by max-content.
fantasai: If I was going to pick randomly I would say use width
and height but not flex-basis.
Bert: Sounds like it's not a serious problem, but I may be
misreading. Any opinions?
gregwhitworth: I'd agree with width and height but not flex-basis.
My only worry is, I don't expect people to hit this
on web but they probably wouldn't know they have
empty flex.
gregwhitworth: Any compat issues?
rachelandrew: As an author it's not an issue I've seen.
rachelandrew: I'd probably agree width/height not flex-basis makes
sense.
Bert: That's one in support. Other opinions?
Bert: Other options...flex-basis as well as width/height and take
the max, they are less desirable. Did we not want to discuss
those?
fantasai: flex-basis is a start place for flexing, it's an input.
Width and height are set. In that case you're setting
something explicit and everywhere else in CSS we take
that.
Bert: Anybody want to argue in favor of flex-basis or max of that
and width?
Bert: Maybe we drop those.
Bert: So only no change or look at width/height.
Florian: Sounds like a good change, but is anyone rushing to impl?
fantasai: I'm not sure but dholbert is planning to look at flex
box.
gregwhitworth: Looking at the test case we have interop. It's a
worthwhile change, we should make it.
Bert: Okay, they we need buy in from more impl.
Florian: We have 2 at least. That's a good start.
Bert: Is TabAtkins on?
fantasai: He's just IRC.
<bradk> Is there existing content that depends on current interop
behavior?
Bert: I'm hearing some support for looking at width/height but not
flex-basis which is a change in spec.
fantasai: Yes.
Bert: Do we put that up? Change the spec to treat width and height
as input for the max content size.
Bert: Who is in favor, who is against?
Florian: In favor
<rachelandrew> +1
Bert: I only hear in favor.
RESOLVED: Change the spec to treat width and height as input for
the max content size.
Bert: fantasai will you write text? or TabAtkins ?
Bert: Whose action?
<TabAtkins> We'll take care of it, don't worry
fantasai: We'll do it, don't worry.
<TabAtkins> As long as it shows up in the issue
<dbaron> I guess I'm surprised they weren't already an input to
the max-content contribution, given that they're an input
for other layout modes.
<fantasai> dbaron, yup, that's why dholbert filed the issue :)
Should last-baseline's fallback alignment be safe or unsafe?
------------------------------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/1611
fantasai: I didn't post a blog post. I did ask jensimmons and her
opinion was unsafe. That's as far as I got.
Bert: You want to continue that action.
fantasai: Yeah.
Bert: Keep that open?
fantasai: Yep.
Definiteness of flex items' main size depend on flex-basis's
definiteness
------------------------------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/1679
Bert: I think gregwhitworth wanted to look at code he had to
compare.
gregwhitworth: Is anybody from FF on?
dbaron: I don't know if I'll be helpful.
gregwhitworth: I put my information in the notes. I sat with our
dev. We could figure out the same thing as
dholbert. We haven't impl this aspect. I pushed him
to see if this is right approach. dholbert seemed
to say he thought it was the right approach.
gregwhitworth: We do because everything is auto we do layout and
then a second pass to resolve percentages. That's
what authors also expect. I'm wondering if we
should remove the constraining on #2 of 9.8. If you
set definite flex-basis and fixed height it does
the extra work. I see a lot of authors doing this
though it's not what they're expecting.
fantasai: Bigger argument is we have introp on 2 impl and the
authors expect that behavior. Spec says something else
so we should change spec.
gregwhitworth: And what dholbert posted to the list, we originally
said 'hey performance'. It's odd for authors to
know that to set flex-basis to 0 is what you need
to do for chrome to look like edge and ff.
gregwhitworth: Let's just remove the constraints of #2 under 9.8
<fremy> fwiw I discussed this with gregwhitworth yesterday, and I
totally +1 his request to remove the constraints on #2
fantasai: Reasonable to me.
Bert: Me too, but I'm not expert. Other opinions?
dbaron: I'm not sure how well performance bugs get tied back to
this. I'm not sure if we would have heard if there were
performance bugs.
gregwhitworth: That's a valid argument. I feel like we're going to
argue a theory. Now that we have grid we'll be able
to have less nested flexes is my guess so I'm not
as worried about the circular problem.
fantasai: In grid percentage always resolved because grid sizing
creates sizes for the tracks. Conceptually grid algo
resolves the equivalent code the way FF and Edge do flex
right now.
Bert: I'm hearing, fantasai, that there are impl that do and some
that don't do the layout based sizing?
gregwhitworth: Chrome and I believe I saw webkit and blink would
have to change. As we stated the people on the
thread aren't on the call.
<gsnedders> FF and Edge agree, Chrome and Safari agree (but are
one impl now again)
<gsnedders> WebKit's implementation of flex was literally copied
over from Blink a few months ago
Bert: Are we confident enough to decide? Do we need more input?
fantasai: Christian is away for the next couple months. We can ask
dholbert that we want this resolution and ask for
approval. From dholbert and whomever people want to tag.
Bert: Sounds like a good way forward. If we document it in the
issue is that enough? Do we need to contact personally?
gregwhitworth: I say we just resolve since we discussed it. We can
re-discuss if they want to get on a call.
Bert: Okay.
Bert: Wording for proposed resolution?
gregwhitworth: It's what I said in the issue. Basically re-write
#2 of section 9.8 to percentage would resolve.
fantasai: Allow percentage to resolve, re-open issue if dholbert
or others want to re-discuss.
Bert: Okay, that's the proposal. Objections?
RESOLVED: Allow percentages to resolve, re-open issue if dholbert
or others want to re-discuss.
Spec for cursor during selection?
---------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/1691
Florian: We discussed and reaffirmed that we want cursor:auto to
only do limited switching. All other types of adjustment
are through UA stylesheet. Chrome is fixing their impl to
change that and they found another thing they can't do in
the stylesheet. While user is dragging mouse they change
cursor to text cursor if it's auto.
Florian: This is chrome only behavior. Safari changes always, not
just auto.
Florian: My feeling is this is sort of out of scope. We already
said UA can ignore cursor if you're doing something like
hovering over scrollbars. We originally suggested that
way the UA does to reflect state of UI is out of scope.
Florian: My suggestion is changing the cursor to reflect selection
is an indication of the browsers UI is out of scope. I
propose an editorial clarification to say that. Is that
sounding sane?
Bert: Does to me.
myles: On mac there's already system behavior. It's valuable to be
able to match platform.
<fremy> +1
Bert: That's support for Florian
jensimmons: I'd add that I have no see authors desiring the
ability to control at this level of detail so sounds
good to me.
Bert: Anybody else?
Bert: Proposal is add a note?
Florian: I'm doing this as a may. Proposal is in issue. [reads:
"User agents may also ignore the cursor property and
display a cursor of their choice to indicate various
states of the UA's user interface, such as a busy cursor
when the page is not responding, or a text cursor when
the user is performing text selection."]
Florian: Resolution would be adopt the wording in the issue.
Bert: Okay, proposal is add the text as is in the issue.
Bert: Objections?
RESOLVED: Add the proposed text from the github issue
https://github.com/w3c/csswg-drafts/issues/1691
ACTION Florian add the proposed text in
https://github.com/w3c/csswg-drafts/issues/1691
to the spec
<trackbot> Created ACTION-862
Metadata
--------
Github topic: https://github.com/w3c/csswg-drafts/issues/1730
Florian: May be better for fuller attendance, but in brief.
Florian: While submitting tests recently I found a difference
between what I understand the policy on how to write test
and what the web platform tests is. I think there's a
mis-match and how we decided to relax our metadata and
how the tooling is based.
Florian: I want to confirm if I'm the only one confused or if
others have the misunderstanding.
Florian: I'm not convinced this is useful without more people.
Bert: We can keep for the next time. Anyone else want to say
something today?
Bert: Okay, we'll wait for more people.
fit-content() vs 'stretch' alignment
------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/1732
fantasai: rachelandrew and rego found spec issues about 'stretch'
and fit-content() and 'stretch' will stretch past the
specified limit and that doesn't make sense.
<rachelandrew> the interop issue is described here
https://github.com/rachelandrew/gridbugs#14-fit-content-is-stretching
fantasai: There's 2 options. 1) Only have stretch stretch auto
tracks but not fit-content. 2) Have stretch work on
fit-content() up to the limit.
fantasai: 2 is more complex to impl but may be more expected.
Bert: I'm having trouble visualizing. Other people understand?
fantasai: I'm happy to defer if people want more time.
gregwhitworth: I prefer to wait. I didn't review in depth.
Bert: How much time?
gregwhitworth: Just a week. I want to run Rego's comment on impl
past our devs.
fantasai: There's also two options for if we do stretch...do we
stretch other tracks once these have reached their limit
or just say nope.
jensimmons: From author side having a track with fit-content grow
and shrink would be expected. And I think that once
the fit-content limit is hit having additional space
appear get distributed through the rest of the grid
would also make sense, not have the grid stop growing.
jensimmons: I don't know the implication for impl. Super quick
issue reading from rachelandrew's github of grid bugs
it looks like that's what other authors expect.
Correct me if I'm wrong rachelandrew
rachelandrew: I think the author that raised it thought stretching
was correct, but I found authors assume Chrome is
correct. They tend to assume the browser they use
the most is correct so I take it with a pinch of
salt.
Bert: So if we come back next week that's enough time to
investigate?
jensimmons: Is what I tried to articulate what FF does?
rachelandrew: FF doesn't stretch. If you align to start you get
the same with everything. Chrome is stretching.
jensimmons: It would be nice...Oh there's a demo here.
jensimmons: I'm fine punting to next week.
fantasai: If people have opinions or thoughts please add comments
to the issue.
<gregwhitworth> Edge doesn't stretch either in the case provided
Bert: So there are impl difference so at least one will have to
change.
Bert: Please add your thoughts to the issue and we'll come back
next week.
Clarify that ::before/etc allowed after ::slotted()
---------------------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/1747
Bert: It's raised by TabAtkins. Anyone else know this topic?
Bert: I don't think I've seen ::slotted() before.
gregwhitworth: I think we should wait for TabAtkins. I think their
implementation is the furthest along.
<TabAtkins> I can call now, one sec
fantasai: I think...issue seems straightforward. There's ::slotted
pseudo element. They want to attach ::before/after and
what's the syntax for that. Obvious is TabAtkins
suggestion. I think we just need confirmation from WG
this is acceptable.
Bert: It's only syntax? I thought it was if it was even possible.
Bert: If it's only syntax this is easier.
TabAtkins: I'm here now.
TabAtkins: Simply, is everyone else okay with allowing this
syntax. ::slotted lets a shadow dom element select
whatever light dom was. There is a real element being
pointed to by the pseudo element. So should we allow
structural pseudos on that element. Should you be able
to modify before and after from the ::slotted pseudo.
TabAtkins: It's fine from an impl perspective. afaict it's not
problem and it's not a problem from spec side. I need
WG sign off and then a small change to selectors
grammar to allow it.
Bert: Now it makes sense to me.
fantasai: Syntax change makes sense. If you should be allowed to
access is separate question. Is slotted how light dom
accesses shadow?
TabAtkins: No. Other way around. slotted accesses light dom.
myles: This isn't arbitrary, just these two.
TabAtkins: ::slotted with ::before and ::after only. We can look
at further combos later.
fantasai: We're doing this similar with pseudo classes on pseudo
elements. Currently only this set is allowed and all
others are disallowed unless explicitly specified.
Bert: So ::slotted is a special kind of pseudo element.
TabAtkins: Yeah. Special part is is refers to a real element in to
dom that's not accessible by standard combinators.
Bert: Have you thought about other syntaxes that avoid stacking?
TabAtkins: We've tried. We talked about the deep combinator taking
elements. It ends up awkward. In general these to act
like pseudo elements. They just happen to be back by a
real element that's not normally accessible.
Bert: I'm ready to propose allow ::before/after after ::slotted()
but not opening it to general stacking of elements.
Bert: Any support or arguments against?
RESOLVED: Allow ::before/after after ::slotted() but not opening
it to general stacking of elements.
Bert: TabAtkins you're making the changes?
TabAtkins: Yeah.
Bert: That's the agenda. Other things to discuss?
Bert: Hearing nothing, thanks everybody!
Received on Wednesday, 23 August 2017 23:27:15 UTC