When to use <cr-*> vs. <paper-*>?

[Dan Beam]

Polymer 1.0 is out, which is their "production ready" release.  It's got a better theming story and more stable API.

I was porting chrome://downloads recently when jlklein@ asked if I should be using <cr-button> instead of <paper-button>.  I wondered: should I be using a <cr-*> instead of a <paper-*> every time?

I don't know the history of <cr-*>, but I'd say we are probably in way better shape than when the need for these started and we should probably only wrap <paper-*> if we have differences that act/look the same in multiple features (e.g. settings, downloads).

What does everybody think?

-- Dan

[Oren Blasberg]

FWIW I think the original reason for adding <cr-*> was so that if we decided to change Chromium's app-wide webUI stylings we could do it all in one fell swoop on a per-cr-element basis rather than having to go and modify each page's css. If that is still useful to you guys then it might be worth keeping the cr- elements.

--
You received this message because you are subscribed to the Google Groups "Chromium Settings" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-setti...@chromium.org.
To post to this group, send email to chromium...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-settings/CANpe7K1EeNE5Hgca3wYQKD64syaExetEFqYPiXHxnZShGpKyGQ%40mail.gmail.com.

[Michael Giuffrida]

We could do the same thing by writing a shared stylesheet and specifying the various paper-* styles, although I prefer defining styles in each element instead of in one monolithic file. Either way, though, we should be able to just change the values of variables like --chrome-text-color in a single file rather than having to modify the hypothetical shared stylesheet or cr-elements directly.

One thing we gain with cr-elements is specifying sensible defaults, e.g. disabling the floating label on paper-inputs. It also affords some amount of protection from changing APIs, but that's not as likely to be a concern with 1.0 (and we don't have to keep upgrading, anyway).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-settings/CAFeCVRephFrPzr1qcUD0fLh5AoQYx0yaOAKeWvL0nqdJQoohFA%40mail.gmail.com.

[Tommy Li]

Sounds like it's unnecessary. It's another layer of abstraction, and a lot of the reasons for its existence seem to no longer apply.

If we can accomplish the same thing using a common CSS stylesheet (a lighter weight abstraction), I think we should just do that.

[Dan Beam]

On Thu, Jul 16, 2015 at 6:23 PM, Tommy Li <tomm...@google.com> wrote:

Sounds like it's unnecessary. It's another layer of abstraction, and a lot of the reasons for its existence seem to no longer apply.

I think we'll intentionally differ from Polymer in some cases (because designers).  I think we should hold onto the infra for doing this and just see how many exceptions we end up with.

 

If we can accomplish the same thing using a common CSS stylesheet (a lighter weight abstraction), I think we should just do that.

They're axing shadow piercing selectors in CSS, I believe (i.e. /deep/ in CSS, not querySelector()).

We've previously created widgets.css and chrome_shared.css that accomplish similar things.  We may have to use CSS vars and the Polymer shim to actually support them in Chrome.  That's kind of an orthogonal problem as we're gonna want to do this in a shared location to all <cr|paper-*> elements as well, I think (e.g. totallly global settings like fonts and stuff).

On Thu, Jul 16, 2015 at 5:44 PM, Michael Giuffrida <mich...@chromium.org> wrote:

We could do the same thing by writing a shared stylesheet and specifying the various paper-* styles, although I prefer defining styles in each element instead of in one monolithic file. Either way, though, we should be able to just change the values of variables like --chrome-text-color in a single file rather than having to modify the hypothetical shared stylesheet or cr-elements directly.

One thing we gain with cr-elements is specifying sensible defaults, e.g. disabling the floating label on paper-inputs. It also affords some amount of protection from changing APIs, but that's not as likely to be a concern with 1.0 (and we don't have to keep upgrading, anyway).

<cr-input> just wrapping <paper-input no-floating-label> would probably be OK (or maybe a behavior?).

Tangent: there's probably a pretty good reason for the floating label, though, as placeholder text disappearing has always been a UI problem ("what was this field again...?" after typing anything in it).

On Thu, Jul 16, 2015 at 5:29 PM, Oren Blasberg <or...@chromium.org> wrote:

FWIW I think the original reason for adding <cr-*> was so that if we decided to change Chromium's app-wide webUI stylings we could do it all in one fell swoop on a per-cr-element basis rather than having to go and modify each page's css. If that is still useful to you guys then it might be worth keeping the cr- elements.

I think a CSS file w/shared variables is just as easy for a "change the look of every X" case and results in way less "font-family: Roboto" in every new component as well as lots of "/* Matches .frobber in blah.css */".

-- Dan

On Thu, Jul 16, 2015 at 3:53 PM, Dan Beam <db...@chromium.org> wrote:

Polymer 1.0 is out, which is their "production ready" release.  It's got a better theming story and more stable API.

I was porting chrome://downloads recently when jlklein@ asked if I should be using <cr-button> instead of <paper-button>.  I wondered: should I be using a <cr-*> instead of a <paper-*> every time?

I don't know the history of <cr-*>, but I'd say we are probably in way better shape than when the need for these started and we should probably only wrap <paper-*> if we have differences that act/look the same in multiple features (e.g. settings, downloads).

What does everybody think?

-- Dan

--
You received this message because you are subscribed to the Google Groups "Chromium Settings" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-setti...@chromium.org.
To post to this group, send email to chromium...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-settings/CANpe7K1EeNE5Hgca3wYQKD64syaExetEFqYPiXHxnZShGpKyGQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Settings" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-setti...@chromium.org.
To post to this group, send email to chromium...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-settings/CAFeCVRephFrPzr1qcUD0fLh5AoQYx0yaOAKeWvL0nqdJQoohFA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Settings" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-setti...@chromium.org.
To post to this group, send email to chromium...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-settings/CACi5S_0VGCkh-984p9TSDe1BLdg6WYhjC5zRwbckVfANd4JxYQ%40mail.gmail.com.

[Michael Giuffrida]

On Thu, Jul 16, 2015 at 7:03 PM, Dan Beam <db...@chromium.org> wrote:

On Thu, Jul 16, 2015 at 6:23 PM, Tommy Li <tomm...@google.com> wrote:

Sounds like it's unnecessary. It's another layer of abstraction, and a lot of the reasons for its existence seem to no longer apply.

I think we'll intentionally differ from Polymer in some cases (because designers).  I think we should hold onto the infra for doing this and just see how many exceptions we end up with.

 

If we can accomplish the same thing using a common CSS stylesheet (a lighter weight abstraction), I think we should just do that.

They're axing shadow piercing selectors in CSS, I believe (i.e. /deep/ in CSS, not querySelector()).

We've previously created widgets.css and chrome_shared.css that accomplish similar things.  We may have to use CSS vars and the Polymer shim to actually support them in Chrome.  That's kind of an orthogonal problem as we're gonna want to do this in a shared location to all <cr|paper-*> elements as well, I think (e.g. totallly global settings like fonts and stuff).

On Thu, Jul 16, 2015 at 5:44 PM, Michael Giuffrida <mich...@chromium.org> wrote:

We could do the same thing by writing a shared stylesheet and specifying the various paper-* styles, although I prefer defining styles in each element instead of in one monolithic file. Either way, though, we should be able to just change the values of variables like --chrome-text-color in a single file rather than having to modify the hypothetical shared stylesheet or cr-elements directly.

One thing we gain with cr-elements is specifying sensible defaults, e.g. disabling the floating label on paper-inputs. It also affords some amount of protection from changing APIs, but that's not as likely to be a concern with 1.0 (and we don't have to keep upgrading, anyway).

<cr-input> just wrapping <paper-input no-floating-label> would probably be OK (or maybe a behavior?).

Tangent: there's probably a pretty good reason for the floating label, though, as placeholder text disappearing has always been a UI problem ("what was this field again...?" after typing anything in it).

Away with you and your Web 2.0 nonsense! In Chrome we label our inputs. 

On Thu, Jul 16, 2015 at 5:29 PM, Oren Blasberg <or...@chromium.org> wrote:

FWIW I think the original reason for adding <cr-*> was so that if we decided to change Chromium's app-wide webUI stylings we could do it all in one fell swoop on a per-cr-element basis rather than having to go and modify each page's css. If that is still useful to you guys then it might be worth keeping the cr- elements.

I think a CSS file w/shared variables is just as easy for a "change the look of every X" case and results in way less "font-family: Roboto" in every new component as well as lots of "/* Matches .frobber in blah.css */".

How would we style something like margins the same for all paper elements, without shadow piercing and without wrapping paper elements?