- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 5 Feb 2020 21:14:54 -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.
=========================================
CSSOM View
----------
- RESOLVED: Have smfr put in a blanket MAY saying in some situations
browsers can have these functions do nothing (Issue
#4728: Window move and resize functions should be
allowed to do nothing)
- RESOLVED: Start defining what we call layout and visual viewport
(Issue #4724: Describe layout and visual viewports)
CSS Sizing
----------
- Those on the call agreed that the intrinsic-size values should be
ordered like physical properties (width then height), however
those arguing for logical ordering weren't represented on the
call so the group will wait until next week before resolving.
Snapshot 2020
-------------
- The group has set a goal of having the 2020 snapshot ready for
publication at the next F2F. What should be included is
currently being tracked in Issue #4715 (Let's make snapshot 2020
while the year is still young).
- A separate GitHub issue will be opened to contain the conversation
about how to message in one document what is in CSS.
Proposing new CSS primitives to enable great web experiences on
foldable & dual-screen devices
---------------------------------------------------------------
- dlibby introduced the proposal to create a new media feature
called 'spanning' which would indicate when a viewport spans
multiple screens such as on a hinged device as well as 4 new
environment variables to interact with the hinge's location.
(Issue #4736)
- The group was receptive to this work and interested in seeing the
proposal fleshed out further. The media feature not being
specific to hinged devices is important so that it can extend
into the future as technology advances and can also be extended
into multiple monitor set ups used now.
- The proposal has good examples in it, but could use a call out to
exactly the elements that would be spanning the hinge so that
it's clear why the new properties are needed.
- More examples around how the env variables interact different
layout mechanisms would also be helpful.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Feb/0000.html
Present:
Rossen Atanassov
David Baron
Christian Biesinger
Zouhir Chahoud
Elika Etemad
Simon Fraser
Brian Kardell
Dael Jackson
Sanket Joshi
Daniel Libby
Chris Lilley
Peter Linss
Cameron McCormack
Florian Rivoal
Jen Simmons
Lea Verou
Regrets:
Rachel Andrew
Tab Atkins
Mike Bremford
Oriol Brufau
Stanton Marcum
Manuel Rego Casasnovas
Christopher Schmitt
Scribe: dael
CSSOM View
==========
Window move and resize functions should be allowed to do nothing
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4728
smfr: CSSOM view defines moving and resizing windows, including
browser windows
smfr: Text restricts to only do things in certain cases which
basically means pop up from window.open
smfr: Following spec suggests window can't self resize which might
be a mistake
smfr: Main desire for the issue is to state browsers often prevent
content from moving in other conditions then those in spec.
For example may be a tab. Would like to add text to say any
move and resize functions may do nothing
<bkardell> sgtm
astearns: One sgtm in IRC. Other comments or concerns?
heycam: To confirm restrictions on which kinds of windows is
specified in spec?
smfr: Says window A can move or resize window B if window A is
familiar with window B and if it's auxiliary browsing context.
No additional optout for the UA to decide this is bad
Rossen: window.open has capability to provide desired size and
location?
smfr: Yes, takes features including height and width it'll be
opened. I don't suggest changes to that
florian: Are there uses that are not abuse? If they do good to
ensure browsers do it when used legit.
smfr: There is legit use. Used to be able to click a button and open
tiled windows. Internet apps that might still be common. With
many browsers having tabs it doesn't make sense for page to
resize window. I see this as cutting off annoying things. Not
as many legit uses, but not forward looking
bkardell: Even legit don't answer how to do on mobile
smfr: Yeah, on mobile makes no sense.
smfr: And browser can't distinguish legit from abuse.
florian: Generally I'm fine allowing browser to curtail. If there
are valid reasons to keep want to make sure not breaking
them
smfr: Would like to hear Chrome and FF behavior. Safari considers it
a pop-up if it's opened with a width. That's part of loose
nature of browser wanting to cut off abuse
astearns: Assuming other impl don't have details at hand. Anyone
want to go code spelunking?
heycam: I can report back in issue if that's helpful
smfr: I don't want to spec when it's allowed, I just want an opt out
in spec text
astearns: May opt out. And if possible to get more details in if
browsers agree that's fine in the future. Blanket may for
now
smfr: Yeah
heycam: Fine with a blanket may for now.
astearns: Prop: Have smfr put in a blanket MAY saying in some
situations browsers can have these functions do nothing
RESOLVED: Have smfr put in a blanket MAY saying in some situations
browsers can have these functions do nothing
Describe layout and visual viewports
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4724
smfr: Rossen and I talked offline. I think browser have converged on
mechanism for fixedpos in face of page zoom: 2 rectangles-
layout and visual viewport. Not defined anywhere. Would be
willing to write text to live in CSSOM View. Asking for a
resolution to add a section to the spec for the layout and
visual viewport. I expect bikeshedding the names
Rossen: I support adding the text. Question- besides describing what
it is and does what else is there to be done?
Rossen: Don't anticipate providing units or capabilities that are
accessible to css?
smfr: Right. Think it should describe how they interact. When you
zoom and scroll some fixedpos will disappear is unexpected for
some authors. Spec should explain
Rossen: 100% with you. Wanted to make sure only thing we're doing is
adding explanation. Not adding capabilities for authors to
target
smfr: Correct
smfr: There is a viewport API spec which will reference this.
Rossen: Link?
astearns: The link is in ther issue
<heycam> +1 on moving towards being able to write down what <meta
viewport> does
florian: I'm supportive of this. For a long time this was intended
to be done once anyone had time. All sorts of reference in
CSS to "the viewport" but we have multiple. Eventually
we'll need to spec the viewport metatag and a CSS way to
adjust so I suggest write definitions so viewport can be
touched eventually
smfr: Additional wrinkle is we have not spec how scroll position is
derived. I think some movement to being around layout
viewport, but we should spec that as well
florian: Need to define the viewports then audit the specs to what
they're referring to. This is one of those but I'm sure
many more
Rossen: Good to remember what constitutes an initial containing
block in presence of these viewports
Rossen: For abspos the containing block is layout viewport but for
fixed it's visual viewport. That's observable for user
smfr: Yes. Not sure those viewports are right but yes
florian: Maybe do this as a series of PRs defining the viewports.
Then finding instances of specs where they're referred will
take longer. Shouldn't be a single pull request.
smfr: Correct
astearns: Proposal: Start defining what we call layout and visual
viewport
astearns: I'm hearing consensus. Any concerns or objections?
florian: Procedural: If defined in OM View it forces us to have it
as a spec that goes to REC. If it's moving makes dependency
chain awkward.
astearns: True wherever they are
florian: True. We can start there and move if we're blocked
astearns: Or a L1 with just these. Do you have a suggestion of where
else?
florian: A viewport. Device adaptation originally but it's becoming
fiction
fantasai: We could drop the fiction and focus what's in there. I
don't think there's a reason to keep stuff not being impl
smfr: I would prefer not device adaptation b/c these concepts feel
more fundamental to basic CSS. Coordinate systems not just
about device adaptation they're fairly fundamental
astearns: We can hash this out at a later time. Let's get it done
and then haggle.
<fantasai> I'd probably keep coordinate systems in either cssom-view
or css-overflow
<fantasai> but layout viewport vs visual viewport is more
fundamental than OM
<fantasai> so I think device-adaptation is a better place, if we
make it to be more fundamental
astearns: Objections?
RESOLVED: Start defining what we call layout and visual viewport
astearns: Past that we discussed other things we might need to
define. Good to have a note saying these things aren't yet
defined but likely to come out of this work? So we've got
a record of things we might get to?
smfr: Sure, happy to add a note.
CSS Sizing
==========
Determine order of intrinsic-size values
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4531#issuecomment-578214370
astearns: TabAtkins wanted to defer but suggested to start so we can
get some discussion in the issue
Rossen: In addition to existing resolution?
astearns: Yes.
fantasai: Order of values ties into broader CSS problem with
ordering of values. Got a solid set of ordering for box
sides. For here it's 2 value one per axis.
fantasai: We have 2 sets of conventions in place. We have logic
properties like grid shorthand and scroll-snap-align which
we went vertical axis first. y first x second. Older
physical are x first y second.
fantasai: Question is which convention for size. Block then inline
or width then height or something different?
fantasai: That's the basic question and not very simple. There is
size for page that is physical. Width then height.
background-size is also physical. I think we should do
width followed by height.
cbiesinger: Agree. Two length version of margins has height first
fantasai: That's why when went logical we did height first.
Reviewing I think that's a mistake but it's too late to
fix. Physical are width, height and logical are block,
inline.
Rossen: Let's not repeat mistake. Let's keep width and height
??: Agree
astearns: Fairly convincing to be consistent with other size
properties.
astearns: Height and width was suggested last time we talked
cbiesinger: Wasn't it block and inline suggested?
astearns: Fair, yeah.
astearns: Can anyone capture argument for block then inline?
fantasai: Main argument is we're moving toward logical coordinates
in syntax design. Why grid and flex and scroll-snap are
logical. But there's a large list of physical and sizing
and boxes are in that category. This is a size property it
should probably slot into that grouping.
fantasai: That's what I feel. But we can argue we don't have a size
shorthand so we could make it be logical.
fantasai: Problem is we have background-size and size in paged
media. We don't have a shorthand for box-size but we have
sizes elsewhere in CSS.
fantasai: Nice to shift to logical but I think more inconsistent
fantasai: Once we figure out how to switch shorthand between logical
and physical we can switch this too. That's an open issue
on CSS Logical
fantasai: This issue seems minor but ties into a systemic problem
that's not solved
cbiesinger: Shouldn't block property on solving systemic issue
astearns: People on call are in consensus on width and height. We
have an impl that agrees and wants to get it implemented.
astearns: Could resolve knowing people want to revisit. Should we
resolve or wait?
Rossen: Resolve. We can always revisit. We've spent 10 minutes and
are fairly convinced
fantasai: Anyone on the call with a different opinion?
<TabAtkins> I'm unhappy with this being inconsistent with the
existing two-value logical properties. Can we just
record this as a conversation and not resolve yet?
astearns: Only TabAtkins who is reading IRC. Not sure if Chris H had
a strong opinion. Don't think he did
astearns: [Reads TabAtkins]
astearns: Let's take to the issue for another week and resolve next
week
<fantasai> TabAtkins, yeah, but if we make it logical, it'd end up
being inconsistent with background-size and page-size
<TabAtkins> page-size I don't care about, nobody uses it.
background-size is a reasonable counter-argument; we're
inconsistent either way. :(
Snapshot 2020
=============
Let's make snapshot 2020 while the year is still young
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4715
chris: I wanted to start. Last time we did a snapshot was a while
ago. We were trying to publish at beginning of year.
chris: Nothing to propose, but I'd like people to look and comment
and add what spec you want.
chris: Also discussion on what snapshot should mean. Would prefer
that separate unless it resolves quickly. Would like to get a
snapshot out.
florian: Would like to say we aim for a ready to approve snapshot by
next F2F. Let github discussion happen and then someone,
maybe me, can write a draft
florian: Important part is the few things that ought to be in
snapshot and missing one publication to get in there. We
should deal with them first
chris: There is an issue with the FPWDs we agreed to publish.
Separate thing I need to deal with. fantasai the patch tool
isn't working, I might not be doing it right.
fantasai: Let's talk about it.
astearns: Sounds like plan is hash out what goes into snapshot in
the issue with reminders on calls. Have a draft ready
before we meet in Cork?
chris: Sounds great
astearns: Changes to the schedule?
jensimmons: Just a comment about scope of snapshot convo to be about
snapshot. I agree. There does seem to be a growing
conversation about if we should define CSS 4 or a more
marketing term. I agree that's a separate thing. The
snapshot is a function of the WG. It's a good idea to
consider something like CSS 4 but that's a different
topic
astearns: Might be good to raise a separate issue on the messaging.
We should keep this github to publishing the snapshot
we've engaged in producing.
astearns: Anything else on snapshot?
astearns: Please do look. There are a number of questions about
which drafts should go in.
<florian> I'll make an ED today, so that we can start to iterate.
Proposing new CSS primitives to enable great web experiences on
foldable & dual-screen devices
===============================================================
github: https://github.com/w3c/csswg-drafts/issues/4736
dlibby: As maybe you've seen Microsoft has announced 2 new dual
screen devices.
dlibby: Given these are cross a variety of platforms and browsers
looking at this for web would be great. CSS is great for
layouts. Been bandying about ways to expose CSS for this so
they can control how web content is in relation to the hinge.
dlibby: Had some principles about don't want to expose unnecessary
new capabilities. Trying to be cognizant that these devices
aren't comprehensive of future. Don't want to shut door on
future form factors.
dlibby: It's a new media feature called 'spanning' Intent is to
describe when viewport is spanning several screens. Depends
on how viewport is positioned.
dlibby: Need to understand where gap/hinge is in terms of CSS
coordinates. Proposed 4 environment variables to describe
where is the fold, width and height of fold
dlibby: Excited to hear feedback, if this sounds reasonable, any
drawbacks. Definitely open to changing based on collective
experience
florian: Always a challenge for a new MQ for new device.
Categorizing devices doesn't stand as time passes. I'm
happy to see this proposal is trying to test a relevant
aspect of what's going on. Means we're on the right path. A
little concerned about environment variable. When it comes
to sizing I think this is likely to overlap the unsolved
viewport units conversation and which parts have and don't
have scrollbar and keyboard
florian: All the struggle with vh/vw seem to overlap here. I don't
have a solution. Problem space seems reasonable.
dlibby: Makes sense. Aware of some interaction with things like vch
unit to reference visual viewport. I would agree there's
rationalization to be had there.
dlibby: Being described with viewport units I don't think it sits
how we've been thinking about it. Not sure if you're just
noting tie-ins
florian: Similar issue, not necessarily units. If you want to size
something to 80% after folding, what 80% are you talking
about? Problems are same as vh/vw even if not same units.
jensimmons: Question: Haven't thought a lot about devices with
hinge. Is mental model for anyone designing for screen
simply that there's a wider screen with a web window
like we've known for years and then suddenly it's
magically half as wide and that's it? It jumps wide to
narrow and narrow to wide?
jensimmons: Or is it that people think about design of the screen
where you have more space then that. WHen you open a
browser window it's usually one space and when you go
wide it goes two up? Are there thing like that?
jensimmons: Is it simply a different way but similar to responsive
or is it more complicated where you have 2 up because
the new screen?
<Rossen> https://user-images.githubusercontent.com/5052316/73715033-8a3e5b00-46c7-11ea-8839-af3801c97502.png
Rossen: A little of both. Awareness of hinge is important and that's
what described in spanning. Spanning is going across hinge
in middle. That allows you to create different experience on
that hinge location
Rossen: If you look at motivational examples in issue they're pretty
well thought through. If there's an email app you can do
columns on left for folder, email titles and then right side
is full experience with selected message
Rossen: These are doable but if you don't know where hinge is you
have content half on one side and half on the other. That's
a simple example. Many others that Zouhir has been working on
Rossen: Knowing where hinge is is important
dlibby: Knowing where hinge is and mapping to it might be useful to
developers in many cases. Also different OSes treat the gap
differently, e.g. some mask content in that area whereas
others split the screen apart.
jensimmons: Some of these things we know so far like where is screen
aren't issues. This is where hinge is.
Rossen: Right. And this is why we're not defining viewport, but
there's something that splits viewport
astearns: Is this proposed MQ matching cases where physical hardware
doesn't have hinge. Thinking like a reader view or
something like that where might want to layout differently
between left and right page. I think the answer is this MQ
is not for a case like Kindle to view on content where
content flows from one side to another. This is about
having a physical gap in screen
Rossen: I don't think we're insisting on physical paradigm. I can
see an epub that uses multiple tabs internally to drive that
experience using this CSS mechanism. It's something we
haven't thought about. Good to consider
myles: It's clear there are use cases for one browser window to span
both halves. I've also seen use cases like in explainer with
Google maps where one half has map and other is locations.
For one big browser window we can do that today. 2 panes
could be solved with presentation API
myles: Your proposal is more powerful because allows mix both these.
Some content aligns to fold and other span both. I haven't
seen cases for this mix. Can you describe one?
dlibby: I think you said there's single window paradigm and you
split content. The other where you lean on presentation API
to open another full window. Correct?
myles: What type of content are you encouraging web designers to
create with this API. Because with no API web designers could
create for this. Presentation API would encourage 2 different
independent. You haven't proposed either of those types.
You're proposing a 3rd type that doesn't fall into first two
buckets. What type of content are you encouraging that's not
in those buckets?
astearns: Specifically a mixed mode were some content is split but
other content spans both?
Rossen: Let's consider a mail app with an application bar that spans
both screens and then left and right sections for the two
screens
myles: Yeah, I think that answers. A nav bar that spans across the
fold.
heycam: A little unclear to me if the model here is the window that
spans the two displays. Does it have a strip of pixels which
are not rendered because they overlap the folder or is the
back buffer for the window is split? Or both?
dlibby: Accommodate both. Early Microsoft devices is that they'd
have different. One has pixels across the back and the other
has a split. In one case your fold-width would be 0 but it's
still there
heycam: Understood.
heycam: For UI or content you want to span, the toolbar and you've
got buttons you want to avoid the fold space so you don't
lose half a button- not sure if there's a great way to use
env variable to make them avoid fold if you're using
flexbox. I guess you can fallback to script
Rossen: What you're saying is exactly what [missed] to avoid having
loss of content to avoid having the button fall under the
hinge
Rossen: If you see fold width it essentially describes that space
heycam: I'm imagining a flexbox container that spans the width. I'm
not sure how you use nth env variable to make sure the flex
items when you get to fold one doesn't go over fold.
florian: Similar is a 3 column grid where you want 2 and 1 and you
don't care which side is the 2 but you don't want a split
grid.
Zouhir: First one is a single flexbox with an arbitrary number of
buttons with width. You won't know when buttons reach hinge
but it'll help you make 2 columns. Request is a single flex
and avoid the gaps
heycam: Right. That might be an example of the more general region
flow
Zouhir: The original demos we experimented with we didn't touch on
arbitrary number of children avoiding hinge. We did make
multiple grid and flexbox where we can snap to the fold
nicely. It's a good note to take
astearns: Good to add examples of env variables with layout
mechanisms
<fantasai> It sounds like you really need media queries against the
fold offsets
plinss: Couple points- Lot of work is being done on folding screens
and I'm hesitant to do something in CSS that we'll have to
carry around when folding screens might no longer have
hinges. However multiple monitors on desktop is common.
Would like to make sure if we solve what we do applies on
desktops as well. Food for thought
<fantasai> plinss++
<Rossen> +1 to plinss
dlibby: Good feedback. Have that in the back of our mind but not
concrete
Rossen: We've taken steps to make sure that's not obstructed. But
yeah multi-monitor is first that came to discussion
plinss: And there's 4 monitors in a grid where you have vertical and
horizontal
astearns: Thanks for the introduction. I'm sure we'll discuss on the
issue and again on a call
Received on Thursday, 6 February 2020 02:15:29 UTC