- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 6 Jul 2019 16:55:28 -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.
=========================================
Upcoming F2F
------------
- RESOLVED: Jan 22-24 for A Coruña meeting, pending final approval
from Igalia.
- Apple has offered to host the Spring 2020 meeting
Publish Early, Publish Often
----------------------------
- RESOLVED: Allow editors to publish at-will, under the discussed
caveats. (Caveats: This can only be done when the only
changes are non-normative/editorial and
non-controversial OR the group already approved the
exact wording. This only applies to WDs, not anything
higher in the REC track. When this occurs the author
must include it in the changes section with a link to
the diff and send an email to www-style about the
publication.)
Tables 3
--------
- RESOLVED: Publish new WD of Tables 3 with the reviewed changes.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/toronto-2019
Scribe: TabAtkins
Upcoming F2F
============
astearns: The January meeting is set for Spain, as I understand?
dbaron: Dates?
<bkardell> here's a thing with the venue
https://webengineshackfest.org/2019/#venue
Rossen: So Igalia hosting, location is A Coruña
dbaron: There's a mozilla all-hands the following week, if we use
the Jan 20-24 dates
dbaron: But Mozilla people thus can't do the following week. Either
week before or after.
jensimmons: Yes plz don't leave an empty week before Moz Berlin
all-hands and this meeting...
TabAtkins: Probably no Houdini, we'll have talked at TPAC.
AmeliaBR: So W-F leading into Mozilla the next week seems best?
Rossen: So tentatively 22-24.
RESOLVED: Jan 22-24 for a Coruña meeting, pending final approval
from Igalia.
bkardell: Igalia confirms that 22-24 works.
[Spring meeting will be at Apple, tess and myles will confirm room
availability]
<chris> TPAC 2020 Tentative dates 26-30 October 2020
dbaron: How many meetings this next year? 13ish months between
TPACs, tentative wiki plans are for 3 meetings now.
[discussion about France in August]
[definitely not doing Tokyo during olympics]
<rachelandrew> the spring meeting - do we have rough dates? I have
conference organizers to get back to
<TabAtkins> Rachel, we're waiting on availability dates from apple
people
hober: We might be able to do two next year, haven't hosted in
forever. We'll see.
florian: Maybe do Spring in Japan, then somewhere else in August.
una: Could probably do NYC Google.
astearns: I could host in 2021 in Noida, India
astearns: In Spring, the best time to go there
<tantek> created https://www.w3.org/wiki/TPAC/2020
<br type=lunch dur=1hr>
Publish Early, Publish Often
============================
fantasai: We're now on Echidna, so we can publish in about 5min
normally.
fantasai: One of the goals of that was to publish more frequently
fantasai: I think when we have significant changes we should check
with the WG to make sure everyone's on board,
fantasai: But there are a lot of things where I think the editor
should just be able to publish. Particularly editorial
changes.
fantasai: So I propose we allow the editor to just push that to TR.
fantasai: Or other obvious bugfixes.
florian: Probably also if we've resolved to accept specific wording
fantasai: Yes
fantasai: But if there's a change that should be reviewed by
somebody, like we resolved on a decision but not specific
wording, and it's non-trivial, that should probably also
still go thru the WG.
fantasai: But for editorial changes, trivial bugfixes, and
resolutions with acceptance of specific edits, we should
let people push
chris: Up to editor's discretion?
fantasai: Editor is fine for me. Could push thru chairs, just not
waiting for the WG call.
<fantasai> has to be very very trivial, though!
AmeliaBR: Is there an intermediate state, where you ping people
first?
astearns: I think if you're concerned, this isn't one of those cases.
astearns: I'd like a ping when things are published.
TabAtkins: Echidna can CC an address or ML when publication is
successful
TabAtkins: Echidna now has a cc feature, pass
`-cc=email@example.org` to the bikeshed command to ping
it when publication is successful
tantek: Strongly supportive.
tantek: The more we can desync publishing and make it rapid is a
good thing.
tantek: Only request is that if you publish what you think are
editorial changes, you still include changes about that,
preferably with a link to a diff.
TabAtkins: W3C has a nice htmldiff tool useful for this, too
chris: This is for WD, requirements for updating other things stay
the same
dbaron: One possible concern, sometimes we get into big arguments
where the result of "we can't agree on anything" is
"therefore we make no change"
dbaron: I don't want this to have too much implication for that, in
that "therefore we make no change" should stay "therefore we
stick with the previous resolution".
florian: Agree, but think that's a chairing issue.
florian: If there's disagreement, chairs can decide that we should
stick with a particular wording.
TabAtkins: That seems to fall under the intended rule of "don't make
non-trivial changes under this process"
florian: Other types of changes allowed here is adding examples and
inline issues.
fantasai: Those are editorial
florian: Technically not true under W3C process, but let's stick
with the definition of "non-normative, non-controversial"
as the dividing line
fantasai: yes
astearns: Do you think you should still have one person review? I've
made "editorial" edits that still cause problems.
???: It's fine, people can review after the fact and then just push
the fix.
AmeliaBR: Yeah, and the faster update cycle can fix issues we've had
in the past with markup errors sticking around for a long
while.
tantek: Adding non-trivial informative changes, like adding
examples, could probably *use* some review, but we shouldn't
require it in the process.
fantasai: As my goal I just wanna close the distance between ED and
TR, so TR becomes more of a useful resource.
astearns: I want to avoid having this quick process meaning you hold
off on normative changes because you want to publish the
editorial.
fantasai: I don't think that'll generally happen.
tantek: In the interest of not blocking on that, do we already have
a custom of letting people be first in the telcon agenda if
you have a pending publication?
astearns: Yeah, nearly always
astearns: So proposal is to allow editors to publish to TR at will,
when the only changes are non-normative/editorial and
non-controversial.
[discussion over difference between "uncontroversial" and
"non-controversial", concluded that when there's a difference it
should be considered controversial]
fantasai: And must include in the Changes section that the only
changes are non-normative, with a link to the diff.
astearns: And ping www-style with the publication.
astearns: Anyone object?
fantasai: Also allowed: substantive changes when the WG has already
approved the exact wording
RESOLVED: WDs with only editorial changes, non-normative
non-controversial changes, and/or substantive changes
with exact wording approved by the WG may be published by
the editor straight to /TR without explicit WG approval,
providing that a diff of changes is linked and www-style
is pinged.
<tantek> editorial vs. substantial vs. normative are all different
things, please don't try to collapse any two
<fantasai> tantek,
https://www.w3.org/2019/Process-20190301/#correction-classes
<tantek> fantasai: I agree with those distinctions, glad to see that
there are *four* made explicit
<fantasai> tantek, yeah, the resolution above was only wrt to #1/#2
-- unless exact text for #3/#4 was WG-approved already
<tantek> fantasai thank you - that's in alignment with my
expectations.
Tables 3
========
Republish Tables 3
------------------
fremy: This is mostly editorial, but I still want to run thru the
group.
<fremy> https://github.com/w3c/csswg-drafts/commit/942a46a1db056174fbb11cdf94bf2de3b14fc0e3#diff-6e3717cf0173351cda3264b270e9586a
fremy: Gonna explain the changes.
<fremy> https://github.com/w3c/csswg-drafts/commit/714ac7625b1b25ccacb183a17a77bb41144d0899#diff-6e3717cf0173351cda3264b270e9586a
<fremy> https://github.com/w3c/csswg-drafts/commit/8dbce74efa894eb8c7183440bd312316cb1ce449#diff-6e3717cf0173351cda3264b270e9586a
fremy: Second, skipping ahead, question was around % for height of
table cells
fremy: Mostly this change just moves text around.
fremy: Previous section was called "computing the table height", but
it had details about resolving %s and other stuff
fremy: Hard to find that text, not in a good spot.
fremy: So I just lifted it to a new section so it's more clear.
fremy: Just wanted to bring it up if someone wants to review and
make sure I didn't change anything.
Rossen: Line 1896, that's a normative change...
fremy: Ah no, that's already implicit in the rest of the spec.
Rossen: But it's not just moving around.
fremy: Yeah, it's a clarification.
Rossen: My point is that here you're defining an algo that says
something has no effect. That's not just an editorial change.
fremy: It's editorial in the sense that it's already normative in
the spec elsewhere. This shouldn't be a behavior change, I'm
just summarizing the effect of other stuff in the spec.
florian: New text, but no new requirements.
astearns: It's often good in those situations to just link to the
section saying that, rather than duplicating.
AmeliaBR: These are literally consecutive paragraphs, in one
subsection
fremy: First link, actually adds something.
fremy: In spec there was a section defining positioning of
everything inside the table
fremy: Described for each of them the left/top/width/height.
fremy: I assumed it was obvious this was the bounding box, but that
wasn't obvious in the spec.
fremy: So I've officially defined that this is the dimensions of the
box, returned get gBCR().
florian: What's the alternative interpretation of this?
fremy: Like, the text was only necessarily about visual stuff. Not
clear that it affected the .offsetLeft, etc.
fremy: Also clarified what border-spacing means with spanning cells,
etc. Obvious in formula, but made it clear in prose.
dbaron: In the first bit, I'm a little nervous about "which means
they are accessible via..." because of table vs table
wrapper box, because only one of those is accessible to the
OM
fremy: Which is used for those APIs is already specified.
dbaron: Yes, but then your statement of fact there is slightly wrong.
dbaron: You give bounding rects for both table and table wrapper,
but only of those is accessible via the OM, so the statement
that the definition "makes them accessible" is technically
wrong.
dbaron: Perhaps add a parenthetical about the boxes that aren't
OM-accessible.
fremy: Sure
fremy: And the third diff is Elika's editorial changes to the
propdef tables, to be consistent with the rest of the CSS
specs.
astearns: I'm hearing no objections to publication
RESOLVED: Publish new WD of Tables 3 with the reviewed changes.
Received on Saturday, 6 July 2019 20:56:21 UTC