profile
viewpoint
Diego Gonzalez diekus @microsoftedge the interwebs with kittens https://diek.us Doctor in Informatics and Computer Engineer from Costa Rica. PM @MicrosoftEdge, interested in bringing PWA technology to the masses and enhancing the web

MicrosoftDocs/edge-developer 183

Developer documentation for Edge.

diekus/pwinter 3

PWA logo printer

PWA-Summit/2021.pwasummit.org 1

Website for the 2021 PWA Summit

diekus/browser-compat-data 0

This repository contains compatibility data for Web technologies as displayed on MDN

diekus/device-posture 0

Device Posture API

diekus/diekus 0

::^_^::

diekus/diekus.github.io 0

personal website 🐱‍🚀

diekus/edge-developer 0

Developer documentation for Edge.

diekus/html 0

HTML Standard

issue commentWICG/window-controls-overlay

How does the window controls overlay fit with the page's layout?

I would expect a fully responsive web app to use safe-area-inset-* vars to make sure their app looks appropriately on an iPhone and the titlebar-area-* vars to accommodate certain content in the title bar region of a window. I don't think they are not "not appropriate" per se... but the titlebar-area-* provide a better more understandable naming for what they are achieving in the context of WCO.

Additionally while both the titlebar-area-* and the safe-area-inset-* are of "types" length, the semantics of them are not quite the same as one is a mostly used/understood as "space to leave from the margins of the 'viewport'" and the other one is a coordinate in the viewport and the width and height from that coordinate that define the title bar area. I think for ease of use the titlebar vars can be better suited.

yoavweiss

comment created time in 2 days

issue commentWICG/window-controls-overlay

How does the window controls overlay fit with the page's layout?

Sorry for the tons of typos, was eating the best burger ever whole I typed on my phone!

Platform or device? Doesn't the Android thing I linked to provide a platform API?

Yes! what I mean is that there is not platform or device where the notch intersects a window title bar. Oh the notch is not hypothetical. What is hypothetical is notches interfering with windows and overlays of controls in those windows.

Do you think addressing irregular viewport spaces (N notches in several different edges (no pun intended)) might benefit from a different API that could cater to the more universal case I can see you are trying to solve?

yoavweiss

comment created time in 2 days

issue commentWICG/window-controls-overlay

How does the window controls overlay fit with the page's layout?

I think it is a very different thing a notch than an overlay of window controls. One has a fixed position in hardware and the other one is always 'attached' tothe window. The window can be in diferent positions in the screen, and, in the hypothetical case that Chris mentions that a notch and a window intersect, it gets messier. How does content flow? Is a notch seen the same as an overlay while dragging? What if a notch touches an overlay of a window? I tend fo agree with Alex this is a case unlikely to happen.

I think if the plan is to solve this for notches, then it is better to look into a different approach that can piggy back of the shape media feature or the shape-inside property for example. Trying to use WCO as a one solution for all irregular shaped viewports can create confusing scenarios and complicate the use of the env variables as well.

Are all notches created equal? To be or notch to be? That is the question.

We've looked in the past at ways of treating the overlay as a notch and it doubles the number of CSS variables just for one notch in the center (which again, does not exist in any platform today).

Are we oveely complicating an API and possibly creating frixtion yo adopt it in its current straightforward way to cater to a UI trend that might go away when under display cameras and sensors become a thing in a couple of years?

The trend of notched phones today is far less than a year ago, I worry we sacrify API usability for a passing UI trend. Just my 2 cents!

yoavweiss

comment created time in 2 days

PR opened WICG/window-controls-overlay

WCO getClientBoundsRect rename for clarity

-Renames getClientBoundsRect -adds considered alternative of treating overlay as a notch in explainer -adds note clarifying approach of WCO + notches.

+58 -10

0 comment

2 changed files

pr created time in 2 days

push eventdiekus/window-controls-overlay

diekus

commit sha 5b552dad17fc3a5c18b8cb59ebf3559942fdc17b

updates explainer. Adds note to address notches - adds considered alternative of treating the overlay as a notch

view details

push time in 2 days

issue commentWICG/window-controls-overlay

How does the window controls overlay fit with the page's layout?

I've discussed with the feature crew and we dont think we want to make the API more complex by enabling support for center notches/multiple notches on title bars because it is not a UX pattern that exists on desktop platforms.

We appreciate the suggestions as it gave us different cases to consider we might have not thought of.

yoavweiss

comment created time in 4 days

issue commentWICG/window-controls-overlay

How does the window controls overlay fit with the page's layout?

I understand. We believe the the API is forward compatible. If a browser decided to implement this feature on say, Samsung DeX running over android, it would be compatible. Same as if any browser in Linux were to implement this API with a GUI like KDE, Deepin DDE, Xfce, Budgie, LXDE, ...

When the API was being developed we looked at trying to work around notch, but quickly realized that it would become cumbersome to develop for since for example, windows in macOS have the overlay region separated in 2 different regions, (basically 2 notches) and that it made using the feature more cumbersome as a whole trying to position elements in N notches by M areas. To this we add the fact that there is no implementation or windowing system on desktop environments that behaves in the described way. This would imply sacrificing ease of use of the feature to support a use case that does not exist.

The Window Controls Overlay for installed Desktop web apps feature aims at allowing the developer to create custom title bars, and it tries to do it in a way that is straightforward, by allowing the developer to easily identify in CSS and JS the available area they can use to do so.

yoavweiss

comment created time in 4 days

push eventdiekus/window-controls-overlay

diekus

commit sha 1e4d7df2dff33680da9e59685c86c7cdd1767404

Update explainer.md

view details

push time in 5 days

Pull request review commentWICG/window-controls-overlay

updates explainer

 The bounding rectangle and the visibility of the window controls overlay will ne To provide the visibility and bounding rectangle of the overlay, this explainer proposes a new object on the `window.navigator` property called `windowControlsOverlay`.  `windowControlsOverlay` would make available the following objects:-* `getBoundingClientRect()` which would return a [`DOMRect`](https://developer.mozilla.org/en-US/docs/Web/API/DOMRect) that represents the area under the window controls overlay. Interactive web content should not be displayed beneath the overlay.+* `getBoundingClientRect()` which would return a [`DOMRect`](https://developer.mozilla.org/en-US/docs/Web/API/DOMRect) that represents the area in the title bar region that is not under the window controls overlay. Interactive web content should can displayed in this area.

fixed and pused

diekus

comment created time in 5 days

PullRequestReviewEvent

push eventdiekus/window-controls-overlay

diekus

commit sha 88417f7cc3f0675b9a4402095ba2d5d4a9e680f5

Update explainer.md -removes typo

view details

push time in 5 days

PR opened WICG/window-controls-overlay

updates explainer

-updates explainer -adds a note in the spec about fallback on unsupported browsers

+26 -3

0 comment

3 changed files

pr created time in 5 days

create barnchdiekus/window-controls-overlay

branch : diekus-explainer-update

created branch time in 5 days

issue commentWICG/window-controls-overlay

How does the window controls overlay fit with the page's layout?

It calls the blue area the "window controls" and "(controls) overlay", but the WindowControlOverlay is in fact the area labeled "title bar area" in the image, correct? If so, then I agree that getBoundingClient(s) rect is a fine name.)

Yes, the getClientBoundsRect is referring to the title bar area (the one in light blue). The red and green sections are there to define the concepts that are used on the spec. In several parts of the spec there are mentions to what are the window controls (minimize, restore, close) for example.

How else would content avoid overlapping with the blue OS window control area? As you diagrammed, when the WindowControlOverlay feature takes effect, the client rect for the developer overlaps the blue area.

Yes, the viewport will have areas that are covered by the controls in the corner. The way to avoid content underneath them is by 1- using the CSS environmental variables or 2- the getBoundingClientRect that represent the same area (the one depiected in light blue as Title bar area).

On a notched mobile device, the notch is usually in the middle. Wouldn't it be nice to expose the sides to the developer, in the same way you're suggesting it on desktop?

This is interesting, it is not supported atm. WCO is a feature primarily designed for supporting the use case of being able to create custom title bars on desktop environments. I believe on mobile the inset variables are the ones that define the safe area for content in general, and while this does not include laying content on the sides of a notch, it is not a use case that WCO aims at resolving. I am certain that if a case comes when a supported platform has controls on its windows that are centered or similar then it is something that will need to be considered.

yoavweiss

comment created time in 5 days

issue commentWICG/window-controls-overlay

How does the window controls overlay fit with the page's layout?

Also, to clarify, titlebar-area-height == safe-area-inset-top in this case. Maybe we are looking at the same aspect form different angles!

yoavweiss

comment created time in 14 days

issue commentWICG/window-controls-overlay

How does the window controls overlay fit with the page's layout?

Hola @chrishtr. The developer does not draw any window controls, this feature only expands the viewport and provides a JS and CSS way of positioning content on the area that was previously occupied by the title bar. I don't quite understand why a window on the desktop with the feature on would need to specify safe area with inset variables?

About the centered title bar, I do not think it is something that exists atm in desktop environments? If you do have a use case please let us know, but this is not supported because there is no use case that follows this behavior in any supported platform.

I believe even in MacOS on the new notched machines there is never a case when a window's app can maximize to intersect the notch. The notch only clashes with the top menu bar.

yoavweiss

comment created time in 14 days

PR opened WICG/window-controls-overlay

Diekus/i2s geometrychange algorithm
  • removes conformance wording from note.
+21 -12

0 comment

1 changed file

pr created time in 14 days

push eventdiekus/window-controls-overlay

diekus

commit sha 5ad6cbc4cedda556a0d153a50eebbaa5e74e1802

removes conformance word in a note

view details

push time in 14 days

issue commentWICG/window-controls-overlay

How does the window controls overlay fit with the page's layout?

Hola @chrishtr. I would expect the safe-area-inset-* variables to be set for when a web app is running on mobile notched devices and the title-bar-area-* variables set as well for when the app is displayed in desktop environments, but I don't think there is a case when both need to work at the same time? (please let me know if I am mistaken or if there's maybe some new device you're shipping I have no context of?)

About the non-rectangular overlay, having the bounds of the overlay would still be viable to avoid putting content beneath it. Is there any special consideration you think we are missing?

Regarding overlays that aren't aligned to the left or right or the frame, MacOS is an example where there is overly to both sides of the window and the API still handles that use case. I do not think there is a use case where a title bar has elements that create more than 1 title bar area, but again, please let me know if there is any case where we would need to readjust the API!

Thanks for the feedback, good food for thought!

yoavweiss

comment created time in 14 days

issue commentWICG/window-controls-overlay

"Update the overlay area information" is not well-defined

@inexorabletash Hola Joshua, yes, I had a meeting with Yoav and ironed out the problems. The new changes, (including the monkey patch to CSSOM) should be live very soon.

yoavweiss

comment created time in 18 days

PR opened WICG/window-controls-overlay

Diekus/i2s geometrychange algorithm
  • removes ambiguous sentence that created confusion that the renderer was responsible for avoiding content beneath the overlay.
  • monkey patches the CSSOM temporally to add the step required after a resizing of the window happens.
+40 -12

0 comment

3 changed files

pr created time in 18 days

push eventdiekus/window-controls-overlay

diekus

commit sha 8dcc507b884e2ef36cd2061fe987807e46aa5521

Monkey patching CSSOM - removes ambiguous sentence that created confusion that the renderer was responsible for avoiding content beneath the overlay. - monkey patches the CSSOM temporally to add the step required after a resizing of the window happens.

view details

push time in 18 days

issue commentWICG/window-controls-overlay

When does the `geometrychange` event fire?

Hola Yoav, please advice: https://wicg.github.io/window-controls-overlay/#the-ongeometrychange-attribute

Regards,

Diego


From: Yoav Weiss ***@***.***> Sent: Tuesday, November 16, 2021 6:15:50 AM To: WICG/window-controls-overlay ***@***.***> Cc: Diego Gonzalez ***@***.***>; Comment ***@***.***> Subject: Re: [WICG/window-controls-overlay] When does the geometrychange event fire? (Issue #32)

Can you point me to the reference? Generally, it's best to trigger the event from the processing model where you want it to be triggered. In case of WICG specs (that don't necessarily have the necessary consensus) we often temporarily monkey-patch the relevant processing models and indicate where in those models the event will be fired.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/WICG/window-controls-overlay/issues/32#issuecomment-969900746, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARUDUUTFHBHUFU5XRXOCCVTUMHZJNANCNFSM5GO7OF3A.

yoavweiss

comment created time in 20 days

Pull request review commentWICG/window-controls-overlay

Diekus/i2s geometrychange algorithm

 <h2>       <h2>         Algorithms       </h2>+      <section>+        <h3>+          Resize the title bar area+        </h3>+        <p>+          To <dfn data-lt="title bar region resizes">resize the title bar+          area</dfn> for a window |win|, run these steps:+        </p>+        <ol>+          <li>If |win|'s [=overlay=] has had its width or height changed (e.g.+          as a result of the user resizing the browser window, or changing the+          page zoom factor, or extensions/other UI appearing or disappearing on

removed extensions

diekus

comment created time in 20 days

PullRequestReviewEvent

Pull request review commentWICG/window-controls-overlay

Diekus/i2s geometrychange algorithm

 <h3>         <p>           The `ongeometrychange` attribute is an event handler whose           corresponding event handler event type is "change". The event is-          dispatched when the available title bar region changes, e.g., in+          dispatched when there the [=title bar region resizes=], e.g., in

fixed typo

diekus

comment created time in 20 days

PullRequestReviewEvent

push eventdiekus/window-controls-overlay

diekus

commit sha 58a60619c6652bbd66bd1967b1840fc866a5137b

- Fixes typo in spec

view details

push time in 20 days

PR opened WICG/window-controls-overlay

Diekus/i2s geometrychange algorithm
  • adds the geometry change algorithm clarification and more images.
+26 -7

0 comment

3 changed files

pr created time in 20 days

more