Re: [CSSWG] Minutes Berlin F2F Tue 2018-04-10 Part II: Editorships, box-sizing, Writing Modes [css-writing-modes][css-page-floats][css-sizing][css2][css-overscroll]

Idk how the minutes got double-spaced, but here's a single-spaced version
for those who prefer it. :/

=========================================
   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.
=========================================

Page Floats
-----------

   - RESOLVED: add rachelandrew and florian as editors to page floats

CSS Sizing & CSS2.1
--------------------

   - RESOLVED: Add an issue and a fix for CSS2 to disambiguate
               inner vs outer width. (Issue #2458: Definition of
               box-sizing in css-sizing)
   - tantek was actioned to make the needed edits to CSS2

CSS Overscroll
--------------

   - There is already a resolution to move this spec into the csswg-drafts,
     but we'll keep waiting on the current WICG editors to join the CSSWG.

Writing Modes
-------------

   - RESOLVED: Transition L4 of writing mode to CR.
   - RESOLVED: Republish L3 writing modes CR.
   - RESOLVED: CR transition period for L3 is 4 weeks.

===== FULL MINUTES BELOW ======


Page Floats
===========

Editorship of css-page-floats
-----------------------------

   florian: Johannes is the only editor of page floats and he's not funded
            to do this work. He's uncomfortable both that it's not progressing
            and that his name on it and it's not progressing.
   florian: I think it's good to have multiple people on the hook.
            rachelandrew raised her hand and I'm interested.
   rachelandrew: I'm happy to take it on, it has relation to the work I'm doing
                 in multicol
   florian: I would propose to add rachelandrew and me in addition to Johannes
   Rossen: Is Johannes interested in remaining?
   florian: Yes.
   Rossen: Objections to adding rachelandrew and florian as editors to page floats
   RESOLVED: add rachelandrew and florian as editors to page floats

CSS Sizing & CSS 2.1
====================

Definition of box-sizing in css-sizing
--------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2458

   florian: Had resolution to move the definition to css sizing
   florian: There was a large re-write while it happened. I filed this to
            disagree with some of it.
   fantasai: We can add a normative reference to UI 3. Problem is CSS 2.1
             refers to width and height but doesn't say if it's inner.
             UI 3 has a diff written in English to figure out how it works.
             It's an awful bit of spec writing we shouldn't keep going forward.
   fantasai: Proposal is add a normative reference from CSS Sizing to UI 3.
             Also maybe fold the edits into 2.1 so it's not necessary to
             have this.
   florian: And this monkey patch once written is mostly obvious, but when
            unwritten it's not clear.
   tantek: and test cases revealed bugs in the definition as well that we
           had to fix in css-3-ui
   florian: Reference to the monkey patch sounds good.

   <gsnedders> inner width is the "content box width" and the outer width
               is the "border box width"?
   <fantasai> no, outer is margin-box
   <gsnedders> box-sizing: border-box refers to the border box and not the
               margin box though?
   <tantek> gsnedders, yes
   <gsnedders> then where do we use the margin box width?
   <fantasai> lots of calculations
   <fantasai> e.g. flexbox algo, float placement
   <gsnedders> then the current CSS Sizing definition seems confusing here
   <tantek> gsnedders agreed
   ACTION: fantasai fix this error in css-sizing

   florian: Other part I raised is that you defined normatively width to
            mean inner-width and we haven't checked all our specs.
   fantasai: In 2.1 any instance where it's ambig it's the inner width
   florian: Sometimes it means the value of the property.
   fantasai: In those cases it's the value minus borders and padding.
             That entire monkey patch basically says “width means inner width”.
             The fundamental concept of 2.1 width is it's inner width.
             There might be cases outside of CSS 2 where we were less careful,
             but those are bugs in the spec.
   florian: What I was thinking about is in practice, in practical speech
            they're unavoidable. I'd rather normatively define an anchor term
            that's non-ambig so if you run into width you don't have to wonder
            if they meant inner or forgot to be careful.
   tantek: Also dimensional width vs vs property width, computed, cascaded etc.
           It's not just inner vs outer, but also the width as a property in
           the cascade. There's multiple levels of ambiguity going on.
   florian: To solve that I'd like the inner to be an anchor term which you can
            link to with bikeshed.

   dbaron: Are there places where we say width and mean inline size?
   florian: That too. In enough cases it's ambiguous but obvious enough and in
            those cases we should fix.
   dbaron: I think the fact that there is a second thing we ought to audit for
           maybe we should not assume here.
   fantasai: For CSS Level 3+, I haven't looked at css-position, but the rest
             of our specs are careful to use “block size”.
   dbaron: But non-layout specs?
   fantasai: Any spec TabAtkins or I worked on is being careful. Anyone else
             editing might want to look.

   tantek: I think we're not focusing on the issue. I think we should resolve
           that CSS UI defines box-sizing. And then the plan moving forward is
           separate.
   fantasai: Box sizing moved to the sizing module. Florian opened the issue
             asking for the monkey patch to be copied over. I think it's better
             to normatively reference CSS UI from Sizing. Box sizing should
             have been in the sizing spec, but it didn't exist yet so it was
             in CSS UI.
   gsnedders: CSS UI 3 have a normative reference?
   tantek: No. It's fine in CSS3 UI and it's because form element behave that
           way. For external specs I'm not sure why we're talking double
           direction here.
   florian: Proposal is keep the box sizing definition out of UI 4 and move
            into Sizing with a reference to the monkey patch in sizing and
            refer to sizing where it has better defs. Mostly defined in sizing
            and refer to the monkey patch to CSS UI 3.

   florian: To be able to apply the monkey patch to 2.1...the other thing you
            dropped from UI to sizing is that I normatively defined width and
            the like.
   fantasai: Box sizing has the terms defined but in pieces. Inner is separate
             from min/max size; you can combine if needed. But the terms do
             exist in sizing. I didn't feel like duplicating your version.
   florian: I felt you underfined them.
   fantasai: Inner is defined in sizing. In CSS 2.1 the spec is written with
             the understanding that width means inner-width. If you want to
             read it with the context of box-sizing existing you need to know
             that. Monkey patch can be compressed to a sentence saying CSS2 is
             referring to inner-width/height throughout the spec. All your
             changes were about that.

   fantasai: I think we should resolve on updating 2.1 so that the potentially
             ambiguous references to width are corrected so we don't need this
             awkward patch.
   tantek: We need to open an issue on 2.1. This issue is multi spec.
   fantasai: That's fine.
   <gsnedders> I am strongly in favour of fixing 2.1 here.
   Rossen: Let's take resolution to 2.1
   florian: Can we normatively reference the monkey patch from sizing?
   fantasai: Yes
   Rossen: We need to update CSS 2.1 by normatively pointing UI 3?
   fantasai: No, 2.1 to be edited to clarify.
   tantek: That's why I'm suggesting a separate new issue.
   Rossen: What's the 2.1 fix?
   <fantasai> Apply https://www.w3.org/TR/css-ui-3/#box-sizing
   tantek: In florian's long comment on 2458.  Errata CSS 2.1 bullet point.
   florian: Trying to craft the wording isn't group. We should open the issue
            keep open until we fix 2.1
   Rossen: Prop: Add an issue and a fix for 2.1 to disambiguate width for
           inner and outer width.
   Rossen: Obj?
   RESOLVED: Add an issue and a fix for 2.1 to disambiguate width for inner
             and outer width.

<br type="15min">
   <gsnedders> FYI: I want to have some discussion about future editing
               of 2.1 at some point during the week, probably as some
               breakout at some point.
   <tantek> gsnedders: count me in :)
   Rossen: Let's get going
</br>

   Rossen: We need to action someone to do the updates of 2.1
   Rossen: We still have one 2.1 editor in the room. So we can action him
           to make the errata edits.
   florian: I think we should be setting up the build system.
   fantasai: gsnedders should be working on it
   Action tantek to make updates to CSS 2.1 Errata
     * tantek thanks Rossen 😝
   <trackbot> Created ACTION-871 - Make updates to css 2.1 errata

   <tantek> In practice we have 3 2.1 editors in the room, since fantasai
            has been editing 2.1 for many years in practice, and gsnedders
            volunteered to edit 2.1 also
   <gsnedders> And we have a resolution adding me as an editor from last year.

[planning for dinner]

Overscroll
==========

   Topic: Move overscroll-behavior spec from WICG to csswg-drafts
   github: https://github.com/w3c/csswg-drafts/issues/2179
   astearns: We resolved to do that. And we're still waiting on Facebook
             to join. majidvp added a comment saying it'll be okay,
             please do this thing. Hopefully they'll find time to continue
             the spec.
   astearns: You're not interested in co-editing majidvp ?
   majidvp: I mentioned in the discussion I'm happy to be the fallback,
            but I prefer the original editor.
   astearns: Hopefully soon we can get Facebook in and you two can continue.
   Rossen: majidvp thank you.
   Rossen: Do we have a timeline on when this will come from WICG?
   astearns: TBD because we need an editor.
   Rossen: If we added majidvp today can we move the spec?
   astearns: It's overcommitting majidvp I think.
   majidvp: The right thing is give the current editor some more time.
   astearns: We'll wait on a response.

Writing Modes
=============

   fantasai: Status is that there are some tests failing. Some we can explain
             as implementation bugs. Main issue is that the automatic sizing
             of orthogonal flows, we didn't have interop to begin and then we
             added rules for scroll containers. There's no implementation of
             what's in the spec. However, it's not a difficult fix.
   fantasai: Status is we should have an implementation report soon to show,
             but we also need a couple of bug fixes.
   fantasai: I was going to finish impl report, but got sick so it hasn't
             happened yet. :(
   Rossen: Is the implementation report something you need help with?
   fantasai: I just need a day. koji and I spent time going over test results.
             It's just taking them and putting them in a document that explains
             what they mean.
   fantasai: We need bug fixes and updated CR.

   fantasai: We should also CR writing modes L4. It's the same spec, just
             adds back everything we cut from L3.
   florian: sideways, sideways-lr
   astearns: Is there FPWD?
   fantasai: Yes.
   dbaron: All maintenance to level 3 also in level 4?
   fantasai: All edits have been duplicated.

   fantasai: So, update CR for L3 and transition to CR for L4 and we'll need 2
             impl of the sizing stuff in the spec.

   koji: We also need to make an exception for the PR. fantasai can do the
         change in 2 weeks for Gecko. I don't have a timeline for Blink so
         may not get second impl in time. I don't think it's worth to wait.
   florian: We need to convince W3M that we should ignore these things.
            Fixing is easier than explaining away if it's reasonably easy.
   koji: Our impl... I'm doing other positioning.

   dbaron: Is there stuff going to CR in L4 that hasn't been to CR before?
   fantasai: Nope, it's just a straight copy of what's been there before.
   Rossen: Let's get a resolution to republish Writing Modes L4
   fantasai: L4 transition to CR, L3 update CR
   Rossen: Obj to transition L4 to CR
   RESOLVED: Transition L4 of writing mode to CR
   RESOLVED: Republish L3 writing modes CR

   florian: Do we have to set a minimum time before it can PR?
   Rossen: 4 weeks is okay.
   RESOLVED: CR transition period for L3 is 4 weeks

   Rossen: Anything else on writing modes?
   fantasai: Not at this point

Received on Friday, 27 April 2018 21:28:58 UTC