- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 26 Apr 2018 23:13:27 -0700
- To: "www-style@w3.org" <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.
=========================================
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 06:13:57 UTC