<scribe> ScribeNick: dael

astearns: It is time but I'd like a few more people so we'll wait a couple minutes

[agenda wrangling]

astearns: Any other changes people would like?

Rossen: I have one for the end if we have time

[css-om-view] Window move and resize functions should be allowed to do nothing

github: 3c/csswg-drafts/issues/4728
... https://github.com/w3c/csswg-drafts/issues/4728

smfr: CSSOM view defines moving and resizing windows, including browser windows
... Text restricts to only do things in certain cases which basically means pop up from window.open
... Following spec suggests window can't self resize which might be a mistake
... 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 reize 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 if window a is familiar with window b and if it's aux browsing context. No additional optout for the UA to deicde this is bad

Rossen_: winow.open has capability to proive 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.
... 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

RESOLUTION: Have smfr put in a blanket MAY saying in some situations browsers can have these functions do nothing

[css-om-view] Describe layout and visual viewports

github: https://github.com/w3c/csswg-drafts/issues/4724

smfr: Rossen_ and I talked offline. I think browser have converserge on mech for fixed post in fac eof page zoom. 2 rectangles layout and visual viewport. Not defined anywhere. WOuld be willing to write text to live in CSSOM View. Asking res to add a section to the spec for the layout and visual viewport. I expect bikeshedding

Rossen_: I support adding the text. Question- besides describing what it is and does what else is there to be done?
... Don't anticiplate providing units or capabilities that are accessible to css?

smfr: Right. Think should desc 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 explination. Not adding capabilities for authors to target

smfr: Correct
... There is a viewport API spec which will reference this.

Rossen_: Link?

astearns: In 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 prsense of these viewports
... 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: Prop: Start defining what we call layout and visual viewport
... I'm hearing consensus. Any concerns or objections?

florian: Proccedural. 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 awk.

astearns: True whereveer they are

florian: True. We can start there and move if we're blocked

astearns: Or a L1 with just these. Do you have asuggestion 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 fund. to basic css. Coordinate systems not just about device adaptation they're fairly fundemental

astearns: We can hash this out at a later time. Let's get it done and then haggle.
... Obj?

<fantasai> I'd probably keep coordinate systems in either cssom-view or css-overflow

RESOLUTION: Start defining what we call layout and visual viewport

<fantasai> but layout viewport vs visual viewport is more fundamental than OM

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 thigns we might get to?

<fantasai> so I think device-adaptation is a better place, if we make it to be more fundamental

smfr: Sure, happy to add.

[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 ording for box sides. For here it's 2 value one per axis.
... 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.
... Question is which convention for size. Block then inline or width then height or something different?
... That's the basic question and not very simple. There is size for page that is physical. Width then height. basckground-size is also phsycial. 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.
... Height and width was suggested last time we talked

cbiesinger: Wasn't it block and inline suggested?

astearns: Fair, yeah.
... 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 scrollsnap are logical. But there's a large list of phsycial and sizing and boxes are in that category. This is a size property it should prob slot into that grouping.
... That's what I feel. But we can argue we don't have a size shorthand so we could make it be logical.
... 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.
... Nice to shift ot logical but I think more inconsistent
... 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
... 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.
... 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 logicla 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
... [Read TabAtkins ]
... 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

Let's make snapshot 2020 while the year is still young

github: https://github.com/w3c/csswg-drafts/issues/4715

<TabAtkins> page-size I don't care about, nobody uses it. background-size is a reasonable counter-argument; we're inconsistent either way. :(

chris: I wanted to start. Last time we did a snapshot was a while ago. We were trying to publish at beginning of year.
... Nothing to propose, but I'd like people to look and comment and add what spec you want.
... Also discussion on what snapshot should mean. Would prefer that separate unless it resolves quickly. Would like to get a snapshot out.

florian: Would 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
... Important part is the few things that ought to be in snapshot and missing one pub. we should deal with them first

chris: There is an issue with the FPWD we agreed to pub. 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 convo 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.
... Anything else on snapshot?
... 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 MS has announced 2 new dual screen devices.
... Given these are cross variety of platforms and browsers and web would be great. CSS is great for layouts. Been bandying about ways to expose CSS for this so they can control how webcontent is in relation to the hinge.
... Had some principles about don't want to expose unnecessary new capabilities. Trying to be cognizent that these devices aren't comprehencive of future. Don't want to shut door on future form factors.
... It's a new media feature called 'spanning' Intent is to desc when viewport is spanning several screens. Depends on how viewport is positioned.
... Need to understand where gap/hinge is in terms of css coord. Proposed 4 env variables to desc where is the fold, width and height of fold
... Excited to hear feedback, if this sounds reasonable, any drawbacks. Definitely open to changing based on collective experience

florian: Always a challange 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 env 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
... All the struggle with vh/vw seem to overlap here. I don't have a solution. Proplem 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.
... Being desc with viewport units I don't think it sits how we've been thinking about it. Not sure if you're jsut noting tie ins

florian: Similar issue, not nec. units. If you want to size something to 80% after folding, what 80% are you talking about? Probles are same as vh/vw even if not same units.

jensimmons: Question: Haven't thought a lot abotu 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?
... 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 hwen you go wide it goes two up? Are there thing like that?
... Is it simply a different way but similar to responsive or is it more complicated whre you have 2 up b/c 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 desc spanning. Spanning is going across hinge in middle. THat allows you to create different experience on that hinge location
... If you look at motivational examples in issue they're pretty well thought through. If there's an email app you can do solumns on left for folder, email titles and then right side is full experience with selected message
... 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 Zo (sp?) has been working on
... Knowing where hinge si 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 nto defining viewport, but there's something that splits viewport

astearns: Is this prop MQ matching cases where phsycial 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 ther answer is this MQ is not for a case like kidle to view on content where content flows from one side to another. This is about having a phsycical gap in screen

Rossen_: I dont think we're insisting on physical paradigm. I can see an epub that uses multiple tabs internally to drive that experience using this css mech. 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 preso API
... Your prop is more powerful b/c allows mix both these. Some content aligns to fold and other span both. I haven't seen cases for this mix. Can you desc one?

dlibby-: I think you said there's single window paradime and you split content. THe other where you lean on preso 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. Presentaion 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-: Accomodate both. Early MS 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.
... 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 gues syou 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
... If you see fold width it essentially describes that space

heycam: I'm imaginging 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 childrens 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

<fantasai> plinss++

<Rossen_> +1 to plinss

plinss: Couple points- Lot of work 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 comment. Would like to make sure if we solve what we do applies on desktops as well. Food for thought

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

end

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/florian/??/
Succeeded: s/many cases/many cases. Also different OSes treat the gap differently, e.g. some mask content in that area whereas others split the screen apart/
Succeeded: s/??/Zouhir/
Default Present: dael, jensimmons, florian, plinss, bkardell_, heycam, smfr, GameMaker, dbaron, sanketj, Rossen_, cbiesinger, dlibby-, leaverou
Present: dael jensimmons florian plinss bkardell_ heycam smfr GameMaker dbaron sanketj Rossen_ cbiesinger dlibby- leaverou
Found ScribeNick: dael
Inferring Scribes: dael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)