- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Dec 2015 05:31:43 -0500
- To: www-style@w3.org
Organizing the Developer Meet Up at Sydney
------------------------------------------
- There were some offers to speak at the developer meet up.
- Rossen will take over the Houdini talk since TabAtkins won't
be able to attend.
- astearns is willing to give the talk he's giving at this
week's dotCSS conference.
- fantasai will do a talk on best practices.
- gregwhitworth offered to do a talk on a TBD topic.
- Bert was willing to speak if needed.
- Bert said that the local organization was handled.
Animating 2d Rotation Transform Function for Polar Coordinates
--------------------------------------------------------------
- Jihye introduced her proposed solution for handling the
relationship between polar-angle and animations.
- The best path forward depended on if the computed value of
polar-angle is an angle or stays as a keyword.
- Jihye will look for use cases of the property to determine which
solution is the right one and present her use cases and
conclusion on the mailing list.
Using Polar Positioning as Part of Absolute Positioning
-------------------------------------------------------
- Most members of the group thought it would be possible to use
polar positioning as a part of absolute positioning, but were
unconvinced it was a good idea.
- bradk, who proposed the idea, was having technical troubles so
the conversation will continue on the mailing list.
Dealing with Pull Request Pile Ups in our Test Repo
---------------------------------------------------
- There is a backlog in the test repo which needs to be worked
through. The issue was raised on the telecon in hopes of
having these specific pull requests addressed and to begin
working on preventing this in the future.
- The idea of assigning who is responsible for testing was raised
and, though it had been tried before, was still believed to be
a good idea worth investigating further.
- A lack of QA people in the working group or any person in charge
of testing overall were both noted as additional problems that
should be a part of the conversation.
- For now the conversation will continue on the mailing list and
in a week or two we will check back to see if the backlog is
starting to clear.
- The standard for accepting a test was briefly touched upon with
several people expressing that it should be a lower standard
than code.
Progress Report on Snap Points
------------------------------
- RESOLVED: Replace scroll-snap-destination with
scroll-snap-padding
- RESOLVED: Replace scroll-snap-coordinate with scroll-snap-align
and scroll-snap-area
- RESOLVED: Add axis keywords to a property applied to the scroll
container with added issues
(https://lists.w3.org/Archives/Public/www-style/2015Nov/0328.html)
Will Change
-----------
- Both topics were editorial and can stay on the mailing list.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2015Dec/0022.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Alex Critchfield
Greg Davis
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Jihye Hong
Dael Jackson
Brian Kardell
Brad Kemper
Peter Linss
Myles Maxfield
Thierry Michel
Edward O'Connor
Anton Prowse
Matt Rakow
Florian Rivoal
Alan Stearns
Ian Vollick
Greg Whitworth
Regrets:
Adenilson Cavalcanti
Tantek Çelik
Lea Verou
Scribe: dael
Organizing the developer meet up at Sydney
==========================================
Rossen: Good morning. Let's get going.
Rossen: Do we have any additional agenda items anyone wants to add?
[silence]
Rossen: I saw that there was some chat about this on the private
list. TabAtkins was mentioned doing a talk on Houdini,
Bert asked about who would speak on CSS. Do we have a plan?
Bert: No plan. I think the situation got worse because TabAtkins
isn't coming. So we need somebody for Houdini. Rossen you'd
be good.
Rossen: I can do that, yes.
<glazou> Tab confirmed on w3c-css-wg
Rossen: TabAtkins, are you not coming to Sydney?
Rossen: We'll miss you.
Bert: So Rossen would be good for Houdini. We can push some topics
we want to push, select what we want to talk about with the
devs. If people have ideas for speakers or topics let's hear
them.
Rossen: astearns is talking at a CSS conference I think...what was
it next week?
<astearns> dotCSS
astearns: [breaking up] Getting some more participation in CSSWG
and Houdini.
Rossen: It was hard to hear, but you said testing and contributing
to CSSWG?
<astearns> yes
Rossen: Okay, great.
Rossen: So if we have nothing else, astearns can rehash that topic.
Or we can do something different. Are there any members
that express willingness to talk at that dev meetup?
<astearns> happy to jump on stage and rehash.
fantasai: In Sydney?
Rossen: Yes.
fantasai: I can do a best practices thing.
Rossen: Great.
Rossen: Who is hosting this?
Bert: Organized mainly by Shane and will happen either at the
Google place or at a nearby place. We're expecting 30-60
people. Local organization is taken care of. My question is
what do we want to talk about while we're there. That was
the question for today. The rest is taken care of by Shane.
gregwhitworth: Is there a way to determine what level of developer
we're getting?
Bert: Professional web developers.
hober: Since modularization developers level independently. We'll
have a mix.
Bert: Yes, but we can assume they know quite a bit about CSS. Not
everything we do but CSS in general yes.
Rossen: I'm still not hearing any takers besides fantasai doing a
process talk. It would be good to have at least one or two.
fantasai: I said best practices.
Rossen: Yes, do that.
Rossen: Do we have anyone that wants to take the opportunity to
talk about the more recent stuff or the things coming in?
It would be good to have something more inspiring than
'come help us'.
Rossen: I'll take that as a weak yes.
gregwhitworth: Can we do this on the list? I'm open to talking,
but I'd like to figure out what would be beneficial.
There's lots of buzz about round-display. I think
we can find speakers, but it would be cool to
figure out the subjects and then see who is best to
speak to them. Is that alright?
Rossen: That's true, but speakers come with their topics. But for
example if you want to talk about grid and flexbox, that
is pretty relevant and recent from a web developer point
of view.
gregwhitworth: I'm game, yeah.
Rossen: Bert did you have anything in mind to talk about yourself?
Bert: No, I haven't thought about that. Maybe I'll come up with
something, but not at the moment.
Rossen: Let's leave it here. It sounds like we will have topics
that will fill time. Between Houdini and fantasai and
gregwhitworth's topics we'll have things. I'm also curious
as to if SVG will join. That would take more time. I'll
touch base with Shane.
Round Display
=============
Animating 2d Rotation Transform Function for Polar Coordinates
--------------------------------------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2015Nov/0277.html
<jihye> https://drafts.csswg.org/css-round-display/#2d-rotation-transform-function
jihye: We sent the extension of the 2d rotation as added to round
display.
jihye: Keyword values polar-angle and polar-angle-reverse can be
the value for the rotate function. There was discussion
about animating this function. When polar-angle property is
inside an animation and 2d rotation transform function is
given polar-angle the transform changes because the
animation.
jihye: Because polar-angle and polar-angle-reverse are computed
value of polar-angle property the element revolves around
the origin and the anchor point of the element.
jihye: It is difficult to design the element's behavior where
there is animation for the extended 2d transform. There can
be a situation where polar-angle property and the function
are animated.
jihye: When the animation of the function is defined with
polar-angle or polar-angle-reverse it means animating
polar-angle property is used for an animation.
jihye: It is possible, but I think it's weird.
jihye: I think if you want to use the function with the keyword
value for an animation there should be a condition of not
animating the polar-angle property. With that condition
it's animated with computed value. Does this make sense?
smfr: I have a question, imagine you have a transform that looks
like:
<smfr> transform: translateX(100px) rotate(polar-angle);
smfr: It has a translate and then polar-angle. Is the expectation
that the angle is computed after the translation? Does
polar-angle get computed after other transforms?
fantasai: It's just a value of the polar-angle, it's not dependent
on position.
smfr: I thought there was a value that computed relative to the
origin of the containing box.
fantasai: No. It ends up working like that if you're doing a
clock-face type layout, but if you position it using
another property than polar-positioning, we would still
take the value of the polar-angle.
smfr: So if there's a transform does it effect the value?
fantasai: No, just like margins or it being a flex box don't. It's
just the value of the polar-angle property. It's a good
point and we should make sure it's clear in the spec.
<dbaron> So when determining the computed value of 'transform',
does polar-angle turn into an angle, or remain as a
keyword?
myles: Am I right that the proposal is to make polar-angle not
animatable?
fantasai: It should be.
myles: Then I'm confused.
jihye: I think polar-angle is animatable and when 2D rotation
transform with polar-angle or polar-angle-reverse we have
to have a condition that not using polar-angle as animation.
Is it possible to have this kind of limitation?
dbaron: One thing I don't understand is if when you figure out the
computed value of transform, does polar-angle turn into an
angle or stay a keyword?
fantasai: That's the fundamental question
jihye: I think computed value.
Rossen: What do you mean computed value? Is it an angle or a
keyword? Both could be computed
jihye: An angle, not a keyword.
myles: So if that's true it's well defined to have animations on
both properties. The element will just look like it's
swimming when you animate.
myles: When I brought this up a couple weeks ago, I wasn't sure if
we've had anything where one animation depends on the
result of another one.
fantasai: Same situation as border color.
myles: If there's precedent, it sounds fine.
Rossen: Okay. So does that sound like a good outcome?
Rossen: For you, jihye?
jihye: Is it okay that polar-angle property is animatable and the
function is used in animation? Both are okay?
<bradk> Yes
dbaron: I think it is. I think one other thing is that the
animation behavior basically can be derived from what the
computed value is, essentially. It maybe is worth thinking
more about which computed value and animation behavior you
want. That's not clear to me.
dbaron: In other words, the decision about if polar-angle turns
into an angle or is a keyword in the computed value it
determines what the animation is.
fantasai: If it stays as a keyword you can't animate between
polar-angle, but as polar-angle animates, the rotation
will also animate. If it turns into a value at computed
value time then you can animate between polar-angle and
a different angle. But if you animate polar-angle and
the rotation, the rotation animation will not track the
changes in polar-angle.
Florian: I think we need to look at a number of examples that
would try to do this and pick what makes sense. In theory
it could be both, but it depends in practice what people
want.
Rossen: jihye do you have examples or preference for one or the
other? Or are you looking for feedback?
jihye: Maybe I can...I will write down the examples/use case in
the mailing list and discussion can continue later.
Rossen: That sounds fair. It would be good to see examples for
that. I'm also having a hard time wrapping my head around
which makes more sense.
Rossen: Did you want to move on?
jihye: Let's move on.
Using Polar Positioning as Part of Absolute Positioning
-------------------------------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2015Nov/0253.html
jihye: When the element is positioned with polar-coordinates, the
position property has to be polar. But there had been an
opinion for using polar positioning as part of abspos.
jihye: bradk suggested instead of having positioning position,
polar distance activates polar positioning. When the
element is abspos it can have 'top' 'right' 'bottom' 'left'.
Combining with polar positioning...I think it's
unreasonable because 'top' 'right' 'bottom' 'left'
indicates how far the padding edge is from the containing
block's edge in abspos.
jihye: With 'top' 'right' 'bottom' 'left' it is positioned based
on containing block edge. Polar-distance and polar-angle
are relative to polar coordinates. So they cannot combine,
I think.
<bradk> I don't think my microphone is working
Florian: They could if we gave a different meaning to 'top'
'right' 'bottom' 'left' when polar positioning is
activated.
ChrisL: You could combine, but it's awkward. You'd have to treat
polar-positioning as a transform and change your
coordinate system and push around matrices. I'm not saying
it's a good idea, but it's possible.
fantasai: Or have the offsets represent changes to the containing
block area so it would change the meaning of 100%.
ChrisL: That's true.
fantasai: We might need an initial value for polar-distance. You
could have abspos change what the offset is and if you
polar position it's in that new box. Similar to grid
layout.
Florian: Wouldn't that be super counter-intuitive? If you put 10px
left it would move it by 5px.
fantasai: It looks like bradk's mic is broken. We may want to
revisit when he can participate.
<bradk> Yes. I don't understand the arguments against, which were
not on the mailing list.
Florian: To add a point, one aspect I found interesting in that
proposal is that it could also work with relative
positioning. Because as currently proposed position polar
is a kind of abspos. If we do something along bradk
proposal it would work in other positioning modes.
jihye: I have a question for bradk. He suggested center property,
but I don't think that is different from polar-origin
property and the center property he suggested. Can I get an
answer to that?
Rossen: Since bradk can't talk without a microphone, we can wait
to see if he can type a reply.
Rossen: Or we can move the topic to the mailing list.
<bradk> Center prop would be usable in other situations
<bradk> Could take other percentage values
<bradk> Could be center-x and center-y also
jihye: Yeah. The discussion should be in the mailing list. It's
better there, I think.
Rossen: Let's pause on this for now and move it to the mailing list.
<bradk> Please present all arguments against in the mailing list.
Dealing with Pull Request Pile Ups in our Test Repo
===================================================
<Florian> https://github.com/w3c/csswg-test/pulls
Rossen: Florian brought this up as a frustration and it's a good
topic for us to bring up for discussion and visibility. As
stands the test repo pull requests are piled up a bit.
There's a few questions. How and who should deal with this?
Rossen: The presence of volunteers to deal with this. And in the
future how to move forward so there's more test coverage
in the repo.
Florian: I don't know if everyone has opened the link, but there's
28 pull requests, most of which are months old. Only 6
are mine.
Florian: It's not necessarily all things get stuck, but depending
on which spec and area, some topics have a hard time
getting review and that's bad.
Rossen: So that is the problem.
Rossen: Do you have a proposed way forward?
Florian: One would be, since now everything is piled up, but once
that's done go through every spec affected by a pull
request, ask who feels responsible, and if yes why it
didn't happen and if no who is responsible for that.
Rossen: Okay. So I'm not hearing anyone...
Florian: Not hearing anyone rush to the rescue.
Rossen: No, and historically editors are willing to jump on test
coverage, but specs are different in their velocity of
being worked on. If editors aren't paying attention to one
area I can see how it piles up.
Florian: I think the problem is worse than the queue. When I have
something like a few test cases submitted and waiting, I
don't submit more, and I don't think I'm alone in that.
So there's tests in people's head or computer because
something isn't moving.
Rossen: That's a fair point. Especially with TTWF events where we
try and get attention. If the response from our side is
silence and sitting on reviews, it's going to discourage.
Rossen: I'm not going to push for immediate action or having to
have a process in place, but I wanted to bring this on
everyone's radar for awareness. If people have ideas it
would be great to discuss those on the list. We can
revisit in week or two.
Rossen: We'll have to make more decisions with no movement.
fantasai: We in the WG...it's largely people in a PM role. We have
developers on the list, but we don't have QA people
across the WG.
fantasai: QA people do their own thing. Maybe we create a
community there and maybe have them talk about how to
make their jobs easier in a community. But we don't have
that now. Jeffery S. is the only QA person we have now
and that's new. The people working on testing need to
get involved.
Florian: Producing the test suite is in the charter of this group.
People in the group should care.
fantasai: But this has been a problem for how many years? Whatever
we have in terms of structure isn't working.
Florian: I think what you're suggesting would help. but also name
who is in charge of test suite.
<dbaron> Didn't we do that before?
ChrisL: I think that's a good idea.
fantasai: I'd like that. We've tried and it varies on the person
named. I think we should do that and have a strong
ownership model of the tests. Then the question is who
will work on tests and who cares.
Florian: I'm willing to review tests submitted against specs, but
can't review my own.
Florian: Naming isn't just ownership, but visibility for when
someone isn't doing it we know we need someone else.
<fantasai> We don't have sufficient people to replace people who
aren't doing their job.
Rossen: Submitting tests shouldn't be different than code changes.
You write code, submit it, and someone reviews your
changes. Testing shouldn't be different, it isn't on our
end.
Rossen: Having people that are reviewers for an area, spec editor
or not, has to be determined. In the end someone has to
own the test side of something like, say, flexbox. When
tests come that person should be expected to review.
Rossen: There there is a thing where someone dumps hundreds of
tests and that's a bottleneck.
Florian: That's okay. If that happens it needs to clear eventually.
Florian: I think we need two people for each area since the person
in charge couldn't submit tests themselves.
Rossen: Certainly.
<dbaron> I tend to think tests shouldn't have as high a standard
of review as code; there are many categories of tests
where mistakes will be caught as a result of seeing
failures and saying "but that behavior is correct"
<astearns> +1 to dbaron's comment
Florian: So do we name people today? Probably not. The other
question is do we go through specs in the queue today and
see if people will react.
Rossen: I don't think we could get anywhere actionable today. We
have 13 minutes and more topics. We brought awareness. It
would be good for use to discuss this on the ML and move
forward both with the current queue and get the process
forward for the future.
Rossen: Let's stop here and Florian if you want to ping people for
your areas I would start with the spec editor and if you
happen to be the spec editor ping someone else and see if
they can help. Otherwise ping me.
Florian: I've done that already.
Rossen: I see. We have a problem and as fantasai pointed out it's
not new.
* fantasai notes that we don't seem to have anyone in charge of
testing overall, either.
<Florian> Just for the record, some of the specs in the test case
PR queue: css-page, css-ui, selectors, css-cascade,
css-flexbox, css-variables, css21, css-transforms,
css-shapes, css-fonts, css-masking, clip-path
<dbaron> Not sure the will-change ones need group discussion
rather than just an editor response.
Progress Report on Snap Points
==============================
Rossen: It's a status update we're looking for from MaRakow.
MaRakow: I'm working on merging in the snap point changes; I'm
adding area and align first and those are mostly merged
in. Once those are in and I update the definitions I
think it'll be a coherent set I can push up.
MaRakow: Right now it has references to other items that need to
be merged, but it should be a reasonable intermediate.
fantasai: While you work on this we should have resolutions on the
specific technical things that we're changing.
<fantasai> 1. Replacing scroll-snap-destination with
scroll-snap-padding
<fantasai> 2. Replacing scroll-snap-coordinate with
scroll-snap-align
<fantasai> and scroll-snap-area
<fantasai> 3. Adding axis keywords to scroll-snap-type
fantasai: These are the things you're working on. If there's no
reason to disagree and you're doing the editing, it
would be good to have a resolution from the WG on the
books since we didn't get there at TPAC.
MaRakow: For #1 and #2 that makes sense but there may be some
small changes. #3 we discussed if axis was going to be
its own property and that's still on the ML.
fantasai: Yes and we can have an issue on that. I would take that
ML discussion as a separate issue and have the
resolutions as the changes we're making.
MaRakow: Would it make sense to resolve the issue before the
resolution?
fantasai: I want to give implementors a clear direction where
we're going.
fantasai: So, we can make the resolution be have axis keywords on
a scroll container, TBD which property. That's what's up
in the air.
fantasai: I want to make sure the things we agreed on are recorded
as agreed on.
fantasai: So for #3 we would resolve "Add axis keywords to a
property applied to the scroll container."
MaRakow: Yeah. I think that makes sense.
fantasai: So we're in agreement. Does the rest of the WG want to
object?
Rossen: So you agree on points 1 and 2. Right now you also agree
on the axis keyword pending some open issues.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Nov/0328.html
fantasai: Open issue^
<fantasai> "Add axis keywords, pending shorthanding issue, per
[message above]"
Rossen: Okay, anyone object?
RESOLVED: Replace scroll-snap-destination with scroll-snap-padding
RESOLVED: Replace scroll-snap-coordinate with scroll-snap-align
and scroll-snap-area
RESOLVED: Add axis keywords to a property applied to the scroll
container with added issues
(https://lists.w3.org/Archives/Public/www-style/2015Nov/0328.html)
Rossen: Okay. We're looking forward to more edits and the spec
coming out soon.
fantasai: We are looking for comments on that issue.
Will Change
===========
Rossen: dbaron preference on will change topics?
Rossen: First one is establishing containing block for fixed
elements.
dbaron: It's okay to let the editor deal with these.
<Rossen> http://lists.w3.org/Archives/Public/www-style/2015Nov/0334.html
<Rossen> http://lists.w3.org/Archives/Public/www-style/2015Nov/0332.html
dbaron: They're both wording details. I don't think there's big
issues to discuss. As long as the editor agrees that what
was meant by the spec is what I think, we don't need
discussion.
Rossen: Okay.
Rossen: Sounds good.
Rossen: If this is something that can be taken care of by
TabAtkins let's leave it.
Rossen: We have 3 minutes. Any topics or do we end early?
Dealing with Pull Request Pile Ups in our Test Repo
===================================================
dbaron: One comment on the testing issue. I tend to think the
standard of review for tests shouldn't be as strict as
code. If a test is testing something that a dev later
concludes isn't what the spec calls for that gets caught
later in the process.
dbaron: Basically I think tests shouldn't need a huge amount of
review. They should be reviewed...at least for
contributers proven somewhat competent, they should jsut
be reviewed for is this testing the thing it says it's
testing. Rather that than set up a comprehensive process.
<astearns> tests have long-term continuous review by getting in
the test suite and getting run
fantasai: I think that is the key issue. As long as a test is
testing for what it says it should be accepted.
<fantasai> Review requirements:
<fantasai> 1. Does this pass when it should pass?
<fantasai> 2. Does this fail when it should fail?
<fantasai> 3. Does this test what it thinks its testing?
<fantasai> I don't think anything else is necessary, though more
detailed comments might be nice in some cases.
Florian: There's a higher risk for tests that pass when it
shouldn't, but given the lack of review we have that's a
lesser evil.
Rossen: These are all fair points. I wasn't suggesting a level of
rigor. If they're going through a short list and later let
them be rejected that's fine. Or we can do detailed
reviews and only accept tests that we think will pass.
It's a long topic, but something we should keep discussing
and come up with solutions.
Rossen: Especially while we have tests. We don't want to stop that.
Rossen: We're at the top of the hour. That's everyone and see you
next week.
Received on Thursday, 3 December 2015 10:32:42 UTC