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

Issue 878458 link

Starred by 1 user
Status: Assigned
Owner:
benjhayden@chromium.org
Cc:
seanmccullough@chromium.org
█ pras...@chromium.org
jeffcarp@chromium.org
dtu@chromium.org
zhangtiff@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Merge fundamental web components from catapult to chops-ui

Project Member Reported by benjhayden@chromium.org, Aug 28 
There are a few web components that seem to be re-implemented occasionally: checkbox, switch, input, textarea, toast, radio, tab, raised button, loading spinner, loading bar, and possibly others. Various Chrome Operations apps require these web components to conform to Material Design 2 and a11y standards while consuming as little CPU and memory as possible. They should look similar between various apps, and possibly support some basic theming.

paper-elements are easy to use and theme and support many features, but tend to be heavy on CPU and memory:
https://github.com/PolymerElements/paper-elements

sk-elements are very light-weight (don't even require Polymer), but may lack some features such as a11y and theming:
https://www.npmjs.com/package/elements-sk

The chromeperf dashboard v2 is growing some components specifically for its own use. They are light-weight (requiring Polymer 2.0) and support theming colors, but lack a11y and other features:
https://github.com/catapult-project/catapult/tree/v2spa/dashboard/dashboard/spa

ChOpsUI aims to be the canonical implementation of these fundamental web components for all Chrome Operations UIs.
https://cs.chromium.org/chromium/infra/crdx/chopsui/

This bug will track merging fundamental components from catapult to chopsui in order to support chromeperf-v2. Since catapult doesn't use DEPS, it will commit chopsui in catapult/third_party. chromeperf-v2 will import them from there.

Open questions:
0. Should chopsui plan to move away from requiring Polymer towards a-la-carte? This would block apps moving towards Polymer 3.0/LitElement, right? This could also someday be an opportunity to share code with sk-elements.
1. When can chopsui move away from HTML imports to ES6 modules?
2. How much theming should chopsui support? Colors? Button styles? Density?
3. Should chopsui provide icons individually? Chromeperf-v2 saved 30KB by copying select icons from iron-icons into its own iconset.
4. Can chromeperf-v2 share charting code with other apps via chopsui? There is an even broader range of charting features between chops apps, so perhaps this is a separate discussion.

Comment 1 by zhangtiff@chromium.org, Aug 28 

Thanks for filing a bug for this! Good context. My personal answers to the open questions:

0. I definitely want to eventually migrate ChopsUI to lit-element or plain web components. I sort of started a CL to work on this a few months back ( https://chromium-review.googlesource.com/c/infra/infra/+/1108482 ), but shelved this work for later for now. I expect we'll need to support Polymer 2 versions for the ChopsUI elements for a while, but I think this shouldn't be too bad. 
1. AFAIK: when we migrate to Polymer 3 or lit-element. :)
2. This still an open question for sure. IMO, we should mostly aim to follow Material Design's guidelines for density ( https://material.io/design/layout/density.html# ) but where we can make it as easy as possible to theme, maybe making a few theming calls to help make ChopsUI styles fit in with our existing frontends and our own brand/style goals for Chops. ie: making sure you can apply styles to :host elements. Where needed, I tend to (not strongly opinionated) favor more generally flexible theming (ie: mixins) over having a bunch of variables exposed, but we may want to consider exposing a few key variables that users can change across their service (ie: primary color). 
3. I would support having a more limited icon package to save space assuming we can find good common ground on what those shared icons should be or some sort of nice way to allow users to specify which icons they import. It's not super clear to me how this should work, but it'd be cool to share this improvement! 
4. I think ChopsUI charting components make sense, but I think this could end up being a pretty big project for sure. That said, I imagine basic charts like line graphs and bar graphs will probably be used/needed across services regularly. Maybe a good starting point would be to share what Chrome Perf does for its charting and see if we can adapt it to be useful for Monorail charts or something similar.

Comment 2 by dtu@chromium.org, Aug 31 

Material Design also has a set of vanilla web components (that are not related to paper-elements). Have we looked at whether we can use those?
https://github.com/material-components/material-components-web-components

They also have "Material Components for the web" but as far as I can tell, these aren't web components (very confusing). But they seem to be in active development, so maybe we can wrap them?
https://github.com/material-components/material-components-web
►

Sign in to add a comment