- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 26 Apr 2018 23:23:01 -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.
=========================================
Sizing
------
- RESOLVED: Treat indefinite percentages in min-width and min-height as 0.
(Issue #2384)
- RESOLVED: Add a note to the spec explaining this problem (adding a 'size'
shorthand for 'width'/'height') and move this issue to level 4.
(Issue #820)
- RESOLVED: Publish a new WD of Sizing with all current resolutions edited in.
Flexbox
-------
- RESOLVED: Tables defines used min-size to fold in its min-content size
where necessary (for 'table-layout: auto'); Flexbox ensures
it is hooked up to this terminology when looking up an item’s
minimum size.
- RESOLVED: Have an initial ED of Flexbox L2, defining combination w/
additional alignment values and gap properties.
Overflow
--------
- RESOLVED: Allow 2 values on the overflow property in physical x/y order
for any existing values.
- RESOLVED: add block and inline longhands to overscroll-behavior
- RESOLVED: text-overflow and resize apply to elements with
'overflow: clip' just as they apply to elements with
'overflow: hidden'
- RESOLVED: when 'overflow: clip' is propagated to the viewport it
changes to 'overflow: hidden' the same way 'visible' is
changed to 'auto'
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule
Scribe: dael
Sizing
======
Does indefinite min-height: N% fall back to zero or auto?
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2384
TabAtkins: This is for min-width and height. Do they fallback to auto or 0?
General rule is we fall back to initial value. Is that 0 or auto?
Initial used to be 0, changed to auto.
TabAtkins: 2.1 explicitly says they're treated as 0, but it was probably on
the assumption that 0 was the initial value.
TabAtkins: Only real case is you have a flex item and you can't resolve the
min-height should it be auto or 0?
TabAtkins: I'm of the opinion it should be auto.
Rossen: Current?
TabAtkins: 0 which was previous initial value.
TabAtkins: Change to be consistent with the change to initial.
fantasai: I'm trying to wrap my head around when this would be different.
astearns: Last time we discussed 0% when we said it should be 0 it's different
on width then min-width.
fantasai: auto for width isn't the same as min-width.
astearns: We could throw out the calc on min-width if it's doesn't resolve.
TabAtkins: Either the percent zeroes out or we throw it out.
fantasai: Makes more sense.
tantek: Treat min-width and min-height the same as we just resolved to deal
with percentages.
astearns: So it's zero rather then auto.
TabAtkins: Still a change from current. calc is replaced with 0.
Current is calc(10%+10px)=0. Now it's =10px.
fantasai: This makes the most sense. Consistent with margins and padding.
fantasai: If you set min-width to a non-auto size you're not expecting it
to look at content.
astearns: Proposal: treat indefinite % in min-width and min-height as 0
RESOLVED: Treat indefinite percentages in min-width and min-height as 0.
Rossen: This is web compat?
TabAtkins: If you have a complex calc it's a change. Percent-only is the same.
Adding a 'size' shorthand for 'width'/'height'
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/820
fantasai: Shorthands are nice. We have them for many things, but not combo
of width and height.
fantasai: We hadn't added that because there's a size property0like thing
that the @page has that does not behave anything like this
shorthand would. That sets the size of the writing box.
fantasai: Options are do something weird where size works differently for
@page. Other option is some other word than 'size'.
"box-size" is the current issue in the suggestion.
fantasai: It would be the shorthand for block-size and inline-size.
min-box-size/max-box-size would be for the min/max props.
florian: Naming conflict is that bad?
fantasai: It's a descriptor technically, but operating on a box that accepts
other properties that apply to boxes. It'll be weird forever.
TabAtkins: Weird because page takes width and height and size should be a
property there. Conflict itself is weird but especially in the
exact case.
TabAtkins: box-sizing is too close to box-size
dbaron: box-size and block-size might be confused by some.
<tantek> indeed
Rossen: What is the motivation here?
TabAtkins: People want to set width and height together.
florian: When people want to say something different they repeat themselves.
fantasai: It's likely you'll want both to a keyword like auto or 100% or
contain.
TabAtkins: Equal sizing is reasonable.
Rossen: The short shorthand is always going to give you squares.
florian: If you do percent it will not.
TabAtkins: Unless box-size 50% is same for height and width.
fantasai: If we didn't have a naming conflict this would be in the spec
already.
florian: I'd ignore the naming conflict and say you can't use it in
@page rule
astearns: I don't like that because if you don't know anything about
@page it's surprising.
astearns: Here I've found I have to use it and the styles I set up
perfectly are no longer good.
florian: It's the code you wrote to size the page, that would be weird.
<fantasai> @page { size: 8.5in 11in; }
<fantasai> @page { size: letter; }
rune: Page doesn't match any elements?
florian: No.
astearns: I'm thinking copying from another container.
emilio: I think having a special-case for @page rule for page rule isn't
worth it.
astearns: First comment TabAtkins said is people have been asking for this
and it would be mildly useful. I'm not sure mildy is worth it.
fantasai: I've had people bug me for this. Those people are not sitting here.
astearns: I'm not hearing consensus on using size or another name. I'm not
hearing huge enthusiasm for solving this.
astearns: Might be worth a note in the spec saying we've considered a
shorthand and have not found enough motivation for dealing with
the problems and outline what the problems are.
astearns: Objections?
RESOLVED: Add a note to the spec explaining this problem and move this issue
to level 4.
Publication
-----------
florian: Do we need a new WD?
fantasai: Sure.
astearns: Objections to a new WD of Sizing with all current resolutions
edited in?
<tantek> +1
RESOLVED: Publish a new WD of Sizing with all current resolutions edited in.
Flexbox
=======
Min-content of shrinkable flex items
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2353
TabAtkins: We made some edits and we need to WG to approve.
Rossen: Can you go over the edits?
<fantasai> https://drafts.csswg.org/css-flexbox-1/#change-2017-flex-min-contribution
TabAtkins: Last comment in the issue has a link to the change.
fremy: I need to process it.
astearns: Anyone else want a summary?
Rossen: Let's get back tomorrow. I want to look as well b/c I spent time
working on this issue. We had a change fixing some edge
inconsistencies with this problem. We had to back it out because
it seemed others were inconsistant.
fantasai: We went with dholbert's solution over fremy's.
astearns: There's a 2nd layout section Thursday morning. Let's add this then
Table flex items with main size less than preferred intrinsic width
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2442
TabAtkins: If you have a table that's flex item, the flex sizing algo
tells it what size to be--but that's can be smaller then
the table's min size. What happens? Edge and FF only use
table sizing algo. Chrome flexes the table, but I'm not
sure if it flexes beyond the minimum size.
TabAtkins: fremy says table should flex and overflow to it's min size.
I agree.
astearns: Anyone disagree that tables flexed to smaller than their
minimum size should overflow?
fantasai: It should function a min-size constraint.
TabAtkins: Does that happen?
fantasai: We shouldn't be like the flex item is smaller then it actually is.
If the table has a minimum size it should be reflected in the
handling of minimum sizes in the algo.
TabAtkins: If it has a specified size, content of 200px but width of 10px.
It'll be 200px but we don't go down a path to look at the
contents.
fantasai: The table has a minimum size that's not reflected in min-size
property's value. Max of specified min-size and min size from
table layout should be the used minimum size.
TabAtkins: Yes, that makes sense.
dbaron: And only for auto layout tables?
fantasai: Yes.
Rossen: If width is specified it's still a min-width
cbiesinger: Flex considers an explicit width as a min-width?
TabAtkins: At all times tables cannot shrink below their min-content size.
cbiesinger: Can you put that in the spec somewhere?
TabAtkins: Sure.
TabAtkins: Between flexbox and table spec we'll put this somewhere.
fantasai: Used min-width of a table should consider the content of the table
and then we make sure flexbox hooks into that correctly.
astearns: We only want flex algo to key off used min-width for tables.
fantasai: No reason for it not to in general. We just need to make sure
correct terms are in flexbox and that tables has that concept.
astearns: Used min-width isn't a term?
fantasai: It is, but we need to make sure tables spec uses it.
astearns: Used means layout has happened.
TabAtkins: This is a flex item.
rune: You need min-width before you layout flex item.
TabAtkins: Sure. Tables need to do layout earlier.
fantasai: Just calc min-content width.
astearns: Prop: define what used min width is for tables to include the
min-content constraint and make sure the flex algo uses that.
astearns: That's the approach we're taking. Let's have you all come up
with proposed edits.
cbiesinger: Anything else have the used min-width?
fantasai: No. Nothing else has a used min-width that depends on random
other information.
astearns: Anything more on this?
RESOLVED: Tables defines used min-size to fold in its min-content size
where necessary (for 'table-layout: auto'); Flexbox ensures
it is hooked up to this terminology when looking up an item’s
minimum size.
Flexbox Level 2
===============
fantasai: TabAtkins and I suggested we draft L2 where it's flexbox 1 +
the current set of alignment properties with all their values.
Flexbox 1 only has a subset of alignment.
fantasai: It's L1 + aligning keywords + gap properties so people can
talk about it as a thing.
TabAtkins: Technically you can read alignment and sizing and figure it
out but this would be convenient.
fantasai: We'd have to dup some parts of the algo to define gaps properly,
but most we can say refer to current Flexbox. We're getting very
stable so end of the year I think we can fold in the entire text.
astearns: Flexbox level 2 would mostly be a diff spec?
TabAtkins: It shouldn't be a diff spec ultimately, just Flexbox 1 with
some extra stuff.
fantasai: Basically normative references into flexbox and alignment and
some normative text on how it combines with maybe some quotes
from the algo. Then in the future we'll fold in all the text.
astearns: Sounds like it would be best as an ED
TabAtkins: Yeah
fantasai: Yeah. Once alignment goes to CR we should have a WD.
TabAtkins: Sure
astearns: Objections to an initial ED of Flexbox L2?
RESOLVED: have an initial ED of Flexbox L2
[TTML discussion goes here; extracted out for cross-posting]
Overflow
========
overflow: clip
--------------
github: https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-377078084
florian: Missed the telecon where we discussed. We recently resolved
overflow:clip does not trigger BFC. I think it failed to
considered some of the things that implies.
florian: The motivation that triggered adding to spec was usage in
combo with contain: paint so you can have contain: paint
with text-overflow or resize property. These only apply to
overflow not visible elements.
florian: We don't want to have contain:paint trigger overflow:hidden
because UA might use too many resources.
florian: If overflow:clip does not create a BFC, are implemenations
comfortable saying resize and text-overflow apply to elements
that are overflow:clip?
TabAtkins: During discussion before we couldn't come up with a reason
you'd want overflow without scrolling, this is the reason.
There are properties that depend on things being non-visible.
florian: Resize.
fantasai: I think it doesn't matter for resize.
<fantasai> and I think that 'text-overflow' should never have keyed off
of 'overflow'
florian: I'm not saying should not apply. but if we're going with “it's
not a BFC” we also have a bunch of properties that should
change to “not visible or clip”.
dbaron: There were use cases for the opposite.
TabAtkins: This is the use case for this situation. We only came up with
use cases for the other resolution. Something that acts like
overflow:visible but it's clipped.
florian: Not affecting margin collapsing.
TabAtkins: Or sticky or scroll-snap.
TabAtkins: This is a reason for the opposite where it's like hidden but
doesn't scroll.
dbaron: They can't apply for text-overflow partly because this is a
purely paint time effect.
florian: This is also a purely paint time.
fantasai: True.
dbaron: I guess those two could maybe be changed to not include the
visible. Nothing is like this because we've put “overflow
does not equal visible” across all our specs where that's
not what we mean.
fantasai: I think a lot that key off “overflow not visible” key off
if it's a BFC.
fantasai: I think a lot of things are keying off that. There's many
effects that key off of that and we don't have to change
those specs. There may be some that don't, though.
florian: That we need to rename was mentioned. If we clarify that
it doesn't apply to text-overflow and resize that solve
my first concern.
florian: Are we okay closing that sub topic?
astearns: Additional concerns?
florian: Assuming we don't find another problem we can clarify the
previous resolution to mean text-overflow and resize refer
to non-visible elements.
fantasai: To rephrase Florian without negatives, text-overflow and
resize apply to elements with 'overflow: clip' just as
they apply to elements with 'overflow: hidden'
florian: The second concern was about what overflow:clip means when
applied to the document or body element and propagated to
the viewport
fantasai: Same way we translate visible to auto, we translate clip
to auto.
florian: That's good.
astearns: Resolve on both?
astearns: Prop: text-overflow and resize apply to elements with
'overflow: clip' just as they apply to elements with
'overflow: hidden'
RESOLVED: text-overflow and resize apply to elements with
'overflow: clip' just as they apply to elements with
'overflow: hidden'
astearns: Prop 2: when overflow:clip is propagated to the viewport
it changes to overflow:hidden he same way visible is
changed to auto
RESOLVED: when overflow:clip is propagated to the viewport it
changes to overflow:hidden the same way visible is
changed to auto
astearns: You're fine with the resolution?
florian: Yes. I'm mildly skeptical, but not objecting.
logical longhands for overscroll-behavior
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2473
majidvp: There's a resolution to add overscroll inline and block
which is reasonable.
florian: We don't have a resolution on this. We have it on similar.
astearns: Overflow vs Overscroll. Oooh.
astearns: Objections to adding block and inline longhands to
overscroll-behavior?
RESOLVED: add block and inline longhands to overscroll-behavior
Let 'overflow' accept two values
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2484
Oriol: It only lets you set overflow-x and overflow-y. It would be
more convenient if it accepted two values. Then there was
the question is the order should be physical or logical.
As an example background-position is x and y. It will
prserve physical order. There's another issue looking to
switch longhand and shorthand into physical order.
florian: Other is issue #1282 which discussed adding logical
keyword to all places currently phsycial.
astearns: Separate from that switch, do we let overflow accept 2 values?
astearns: Concern about changing this?
astearns: Weird mistyped declarations may now have an effect?
florian: I suggest we presume that's rare and if it's a problem we raise it
florian: A more consistant system where they all have shorthands and
they're physical.
astearns: Prop: Allow overflow to have two value and for the ordering
to be physical.
iank: Which order?
emilio: x and y.
dbaron: Question: There are sets of values transformed into other values.
If x is visible and y is scroll we make scroll into auto.
Should those combos be syntatically valid for shorthand?
myles: Related that this shorthand shouldn't allow new functionality
dbaron: Transformation would still happen. I'm thinking a it would be
nice if it rejected but it's not possible because serialization
problem. Because then values could not serialize to shorthand.
emilio: Happens in a lot of places.
dbaron: I guess it's not really a serialization problem. Do we want the
things that are not going to be valid in the end be parse errors?
emilio: I think it would be weird if spec shorthand would yield different
results.
myles: You set the shorthand and it's rejected and that's different that
if you set the 2 longhands.
florian: You have a minifier and it takes the 2 longs and puts them to
short and that's a parse error.
astearns: I would prefer let you set the shorthand to whatever and
letting it transform.
florian: I don't think we gain by forbidding these.
fantasai: If you serialize out computed values it's always valid anyway.
florian: What do we gain by forbidding?
dbaron: Reject things that don't makes sense.
florian: Makes sense when you transform.
dbaron: CSS tries to reject things that don't make sense.
fantasai: Would be nice if a validation tool flagged this as a warning,
regardless.
astearns: Computed value shows something changed.
fantasai: That always happens.
emilio: [missed]
fantasai: Tranforming em to pixel doesn't show you've got a problem in
your style sheet.
astearns: I'm not certain having a transform apply implies there's a
problem in your stylesheet.
fantasai: rachelandrew?
rachelandrew: I don't have an opinion.
florian: Stylesheet maintenance it's strange.
myles: Have we never encountered this?
fantasai: Almost for display but we made all meaningless combos invalid
and got rid of the longhands.
emilio: Outline style stuff which when you have hidden outline and the
line-width becomes 0.
astearns: Anyone have a concern with allowing whatever combo we specify?
Anyone object to taking what we get and transform?
astearns: Prop: Allow 2 values on the overflow property in physical x/y
order in any existing values.
myles: What a combo authors want with different keywords?
astearns: hidden x auto in y.
myles: So only one scroller.
astearns: People use overflow x and y in various situations and it's just
that it would be nice to let them use the shorthand for both.
rune: If you have visible overflow in x and y you get visible.
florian: Transformed to auto.
myles: Hidden and auto are okay.
astearns: Objections?
RESOLVED: Allow 2 values on the overflow property in physical x/y order
for any existing values.
astearns: we're done for the day.
<RRSAgent> https://www.w3.org/2018/04/10-css-minutes.html
Received on Friday, 27 April 2018 06:23:32 UTC