- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 31 Aug 2017 08:27:12 -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 Metadata
-------------
- Florian raised some confusion he had regarding how to move tests
when what they're testing changed level in the spec.
- WPT needs the path name not to change so that references stay
accurate, however CSSWG needs to have something that says what
a test is for in order to move specs to REC and these two
needs are conflicting.
- There is a requirement within the CSSWG folder to have the
rel=help populated which is providing the necessary data, but
this requirement isn't applied to anything outside that folder.
- The group re-committed to continue requiring rel=help within the
CSS folder in order to keep the test harness and associated
programs working.
- Path not being changeable also create problems since right now
everything in wpt is versioned.
- There was a desire to move into unversioned folders to ensure
the path is consistent even if a feature moves to a different
version of a spec, but this kind of move needs coordination so
gsnedders will look into what is the preferred approach.
Consider policy to ask for web-platform-tests
---------------------------------------------
- The group approved of zcorpan's suggested text
(https://github.com/w3c/csswg-drafts/pull/1767 ) and agreed it
should be worded as a must and applied to all CR specs and any
specs close to CR where the author feels comfortable requiring
it.
Should viewport units still depend on scrollbar width for
overflow:scroll?
----------------------------------------------------------
- Though the original instinct was to remove this requirement as
there's only one implementation, there were strong opinions as
to why this behavior is valuable and solves an else wise
unsolvable use case.
- There's still a need for implementer feedback in order to have a
second implementation of this feature.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Aug/0043.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Robert Flack
Tony Graham
Dael Jackson
Brian Kardell
Tomoya Kimura
Peter Linss
Myles Maxfield
Simon Pieters
Anton Prowse
François Remy
Melanie Richards
Florian Rivoal
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Regrets:
Vlad Levantovsky
Chris Lilley
Jen Simmons
Lea Verou
Scribe: dael
Spec Rec Next Steps
-------------------
astearns: Let's start. Is there anything extra to add to the
agenda?
[silence]
astearns: Next would be spec rec, but I haven't done anything to
figure out where things are. Is there anything people
would like to volunteer?
Florian: Is Bert or Chris on? I think Chris is off.
Florian: Okay. I had asked for MQ4 CR transition. Got a reply it's
okay, but someone needs to do it.
astearns: I will ping them for a status.
astearns: Anything else on rec track items?
Test Metadata
-------------
github: https://github.com/w3c/csswg-drafts/issues/1730
astearns: You were putting tests in that had the rel=help metadata?
Florian: I was moving tests from UI3 to UI4 and I fixed the rel
and fixed the file path because my memory of when we
agreed to merge repos rel was agreed to be optional
because same info was in path.
Florian: I naively updated the path and was told not to do that.
Now I understand they prefer when rel is there and the
path doesn't change.
Florian: They want rel=help and the path to be accurate, but
higher preference is path to not change. The preferred
way to do this is un-versioned spec in the path. I
thought the path must encode location and it's only a
should.
Florian: Currently our tooling relies on rel=help, but I thought
we were eventually supposed to update tooling.
astearns: Also when we imported CSS test to web platform we didn't
follow the spec name folder, it's all in CSS.
Florian: And leveled spec names.
astearns: Right. So I think the point where we fully use path as
encoding for the test is when we start adding tests for
new spec outside of css directory.
Florian: I think there is already a few.
Florian: Key point for me is to understand if it's just me who
misunderstood or if it's the whole group. We can't
programatically rely on the path or rel=help being there.
Florian: If it's just me, fine.
plinss: Clarification. Our tooling depends on rel=help. wpt was
planned to have path as encoding and beyond the spec
having sub folders. Some structure. There was a plan to
augment our tool to fallback to path, but that's on hold
until path name is reliable.
<zcorpan> Currently top-level css directories: css-backgrounds
css-cascade css-font-display css-font-loading css-fonts
css-paint-api css-scoping css-timing css-typed-om
cssom-view cssom
Florian: And there's no plan for that. Spec names unversioned are
sorta expected to be reliable, but unversioned not and
section level will be more of the same. When a piece of
spec moves there's resistance to changing the path.
astearns: And other outside tooling relying on that means we can
never rely on path. We need a requirement to have the
rel=help links.
Florian: But that goes against moving outside css directory.
plinss: No. The css directory was there because that was easy for
the transition. Our tooling doesn't care about the path at
all if there's a rel=help link.
Florian: But a wpt will not make rel=help mandatory.
gsnedders: It's mandatory in css subdirectory.
Florian: Right.
Florian: But we're not mandating the subdirectory.
fantasai: Do we want to transition outside css directory?
plinss: There are already some. There are some people moved out,
there were some outside already. I don't really care where
they are.
Florian: I kinda came into that...on the one end I think we
strongly require this and they strongly require this to
be option and we apparently had not agreed.
astearns: I don't think we decided rel=help is mandatory to check
in tests. We don't want a fail if it's not there, but we
strongly prefer it. As tests get run we're going to add
rel=help meta data to those.
fantasai: We decided to make rel=help optional because it would be
replaced by file path. If that's not the case having it
optional makes no sense. We need to know what's being
tested.
Florian: What I was told is that moving things along the rec track
was a non-goal for the wpt. Though it's better to have
meta data it still works as a test and it's better to
have this than no tests.
fantasai: We agreed to have our tests in their repo, but we
shouldn't drop our goals.
astearns: While our tooling isn't going to use anything in the
path, we are still able to rely on top level css folder
or top levels that correspond to our tests to see it is
css and if it's lacking rel it can be fixed.
astearns: I'd prefer we keep it optional in that nothing will stop
someone from checking is a test but still strongly
preferring it so that we have the practice of checking
in the rel=help
<dbaron> I agree with the position -- having regression tests is
useful even if they're not used for advancing on the REC
track.
<fantasai> dbaron, sure, but I expect it's going to be used as an
excuse for people to be sloppy and putting more work on
us
<fantasai> dbaron, it's way easier for the test writer to
associate at test with a spec than for us to go back
and do so retroactively
<fantasai> dbaron, also people should COMMENT THEIR CODE, and that
includes tests, and the WPT folks insisting that tests
be uncommented regression dumps while also believing
that function declarations should have some kind of
commenting is hypocritical
<fantasai> dbaron, tests are maintained code, too
<dbaron> fantasai, There are also regression tests where it's not
clear what the specs say, but we actually do have interop
and should keep it.
<fantasai> dbaron, sure, and those should be filed as bugs against
the specs, preferably with a link to the test in
question so that we can update it as necessary
gsnedders: If I can summarize, two parts. 1 there was some plan to
add a per directory file to preserve the mapping to
specs even if things got moved around. The other thing
was I thought there was some agreement to move away to
the tooling people were using for impl tests and wpts
plinss: We have to rely on the tooling we have until there's a
tool that meets our needs.
Florian: And I don't think there's a perception that we require
our meta data b/c w3c, but because it makes our lives
easier. I've been told we're just imagining requirements
from w3c when they're not.
plinss: We've never done our testing infrastructure b/c a w3c
mandate. They only mandate we have tests. How we do that
is up to us.
astearns: fwiw there was someone complaining on whatwg irc about
an undocumented test.
fantasai: This is a general problem. There are people that think
web platform is a regression dump, but there are other
people that have to go back and maintain that code.
We're those people. We have to look at the code.
astearns: I don't have a good idea of how many tests we have in
wpt that are css tests and lack rel metadata. Does
anyone?
gsnedders: In principle everything in css subdirectory does. It's
a question of how many are outside.
astearns: And how many have meta data.
gsnedders: Few outside the subdirectory have it, I think. This is
my impression, I don't have numbers.
astearns: Does the current tooling require rel to check in to css
subdirectory?
gsnedders: It does.
astearns: So it won't spread in css subdirectory. And maybe we can
turn it on elsewhere.
Florian: But there's a plan to move out of subdirectory.
astearns: As we spread out we can spread the requirements to the
directories with our tests.
Florian: gsnedders do you think it's welcome?
gsnedders: I guess not.
gregwhitworth: What's the difference between sub level and top
level that's not ours?
gsnedders: The status quo is we have this one top level with a
bunch of different requirements to everything else. I
think it's the only one that has any different actual
check in level req.
Florian: Based on the discussions I've had the rest outside csswg
is for the web community and if they want to write tests
they shouldn't have to follow our unusual rules.
<fantasai> How are people supposed to cooperate on test coverage
if everyone's writing tests in their own little corner
and not looking at what else is in the repo? Part of
the point here is not to duplicate work by having each
implementer write its own version of the same exact
test.
<dbaron> OK, I guess I'm fine with requiring rel=help
astearns: I would guess the policy for a top level should be
dictated by the owners. The cssom tests are outside the
directory. So zcorpan are the tests there using rel
links? And would you welcome having that req for those
folders?
zcorpan: They are currently outside CSS. I believe they mostly
have meta data.
zcorpan: Exception is prob there are test using like .window.js
zcorpan: I usually at least make sure the path [missed]
astearns: That's part of your review to make sure the rel links
are there?
<zcorpan> I don't know how many of the tests have metadata, but
the tests were in css before so presumably most have
metadata.
astearns: Okay.
gsnedders: I think some of the cssom tests were already in wpt
before the merge.
gsnedders: Therefore those might not have the meta data. That's
why they live outside css.
<zcorpan> When I write tests I try to make sure either there's a
rel-help or that the directory structure matches which
spec is tested.
<zcorpan> https://github.com/w3c/web-platform-tests/blob/master/html/README.md
is the policy for html/
fantasai: I think it's fine if cssom since they're different. If
we have a separate top level for every spec we'd have
some test outside css subdirectory and some within so it
makes it hard to find things. Also that's a lot of
subdirectories so people finding what they're looking
for is hard.
astearns: I agree it's messy for some in and some out, but it's
the current reality. We could not add more to it but
adding new tests in css. It sounds to me like we want to
continue to require rel meta data links on all tests
inside css directory going forward. Doesn't seem like we
can change that and it's helpful to have.
astearns: We can look into requiring the rel link in other folders
for tests outside css folder.
<fantasai> There are less than 200 non-CSSOM tests outside the css.
<zcorpan> (I think for Chromium there's no problem with moving
tests, the tooling should figure that out. Might be
different for other vendors.)
<gsnedders> fantasai: including almost all of Houdini, IIRC
<gsnedders> zcorpan: (expectation data hardcodes the path)
Florian: Questions. 1) if it annoys people when files move we
should stop that so when we get close to rec and an at
risk feature moves moving them is not liked. unversioned
folders solves that. Should we start doing that? If yes,
when?
astearns: Any thoughts on moving to non-versioned folders?
fantasai: I'm okay with that.
Florian: If we do it in one shot and warn people it might be okay
<zcorpan> gsnedders: (I was informed that the downstream updater
figures out expectations for moved tests.)
gsnedders: There's some consensus it's okay to do these things in
big moves to get rid of cases where css uses policies
not used by the rest of the repo.
Florian: That's pref? moving css/cssfoo3 or move everything to css/
foo all at once?
gsnedders: There's a part of me in favor of keeping status quo
until we have different tooling and them move to top
level at once.
fantasai: If we want to move to having the path encode data we
should do that at same time. But if we drop versions we
can't do subscriptions reliably because they'll change
level to level. Some will be same, some won't.
fantasai: I think it'll be tricky to have unversioned module
directories but also do what to have per section sub
directories. We can do one or the other but not both.
Florian: I think we might want subdirectories per topic, but if we
can't move the shouldn't be fine grained.
fantasai: Agree. We should just have per module directories on
level. It would be a good idea to move the tests outside
css subdirectory in and then maintain that for all
tests. If we put them top level it'll be 60 top level
and be hard for people to find all css tests.
fantasai: I think it makes the repo more usable if we don't have
all 60+ modules scattered across the top level.
astearns: gsnedders can I give you an action to look at moving to
unversioned folders in one go to avoid file movements in
the further? Within the css subdirectory?
gsnedders: I guess
Florian: Until we have the answer, should we start making
unversioned subdirectory to avoid making it worse for new
tests?
astearns: I think it makes sense for new tests
fantasai: If we're going to move a bunch people will have to deal.
If we don't move we'll have to move those things back.
astearns: Perhaps new test suite if you have to make a new folder,
make it unversioned.
Florian: Question 2) If we move out of css subdirectory for
purpose of no longer following css rules, what do we lost
beyond rel=help?
gsnedders: I can't remember all. There's the check for unique
files names within test suite. We have rel=help.
There's another I can't remember
Florian: These are things we only care about b/c build tool relies
on them. Correct?
gsnedders: Yes. All CSS only events are there to keep the build
system working.
<zcorpan> css/ also can't use .window.js, .worker.js, .any.js,
since they can't encode rel=help
<zcorpan> though adding ability to encode a spec link in those
seems possible
<gsnedders> zcorpan: also that doesn't work in the build system,
because they don't use wptserve
plinss: Beyond that the build system org tests into per spec
suites and generates other versions of tests. Other
tooling relies on that output like test harness and spec
annotations. Also if we ever want anything to say what
tests a spec change may break. So I keep hearing we might
move, but if we lose the meta data we lose these extra
capabilities.
Florian: This idea is that other people get by without this and
why can't we. I don't know why we should change.
plinss: We care about taking specs to rec. It's a non goal of wpt
so do not expect support for that goal.
astearns: Other people also require a test when you change a spec.
<fantasai> gsnedders, if we're looking into reorganizing the tests
within css/, we should also look into moving those <200
non-cssom tests into css/; otherwise more people will
try to copy that pattern and we'll end up with
duplicate locations
Consider policy to ask for web-platform-tests
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1755
astearns: zcorpan would like to require tests for cssom and cssom
view changes even though those specs aren't in cr. I
think that's consistent with what we resolved in Paris.
Requiring this for tests not yet in cr also makes sense
and it's up tot he spec author to make that
determination.
astearns: zcorpan is that accurate?
<zcorpan> Yep.
<zcorpan> So how this works in whatwg and other places is that a
spec PR is blocked on having tests, and the two PRs are
merged at the same time
astearns: I am in favor of having spec authors require tests for
changes they make at their discretion in addition to
having rossen and I hold people to that standard for CR+
specs
Florian: I'm a little confused. I thought zcorpan wanted to check
in a file that explained that. It's not the author
requiring himself to do that, but for 3rd party
contributors.
Florian: It's things added by everyone to that spec. poss merged
by editor
astearns: I think zcorpan should add something saying it's
required for CR specs and also for other specs at some
level of stability.
Florian: I think his wording was a should and it was reused from
other places. zcorpan are you okay with more specific
wording or do you want to keep the generic one?
<zcorpan> I would be happy either way, whatever works best for the
group
astearns: I think I would prefer having the more specific wording
so that I have something to point to when I start being
hard about this requirement.
astearns: Any objections to having more specific wording in test
repo documentation?
<Rossen> +1
<Florian> astearns: +1
<zcorpan> sounds good
* fantasai suggests astearns doesn't start being hard about the
requirement until the next publication of css-flexbox
and css-grid, or else they will not get updated on /TR
for at least another 5 months
astearns: I'll ask zcorpan to check those changes in.
fit-content() vs 'stretch' alignment
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1732
astearns: I'm not sure what's left. Can anyone summarize?
* tantek reads
<tantek> looks like we discussed it last week
TabAtkins: No one removed the agenda+
<tantek> because: <dael> jensimmons: I'm fine punting to next week.
Should viewport units still depend on scrollbar width for
overflow:scroll?
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1766
astearns: We're waiting on impl feedback?
TabAtkins: Yes, I'm getting ?? to comment.
dbaron: I raised this b/c gecko was the only engine that impl when
we decided this years ago. It's apparently harder to do on
stylo. I think it's reasonable on their part.
myles: If all browsers except Mozilla ones don't support and Moz
wants to remove it seems clear
TabAtkins: Without this feature there's a lot of cases where
viewport is broken. There are plenty that do, but I
suspect people are avoiding these things. You cannot
get 100vw to be the size of the screen. There's usually
a scrollbar and 100vw is too big.
myles: The description says it's only on scroll not auto.
TabAtkins: We decided viewport should be resolved at computed. For
overflow auto we decided to ignore scrollbar, but w
wanted to pay attention when it's there.
overflow:scroll causes a scrollbar so we set it to take
scrollbar into account in that case.
myles: Overflow:Scroll on root is not common case.
TabAtkins: I agree. But when your scrollbar appears your items to
100vw will overflow horizontal and cause a scrollbar.
The way we decided to let that be solved you can set
overflow scroll on it explicitly so it fits. Without
this viewport units are just broken. The only time they
add to the viewport is when you have no scrollbar which
is uncommon.
fremy: You still need to know size of scrollbar. It's not a static
number.
Rossen: We're talking about unit value. I'm with TabAtkins. If in
the case of overflow:scroll when scrollbar takes space away
from viewable viewport current spec mandates the correct
behavior from user PoV. viewport should resolve to
scrollbars.
Rossen: Changing spec for interop and going against what makes
sense isn't best.
Florian: If we don't drop the thing should we extend it to handle
the scrollbar-gutter property? Even if it's auto?
TabAtkins: Prob should. Assuming whatever element applies to root
scroller. If that works and we define how that would
help.
* fantasai agrees with TabAtkins
Rossen: I would argue against that. The element causing the
scrollbar could be defined in vh unit which causes
scrollbar and introduces a dependency. In the case of
overflow scroll on the viewport we only need to add
computed value and resolve overflow for the root. From
there on decide what the value will be.
fantasai: No one is suggesting auto for scrollbar. There's a
scrollbar-gutter property that adds extra space.
Rossen: I was reading the minutes from Florian about perhaps
extending to auto.
<fantasai> Florian was asking about scrollbar-gutter property
<Florian> https://drafts.csswg.org/css-overflow-4/#scollbar-gutter-property
TabAtkins: It's only when you have a predictable value to auto.
Florian: Even though you get that you get a predictable size with
space reserved but not scrollbar so maybe that shouldn't
count. I don't know.
Rossen: Let's assume simple l to r. Whatever an element with
abspos top 0 right 0 wherever that positions to should be
extent of vh.
TabAtkins: No because then by default auto changes value of vw
unit and that defeats the computed value time purpose.
Rossen: No in the case of the gutter we're talking about the prop
reserving space for gutter.
TabAtkins: If gutter is predictable yet.
Rossen: That's what I'm talking about. So if abspos items are
positioned to gutter this should be extent of vh as well?
Florian: I don't think we explicitly define it may fall out of the
wording, but I don't think that was conscious decision.
Florian: I don't think we decided on that.
astearns: Is that enough on the gutter sidebar?
Florian: I think we need to come back, but not for this call.
astearns: I want to go back to the discussion before gutters
where...I agree that vw should take the scrollbar into
account where it exists. But the one piece of impl
feedback on that is it's really annoying to have to
layout arbitrary things when you gain a scrollbar. Would
it make sense to define auto same as scroll case for vw?
It's always taking into case possible scrollbar?
TabAtkins: If you have overflow: hidden on root vw doesn't stretch
all the way across the screen.
Florian: Just auto.
TabAtkins: No, still hidden. Just changing auto doesn't fix dbaron
problem. He didn't want size of vw change based on
somebody updating [missed]
TabAtkins: Change at all is the worry. Main response is this is no
different when m unit. You change the font and
everything below has to change. Only more complicated
is that sometimes body can set viewport. So you can
effect one element up.
TabAtkins: Aside from that one element jump which is very rare and
not important for purpose of tree expense this is
identical to setting font size.
TabAtkins: You don't need layout this is computed value time
<dbaron> I think there were actually 2 issues.
<Rossen> dbaron, can you pls summarize?
<dbaron> One was that dynamic changes to 'overflow' are hard, but
that the other is that in Gecko, we need to depend on
layout to find out what the scrollbar width is.
dbaron: Second thing that made it hard in gecko, it's not ready.
dbaron: [missed]
dbaron: I'm not even sure it worked reliably. I think it worked
most of the time because usually we constructed scrollbars
first.
TabAtkins: Is that b/c scrollbar width is controllable in FF?
dbaron: It depends on too many OS dependent things and that code
exists in scrollbar layout.
TabAtkins: So maybe just moving the code up and piping the data
down into layout instead.
dbaron: It's possible that the number of things to test is 2 or 3,
but that's not the way it was written.
<Rossen> wouldn't webkit-scrollbar {width} have the same effect?
astearns: We're at time. I'm hearing the desire to keep spec
behavior as-is, but we'll need other impl to make the
changes. We should continue impl feedback in the issue.
We're out of time today, we'll talk next week.
<TabAtkins> Rossen: A controllable scrollbar width does cause
problems for this, yes. I'd be fine with a vw that
only responds to the "default" width of the scrollbar.
It actually *is* easy to make a global --var that's
equal to 1% of the viewport width minus whatever you
manually set the scrollbar to. (Not the case with the
UA-defined scrollbar width, I think.)
Received on Thursday, 31 August 2017 12:28:07 UTC