- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Feb 2019 07:47:55 -0500
- 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 Grid
--------
- The group agreed to the approach in issue #3565 (minmax(
auto,min-content) under a max-content constraint) to match the
behavior implemented in Edge/Chrome. Prior to a resolution next
week, fantasai will look into when span > 1 and when there's a
mix of fixed and `min-content` max-sizing tracks to ensure the
solution holds up.
- RESOLVED: Accept the edits to issue #3042 (What track sizes match
the concept of "intrinsically-sized track" ?)
Media Queries
-------------
- Issue #3587 (Orientation does not respect soft keyboard on mobile
devices) needs use cases in order to help the group understand
better what the right solution is. Additionally, some tests will
be created to get a better sense of what browsers are doing now
in order to see what is done now and if there's design pattern
blocked/broken by this.
CSS Pseudo Elements
-------------------
- A potential solution to Issue #3607 (Identity of Element.pseudo()
return value) is to treat the pseudo element as detached from
the tree. However, there wasn't enough time to really discuss
this idea so discussion will continue on github.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jan/0014.html
Present:
Rossen Atanassov
Brian Birtles
Oriol Brufau
Tantek Çelik
Alex Critchfield
Benjamin De Cock
Elika Etemad
Javier Fernandez
Brian Kardell
Cameron McCormack
Jen Simmons
Greg Whitworth
Eric Willigers
Regrets:
Daniel Bates
Angelo Cano
Emil Eklund
Simon Fraser
Tony Graham
Chris Harrelson
Dael Jackson
Chris Lilley
François Remy
Lea Verou
Scribe: heycam
Rossen: Any changed agenda item proposals?
[none heard]
CSS Grid
========
minmax(auto,min-content) under a max-content constraint
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3565
Rossen: Elika or Mats or Oriel on the call?
oriol: The issue is that when you have track sizing with minmax(
auto,min-content), and the grid container is being sized
under a max-content constraint
oriol: the spec says that the auto minimum becomes the max-content
contribution of the item
oriol: However this is just when sizing the grid container. Once you
know its size, which will be determined with the max-content
contribution of the item, then you layout again for real,
using this size
oriol: but this time since it's not being sized under the
max-content constraint, since you already know the size, then
the auto minimum just reduces the minimum contribution
oriol: which is usually like the min-content contribution
oriol: Then since the max-sizing function of the track is also
min-content, then the grid item wouldn't grow
oriol: but the grid container would be bigger than the track
oriol: The result seemed a bit strange
oriol: Instead Chrome and Edge seem to clamp the auto minimum in
this max-content constraint, which was behaving as a
max-content contribution,
[missed]
oriol: then fantasai did some edits
oriol: and asked for review
Rossen: Also rehashing some of the thread
Rossen: Mats from Gecko also has an explanation of what Gecko does,
and according to him, the behavior Firefox currently
implements is per spec
Rossen: What I'm wondering is if there is a concrete proposal for
change here
oriol: fantasai already did the edits
oriol: Firefox was following the spec before the edits
oriol: Then I think this would just be for approving the edits
fantasai already did
fantasai: There was another commit
<florian> https://github.com/w3c/csswg-drafts/commit/ea7028dfe4d5d8b8430b9e9622de3ecbc418adad
<florian> https://github.com/w3c/csswg-drafts/commit/a3091ab46f393c5b50a5a9dcce558214041ea8d1
florian: The second link there is the main commit, the first is a
fixup to that
florian: This matches what Chrome and Edge do but not Firefox, right?
Rossen: Yes
florian: Is Mozilla ok with that?
jensimmons: I am here but can't say about this issue
fantasai: Basically what we're trying to do here is not exceed the
growth limit when we are sizing under a max-content
constraint
fantasai: The spec as it is right now says to size the max content
when we're calculating the minimum contribution
fantasai: and if the growth limit is a fixed number it's clamped by
that, but if it's a keyword it's not clamped by that
fantasai: In a lot of cases it doesn't matter
fantasai: but if your growth limit is min-content you probably want
to limit yourself to that
fantasai: otherwise you contribute more space then you end up using
in the end
Rossen: We have 3 impls shipping. Gecko is the only one that will
have to change here, even though they are implementing the
previously specced behavior
Rossen: we can call for objections and resolve on accepting the
changes, and then work through additional issues being
raised by Gecko, or give this another week to get Mats'
perspective
Rossen: Implementation wise, the fact that this is implemented
already in 3 engines out of 4 we have a proof of existence
that it's implementable
heycam: In Mats' comment, did he indicate whether he was happy with
the change?
jensimmons: I think that what authors will want is what Chrome/Edge
implement right now
jensimmons: so it would make sense to do what authors are going to
need/want out of this
florian: In Mats' comment he is somewhat arguing for the old logic
makes sense
florian: but also we could cap like in Chrome if it's desirable
Rossen: I don't think he's arguing implementation complexity
florian: I think the most interesting part of this comment, is
whatever you decide, please make sure it makes sense when
span is more than 1
florian: and there is a mix of min and max content sizing constraints
<florian> "Whatever you decide, please make sure it makes sense also
when span > 1 and when there's a mix of fixed and
`min-content` max-sizing tracks."
fantasai: I should go through a double check this holds true with my
changes
fantasai: or if additional edits are needed
Rossen: So general consensus on accepting this edit. followups after
Mats comments would be good.
Rossen: Otherwise we could easily resolve this next week on the
call. Does that sound reasonable?
<jensimmons> +1
florian: yes
What track sizes match the concept of "intrinsically-sized track" ?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3042
Rossen: fantasai can you summarize?
fantasai: Just made some changes and wanted to check that nobody had
any issue with the changes
fantasai: We defined flexible tracks as intrinsically sized when the
grid container has an indefinite size in that axis
<fantasai> https://github.com/w3c/csswg-drafts/commit/b86cf52f9d5dca765efa8758896a989847a5c68c
fantasai: The reason we did that is when you're sizing under a
max-content constraint, and you have flexible tracks, we
do consider the size of the grid when determining that size
fantasai: If the grid floated, with 2 fr tracks -- normally with a
fixed size of the grid each track will be 1fr
fantasai: minmax(0, 1fr)
fantasai: but if you are max-content sized, you will look at the
content
fantasai: Maybe something in one track tacks up 100px, the other
track even if empty will be 100px
fantasai: Since we're trying to size the grid such that each track
is at least the size of its max-content and it's equally
distributed
fantasai: Here they are considered intrinsically sized
fantasai: so that means when you're doing baseline alignment stuff,
there are cyclic dependencies
fantasai: and we cut the loop by ignoring certain baseline alignments
fantasai: which is what originally brought up the issue
fantasai: So I wanted to double check this all seems ok
Rossen: The change seems ok on our side
fantasai: In fact I was almost surprised we're adding this so late
fantasai: Reading through the explanation is exactly what I'd expect
the distribution algorithm to do
fantasai: so adding this clarification is good, we're in support
fantasai: Any other feedback?
lajava: I was fine with this change
lajava: We wondered if it will be necessary to add something to
clarify that this flexible tracks will be considered
intrinsically sized even after having resolved the container
size in subsequent passes of the grid sizing algorithm
lajava: I mentioned that since Mats already requested something
similar for the percentage track resolution
lajava: where the grid container is initially undefined, and after
being determined the intrinsic size, we use that size to
resolve the percentage tracks
lajava: We wonder if in this case we need to clarify that these
flexible tracks will be considered intrinsic even though we
already resolved the intrinsic size
lajava: because of baseline alignment it has an important impact
lajava: We decide to discard some items from baseline alignment
because of this cyclic dependency
lajava: once you resolve intrinsic size, it's the agreement we
should ...
lajava: These flexible tracks should still be considered
intrinsically sized
lajava: There is no min-content constraint
<fantasai> https://github.com/w3c/csswg-drafts/issues/3046
fantasai: I think you raised a similar issue here in 3046
fantasai: We can try to clarify if you point out what is needed
fantasai: If the track is considered intrinsically sized then the
determination is constant
<lajava> https://github.com/w3c/csswg-drafts/issues/1921#issuecomment-399170288
lajava: Mats also requested a similar thing for percentage tracks
fantasai: I don't know if it makes sense as much, would have to
think about it
Rossen: Percentage tracks in the context of resolving tracks during
measuring?
lajava: yes
Rossen: We have discussed this at the past, and our agreement AFAIR
is that percentages in this case are ignored
Rossen: and the intrinsic size is used
lajava: Then we use the resolved intrinsic size to again resolve the
percentage tracks?
lajava: But we are not doing the same with flexible tracks
lajava: We consider them intrinsically sized even though the grid
container is not indefinite any more
lajava: so we are not doing the same in both cases
Rossen: They are not, because the percentage will resolve during the
layout pass
Rossen: and for the fr the expectation is that you would have the
max-content contribution size taken by that track
Rossen: If the track were 50% instead of 1fr, you would get 50% of
what the max contribution would end up
Rossen: They are the same during the measuring pass, intrinsic
sizing, but don't behave the same during the layout sizing
Rossen: So I'm not sure we need to be necessarily talking about the
two as being the same thing
lajava: I understand
lajava: I wonder if we should specify for the case of the flexible
tracks if in this case second pass, in case of orthogonal
items were you have to repeat the sizing algorithm, that we
should still keep the original behavior of these flexible
tracks being intrinsically sized
lajava: and ignore the already resolved value
lajava: It may be enough with the current spec
lajava: The change says that for this purpose flex tracks count as
intrinsically sized when the grid container has an
indefinite size in the relevant axis
Rossen: The relevant axis is the key
Rossen: Just trying to process your assertion about orthogonal
content and if that has any bearing on this
lajava: When you repeat the track sizing algorithm as the spec says,
for the case of orthogonal items, in this second pass is it
still true that the grid container has indefinite size?
Rossen: It should
lajava: Yes, I think that is what fantasai and Tab resolved in
another issue
lajava: but should we specify that somehow?
lajava: Or is it obvious
fantasai: I don't know where I would clarify it, but if someone
suggests I'm happy to
Rossen: How about lajava if you have the time I would suggest
handling this as part of the other issue that was pointed
about by fantasai
Rossen: 3046
lajava: ok
Rossen: and then we can decide whether or not we need to change
anything
<fantasai> Here's the spec
<fantasai> https://drafts.csswg.org/css-grid-1/#row-align
<fantasai> "If baseline alignment is specified on a grid item whose
size in that axis depends on the size of an
intrinsically-sized track (whose size is therefore
dependent on both the item’s size and baseline alignment,
creating a cyclic dependency), that item does not
participate in baseline alignment, and instead uses its
fallback alignment as if that were originally specified.
For this purpose, <flex> track sizes count as
“intrinsically-sized” when the grid container has an
indefinite size in the relevant axis.
<fantasai> Note: Whether the fallback alignment is used or not does
not change over the course of layout: if a cycle exists,
it exists."
fantasai: [reads above quote]
lajava: ok
Rossen: Back to the original issue, any additional comments about
the edits?
Rossen: Any objections on accepting the edits for issue 3042?
[none heard]
RESOLVED: Accept the edits.
Media Queries
-------------
Orientation does not respect soft keyboard on mobile devices
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3587
florian: The problem here is as the title says, when the soft
keyboard pops up, the screen effectively switches from
portrait to landscape
florian: but that is not reflected by the orientation media feature
florian: Two ways to look at this
florian: One is to think first if the soft keyboard is more of an
overall, or if it changes the size of the viewport
florian: Currently per spec the width/height media features,
aspect-ratio, orientation, as well as vw/vh units or the
position of fixed pos elements, all of this is supposed to
be in sync with the viewport
florian: If the keyboard is an overlay none changes, if it changes
the viewport, then all should change
florian: so I think it's clear, the UA can choose if it's an overlay
or not
florian: but maybe orientation maybe could be different
florian: If the author wants to query the orientation of the device
itself
florian: we have some device-related features that are deprecated
florian: but we don't have one for device-orientation, it sounds
like it might be useful on mobile, unclear on desktop
florian: Whether it's useful I'm worried about changing the
definition of orientation
florian: since it's in sync with the other ones
fantasai: I don't think we should change the definition
Rossen: Definition of screen orientation should not be changed for
sure
Rossen: based on size
Rossen: Either platform specific settings which could apply to any
shape of output device regardless of width/height being
greater than 1 or the other
florian: In general I agree but I wonder what we should do if you're
on a phone and the keyboard resizes the screen from
portrait to landscape, in a way it's not really a landscape
orientation, it's a squished portrait
florian: but if you have a different design for landscape you don't
necessarily want to change to it
florian: but it's a bit fuzzy
Rossen: So you're saying by changing the visual viewport you'll
reevaluate the MQ and it's now landscape?
florian: Yes per spec
florian: Comparing the width/height of the viewport
florian: If you choose to have a soft keyboard that goes over the
viewport and doesn't resize it that 's fine too
bkardell: Does anyone do a keyboard overlay? On my Android devices
it seems to resize the viewport
florian: I think everyone does resize. It's a UA choice
florian: The only thing the spec mandates is that all these things
go together
florian: No way to distinguish units from the MQs or something like
that
bkardell: So it does resize the viewport but it doesn't recalculate?
florian: It should recalculate
tantek: I just tried doing this on Safari. A popup select chooser
did not resize the viewport
<tantek> I tried the popup select on https://www.purpleair.com/
florian: Did you check if it does different things for MQs and vw/vh
units?
tantek: No, just trying on some websites
tantek: It seems to overlay the user entry portion on top of the
page, doesn't resize the page at all
??: ...
jensimmons: This issue will only come up if the site has some CSS to
adapt to the viewport size
tantek: I wouldn't trust FB as an example, they might have some
crazy JS in there
<bkardell> I mean, they have to know where the viewport is right?
the same on twitter btw
jensimmons: Would be helpful to have some examples to open up on
different phones to test this
jensimmons: What do we want? Consistency in following the spec?
jensimmons: The issue about the device being portrait/landscape, but
what about min-height max-height
jensimmons: Do we need to give authors the choice of whether the
keyboard is overlaid? Or maybe it doesn't come up enough
for us to care?
<jensimmons> We need something that resizes in the vertical
direction like this:
https://labs.jensimmons.com/2017/01-008C.html **PLUS**
a text input
tantek: I just tried a simple textarea on a mediawiki page
tantek: The viewport is also maintained, the keyboard comes up just
overlaying
tantek: iOS Safari
florian: So the page has something that would resize vertically?
florian: Or it's transparent?
tantek: The latter
florian: This doesn't necessarily give us the answer
tantek: For a file input control, it does an overlay of its own UI
stuff on top of the page, it doesn't resize anything
tantek: Feels like iOS is being consistent
florian: Unless you have something that is sizing to the vertical
axis, you will not be able to tell between resizing the
viewport and not
tantek: If we can have a test file
jensimmons: I just dropped a demo
jensimmons: No textarea, but you can see that's an example where if
you resize in the vertical direction the layout changes
drastically
jensimmons: The combo of that plus something that triggers the
keyboard
florian: The test tantek suggested is worth writing
florian: The other thing: if people have MQs that react to
orientation, what are they doing with these?
florian: So that we can evaluate a bit more whether that is indeed
the right thing to do, keeping everything in sync
florian: Or if there is something valid to do that doesn't keep them
in sync
florian: I'm a bit confused what the exact use case is
florian: I would be uncomfortable with these things getting out of
sync, I don't understand what the need is currently
<bkardell> if you were in a twitter dm and clicked to add text,
couldn't the field you were typing in disappear if it
overlaid, since it is locked to the bottom of the
viewport?
myles: If you tap the input do you want the page to relayout?
jensimmons: Answer is usually no
jensimmons: but right now it depends on the OS
florian: Giving the author a choice doesn't sound insane
florian: What does the MQ evaluate to is a different issue
jensimmons: There are not many people who are making changes to
vertical height
jensimmons: Apple is loading different images
jensimmons: I think this is an issue though
jensimmons: I'm trying to push designers into understanding
jensimmons: We'll see in 10 years if I or someone succeeds
jensimmons: I think this is a case authors should care about
florian: Responding to the vertical dimension, definitely
florian: should or should not respond to the screen being shrunk due
to the keyboard is harder
florian: in response to the window resizing to be shorter, and
expecting it not to be relaying out to a different reason (
the keyboard) ...
Rossen: In all this discussion we've only been considering vertical
viewport and not the visual viewport
Rossen: If you look at the last comment, that was added by Matt Rakow
Rossen: he has a strong case for taking the visual viewport api spec
into consideration with this proposal
Rossen: and highlighting the fact that if we start changing what is
being proposed here, then windowed / multitasking will start
to break
Rossen: So we can't really make this to be a device thing
florian: Is there a right thing to do then?
jensimmons: I think it's about visual viewport
jensimmons: authors think about that
florian: There are two points to investigate. One is tantek raised,
checking to see that all these things are synchronized
florian: The other is understanding use cases better
florian: <aybe I can ask Jen to do some homework on the use cases?
jensimmons: The use cases [...] if we want to know if we wanted to
add something we don't have here, we should think about
app use cases
florian: I see more of a need for overlay/resizing keyboard, and
having the MQs respond to that
florian: rather than a bunch of MQs that some respond to the
viewport and some don't
<tantek> From what I can tell, all input element activations on iOS
browser (Safari, Firefox) are overlays, and the page does
not resize / reflow / reformat at all.
https://www.purpleair.com/map is one example of a page that
reflows/reformats to fit the viewport
<tantek> That is, there is no resizing of the viewport on iOS when a
soft keyboard, soft popup select, soft file upload UIs are
activated by the user
<myles> the iOS keyboard is designed to work in a particular way.
There are platform conventions that browsers are designed to
obey
<myles> Giving the choice to web authors would be something that
would be incompatible with the design of iOS
Rossen: Action item here for Jen and ideally others to identify use
cases
Rossen: also we'll hear what Kevin Cook (the issue raiser)
Rossen: Then based on this we might continue the discussion, see
what we can do
Rossen: Sound reasonable?
florian: yes
<jensimmons> +1
florian: I can write a test case and check on Android
Rossen: I'm more interested in if we can identify use cases
Rossen: not just a test case
florian: Me too
Rossen: But if there is a design pattern blocked/broken by this
Rossen: that would give a lot more weight to consider this
<tantek> agreed with Rossen's prioritization
florian: Also understanding what browsers do today is useful
CSS Pseudo Elements
===================
scribe: fantasai
Identity of Element.pseudo() return value
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3607
heycam: The issue here is that the spec doesn't say anything
currently about when we need to return the same object that
we used before on this function
heycam: The other confusing part is, the function is defined not
return null if the pseudo doesn't currently exist
heycam: Already we have a case where sometimes it'll return
different values
heycam: But what is meant to happen if e.g. you restyle the element
and its ::before content changes to something different
heycam: Do we keep track of whether we went to null in the interim?
heycam: What is meant to happen?
* fantasai has no idea
florian: Would you prefer to return the same object in general to
avoid garbage?
florian: or return different objects
heycam: Given you want to use these as event targets, I think it
would be best to return the same object
heycam: Otherwise you grab an object, attach an element, then pull
it again to remove your event handler, and it's not there so
you can't remove it
florian: You could maybe have an object that is a shallow copy?
florian: Then you'd have the same items on it
florian: that you could reach, although the object identity would be
different
heycam: I think that'd be weird
Rossen: How is that different from having a reference to an element
Rossen: and referencing... asynchronously
Rossen: In terms of lifetime and identity, original reference will
be held
Rossen: You'll have an element disconnected from the tree
Rossen: You will have some sort of state of whatever it is, and you
may use it if it's useful to you
Rossen: but you have understanding that this element is no longer
part of DOM
heycam: One difference is that it's a lot less obvious when the
underlying thing goes away
heycam: It's determined just by the style values of the element,
e.g. what 'content' property value is
heycam: whereas normal elements, it's more obvious when the thing
has gone away
Rossen: To me what you're describing is the same as saying, if I
have the pseudo element and I ask the containing element
Rossen: If I change the pseudo element to the extent that I need to
generate a new pseudo element
Rossen: then I expect that everything gets disconnected
Rossen: This would be the same pattern as disconnecting a node from
the DOM and still having a reference to it
heycam: I didn't consider that .parent would become null in that
sense
heycam: could change the spec
Rossen: It's one thing to change state
Rossen: Different thing to completely change the element
Rossen: which in DOM case, this is removing the element and creating
a new one
Rossen: For example, changing a div with a text node
Rossen: That would be equivalent transformation
Rossen: In either case if you get disconnected you still have a
reference to the original source element
Rossen: or in this case pseudo element
Rossen: But it's no longer useful to you, and is discoverable that
it's no longer useful to you
florian: Two concerns
florian: One, elements that are disconnected from the tree is a
thing that exists already
florian: Pseudo-elements isn't
florian: Wondering how many odd entities or situations we'll create
by making that exist
florian: Also, for ::before / ::after, that sort-of makes sense
florian: But with e.g. ::selection, the lifecycle is less clear
florian: If you select different things, have you collapsed the
range or ... does it change when you change your
selection???
florian: Having an object that you always return regardless of
styling
florian: is not so consistent with the element view of the world you
were talking about
florian: But exposes a lot less details that are hard to understand
for the author
Rossen: I don't have a ready answer, but I still think that mixing
identities and lifetimes is going to be ...
Rossen: Keeping identity but changing type would be horrible
Rossen: Also, we're over time.
Rossen: I don't think we can resolve on this atm
heycam: I think it'd be good for more people to put opinions in the
issues
heycam: I think in your model, we'd need to know what causes the
identity of the object to change.
Rossen: Ok, let's end the call here. Thanks for calling in. We'll
chat again next week
Received on Thursday, 7 February 2019 12:48:55 UTC