The original design idea is what Marcus said: use z-index.css to collect all top level (relative to #screen element) z-index in one file, to fix the problem that "every component redefined their root element's z-index in their own stylesheet and may conflict with the desired z ordering.".
For component specific z-index, such as appModalDialog or BrowserContextMenu, should be defined in app_window.css or app_window_zindex.css to avoid the same issue - if the amount of the sub components grow too much. I am not sure if it worths to have/write a linter; IMO it's reviewer's responsibility to check this rule, but this is sometimes failed to communicate to all the reviewers. One thing worthy to try, is like Marcus said, to define something like BASE_ZINDEX in definition.css, and use calc(BASE_ZINDEX+$NUMBER) to specify the current hardcoded value. CSS variable was not invented before zindex.css, forgive me :) 2015-09-02 13:40 GMT+08:00 Marcus Cavanaugh <[email protected]>: > It looks like there are two uses for z-index in system: > > 1. global stacking order for dialogs/apps > 2. component-local stacking order > > If we want to preserve the ability to do both of these things with a > reasonably easy linter test, one simple way would be to (1) define all > top-level z-indexes as larger than, e.g. 1000, and (2) lint-fail any CSS > file other than zindex.css that defines a z-index larger than that value. > This would allow components to define local z-indexes within themselves, > while preventing them from overriding the top-level z-indexes by mistake. > > As an aside: While that tactic might help, it doesn't do much to alleviate > "z-index soup" -- that is, that zindex.css currently defines the standard > z-indexes far away from their owning components, where they are more likely > to fall out of date. Now that we have CSS variables, it would be nice if we > could take the "data-z-index-level" idea one step further, and define > standard windowing-system z-indexes as CSS variables. I see two advantages > to this: (1) the ability of CSS variables to cascade, and (2) that we could > then move components' standard z-indexes into their owning CSS file. > > That said, I'm not sure that this is worth fixing, if this is still more > of a hypothetical footgun than a real one... but I'm in support of some > sort of consolidation. > > > > On Tue, Sep 1, 2015 at 9:20 PM, Tim Guan-tin Chien <[email protected]> > wrote: > >> Years ago Alive concentrated all the top-level z-indexes into [1] >> >> [1] >> https://github.com/mozilla-b2g/gaia/blob/e9d7c4e3ed/apps/system/style/zindex.css >> >> However I am now seeing z-index everywhere in [2] >> >> [2] >> >> $ grep -rl z-index apps/system/style >> apps/system/style/action_menu/action_menu_extended.css >> apps/system/style/app_titlebar.css >> apps/system/style/crash_reporter/crash_reporter.css >> apps/system/style/devtools/developer_hud.css >> apps/system/style/entry_sheet/entry_sheet.css >> apps/system/style/media_playback/media_playback.css >> apps/system/style/system/initlogo.css >> apps/system/style/system/system.css >> apps/system/style/textselection_dialog/textselection_dialog.css >> apps/system/style/themes/default/core.css >> apps/system/style/window.css >> apps/system/style/window_layout.css >> apps/system/style/wrapper/wrapper.css >> apps/system/style/zindex.css >> >> I can only assume they are not top-level z-index styles but there is >> not way to assure of that, other than manually verifying it one by >> one. Given that, I am pretty sure we have regressed since, and there >> are some other z-index in files other than zindex.css that tries to >> compete with it. >> >> Can we automate this with CSS linter? Can we fix it? Do we want to fix it? >> >> >> Tim >> _______________________________________________ >> dev-gaia mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-gaia >> > > > _______________________________________________ > dev-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
