Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Title Bar Customization] Use CSS environment variables to layout title bar #212

Merged
merged 5 commits into from
Mar 3, 2020
Merged

[Title Bar Customization] Use CSS environment variables to layout title bar #212

merged 5 commits into from
Mar 3, 2020

Conversation

amandabaker
Copy link
Member

Update explainer to use and explain new CSS environment variables: unsafe-area-top-inset-left/right.

CSS working group proposal:

Related issues:

@amandabaker amandabaker merged commit cf264f9 into master Mar 3, 2020
@amandabaker amandabaker deleted the titlebar-env branch March 3, 2020 05:57
This was referenced Mar 3, 2020
Closed
Closed
@aarongustafson
Copy link
Member

@amandabaker I was already gone for the day when this request came in. On the whole I think it’s good. Did you consider using logical properties for the directions rather than left/right? I know CSS is currently being refactored to support logical properties, so it might be worth consideration. More: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Logical_Properties

@amandabaker
Copy link
Member Author

The original approach was to use unsafe-inset-top/B/L/R-inset-inline-start/end. The problem with it was the fact that the browser could be in a RTL language when the content is not.

For example, if the browser is in Hebrew (RTL browser layout), and the content is in English (LTR text direction), then which of those does unsafe-inset-top-inset-inline-start respect? Sure, you could say we take the direction on the HTML element (note, that you have to set direction: RTL just setting the language doesn't seem to be sufficient), and use that as the basis for the inset-inline's.

But what if instead a developer flips the direction on some lower element (<body> or some <div> that holds all the content of the page) instead of the root HTML element. As an global environment variable, it can't cater to two different directions. We could just tell developers that they need to place this info at the root, but it still doesn't seem like the right solution.

Since we already are dealing with L/R/T/B in the case of safe-area-inset-*'s, it seems natural to not mix and match physical properties (left/right) with logical properties (inset-inline-start/end).

All that said, inset-inline is an especially confusing topic when crossing the border between browser chrome and web content, so if I'm making a mistake here, then I don't mind going back to revisit the inset-inline option.

@aarongustafson
Copy link
Member

@amandabaker I totally see where you’re coming from. My general feeling is that if logical properties are used, they would relate to the content (according to the root element) and not the browser chrome. We should probably flag it as something to discuss with the CSS WG as they are the ones who would ultimately make the call on how it should be standardized.

@amandabaker
Copy link
Member Author

@aarongustafson Agreed. This is the issue against the CSS WG, but it hasn't gotten any feedback yet: w3c/csswg-drafts#4721

Ultimately, we can do this either way if we tell developers that they must set the direction on the root of the document if they want to use this feature with RTL, so if they decide to go with the inset-inline approach, then we can adjust appropriately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@mwjacksonmsft mwjacksonmsft mwjacksonmsft approved these changes

@aarongustafson aarongustafson Awaiting requested review from aarongustafson

@Maggers Maggers Awaiting requested review from Maggers

@lmitchell lmitchell Awaiting requested review from lmitchell

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@amandabaker @aarongustafson @mwjacksonmsft