- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 4 Dec 2017 19:28:55 -0500
- 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.
=========================================
Flexbox
-------
- dholbert will investigate the Firefox code around sizing images
and add more details on their implementation to the issue.
His comment is here:
https://github.com/w3c/csswg-drafts/issues/1322#issuecomment-342307410
Image Decoding
--------------
- smfr introduced the group to the proposal to expose an API to
control background decoding of images:
https://github.com/whatwg/html/issues/1920
Line Clamping
-------------
- There were two points of discussion, how to address the existing
desire to have some of webkit-line-clamp and, if so, how to
extend that further.
- The desire is to have a concrete proposal for a webkit-line-clamp
like property to further discussion.
Cleaning up OWNERS files
------------------------
- Anyone listed on an OWNER file who won't be reviewing tests was
asked to do a PR and remove themselves.
- There was some interest in a bot to notify of unreviewed tests.
Feedback on testing policy
--------------------------
- The group spent time discussing how the resolution to require
tests for CR+ spec has been doing in practice.
- There was a desire to see a bit more nuance in the definition to
have the tests become required once there is one implementation,
to exclude editorial changes, and to clearly not require testing
every possible variation, but to instead be a general test.
- Additionally, there was a desire to add teeth to the policy where
changes are not merged into the main until there is a test.
However, several people were concerned that that requirement
would cause changes never to be merged in instead of the
intended addition of tests.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda
Scribe: iank
Meeting Planning
================
astearns: Talked with the chair of TTWG, about CSSWG equiv things,
talking with them on Friday this week.
<astearns> https://github.com/w3c/ttml2/issues/406
astearns: Looking for volunteers to go the meeting.
astearns: Lets go to non-interop of sizing images in flexbox.
Flexbox
=======
Non-interop of sizing images in flexbox
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1322
fantasai: <goes to project>
fantasai: Testcase in last comment: https://codepen.io/jensimmons/pen/aVmogq
fantasai: Flex container, and has some content that shrink down to
their min-content size, if you have too many items they'll
start to overflow.
fantasai: Excess space starts to take up, the text starts to break,
<explains the testcase>
fantasai: The item with the image starts shrinking.
fantasai: This FF behavior is kinda nice.
fantasai: So we want to make FF follow the spec? Or make other
vendors follow FF implementation?
dholbert: I wrote most of the flex code in FF, and don't know whats
going on here.
gregwhitworth: What is the usecase where folks would want this
behavior?
fantasai: This means that it won't overflow, where other
implementations would.
dholbert: <explains image gallery usecase> being able to shrink them
is kinda nice.
fantasai: The image doesn't shrink until everything else has wrapped.
cbiesinger: If you give the image a flex-basis: auto, and others a
flex-basis of 0, don't you get that behavior?
fantasai: You wouldn't be able to get them to start out at their
content sizes?
fantasai: I don't think we need to resolve now, but interesting to
think about.
dholbert: I'll try and figure out whats happening in our impl, and
report back on the github issue.
jensimmons: I had a few questions about flexbox, lots of interop
issues around squishing images, and because of those
issues, they are really hard for authors to think about.
astearns: Definitely want interop here, just need to agree what that
behavior is.
Rossen: It looks like we have all the impls apart from FF, having
interop.
Rossen: Switching to FF, means that we might run into compat.
fantasai: We were going through interop cases, and most of them were
obviously needing impl fixes, but this one seemed
interesting.
jensimmons: It also seems like we could do what we want, as there
seems to be such lack of interop around images.
gregwhitworth: Only about this issue?
jensimmons: No, more broadly about images as flex items.
gregwhitworth: Where are the bugs?
fantasai: Don't have them here. But this one just seemed interesting.
<gregwhitworth> jensimmons: it would be cool to see the full list of
issues for images as flex items
Image Decoding
==============
Github: https://github.com/whatwg/html/issues/1920
https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-decode
smfr: This should be fairly short. WebKit making more of its image
decoding async, to a separate thread.
smfr: Browsers do this in different ways, if an image has loaded
(event), there won't be a flash.
smfr: Off main thread decoding for animated images, - fairly
straight forward.
smfr: Also tried to do this for a large images.
smfr: A bunch of authors have assumptions about where the decode
happens.
smfr: Would like to propose a new APIs to allow us to do background
image decoding.
smfr: 2 things we've done so far.
smfr: Proposed an API for decoding. promise = img.docode();
smfr: <explains that once promise has resolved, image has decoded>
smfr: The 2nd thing that we've proposed, a way for authors to tell
the engine that is ok to decode these images async. (may be a
flash).
smfr: A way for authors to opt into async decoding for <img>, but no
way to do this for CSS images.
smfr: This might be something like a new image function, or
additional argument to the image function, etc.
smfr: Nothing written up yet.
TabAtkins: We left space for an async tag, in the url() function.
<group talking about image() function>
smfr: Google images does a thing where they load a low res image,
and then replace to a high res image.
smfr: This is broken in FF, and Edge.
Thomas Wisniewski: Can authors opt into sync decoding instead?
smfr: I think we need the attribute to go both ways... might have an
"auto" which is current browser behavior.
leaverou: Whats the usecase for authors to control this?
smfr: Want to display large images, without blocking the large
images.
leaverou: Why control for authors.
smfr: For compat reasons we can do this in more cases, as it
introduces flashes.
smfr: Lots of sites to this based on size of page, this case we'd
always to sync decoding.
smfr: If an image is going low-high res, you really don't want a
flash. The user-agent doesn't have enough information to make
the best decision.
smfr: It's hard for a UA to tell whether the image is replacing
something similar to itself (e.g., a low res version) or
whether it's replacing a blank space or a placeholder.
leaverou: Is there a way to provide a fallback image?
TabAtkins: image() function has this.
various: image() function was about supported formats fallback list
TabAtkins: We could have it such that the image() function will look
until it can render something that can be immediately
rendered, like a color or gradient.
leaverou: What's a data URL of an SVG considered to be?
TabAtkins: I don't know.
dbaron: Isn't there one reason that you need this the fact that
there is a 'load' event for images, do you need this for CSS
as there isn't a load event for CSS?
smfr: Authors do things like load the same image with an img tag,
then place the same image into CSS.
smfr: With decode you need to have additional information like the
size of the image.
smfr: prefer to have a declarative solution to this problem
<leaverou> also a remote image that has already been loaded and
decoded for some other reason should probably be fair
game too?
<leaverou> though then you have race conditions
chrishtr: The promise returned isn't permanent, such that the UA can
evict it from the cache if needed.
fremy: There are way for authors to place images on top of each
other.
smfr: We saw a bunch of different ways that people did this.
smfr: We found that there wasn't a way to do this well unless that
authors told us what they wanted.
plinss: Is there going to be an event?
smfr: No, unless we want to fire events for CSS images in general, I
don't think that we should special case.
Line Clamping
=============
GitHub: https://github.com/w3c/csswg-drafts/issues/390
TabAtkins: Ignore the topic of the github issue, basically many
years ago, hyatt added some hacky code that turned the
-webkit-box code, to allow it to do line clamping.
TabAtkins: If you have more ignore them for sizing purposes.
TabAtkins: The implementation is weird, very weird behavior,
property etc.
TabAtkins: We'd like to address this properly.
TabAtkins: This is the only major part of the -webkit-box code that
needs to be maintained.
TabAtkins: What needs to be mapped, preserved for line-clamp, and
removed.
TabAtkins: We'd like to start up a spec to handle the line-clamping
behavior.
eae: Would like a way to eventually alias this property over.
eae: And would like to do this in a way that other folks can alias.
florian: I don't remember the discussion of the spec.
florian: Expand on what we already have?
TabAtkins: Yes.
smfr: Would like to extend this feature a little.
smfr: Mail client has a feature where it keeps some lines at the
beginning, keeps some lines at the end, and collapses in the
middle of the content, with clicky in the middle to expand it
all back
smfr: Collapses in the middle of the content.
smfr: We would like to see this as start, end, middle.
florian: max-lines as currently specified is a fragmentation thing,
makes the div into a fragmentainer, that breaks after a
certain number of lines.
florian: Drop the rest of the lines.
florian: Could make it such that you get additional lines.
smfr: We did consider fragmentation to implement this feature, I
don't really have opinions on how to do this.
smfr: It does interact with fragmentation possibly.
leaverou: Why is this being discussed in terms of max-lines, and not
max-height?
florian: Images in between for example, typically people want to
clamp lines
florian: and break at a fragmentation point, not slice partway
through a line
florian: The generalized this in overflow-4 lets you deal with
heights...
florian: And let you decide if the additional div gets dropped.
leaverou: In most cases I've seen the clipping is visual.
florian: But you don't want to split a line in the middle?
leaverou: If an ellipsis isn't displayed, people won't use this.
florian: Its a separate issue...
Scribe: eae
iank: One thing I'd like to stress is that we've seen a lot of
demand for something simple like clamping the number of
max-lines. Would like to keep it simple and not expand scope
too much.
iank: Clamping both start and end adds complexity as it requires
layout out all of the text. Have to think about.
iank: We're looking to remove support for percentage values for
webkit-line-clamp. Behavior is bizarre and there is
essentially zero usage.
<eae> use counter for percentage values:
https://www.chromestatus.com/metrics/feature/timeline/popularity/2139
fantasai: I agree that we should limit scope. Discussion about
advanced use cases is great, but I don't want to go
there right now. Want to understand actual proposal.
fantasai: As I understand from proposal, calculate the height of
specified lines and set max-height based on that.
Is there more to it then that?
TabAtkins: You don't want the lines to still be there like with
line-clamp, we want to omit the rest of the lines.
TabAtkins: Want to suppress display of line boxes after the cut off.
TabAtkins: Right now they are simply considered to be of zero height
for sizing but are still there.
<TabAtkins> https://drafts.csswg.org/css-overflow-4/#issue-6fadc074
fantasai: So the ellipsis gets inserted?
florian: The machinery of clamping or cloning or fragmentation is
invoked implicitly if set max-lines. There is an issue
saying that one has to explicitly enabling the
fragmentation support.
iank: My only concern with that is that invokes a bunch of machinery
that takes a lot of implementation work. A simple max-lines
behavior is potentially a lot simpler.
florian: Concerned that it would require a lot of reinvention.
Rossen: Want to re-emphasis fantasai's question. In my mind we keep
going back and forth between two different things:
Rossen: 1) Fragmentation and stop layout at some boundary. Should
think of this in css4
Rossen: 2) Existing pain, what TabAtkins is taking about. We have a
a lot of requests for webkit-line-clamp support.
Rossen: My point here again. This is different. If we want to be
compatible with webkit-line-clamp then the behavior is
different. Not fragmenting, consumes space differently.
Rossen: Not that different to implement as long as it doesn't
involve fragmentation.
fantasai: Would like to see a concrete proposal.
TabAtkins: The goal of this was to start up something that at the
bare minimum addresses the "I want n of something".
TabAtkins: All reasonable things that I'd like to see addressed.
Should resolve whether we want to do or not.
fantasai: line-clamp can be made to support a subset of uses cases
but if you want support for more complex use cases then
the problem gets a lot harder.
fantasai: Should try to tackle the problems one at a time.
fantasai: I don't want to expand line-clamp, I would rather it
stayed as some minimally simple property that could be
used to *build* other things. Not design it to be expanded
to do all the other things.
TabAtkins: I would like to explore the space. Replace
webkit-line-clamp first and then, maybe, extend it later.
florian: Responding to ian/rossen. When I was talking about invoking
the machinery not walking about ..., to deal with
fragmentation. I think we sort of have to, if not then we'd
have to resolve what to do about text shadow, intruding
floats etc. Would rather refer to the fragmentation spec.
florian: Would also be compatible with the rest of the spec in the
future.
florian: css overflow invokes css break, max-lines already speced
there.
<fantasai> https://www.w3.org/TR/css-break-3/#possible-breaks
Cleaning up OWNERS files
========================
Scribe: TabAtkins
gregwhitworth: I got put on a review for Syntax (which should never
occur, I don't know it)
gregwhitworth: That exposed a problem - I submitted some tests,
those people should be in owners.
gregwhitworth: When I add a flexbox test, 9 or 10 owners are added,
but geoffrey ends up always reviewing them.
gregwhitworth: So if we could go thru and review the OWNERS files
and make sure it's actually the QA owners.
gregwhitworth: Whoever is actually going to be the person that will
review a given spec.
astearns: I think >1 person is good, but yeah, if you're on an
OWNERS file and not willing to review, is it just a PR to
remove yourself?
gregwhitworth: Yeah, just asking everyone to do it for themselves.
^_^
astearns: And adding yourself to OWNERS where appropriate.
gsnedders: There has historically been some habit of using that like
a cc flag, rather than a test-owners thing.
foolip: This ties into triage - we can mess with OWNERS files, but
we also need to notice when people in those files aren't
doing reviews.
foolip: Also helps us discover where we need to add people.
foolip: What do people who are submitting tests want? Immediate
review, I guess, but how do you deal with spec issues when
things go unnoticed for a while?
florian: For spec issues we eventually had to do a DoC, so we go
thru and make sure nothing was dropped.
florian: That helps with specs that are worked on, even if slowly.
But it doesn't help specs that aren't worked on.
foolip: So that's like every quarter or so?
[laughter]
florian: Usually much slower. Sometimes every few years.
foolip: So any prefs on how this should work? A bot emailing the
list when things go unnoticed?
florian: If we sent something every *year* when things were
reviewed, it would be a massive improvement. 2 days would
be crazy fast.
gregwhitworth: Related: if you've ever committed to a spec, go to
w-p-t repo and check the OWNERS files. If you're not
actually relevant for that spec, remove yourself.
dbaron: Or if you notice yourself getting reviews for something you
feel like you shouldn't be reviewing.
Feedback on testing policy
==========================
zcorpan: I made a PR in September to add a testing policy for the
CSSWG for specs in CR.
zcorpan: + CSSOM and CSSOM-view
zcorpan: I wanted to get feedback from the WG on how this has been
going - if policy is working, what benefits, what might
need changing.
Chris: In other groups that do this, editors do PRs and then the WG
approves and merges.
Chris: In there, adding a test in is really easy.
Chris: In our group we don't do that, editors push to master. That
makes this hard.
Chris: *Some* editors seem to be doing tests and specs together,
it's useful.
florian: I've tried to be more systematic about writing tests with
changes, and linking to the tests from the changes.
florian: What I haven't noticed is a significant difference in
reviewer activity; I was worried it would be the
bottleneck, and it still is.
florian: We haven't been doing this long enough for my anecdotes to
become data, but it doesn't seem improved from the past.
Chris: The spec-readiness things that go out every week, I've been
guilty of using that to push people on reviewing things.
<zcorpan> (issues with "Needs Testcase" label
https://github.com/w3c/csswg-drafts/issues?utf8=✓&q=label%3A"Needs%20Testcase%20(WPT)"%20
)
gregwhitworth: I'm gonna be a pain - I agree with florian from last
discussion. I desire a world where everything modern
- I run flex, grid, vars, etc - I'm running daily our
build system, and if it turns red I know we regressed
or the spec changed.
gregwhitworth: This is very important, I can't keep track of
everything.
gregwhitworth: I'd like to start giving teeth to this.
gregwhitworth: I don't think we'll ever get to the interop goals us
browsers want without tests added for every change.
foolip: What teeth would you like to add?
gregwhitworth: There's words that it's CR.
gregwhitworth: I feel like it should be more universal.
gregwhitworth: Every other WG MS is in has this policy - every spec
change has tests along with it. We're the only WG
that doesn't.
gregwhitworth: Just spent a lot of time reviewing flexbox tests,
finding a lot of old redundant tests, a huge waste of
time.
<tantek> I would be ok with WD + impls
<tantek> = require test case to make normative change
<tantek> not just WD
florian: Even tho this is somewhat informal, this group sometimes
does internal incubation, and forcing tests then seems
counter-intuitive.
florian: Once we reach the point we're no longer brainstorming,
actually refining...
foolip: Most other groups don't have a CR req, it's just a matter of
"if it makes sense at this point, let's do that".
foolip: That's a problem for immature stuff.
foolip: So the criteria I propose is: anything with one or more impl
has tests.
<tantek> +1
foolip: Means you can punt on testing until someone tries to
implement.
foolip: And first implementor is in a good position to write tests.
Shouldn't always be editor's task; it's not that in the
WHATWG.
dbaron: Same - when you have impls.
dbaron: Also it's very dangerous to write tests without impls.
dbaron: You write a whole bunch of tests, try to execute spec in
your head, and it turns out that people are worse at that
than software.
dbaron: So you end up with lots of tests that are wrong in subtle
ways.
<tantek> +1
<bkardell> +1
dbaron: We also have a general problem of losing track of things
like spec changes, edits, and figuring out the state of
things.
dbaron: Part of that is that we tend to resolve to change things,
and then nothing happens.
dbaron: I feel like we should try to use GH issues more for this.
dbaron: If we have a thing we agree to do and it's not done yet, we
should be tracking it in GH as an open issue.
<tantek> resolutions for normative changes MUST be in a github issue
<foolip> for people reading the logs,
https://github.com/foolip/testing-in-standards/blob/master/lifecycle.md
is my whole thinking about when it makes sense to start
caring about testing.
florian: Aren't we already doing that?
dbaron: I feel like we're not.
dbaron: This includes us agreeing to some resolution, and there
isn't an issue for it.
TabAtkins: After F2F, make sure everything is in an issue or tracked
otherwise
dbaron: Even in a meeting - should have an issue as soon as we
discuss something.
astearns: Going back a bit, question of teeth.
astearns: Whether we should apply this rule to CR+, or bring it back
to things with impls.
astearns: What are the teeth?
astearns: We haven't been consistent about it even with CR+
TabAtkins: For anything in testing stage, only do edits via
PR-merging.
TabAtkins: Only push to master for incubation-stage stuff.
<tantek> for normative changes
<tantek> editorial should not require that
astearns: Agree
<TabAtkins> agree with tantek
<tantek> also important to drop or update existing tests that are
affected!
florian: If we agree to enforce it that way, we need to be careful
about how to process the giant backlog, and if fantasai and
tab create 25 PRs per week, still problem with processing
them.
florian: So going from "a bunch of specs not tested" to "most of the
spec is in hanging PRs" isn't an improvement.
fantasai: That's my point - "why don't you block edits on writing
tests", I think it's better to publish things where they
can see them, instead of seeing a diff.
fantasai: Some things will only require one test, others will need
200. I don't want to be on the hook for all of those.
astearns: That's not the request - SOME tests, not a full test-suite.
florian: Not full test suite, just full tests *for the feature being
tested*.
astearns: I'm saying just "at least one".
fantasai: Like, if I change an orthogonal flow thing, I need to
write like 500 tests.
fantasai: That's an extreme example.
fantasai: but 30+ test isn't uncommon
florian: Regardless of the rules we set up, we won't solve this
until some companies set up a budget to pay for QA.
florian: If we don't get that, we'll rely on the goodwill of people
like me, and that doesn't scale.
zcorpan: PR model in the whatwg - every change has a PR, someone
needs to review, someone needs a testcase.
zcorpan: Without that, the PR is left open, we never commit to
master.
zcorpan: Sounds like there's some issue with the workmode - edits
get made, we forget about testcases, or resolution are made
and we forget about edits, that sort of thing.
zcorpan: So what workmode do we need to not lose track of things.
fantasai: I think GH is helping a ton with that, to the extent that
things are in GH.
fantasai: Resolutions get in there from gh-bot
fantasai: And we have a needs-testcase flag.
zcorpan: Responding to fantasai's point, about changes with a big
testcase burden.
zcorpan: The policy in CONTRIBUTING.md is that in such cases,
instead of writing the tests, you file an issue with wpt
explaining that this change needs testcases.
zcorpan: Or something is blocking writing the testcases.
zcorpan: So documenting that testcases are missing, and why.
florian: So this sounds like a variant of our needs-testcases flag;
not sure which is better if nobody looks at them?
zcorpan: If it's straightforward but a lot of work, then
needs-testcases in CSSWG seems like it's sufficient.
zcorpan: But sometimes there's tooling missing to write it at all,
in wpt, so that needs a separate fallback.
zcorpan: So then we need an issue in wpt, saying that the current
tooling makes it impossible to write a case for.
gregwhitworth: I agree with the once-one-impl thing.
gregwhitworth: I know internally we're focusing more on testing.
gregwhitworth: I think it's worthwhile, as much as we'd all love to
solve every problem in spec form, we all depend on
interop.
gregwhitworth: Doesn't matter if we all implement some new thing if
it doesn't work properly in every browser.
gregwhitworth: So go with PR, say it doesn't land without at least
one test.
gregwhitworth: And with gh issues, often there are already
testcases, just informal, need to be wrapped up in
testharness
gregwhitworth: I don't think it's a monumental task to get this
working.
gregwhitworth: And when we go implement it, we'll create more
testcases, and implement that.
fantasai: Yeah, one or two testcases is way more manageable than
"please fully test this change in all permutations".
gregwhitworth: I'd love when we go to CR we already have a testcase
working.
gregwhitworth: To hammer home the point - I'd like to get some
resolution that's beyond CR.
gregwhitworth: I think we need teeth or else nothing will happen.
* fantasai would like to just get more specs in to CR that are
supposed to be in CR
gsnedders: I have 2 viewpoints.
gsnedders: I don't think there's any point in testsuites before
impl, same as others.
gsnedders: But when there is an impl, the vendors who impl'd will
have written tests, to land the feature.
gsnedders: So inherently there's already a testsuite.
florian: It might not be shared, or shareable.
gsnedders: Tho now we have 2-way sync from Gecko and Blink, so
hopefully more and more tests are in wpt from the get-go.
gsnedders: The other thing is getting tests per edit.
gsnedders: So presumably, when someone impls the edit, there's a
test for it.
TabAtkins: We don't want to hold up PRs until someone impls
something.
fantasai: Yeah, anything that forces us to hold a PR for more than
2 weeks is a failure.
fantasai: In CSS2, we had that errata list, and if you wanted to impl
something you had to check the spec and the errata.
fantasai: This got super unwieldy, so we eventually merged all the
changes in to create CSS2.1.
fantasai: I don't want to get into that same state, except way worse
because instead of an errata list you have a disorganized
pile of diffs in GH PRs.
fantasai: If we're withholding edits from being published for
too long, that's a failure state.
gsnedders: When it comes blocking things on PRs, the experience from
the other groups that have done this is that we don't end
up blocking on PRs.
florian: How?
gsnedders: Someone comes along and actually looks at it.
gsnedders: Sometimes someone wanted to impl it, so they want the PR
landed. Sometimes because someone is watching and
reviewing the changes.
gsnedders: Generally there's far less problem getting review.
dbaron: The point of changing the process is to change how people
spend their time.
dbaron: I think if we're changing the process to make people spend
more time writing tests, people will spend more time writing
tests.
florian: And we might distinguish between "everybody" and "tab and
fantasai". If we don't want tab and fantasai to spend less
time writing specs, we need more people to write tests.
florian: Their plate is already more than full being the catch-all
editors. That's why I suggested someone funding the QA work.
foolip: I don't think it's a matter of decreasing throughput.
foolip: Ultimately everything needs to be implemented.
foolip: It's a matter of closing the feedback cycle, so the thing
being written is closer to time of test being written and
time of implementation.
foolip: So getting impls more involved in writing tests and keeping
track of changes to the spec.
foolip: It would be a failure if it ends up with the editor writing
all the tests.
florian: My earlier point here - either we decrease tab and
fantasai's throughput, or we move test burden.
foolip: In Blink, soon to actually ship something we'll require it
to have wpt. So that's a forcing function.
foolip: Can't go on indefinitely without it being on a Chromium
engineer's plate to get the work done.
fantasai: So that bug - made edits, made a PR, then engineer is
leave of absence for months, then team does a perf push,
then a YEAR LATER someone finally impls it... the PR has
been there for a year.
fantasai: The spec needs to be reliably up-to-date with what we
decided.
<jensimmons> +1. We can’t have secret spec updates living in pull
requests, invisible to people.
dbaron: If you make a spec change and *nobody* tries to implement it
for a year, we'll just wait and change it again anyway.
fantasai: But if it's in PR, and I need to change something about it,
I can't see those edits.
fantasai: I can't deal with a pile of PRs like that.
fantasai: If we wait for impls to make the change, it'll always be
months.
<dbaron> I don't think the implementors have to be the ones who make
the test change
<fantasai> dbaron, right, which brings us back to the editor has to
make the test change
<fantasai> basically I'm saying foolip's idea that implementors will
take up the responsibility to write tests for all spec
changes is unworkable
<jensimmons> as a person who’s worked in git code repos for years,
with teams, you cannot leave things lying around in
pull requests. That’s a terrible way to work.
<gsnedders> jensimmons: the experience in other groups hasn't been
things lying around in PRs; if this WG can't get things
reviewed that implies something is going wrong within
this WG
<jensimmons> gsnedders: but that is the experience of *this* working
group
<gsnedders> jensimmons: yes, indeed; the question is why are
participants, most of whom work for vendors, act
differently to their colleagues in other WGs
<jensimmons> this is has been sitting here for 2 months:
https://github.com/w3c/web-platform-tests/pull/7364
<gsnedders> jensimmons: and this is something we see relatively
rarely for other testsuites, which implies for whatever
reason the layout developers behave differently to e.g.
the DOM developers, and it's not clear why
<jensimmons> gsnedders: struggling with getting people to write
tests is *insanely* common in the industry of people
who make websites. It’s not the CSSWG.
<gsnedders> jensimmons: yes, that's true; but it's not an issue we
see around most of WPT
twisniewski: I was gonna suggest we start with something simple,
like have gh hooks that say when there's open requests
in the spec. Someone will be annoyed and poke people.
twisniewski: And there's a push for people to go fix it up.
Chris: Echoing fantasai, it's hard to review spec changes and tests
with a bunch of diffs.
Chris: When I was doing the fonts 3 review, I put them in the w3c
repo just so people could see them execute.
plh: We have a mechanism for that in wpt.
<plh> --> http://w3c-test.org/submissions/ pull requests for WPT
astearns: I suggest we take out of this discussion to tighten up
what we resolved on.
astearns: Already resolved on tests for CR+
astearns: I suggest we try out the PR for CR-level specs model.
astearns: With the caveat that we want to see how we deal with those
PRs, so they don't just pile up.
florian: We'll still have stuff piling up.
florian: Nobody's been reviewing tests, even tho I'm blocked.
astearns: I don't see a way of solving that issue before break.
florian: I don't have a solution without money.
gregwhitworth: Or down the through-put.
fantasai: So say we're like "you need tests for the PR, but nobody
else will do it, therefore editors have to write the
tests".
fantasai: So 50% of my time goes to tests or whatever.
fantasai: Then people complain "why isn't this in the spec, I want
to ship it yesterday"
TabAtkins: The earlier failure mode was "no impl happens for a long
while, so no urgency on the test, and the PR hangs". Here
you're positing someone wanting to implement. They'll
produce a test, then.
<tantek> thank you astearns
<br dur=20min>
Received on Tuesday, 5 December 2017 00:29:51 UTC