- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 Jul 2018 19:08:49 -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 Variables
-------------
- RESOLVED: 'all' shorthand does not reset custom properties (Issue
#2518)
- RESOLVED: -- is reserved (Issue #2518)
- RESOLVED: Don't add shorthand for custom props (Issue #2518)
CSS Environment Variables
-------------------------
- RESOLVED: Accept proposal in the issue. “UA vendors MUST NOT
expose built-in env() features to the web without going
through that process” (Issue #2820)
- Mostly issue #2868 (Accept safe-area-inset*) was favored in
general, but it was unclear how the insets are defined when
different axes interact, as two different definitions were
possible. Raised use cases raised included round watches, the
iPhone notch, but also TVs and printers, for which one of the
definitions wouldn't really work very well. Dino will bring it
back for discussion after figuring out these issues.
- The fullscreen-inset proposal (Issue #2871) also was in favor and
both Microsoft and Apple have already tried to solve for having
something like a keyboard or a close icon appear without
shifting what's on screen.
- It will need to be renamed, though, since it isn't
really about fullscreen and more about overlaying.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule
Scribe: fantasai
CSS Variables
=============
Does all reset custom properties?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2518
TabAtkins: Two questions to this issue. First is does all reset
custom properties? I say yes
TabAtkins: Second, should we have something that does? I say yes,
Emilio says no
emilio: I don't remember why...
astearns: Proposed that custom properties don't get reset by all.
Any objections?
dbaron: Have ppl checked implementations?
frremy: Edge doesn't
xidorn: In Gecko it doesn't reset custom properties either
emilio: We have an invariant that only have one longhand in a given
declaration block
emilio: We only store longhands, we don't store shorthands
emilio: That's why it doesn't reset custom properties
emilio: We'd need to rewrite everything.
TabAtkins: Chrome also does not reset custom properties
RESOLVED: all shorthand does not reset custom properties
<TabAtkins> test:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6017
TabAtkins: Next question, should something reset all custom
properties
emilio: Custom properties are inherited, so if you had a -- property
that resets everything, and it would inherit, so it resets
everything all the way down the subtree?
fantasai: It would have to be a non-custom property
leaverou: What's the usecase?
TabAtkins: If you have some component, you want to make sure you
don't get the outer page inheriting stuff into it that
disrupts your stuff because of name clashes
emilio: So it would be a longhand
TabAtkins: So it would be a shorthand
fantasai: It would be a longhand from engine's perspective, has
effect of reseting the properties, so it looks like a
shorthand to the author
emilio: Reason why it's hard is, it's hard to know when do you need
to reset it. And hard to make it do the right thing
emilio: When do you check the value of this property?
emilio: Presumably you want it to work like all property
emilio: --: reset;
emilio: vs --: foo;
emilio: What properties is it resetting? We don't know what the
properties are that we're resetting
emilio: until we've cascaded/inherited all the custom props
TabAtkins: ... I understand the problem now
TabAtkins: If you say --foo: red; --: initial; --bar: blue;
TabAtkins: The --foo needs to be reset to initial, but --bar needs
to still be blue
TabAtkins: That's problematic because you have no idea that -- needs
to expand into --foo until you see that --foo is declared
on or inherited into that element
frremy: In Edge we have a registry of all properties, which need to
be handled before ...
TabAtkins: So you would expand it to all the properties on the page?
emilio: That's not the point of the feature
emilio: You can't expand it at parse time
frremy: You don't expand at parse time
xidorn: Expanding at parse time is how shorthand is supposed to work
emilio: Also, magic of "every prop that has appeared on the page so
far" is really bad
frremy: Not proposing that
TabAtkins: If you do it as that type of pre-scan, then you can do
this. Otherwise you can't
emilio: You can't implement as a shorthand, because you don't know
for serialization what it expands to
emilio: You have to treat it as a longhand, but then you need to
look at that property before you look for custom properties
emilio: Let's say you specify this as a longhand property, then you
can do what eric said
emilio: But you need to look at the value of this property before
computing the custom properties.. which you need to compute
the values of the rest of the properties (in case they're
used)
emilio: Right now we have different phases
emilio: This would convert it from 2 to 3 phases.
emilio: First figure out magic property's computed value
emilio: then figure out custom properties
emilio: then figure out the rest
emilio: which is kindof annoying
...
frremy: ...
emilio: We don't want a global index of custom properties
xidorn: Maybe we can have a longhand property which doesn't affect
element itself, but cuts inheritance to its children, which
doesn't have this problem
TabAtkins: This would change the inherited value of your custom
properties on the children to the value of --
TabAtkins: But then can't both block inheritance from parent and set
specific custom props for inheritance to your children
TabAtkins: on the same element
TabAtkins: Possibility is to make -- take a list of custom
properties to *not* reset, and then it alters the way
that all unspecified custom properties inherit to the
element's children.
TabAtkins: And then it alters the way that all unspecified custom
properties inherit to the element's children
frremy: I don't think we like this
TabAtkins: I think it's the only way to make -- work on a single
element without being a shorthand
astearns: You would be duplicating the properites that you want to
declare on that element
TabAtkins: Correct.
fantasai: Think that this means we should not add the feature.
Nobody's been clamoring for it anyway.
RESOLVED: -- is reserved
RESOLVED: Don't add shorthand for custom props
CSS Environment Variables
=========================
process for adding env() variables
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2820
TabAtkins: I agree.
astearns: Currently spec says “user agents may define additional
undocumented environment variables”
* heycam agrees too
TabAtkins: I think Apple agrees with proposal, too
dino: When original discussion happened, there was some mumblings
that some platforms might want to expose system colors
specific to that platform in some way
dino: But I don't know if anyone still believes that
RESOLVED: Accept proposal in the issue. “UA vendors MUST NOT expose
built-in env() features to the web without going through
that process”
Accept safe-area-inset*
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/2868
drawing referenced below:
https://github.com/w3c/csswg-drafts/issues/2868#issuecomment-402755877
<astearns> https://drafts.csswg.org/css-env-1/#safe-area-insets
dino: We proposed this last year
dino: I think this one is hopefully not so controversial
dino: We expose it so people can avoid notch in iPhone and rounded
corners
dino: But can also be used for e.g. safe area for televisions
fantasai: Would be really useful for printing as well
dino: Having experimented with this, it makes sense for insets
dino: But let's imagine that what you're trying to do is get ppl to
avoid X in the top corner of the screen
dino: page shouldn't put anything there
dino: Should we inset the entire top/left sides?
dino: Or just a note saying avoid that part of the screen?
dino: Let's pause and talk about that later?
dbaron: There was some spec prose that Rebecca Hughes and I iterated
over
dbaron: Because I didn't want Google to ship without a spec for it
dbaron: What I suggested there, and which I think is now in the
draft,
dbaron: Was that the insets together should define a rectangle such
that everything in that rectangle is safe
dbaron: But what you're showing is your insets are more than that
dbaron: You could use any pair of them... but that doesn't work for
the notch
dino: Right, for notch, we have top and bottom insets and it's fine
dino: But if your rotate sideways, then you have left and right
insets
dbaron: I'm wondering if the diagram is intentional
dbaron: I'm suggesting that the rectangle inside the insets was safe
dbaron: but if you move any of those lines outward, then it's no
longer safe
(dbaron is talking about taking the largest rectangle that would
fully fit within the safe area, and using its edges as the inset
edges vs. considering each inset individually, making sure the
entire screen is safe along that edge or inward from it)
dbaron: Specced that the UA is allowed to pick whatever it wants
that would maximize the the usable space
dbaron: There are multiple solutions, might want a narrower or wider
rectangle, that affects how tall it can be
myles: The UA is the one that decides what safe meanss
myles: We could say that the innermost rectangle is safe
dbaron: Prose we put it said something like
“There is some non-rectangular safe region. The insets
define some maximal rectangle within that region”
[fantasai restates what dbaron was saying since ppl look confused]
dino: I think this definition would be acceptable...
dino: User agent could also be free to pick a rectangle where it
only specifies a top and a bottom inset in this case, and uses
the entire width
dino: Would be overaggressive in saying what's safe
fantasai: There might be different use cases for each definition...
myles: For TV example, there's no horizontal line that's safe all
the way across
dino: TV wants more like the green example (individual insets)
dino: Whereas a rounded display needs more like the red one
(dbaron's definition)
iank: Another take is that the green is the same as the red plus a
margin
fantasai: Could have two different sets of variables,
safe-area-inset and safe-rect-inset...
heycam: With scrolling, might have different preferences on whether
to maximize horizontal or vertical areas
myles: UA could alter these
astearns: Horizontal vs vertical orientation of device, would UA
reset them depending on orientation?
dino: Currently does, yes
myles: ...
astearns: Are you unsure whether having these four insets is the
right design?
dino: I was sure, now wondering whether we should define them as the
red rectangle
dino: With the green rectangle you can be safe, if I pad enough from
the top, I know I'm going to be visible in that case, even
though I won't be safe...
dino: Maybe we should hold this.
dino: I will take this back and discuss with other people
dbaron: I think the text needs adjusting for the TV use case, also.
Full-screen insets
------------------
github: https://github.com/w3c/csswg-drafts/issues/2871
[dino draws a fullscreen video player
There's a title in the top left corner
There's controls along the bottom]
dino: Works fine on a desktop machine because everyone knows you can
get out with escape or whatever
dino: But touch interface doesn't have escape key
dino: So we need to provide some UI for escaping
dino: e.g. an X in the top left corner
dino: Fades away if you haven't touched the screen much lately
dino: Trying to come up with variables to take the page where it can
draw content when the browser UI is available
florian: We kindof talked about that when we were doing round
display, with different approach
florian: MQ with coordinate, if I put something there, will it be
visible?
florian: Rather than browser trying to prove geometry, can just ask
"can I put the box there"?
myles: Why would you want to binary search for an available space?
Seems awful
[dino writes an example: title { pos: abs; top: env(fs-inset-top); ]
dino: Can even say title { transition: top 1s; }
dino: then the title shifts as the browser UI disappears and appears
dino: While we specify top/left/bottom/right
dino: Top effectively reserves the entire top
dino: We might do {various things } in this area
dino: In safe mode, would also have put the left side offset, but we
decided to just do the top
...
astearns: So the space taken up by the browser UI is only known when
the UI is showing
dino: The issue is that we did that for awhile, and it looks weird
if the title is not at the top. Looks like they've got a weird
design
dino: Other issue I link to, because we fade out the X, it's a good
example where YouTube fades out their UI as well
dino: Might want to expose timers on our fading so they can
synchronize
heycam: Maybe use events rather than time?
dino: Events makes more sense, usually we're responding to those in
JS anyway
heycam: Also you don't know when exactly to start counting those
seconds
dino: We'd also have to publish and make sure everyone's listening
to the same events
dino: That's basically the two proposals. Happy for any suggestions
or comments
florian: What we started with seemed nice and simple
florian: but seems like maybe they're overly simplified, and as you
get into more complicated situations we keep having to add
more and more tricks
dino: It's very specific to our design, but we want to have
something that works for others as well.
[florian draws a dashboard display and asks about how far are we
going to go]
dino: safe-area-* is about hardware shapes. fullscreen-inset is
about on-screen displays
florian: ...
myles: System with arbitrary shapes would be so difficult to use
that no developer would do it
Rossen: Similar to this, we had a value called device-fixed
Rossen: Worked exactly you describe,
Rossen: When onscreen keyboard came in, didn't want to resize the
entire window
Rossen: But if you wanted to attach UI on top of the keyboard, e.g.
Rossen: Instead of position: fixed
Rossen: You'd do position: device-fixed
Rossen: And it would adjust
Rossen: You won't have to resynch or compute any numeric values like
top/bottom etc.
dino: You wouldn't be able to animate
Rossen: That would be done for you
Rossen: Basically saying that the device now is going up
Rossen: on-screen keyboard is coming up
Rossen: If this UI was important for YouTube, they'd simply position
this as device-fixed
Rossen: And then this simply becomes bottom: 0;
Rossen: And they don't need to do anything else
Rossen: They don't even know, it's still the same thing
florian: If you are sizing things, would that affect viewport units?
Rossen: This is overkill
Rossen: Another example put forward was if you have, suppose some
vertical sidebar
Rossen: Same thing, a bit more work for us, but if you have
positioned top and bottom it would respond
Rossen: From what I know, it was very successful because very simple
Rossen: position: fixed vs position: device-fixed
fantasai: Why isn't position:fixed have the behavior of device-fixed?
Rossen: We weren't actually resizing the viewport, it was an overlay
UI
Rossen: e.g. keyboard uses semi-translucent colors
fantasai: But what if you want to clearly see the content at the
bottom of the page?
Rossen: Just dismiss the keyboard
fantasai: What if you need to type into a form field at the bottom
of the page?
frremy: Then you can dock your keyboard.
dino: Do you still support device-fixed?
Rossen: Yes
Rossen: We were doing this for action center, which is something
that swipes from the right
Rossen: If you have some UI that's really important to your app
Rossen: you can attach it
myles: Does it work if the window is not full screen?
Rossen: No, this is only for full-screen
iank: What is the box?
dino: In our case the device-fixed box would be what remains after
the inset here.
iank: But it wouldn't solve this use case?
dino: It would, but it wouldn't solve use case of wanting to fade
all controls at once
iank: What about tile shifting to the right?
dino: We're reserving the right to put more things up there
dino: Would be up to browser to animate the the device-fixed box.
myles: Animation is different
myles: We want the animation to fade out
myles: whereas you want it to slide out
Rossen: You can fade out the keyboard or slide it?
myles: How does the page know to fade out or side out things?
dino: Say youtube uses a 3s fade, and we use a 4s fade.
dino: Want to tell youtube to use 4s if it wants to be in sync
fantasai: In Apple's case, could just use the transition time value
in the 'transition' property
Rossen: Reason we wanted it done in browser was because syncing
timers was not working
astearns: Weirdly shaped things will need to use a lot of
environment variables
dino: OK, we'll take back this feedback
fantasai: Also, you might want to consider s/fullscreen/overlay in
the names... it's not really about the fullscreening
Rossen: If we are looking to solve the tying of author-defined
controls with UA controls animation
Rossen: You can have a start and an end event
Rossen: Just also need to know how long between the two
myles: Could be part of the start event
astearns: Maybe you only need one set of environment variables
Received on Tuesday, 24 July 2018 23:09:44 UTC