W3C home > Mailing lists > Public > www-style@w3.org > July 2019

[CSSWG] Minutes Toronto F2F 2019-06-04 Part II: Upcoming F2F, Publish Early Publish Often, Tables 3 [css-tables-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 6 Jul 2019 16:55:28 -0400
Message-ID: <CADhPm3uVD+Lc0p+V6Xo6npCqtpbVBZQONuHysO76FhHoJS0LXQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Saturday, 6 July 2019 20:56:22 UTC