New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 862762 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Implement specced shadow for the unified system menu and notifications

Project Member Reported by sgabr...@chromium.org, Jul 11

Issue description

Currently the shadow is not as specced. 
See screenshot and spec excerpt from https://gallery.googleplex.com/projects/MCHbtQVoQ2HCZQpLhKoE-Okp/files/MCG-yRuxEmhsHgr0bgEw6NU8wMSJbxAVNpw attached
 
spec excerpt.png
159 KB View Download
screenshot-2x.png
198 KB View Download
Labels: -M-69 M-70
Labels: -Pri-2 Pri-1
Labels: -M-70 M-71
Labels: -M-71 M-72
This seems a little involved because of ARC++ notifications. 
Cc: tetsui@chromium.org
Owner: manucornet@chromium.org
Cc: sgabr...@chromium.org
Thanks Sébastien! I'm starting to take a look at this. I'm trying to reconcile the way shadows are defined in the specs and the way they are implemented. For instance, the code defines a "shadow elevation" as a single number. Some standard values are defined for the whole window manager:

----

// Standard shadow elevations used by the the aura window manager. The value is
// used to initialize an instance of wm::Shadow and controls the offset and blur
// of the shadow style created by gfx::ShadowValue::MakeMdShadowValues().
constexpr int kShadowElevationMenuOrTooltip = 6;
constexpr int kShadowElevationInactiveWindow = 8;
constexpr int kShadowElevationActiveWindow = 24;

----

If possible I'd like to remain within what's defined as standard values, or add a new one if necessary. Do you know how this connects to numbers in the spec (which define shadows more like in CSS)?
Labels: -Restrict-View-Google
Removing Google restriction, I don't really see any issue with this happening in the open. Do let me know if you disagree.
My assumption after working on this with estade@ is that he has built the shadow system in Chrome OS based on the specification you see in #0. Shadows are built with a combination of an Ambient + Key shadow, as defined in this spec:
https://gallery.googleplex.com/projects/MCHbtQVoQ2HCZVwwz_9lG2u2/files/MCG6rbSUEnzjjeAb6qo-x28pwMSJbxAVNpw

This means that if you use kShadowElevationActiveWindow = 24, it will render the combination of shadow which approximates the CSS equivalent, in SKIA:

Ambient: 0 0px 24px 0 rgba(0,0,0,0.12)
Key shadow: 0 24px 24px 0 rgba(0,0,0,0.24)

So what I've defined in this spec is to use "constexpr int kShadowElevationActiveWindow = 24;" which is consistent with the pre-defined standard value.

---


I do not know if this system is flexible beyond the three values 6,8 and 24, meaning if it will automatically generate the shadow elevation and blur value, if I set shadow = 40 this means it should render this:

Ambient: 0 0px 40px 0 rgba(0,0,0,0.12)
Key shadow: 0 40px 40px 0 rgba(0,0,0,0.24)

Could you help me figure this out? This would help me understand how shadows work and enable me to report that in the guidelines.
Labels: -M-72
Labels: -Pri-1 Pri-2

Sign in to add a comment