- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 28 Mar 2018 20:41:52 -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.
=========================================
Test Suite
----------
- An issue was created to make progress improving the test suite
documentation. Everyone is encouraged to review and contribute
on the thread: https://github.com/w3c/csswg-drafts/issues/2438
CSS Grid
--------
- RESOLVED: Serialization of the repeat() MUST use the repeat
syntax. (Issue #2427)
CSS Overflow
------------
- RESOLVED: overflow:clip is a paint time only operation and we
shouldn't require that an element with overflow as clip
in either direction be a BFC nor a scroll port. (Issue
#1971)
Typed OM
--------
- RESOLVED: If you attempt to get a computedStyleMap() or use a
computedStyleMap() on an element not in the document it
throws. (Houdini Issue #659)
- RESOLVED: Style maps of elements moved between documents throw.
(Houdini Issue #659)
CSS Images
----------
- RESOLVED: Clear gradient color stops with two locations for
shipping. (Issue #2439)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Mar/0044.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Garrett Berg
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Vlad Levantovsky
Chris Lilley
Peter Linss
Thierry Michel
Michael Miller
Liam Quin
François Remy
Melanie Richards
Alan Stearns
Lea Verou
Eric Willigers
Regrets:
Manuel Rego
Florian Rivoal
Greg Whitworth
Scribe: dael
Agenda & F2F Planning
=====================
Rossen: Let's go ahead and get going
Rossen: Usual item number one, any extra agenda items?
Vlad: I sent a digression topic.
Rossen: I didn't see it.
Vlad: I sent to working group.
Rossen: Yes, yes. Also a reminder to add agenda + to the F2F topics.
Don't be surprised if we add stuff to the wiki.
Rossen: Anything before we give Vlad he floor?
<tantek> https://github.com/w3c/csswg-drafts/issues/2438
tantek: 2 weeks ago I brought up the problem with the state of the
test documentation. If folks want to look, feel free to
comment on the issue. I don't think we need to discuss on
call.
Rossen: Okay. Please look at issue 2438 from tantek and engage to
help prepare test suite talks.
tantek: I'd like it on F2F agenda
Rossen: Go for it.
Rossen: Other topics?
[Unminuted F2F Planning]
CSS Grid
========
Disallow repeat() syntax in grid-template-rows/columns resolved values
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2427
Rossen: Summary: there was a question about hey we are seeing a
couple of ways repeat() is being serialized, why can't we
have one?
Rossen: Edge supports serialization of repeat() by using repeat
syntax and computed values inside.
Rossen: FF, Webkit, and Chrome serialize as a list of computed
values.
Rossen: Question from TabAtkins and fantasai was just tell us which
you want, we don't care.
Rossen: Seems Igalia is pushing for simpliest which is not use
repeat() syntax and they asked MS to voice our thoughts. My
position is having repeat() serialize as a list is more
difficult for editors and script to handle.
<Rossen> https://wptest.center/#/nsrrq1
Rossen: Test case inside the issue ^ serialization is okay, but if
the repeat >2, really big, in Chrome if you use 5000 you get
100 columns and it drops. Firefox is between.
Rossen: Having to parse this many is harder. Finally, this isn't
new. gradient-repeat() has the same challenge but we're not
serializing a list.
Rossen: Our opinion is preserve the repeat syntax and have others
catch up.
Rossen: Looking for other opinions.
<leaverou> What if the number to repeat by is a var()?
<fantasai> leaverou, it's the used value that gets returned by gCS
<leaverou> Oh right
AmeliaBR: What if author has spec columns that could be collapse?
AmeliaBR: If the author has literally specified multiple columns
without using repeat syntax but they could be collapsed
using repeat would you serialize that using repeat?
Rossen: Not really. That's like saying if we have width: 10px why
not serialize as calc(10px). I don't believe shorter is the
goal here.
AmeliaBR: Just so long as there's a clear definition. You argue keep
as specified by author.
Rossen: Right. Roundtrip of repeat serializes as repeat, not a bunch
of values.
<Rossen> grid-template-columns: repeat(2000, 100px);
Rossen: In the test case from Igalia you have the repeat syntax that
looks okay, but if you try this ^ the serialization is crazy.
Rossen: Any other opinions?
Rossen: If not, can we resolve?
Rossen: Objections to keeping repeat syntax as is currently in the
spec and open bugs for other implementations to do that?
frremy: Spec is a may. So there is no implementation bug to file
unless it's a must.
Rossen: Ah ha. Good point frremy. I didn't realize this was a may.
Rossen: Objections to specifying the repeat() syntax serialization
as a must?
<AmeliaBR> +1 to interop!
TabAtkins: Yes, we should spec one way or the other as a must.
Rossen: I'm not hearing objections.
RESOLVED: Serialization of the repeat() MUST use the repeat syntax.
CSS Overflow
============
Is the box a scroll container if only one of 'overflow-x' or
'overflow-y' is 'clip'?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-370692229
Rossen: florian sent regrets. Can someone else take it?
fantasai: There's several issues here. Main one is that we wanted to
figure out what various values of overflow compute to when
you set...set x axis but not y.
fantasai: Before we introduced clip any value that's not visible in
one axis causes the other axis compute to auto so you have
a scroll container in both axes.
fantasai: Clip didn't spec how to compute. In general it was
supposed to not trigger a scroll container.
fantasai: Combo of clip in one axis and visible in the other seems
to be valid and should not cause visible to compute to auto
fantasai: We updated computed value field. That's the first request.
Current text says if one axis is not visible or clip then
any axis that's visible or clip computes to auto or hidden.
<fantasai> https://github.com/w3c/csswg-drafts/commit/1d1a8e9caf4333518620e32f2a8b08ec3efdfa13
fantasai: Changeset^
fantasai: That raised the question of "but clip creates a BFC and
visible doesn't", what happens when it's overflow:visible
in one axis and clip in the other. That caused a separate
discussion on if a BFC.
Rossen: We should take these one at a time. Thought they're related
I think we can resolve independently.
dbaron: Bigger issue is should clip create BFC and the other thing
falls out.
Rossen: Correct. fwiw I think we had this discussion in the past and
every time we do a full circle and at the end we convince
ourselves that not having it be a BFC becomes complex for
implementation.
Rossen: At least what I recall is are how floats that start before
the element with a clip and extend past the clip region, how
are they effected in terms of flow.
Rossen: If clip is intended to be render time only
effect...nevermind.
Rossen: The interaction between floats that start before clipping
elements or those on the side are hairy if overflow:clip is
not BFC. If it is BFC it's predictable but then you have
overflowing visibly content to the left or right and because
BFCs allow floats next to them you have overlapping content
with floats.
<dbaron> I didn't actually follow that... and I actually don't
remember having this discussion before.
Rossen: Every time we have this discussion I recall us coming back
to the BFC one makes the most sense if we have to implement.
Rossen: I'm happy to discuss one more time if people think we can
arrive at a different resolution.
TabAtkins: I think it's clear if there's a BFC creating context it's
scroll. For clip it's just a matter of what the intent of
the value is. If as dbaron says clip is supposed to be
like visible but without painting outside the bounds
that's fine. Geometry will project out but it does what
we're asking for here.
TabAtkins: If we want to restrict geometry clip is hidden with 0
ability to scroll. We have to decide.
fantasai: Or we make it effect layout by truncating the float.
TabAtkins: That's a new concept that I'd prefer not to add.
<AmeliaBR> Floats affecting layout outside of the container but not
painting outside the container sounds super confusing.
dbaron: The two things we described extend existing concepts and
don't require huge changes. If we create one of those
concepts we may decide to make the other in the future so we
should name appropriately.
TabAtkins: In that case, on naming issue, perhaps we can plan for
visible-clip and hidden-clip to suggest they're same as
base...wait...doesn't make sense.
Rossen: What was the motivation use case here?
TabAtkins: I presume dbaron can explain the visible unscrollable.
dbaron: It's what css2.0 specified. The hidden creating a scroll
container and BFC was new to 2.1. It's what the WG rec
recommended for a decade.
Rossen: And you're the only one that implemented?
dbaron: I think so. Other implementations did hidden in terms of
scrolling.
Rossen: If this is back compat with a not compatible feature should
we decide?
dbaron: I don't think that's why it was added to spec.
Rossen: Was it used anywhere?
dbaron: Internally. Not externally.
fantasai: I think idea was to not have some of the hidden side
effects like a scroll container.
fantasai: Has a bit more effect on stuff now then in the past. In
the past it meant you have slightly different performance
considerations. Sometimes certain user events can scroll a
hidden thing. Currently if you turn something into a
scroll container it catches things like scroll snap
Rossen: This is a large topic. I think this is perfect for
whiteboard between sessions thing and convince ourselves one
way or another. And then hopefully we have florian. Should
we table?
TabAtkins: I'm fine right now resolving clip is the visible but
doesn't paint outside the bounds thing. I can see use
cases for it as fantasai describes. Doesn't disturb
margin or capture scroll snaps.
Rossen: Margin collapsing and everything else?
TabAtkins: Same as visibility.
Rossen: Visibility:hidden takes layout space.
TabAtkins: This will too.
Rossen: No, it says you stop at the bounds of your container. Which
means if you have a whole bunch of floats or 0 height divs
with negative margins that effect after clip but they're
overflowing, do you take that into account?
TabAtkins: I'm not willing to spec something that clips geometry.
I'd be happy with the it's like visible but clips paining.
Rossen: If you don't have floats and a div with
overflow-clip:vertical and a bunch of text with at the end a
div with a huge negative bottom margin. It overflows.
Rossen: After the clip the div isn't visible nor is the content. Is
the negative margin in effect?
TabAtkins: Full geometry. Exactly like visibility:hidden but you
extend the geometry.
dbaron: I'm not sure visibility:hidden is greatest analogy, but it's
purely a paint time effect. Layout is the same as
overflow:visible but descenders outside bounds are clipped.
frremy: We have requests for overflow:hidden but have position
sticky work and I think this fixes that.
TabAtkins: That's good. Another thing scroll containers block. Nice
use case.
TabAtkins: I'm seeing good reasoning for a purely paint time
clipping. You'll have weird looking stuff sometimes, but
that's going to be rare. If you don't want that use
overflow:hidden
Rossen: And we shouldn't ask people to do that with clip or clip
path? How many other ways do we have for clipping?
Rossen: This was the intent of css clip in 2.1.
TabAtkins: Good point.
dbaron: Clip in 2.1 was only for abspos. We can't change that due to
compat.
Rossen: I don't think we can undo the things in the past. What we
can do is narrow down this issue and see if we can get
consensus.
Rossen: Sounds like most people feel like overflow:clip is a paint
time only operation and we shouldn't require that a element
with overflow as clip in either direction be a BFC. The note
in the spec would be yes geometry and everything else works
as it does before and if geometry overflow it will have side
effects.
Rossen: Would people object to this as a resolution?
<fantasai> +1
RESOLVED: overflow:clip is a paint time only operation and we
shouldn't require that an element with overflow as clip in
either direction be a BFC nor a scroll port.
<TabAtkins> Yeah, not seeing why we shouldn't just use clip-path
here. Need to recall what the syntax is of just clipping
to border box.
Rossen: Now if overflow computes to clip in one direction or visible
in the other. If we have overflow...I'm confused if we need
a resolution. If you have overflow auto or scroll in one
direction the other is hidden by default. If you have clip
in one direction the other is visible.
TabAtkins: We need a resolution because we have terminology that
talks about this.
Rossen: What would you want to call this?
TabAtkins: Dunno.
fantasai: I'm confused that we need. If we have the resolution we
need to resolve on the changes in the issue.
TabAtkins: We have various specs that have behavior when overflow is
non-visible, but it means when it causes a scroll
container. So clip now falls into visible so we need
specs to refer to a term.
Rossen: Can we replace to overflow computes to scrollable or
non-scrollable?
fantasai: It's editorial. We don't need a resolution.
TabAtkins: Yeah. But we need to do it.
Rossen: No more resolutions needed and we can move on?
Typed OM
========
What does computedStyleMap() do on elements that are in documents
with no browsing context?
-----------------------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/659
TabAtkins: If anybody has strong opinions I'm happy to go with it.
You grab a computedStyleMap. It has changes to the
underlying element. What happens if the element isn't in
the document? What happens if you grab the map off of
something and then move the element to another document
and you query the computedStyle. What's it reflecting?
Rossen: For the first one, what happens on an element that is not
connected to the current document but is constructed from
script and you ask for a style map. Everyone but Edge
returns initial values. We try to do more and try to compute
the cascade on that sub tree in the ether.
Rossen: I don't think this is great. We do see some interop issues,
but not huge. We went to some effort to represent the
cascade style and we'd prefer not to.
TabAtkins: If you try to get a style map off of something in the
document I'm happy to say it throws. If you have a
computedStyleMap and the element is removed any attempt
to get or set throws.
TabAtkins: That's easier for everybody.
Rossen: I support that. Makes it a lot more predictable.
TabAtkins: Let's resolve on that.
Rossen: Proposal: computedStyleMap() is a live object that returns
all expected values when attached to main markup and throws
otherwise
TabAtkins: If you attempt to get a computedStyleMap or use a
computedStyleMap() on an element not in the document it
throws
Rossen: Objections?
RESOLVED: If you attempt to get a computedStyleMap() or use a
computedStyleMap() on an element not in the document it
throws.
TabAtkins: Sub issue if you grab a computedStyleMap() while in doc a
and it moves to document b do you get a value?
TabAtkins: I think the style map just reflects the value in the new
document.
TabAtkins: Issue is what is the document providence of the objects
returned. Different documents have different globals.
Would computedStyleMap() from old doc still work? Or
return typedOM values from old or new doc?
TabAtkins: Those problems make me lean throw here as well.
Rossen: Not sure. This is equivalent to grabbing a style sheet from
one doc and inserting to a new doc. You would expect
everything will return values...
TabAtkins: That's fine because it's immutable permanent strings.
This is using an old object. If you say is this style map
part of doc a it's [missed]
Rossen: Because it's mutable it's a problem.
TabAtkins: Yes.
TabAtkins: I'm fine with putting in a doc check.
Rossen: That or we can...we can keep referential integrity and
re-calculate everything. So you still have the live object
but a new topography on it.
TabAtkins: The obvious way to define what global the produced
elements are from is the global of the method you call to
create. So get on computedStyleMap() so your unit values
are from the old document. That falls out and might be
okay, but it's a weird mix of values from different docs.
TabAtkins: You're still producing style values from the old.
Rossen: I'm fine more restrictive for now and if compelling use
cases arise and extend life time we'll deal then.
TabAtkins: Yeah. And solution is to call getComputedStyleMap on the
new. So throw now and relax later if we need to?
Rossen: Yeah.
TabAtkins: Check for previous resolution can also check if it's in
the same document as the map cares about.
Rossen: Other opinions or objections?
RESOLVED: Style maps of elements moved between documents throw.
Rossen: So if element moved or created in the ether or moved and you
try and use it it throws. Only time where you can take the
element out, put it back in the same document, that'll work?
TabAtkins: Yes unless you call middle of append steps. Yes. Moving
elements within doc has no negative effect.
Rossen: That's what I wanted to point out.
CSS Images
==========
Clear gradient color stops with two locations for shipping
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2439
leaverou: Two weeks ago we cleared conic gradient for shipping.
Turns out many conic gradients in the wild were using the
two locations. It's been in the draft for 6 years. Chrome
implemented it a year ago because it was in many demos.
leaverou: Dev that implemented asked if he can ship it as well.
Chrome implemented a year ago. I don't see why not.
ChrisL: I think it's an obvious good thing.
leaverou: It's what I said in issue.
ChrisL: Question for Chrome folks. There's a question in the spec as
to if fixup applies before or after layout. I don't think
that effects this issue.
leaverou: I don't see why depend on layout.
ChrisL: There's an issue that says it might.
TabAtkins: Not sure
ChrisL: Can you find out?
<fantasai> I thought we resolved on that in Tokyo?
<fantasai> ChrisL,
https://lists.w3.org/Archives/Public/www-style/2017May/0051.html
ChrisL: In general I support this.
<AmeliaBR> +1, this is a very useful syntax (especially when using
variables in gradients), doesn't involve any new
rendering code, only computed value changes.
ChrisL: People are using it and it's a trivial extension.
Rossen: Hearing some support. Other opinions? Especially from Chrome
folks who are shipping?
TabAtkins: I'm fine with shipping I agree it's minor feature very
useful.
<tantek> we have tests?
<leaverou> tantek: we don't have tests for ANYTHING about gradients!
<tantek> SMH
<tantek> so now we're agreeing to ship features based on demoware?
<AmeliaBR> It's basically adopt
https://drafts.csswg.org/css-images-4/#color-stop-syntax
<tantek> just WD right?
<ChrisL> just wd, which is why we needed a clear to ship. would not
be needed for CR
<tantek> yeah prototypes are good enough for WD
Rossen: Objections to color stops are extended into their
consecutive color stops?
leaverou: Color stops with two positions.
leaverou Color stops with two positions are expanded to two
consecutive color stops with the same color
frremy: This is in spec we just have to say fine to ship
leaverou: Yes.
Rossen: I heard no objections.
RESOLVED: Clear gradient color stops with two locations for shipping.
Rossen: We're at top of hour. We couldn't get to display or value
issues, those will push to next week.
Rossen: I'll miss next week so see you in Berlin!
Received on Thursday, 29 March 2018 00:42:49 UTC