Z-indexes
karuto opened this issue · comments
We need to put z-indexes in this repo. Here's how our designers use it, the exact words copied from the design spec of new restaurant profile:
These are suggested values. What matters most is the values should be in this order (from highest to lowest)
Tooltips on modal: 12
Modal overlay (photos, sign in, etc.): 10
Tooltip: 8
Header, footer: 6
Sticky PageNav, sticky right rail: 4
Menu fade-out div (only exists when “View full menu” is present and menu exceeds max-height), “Collapse Menu” button: 1
Page body: default (0)
So we have 7 z-indexes for now. I personally like to separate them with high increments, so that if later we need to add anything between two z-indexes we have some breathing room. We can multiply the values above by 100, so we have 1200, 1000, 800 and so on.
I suggest we put the raw values in aliases.xml in a group, just like we did in the settings file of opentable-theme.
Should we make another token just for mapping and consuming these z-indexes? Thoughts?
It's my opinion that a platform agnostic design token should not have these values in it.
They are not really important at all and imply an implementation architecture that may or may not exist in a client.
For example on mobile web hover overs and dialog boxes may be implemented completely differently and may not even need a z-index. Certainly this would be true on mobile native.
I think that we need a place to store shared implementation details of web stack, which is not the design tokens NPM packages. It might be stored side by side, here in this same repo, but I think it should be one abstraction layer higher and also be the place to store the font stack, etc.
I think we shouldn't have otkit-breakpoints because media query breakpoint is a desktop specific concept, if this repo's intention is to be as platform agnostic as possible.
Same could be said about #48, the desktop typography values that we deemed appropriate to add earlier.
What would you think is the right abstraction level of "shared implementation details of web stack" that we should store, and what's the relationship between that abstraction level and this repo's abstraction level.
I personally think it's ok to have a "composed" token that addresses platform-specific problem, like desktop typography, media query or z-index. I don't think the existence of platform-specific tokens defeats the idea of this repo. We are not forcing people to adopt all the tokens inside this repo. Why can't we keep the "core tokens" of this repo agnostic (such as spacing, colors, etc) and have other platform tokens too? My $0.02
Ok, after talking about @nickbalestra I have changed my mind. Nick convinced me that this repo should store things that are "design dependent". Z-indexes are more of a logical construct that belongs more in "things should be functional" rather than "I need to consult a designer" realm. So I'm going to close this proposal.
I think that's a good general rule to follow: if I wonder next time that something should be in design tokens, I will ask myself "do you need to consult a designer for this?".
@nickbalestra and I also support the idea of having platform-specific, composed tokens side by side with platform agnostic base/core tokens, like SkyScanners did.
Yes, we can generate the platform specific stuff from this same monorepo, but the abstraction layer is one level higher. We might need a different build system to generate the platform specific stuff at times, but if we can use direct token values we should if we can.
@lastquestion Glad you are on board with platform specific tokens. We can follow SkyScanner's example of using imports, or we can have a less verbose file structure as I personally think their tokens are a bit too opinionated and tightly coupled with the view for us to directly adopt. Nick, Matteo and I have a meeting tomorrow to discuss this strategy, will report back.
I don't think that we need to use design tokens to export platform specific values, as they are by definition platform specific and can be tied directly to the implementation platform. In other words, you should use CSS module exports directly to export z-indices, font stack values, and text style classes.
Ok, I see what you mean by having the platform specific values "one abstraction level higher". You are talking about composing them in the consumer's application land. So I understand that we are just keeping this design token repo completely platform agnostic then?
We can continue to use this monorepo to collect shared design stuff, and publish out of this repo. That seems kinda nice because it collects all shared design values all together, even if it's a different abstraction layer.
I guess for text-styles in particular, what we currently have will need to be abstracted into a CSS class definition for multiple microsites and that is what I'd like to DRY up into a platform specific design value-thing.
So, if I'm not mistaken, you want a separate repo, that's very structurally similar to design-tokens, but one abstraction level higher, let's call it web-design-tokens or whatever, it composes platform specific CSS classes based on variables in this repo, and should eventually somehow work with CSS modules setup in our start page. Correct?
You could also just leave it in this repo and publish it out of this one, or a separate repo. And it should export CSS modules directly as files so we can do things like compose classes out of it and import values out of it, yes.
Interesting to see that z-indexes are being specified by design. I've never actually found that way of working with z-indexes particularly useful in real life. Even less so with composable UI components. It's one of those things that seems like it will help, because you put it on paper and it looks sensible and understandable. So you think, I'm not going to have z layering trouble anymore!
But the number is only relative within a stacking context, and modal, tooltip, top nav, etc. almost certainly each establish their own stacking contexts and are often going to be nested inside other stacking contexts. And each unique composition of those in differently organized and nested views will require different orchestrations of their "top level" contexts relative to each other if they overlap, and they don't even need different z-index values if they don't.
YAGNI because it's the next thing to useless.