- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 29 Oct 2020 19:38:54 -0400
- 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.
=========================================
CSS Sizing
----------
- RESOLVED: Adopt a property to solve the requested property and
values from issue 4585 (Use cases for explicit
intrinsic-size)
- RESOLVED: Accept edits made (Issue #3973: Why was min-content,
etc. redefined to do nothing in the block axis)
- RESOLVED: Accept proposed edits to cyclic percentages in
https://github.com/w3c/csswg-drafts/issues/3010#issuecomment-672335319
- RESOLVED: Rename term "intrinsic size" of image with "natural
size" (Issue #4961: Distinguish intrinsic size's two
definitions with two terms)
- RESOLVED: Republish WD of css-sizing-3 (and start CR process after
that)
CSSOM View
----------
- RESOLVED: Add emilio as editor of cssom-view
Logical Properties & CSSOM
--------------------------
- RESOLVED: During serialization, each logical property group is
considered, and shorthand values can be emitted instead
of the longhands only if the all the longhands of the
same mapping logic are present and consecutive (ignoring
all properties that are not in the group). Otherwise,
the shorthand is not used when serializing the
properties in the group. (Issue #3030: Interaction of
shorthands and logical properties)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2020#agenda-schedule
CSS Sizing
==========
Scribe: Tantek
Use cases for explicit intrinsic-size
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4585
<fantasai> https://github.com/w3c/csswg-drafts/issues/4585#issuecomment-701595999
fantasai: We created this issue to collect use-cases for control
over over intrinsic sizes of boxes
fantasai: We have 3 maybe 4 behaviors collected now.
fantasai: One is Web-compat behavior,
fantasai: another is zeroing out the min-content contribution of
scroll containers,
fantasai: another one is zeroing out the min-content contribution
when there is a percentage size or max size in that axis
fantasai: Someone wanted to have a box that had the same behavior as
a replaced element
fantasai: They were able to replicate a lot with our aspect ratio
stuff
fantasai: but this is a quirk of how replaced elements behave that's
unrelated to aspect ratios
fantasai: Question to the working group, do we want to design a
property to switch between these different values?
fantasai: Second question to working group, are there are other
cases we should add to this?
Rossen: Opinions?
(awkward silence)
Rossen: Do we care enough about this? Or we can also move on if
there is not enough interest here
Rossen: There was interest here. In terms of behavior what do we
want?
Rossen: dbaron also dumped a bunch of mozilla bugs that were a good
indicator that we need to look into solving this
Rossen: I don't see anyone on the queue or engaging
Rossen: Shall we close the issue with no change?
cbiesinger: I would really like to have this property
cbiesinger: The second part was requested by me because I know some
people who want to use this on their websites
cbiesinger: to set the min-content to zero to act like replaced
elements
cbiesinger: Seems like useful behavior to get the regular size
normally but when you shrink the window you can shrink
the element with it
cbiesinger: That's my case for it
fantasai: Proposed resolution: define a property to switch between
these behaviors and hope someone comes up with sensible
keywords
Rossen: better than the ones currently in the issue
jensimmons: I also think this is a really good idea
jensimmons: I can see... it's sort of an advanced feature ...
authors need to wrap their heads around sizing period.
it requires understanding how layout works first.
jensimmons: To me the big use-case is you have multiple grid items
in a grid track, and the track itself is going to be
based on something in the track, and you can say don't
base it on the headline, base it on something else
jensimmons: you set its intrinsic size to 0 or 100px
jensimmons: That could be very powerful
jensimmons: The columns will be the size of the content in it,
except not this content or this content
Rossen: Thank you. Other opinions or objections to adopting such a
property. Name and value names tbd
Rossen: I see some nodding of heads
Rossen: no objections
RESOLVED: Adopt a property to solve the requested property and
values from issue 4585
Why was min-content, etc. redefined to do nothing in the block axis
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3973
Rossen: cbiesinger you opened this one
Rossen: and you also added it to agenda+
cbiesinger: I did?
Rossen: On Jan 22
cbiesinger: Oh that was a while ago lol
cbiesinger: Why are we discussing today, wasn't it addressed by a
recent edit?
TabAtkins: Yes it was
TabAtkins: making sure others are ok with the edit
cbiesinger: I can summarize
cbiesinger: In the block axis the ..[missed].. and fit-content take
the same value as auto
Rossen: Sounds reasonable
cbiesinger: It lets you get the min height auto behavior from
flexbox and grid
cbiesinger: and ... ratio in other contexts
<fantasai> at one point the spec defined min-content/max-content/
fit-content to behave the same as 'auto' in the block axis
<fantasai> the edits changed that to say that the min-content and
max-content sizes in the block axis are as defined by the
layout model, defaulting to max-content behavior
<fantasai> more or less
Rossen: Any other opinions?
Rossen: Or objections to accepting the edits?
RESOLVED: accept edits made
Cyclic percentage concept should not exist
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3010
fantasai: This was less of a change in behavior, and more of a
change in how it was explained
fantasai: Determining whether a percent is cyclic is itself a bit
confusing
fantasai: but not all percents are cyclic
<fantasai> https://github.com/w3c/csswg-drafts/issues/3010#issuecomment-672335319
fantasai: We tried to draft a clarification ^
fantasai: We wanted to know if that would make the spec acceptable
fantasai: We're trying to get this spec to CR soonish
Rossen: Ok
Rossen: Special resolution is defined after this paragraph?
Rossen: This clarification is pretty good actually
Rossen: Any other opinions or feedback?
(silence)
dbaron: The new text looks good to me
fantasai: Yay!
Rossen: Hearing no objections
RESOLVED: Accept proposed edits in
https://github.com/w3c/csswg-drafts/issues/3010#issuecomment-672335319
Distinguish intrinsic size's two definitions with two terms
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4961
fantasai: We've been using intrinsic size to refer to two different
concepts
fantasai: One is the size of a replacement element
fantasai: The other concept is referring to the min-content and
max-content sizes, which always exists for any box, they
are determined in some manner
fantasai: We need two different terms for this
fantasai: The HTML spec uses the term natural width and natural
height
fantasai: We were thinking to replace the use of intrinsic size as
it applies to the inherit size of a replaced element with
natural size
fantasai: and keep intrinsic size to mean the other
<heycam> +1 for aligning terms across specs
florian: With the new dfn, the intrinsic size of a replacement it
would be the natural size and 0 otherwise?
fantasai: No it can lack an intrinsic size
florian: I don't understand
fantasai: You have to distinguish between whether you are taking
about a min-content and a max-content size
fantasai: When the natural size of something does not exist, there
are rules for determining a non-zero min-content size
myles: Is this purely a rename or behavior change?
fantasai: Purely terminology in the spec
cbiesinger: This is only for replaced elements but, don't you need a
terminology for non-replaced elements with an aspect
ratio because the regular min and max content size will
be affected by the aspect ratio, but you also need a way
to refer to the original min and max content size
because you need that for min-size auto
fantasai: I see what you're talking about, haven't thought about
that yet
heycam: We should check what the HTML spec says
heycam: and I did, and they return 0 for images that have no natural
size
heycam: I just want to make sure we don't have any confusion by
using the same terms
fantasai: I think the DOM APIs can return 0 when there is no natural
size, even though we consider undefined distinct from zero
TabAtkins: Do the DOM APIs refer to it any other way other than the
camelcased form?
heycam: No it refers to JS properties
florian: HTML spec says natural size is intrinsic size.
This is confusing / not good
scribe: fantasai
fantasai: Their spec is using 'intrinsic size' because that's what
our spec (css-images-3) uses.
fantasai: When we update our specs, we'll make sure HTML updates
their terms to match also
Rossen: Hearing mostly support for having this clear distinction
Rossen: Are we leaning towards also accepting the proposed names
here, "natural size"?
<florian> +1
fantasai: 2 votes in favor from rachelandrew and SimonSapin on GH
<bkardell> +1
<bkardell> actually this confused me quite a bit last year
<bkardell> I remember having exactly this conversation with tab in
toronto trying to figure it out
Rossen: I don't see anyone not liking it. Any objections?
RESOLVED: Rename term "intrinsic size" of image with "natural size"
Rossen: Seems like everything on Sizing 3
Rossen: Alan has an editorial issue to talk about
Publication
-----------
Rossen: With everything we resolved, do we need to republish
fantasai: Yes, and
fantasai: That closes all the major issues on this spec, so we'd
like to issue a last call for comments and start preparing
for CR
astearns: So resolution to publish after all these edits are in?
RESOLVED: Republish WD of css-sizing-3 (and start CR process after
that)
CSSOM View
==========
astearns: emilio just volunteered taking on cssom-view at least on
the issues he raised
RESOLVED: Add emilio as editor of cssom-view
<smfr> thank you emilio!
<myles> emilio is the best
astearns: Note that emilio also has editorship of cssom, and
probably needs help
CSS Logical Properties
======================
scribe: tantek
Interaction of shorthands and logical properties
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3030
fremy: Main issue is that in CSS spec it defines how to serialize
properties, contains a lot of tricks to merge declarations
fremy: e.g. if you set all four border properties, the rules merge
it to a single declaration
fremy: When I looked at the logical properties, this is not as easy
fremy: Even if you have all four, you cannot always merge them into
a single property
fremy: It means you have to detect this case (e.g. inline-start) and
do something smart
fremy: logical and physical properties
fremy: Proposing a couple of rules to the serialization steps
fremy: to only merge all four if they are of the same type
fremy: While we were looking at this, a few more updates
fremy: e.g. dbaron proposed if you set the margin property on the
style attribute
fremy: There is no reason to keep the margin-inline properties
fremy: the logical ones
<fantasai> (because they have all now been overridden)
fremy: proposal: make sure that the grouping would work
fremy: making sure when you set things you override property
emilio: Gecko has the concept of logical property groups
emilio: We added it to the spec
emilio: This concept already exists
emilio: e.g. border-inline-start:10px; border-start:20px;
emilio: Gecko will do the right thing
emilio: The concept is already in the spec. This is an obvious bugfix
<Rossen> See the refs for
https://drafts.csswg.org/css-logical-1/#logical-property-group
fremy: The link sounds like exactly what I'm proposing that seems
fine
fantasai: We should make sure ... interleaved ... then that can be
folded into a shorthand
fantasai: The other part of your proposal, if a shorthand is set,
then you can drop any previous declarations that set any
property in that logical property group
fremy: That sounds correct to me
<emilio> https://drafts.csswg.org/cssom/#set-a-css-declaration is
already using this concept
<emilio> We should use it from serialization
Rossen: Do we not have this currently specified? The part you just
added fantasai? In terms of the behavior?
fantasai: I think in terms of how everything is supposed to behave
like cascade, etc. is defined. This is about CSSOM
interaction
Rossen: So this is going into CSSOM then? mostly?
fantasai: I guess so. emilio and I will work it out
Rossen: Any other opinions?
emilio: I need to look a bit more closely at the replace all the
physical longhands
emilio: because there are more complex cases
emilio: e.g. shorthands that only override two properties
emilio: Like the serialization stuff when stuff is interleaved,
that's good
emilio: The replace of the existing physical properties, that may or
may not be confusing
fantasai: I think they are two separate proposals that happen to be
in the same issue
Rossen: Can you separate them for resolutions?
<fantasai> First proposal from fremy: During parsing of a css
declaration block, shorthands (like margin and all)
expands only to the set of longhand (grouped by mapping
logic: so either logical or physical) required to
describe their value, and by default resort to use
physical properties if both sets are possible. Note that
they can only expand if they do not contain var()
substitutions.
<fantasai> Second proposal from fremy: During serialization, each
logical property group is considered, and shorthand
values can be emitted instead of the longhands only if
the all the longhands of the same mapping logic are
present and consecutive (ignoring all properties that are
not in the group). Otherwise, the shorthand is not used
when serializing the properties in the group.
Rossen: Please read the first one, which is about the behavior
specifying, and how declaration blocks behave between
shorthands and longhands and logical properties
fantasai: Looks like I'm finding more pieces of it
fremy: The first one I assume every browser already does that
fremy: it's not clear from the spec, but I assume that should work
regardless
<fantasai> Third piece from fremy: When removing a shorthand
property, all the longhand associated with that shorthand
should be removed, regardless of their mapping kind.
<TabAtkins> +1, all sound good
<fantasai> Fourth piece from dbaron: appending a shorthand property
could set all of its constituent shorthands of one
mapping logic and also remove all of the constituent
shorthands of the other.
Rossen: Any objections to accepting this first proposal
emilio: Question, we are talking about shorthands that map to both
physical and logical properties? but those do not exist in
browser today
fremy: It's possible, back them we had proposal for margin, I don't
know if we still have that
fantasai: We never figured out a syntax that was appropriate
fremy: That was mostly to make sure that case worked
fremy: I don't think it's wrong to add this even if we don't have
the mechanism
emilio: Not saying it's wrong, just possibly confusing
fremy: Mostly the loop needs to be modified
<fremy> https://www.w3.org/TR/cssom-1/#serialize-a-css-declaration-block
Rossen: Wanting make sure everyone is comfortable with accepting
this change
<emilio> yeah, +1 for the serialization change, that's
unobjectionable imo
Rossen: Without delaying people too much, any objections or wait
till Thu morning?
fremy: For me both is fine
RESOLVED: During serialization, each logical property group is
considered, and shorthand values can be emitted instead of
the longhands only if the all the longhands of the same
mapping logic are present and consecutive (ignoring all
properties that are not in the group). Otherwise, the
shorthand is not used when serializing the properties in
the group.
Received on Thursday, 29 October 2020 23:39:57 UTC