W3C home > Mailing lists > Public > www-style@w3.org > April 2018

[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]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 26 Apr 2018 23:13:27 -0700
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <4566c0cc-eb94-4845-f2a0-dfe18f5a6a08@inkedblade.net>

   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.


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


   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


   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]



   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 06:13:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:10 UTC