PolymerElements / paper-button

A button à la Material Design
https://www.webcomponents.org/element/PolymerElements/paper-button
138 stars 64 forks source link

Raised style is not showing #118

Closed greenbergjosh closed 8 years ago

greenbergjosh commented 8 years ago

Description

I added nothing more than the following code to my-view2.html of the app-drawer-template.

`

link
<paper-button raised>raised</paper-button>
<paper-button toggles raised>toggles</paper-button>
<paper-button disabled>disabled</paper-button>`

The link tag is at the top of the file, while the paper-button tags are within the template tag just after the div that comes standard with the template.

Expected outcome

I expected the buttons to reflect the style classes applied.

Actual outcome

Only the disabled style is applied.

image

I tried to debug the issue a bit. In chrome I selected the paper-button element with the raised property. I then attempted to call $0._setElevation(), but it does not seem to work. I am quite new to this, so it is very possible that I am calling it from the console incorrectly.

image

The fully expanded node in the console appears as follows: image image

I also ran a much simpler test with the following code (removed pretty much everything from my-view2.html):

image

This simple test produced the same result.

If there is some other required import, can you please point me to the part of the documentation that says how to use it. This is such a fundamental functionality, that I can only believe I am missing something very basic.

Steps to reproduce

  1. polymer init app-drawer-template
  2. Add the code above to my-view2.html

    Browsers Affected

CaptainCodeman commented 8 years ago

I'm seeing the exact same thing - the styles added to the page have nothing included for elevation:

<style scope="paper-button-0">.paper-button-0 {
  display: block;
        position: relative;
}

.paper-button-0[elevation="1"] {
  ;
}

.paper-button-0[elevation="2"] {
  ;
}

.paper-button-0[elevation="3"] {
  ;
}

.paper-button-0[elevation="4"] {
  ;
}

.paper-button-0[elevation="5"] {
  ;
}

.paper-button-0[animated] {
  ;
}
</style>
CaptainCodeman commented 8 years ago

Ah ha ...

After tracing through the code I understand better how it works now. The styles need to be pulled in at a higher level. Adding the paper styles at the app element level makes the shadows show up for me, e.g.

<link rel="import" href="../bower_components/paper-styles/paper-styles.html">

greenbergjosh commented 8 years ago

CaptainCodeman,

Thank you for verifying that you are also seeing the behavior. I felt certain it was something that I was doing wrong. I went ahead and rebuilt my entire environment on a new machine, and I was again able to reproduce the issue. I then added the paper-styles include to my-view1.html, thinking that should be adequate to correct the problem. It was not. So, following your suggestion, I added the paper-styles include to my-app.html, and it worked. However, I feel this is somewhat unsatisfactory for a number of reasons.

  1. Why do I have to make my entire app paper-styles? I should be able to limit the scope of this include to the individual view. Or, better, to the button itself (since it is a /paper/-button).
  2. Where on the paper-button documentation page does it mention that I also need to include paper-styles? This omission makes programming trial-and-error. I don't want to guess. It's not a video game.
  3. But, I don't think I should have to include paper-styles at all. That seems wrong, and most certainly wrong all the way up at the level of the app. It is, after all, a paper-button. If I need paper-styles to use the button, then it should be named something like, polymer-button. Then, adding paper-styles would make the polymer button look paper-y.

I believe this is still broken. If it is not broken, then the design and the documentation are broken - both of which are arguably more important than the code.

Forgive me if my tone sounds judgmental. I just feel rather passionately that polymer, like other javascript libraries, which are de-facto standards imposed on programmers to maintain their currency, should be somewhat less flaky. I can choose not to use open-source, but then I become a dinosaur. So, I really can't make that choice. So, I choose to use open source, but then I run into nearly hourly, significant issues. There must be a middle ground somewhere.

CaptainCodeman commented 8 years ago

I took it as a learning experience & problem with the level of my Polymer experience but it was a puzzle because I assumed that pulling in the element and using the raised attribute would simply work and it was a surprise that it didn't. From the 'element of least surprise' it seems wrong.

There's often tradeoffs though between ease of use and performance & efficiency. I definitely need to learn more about the styling side of things and best practices to follow.

abdonrd commented 8 years ago

Related: https://github.com/Polymer/app-drawer-template/issues/19

greenbergjosh commented 8 years ago

I love your optimism. I have spent a good deal of time "learning" polymer and a number of other JavaScript frameworks. My fear is that we all accept a definition of "learning" that is less accumulation of transferable, synthesizable knowledge, and more rote memorization of workarounds to compensate for questionable design decisions.

I will freely acknowledge my limited familiarity with polymer, but I find it frustrating that my general knowledge of computer science rarely finds application. The decoupling of style (paper-style, in this case) from the widget being styled (paper-button) is reasonable. However, I still feel that it should not be called paper-button in this case. Calling it paper button implies a style, thereby limiting the reusability that would accompany the separation of concerns. Furthermore, being forced to place the style so far up in the application also limits the flexibility to independently style different parts of the application.

I still think it is a bug in the code. However, isn't it very dissatisfying that your "discovery", while functional, cannot be "proven" to be the correct approach. We are both left wondering; are we noobs who don't know, is this really the right way to make it work, why wasn't it documented anywhere, is it a bug????

We just don't know. And, for all of our effort, whether your method turns out to be correct or not, what have we really learned?

I imagine my position in this seemingly trivial topic may not make me popular here, but I think the ball has been dropped. I would love a definitive answer as to whether your approach is correct, and a justification of why it is acceptable in the context of the concerns I have raised.

Just fixing the bug in the code, or just telling me "that's how it is", doesn't really address the underlying issues, improve the product, or improve our knowledge.

I hope my thoughts are received as an attempt to participate in improvement rather than criticism. I hope we get a great answer from someone in a position to address all points.

Kind regards.

greenbergjosh commented 8 years ago

Abdonrd, Thank you for the reply. I was typing my lengthy response on my mobile while you posted your link, so I did not see it before I submitted my comment. I will try to review your link more carefully as soon as I am able. I still hope someone will address the points I raised above. Thank you again.

keanulee commented 8 years ago

You shouldn't need to import paper-styles - paper-button already imports paper-styles/shadow.html though its dependency paper-material/paper-material.html. Are you sure you have installed paper-button's dependencies and see paper-material/ on the same directory level as paper-button/ (e.g. bower install)?

Repro: http://jsbin.com/meperehava/edit?html,output

greenbergjosh commented 8 years ago

keanulee,

Thank you for your thoughts on the topic. The link posted by abdonrd appears to confirm the bug. The issue is related to the lazy loading of styles. There does not seem to be a fix at present. It would seem to me that the importance of the app-drawer-template, as a learning tool for developers new to Polymer, coupled with the fundamental nature of the paper-button, would elevate the importance of the issue.

It is my understanding that all users of the app-drawer-template, and any other applications doing lazy loading in that fashion, will be affected by the bug. If I had an application in production, and it were failing due to this issue, I don't know what steps I would take.

I am very new to open source. I would love to initiate a conversation with members of the Polymer development team related to the following issues. I believe that solutions to these problems would enhance adoption and productivity.

  1. The post by CaptainCodeman (and my thanks to him and everyone else who posted - we are all putting in our time to help) shows that a new developer, when faced with a bug, will find a solution, potentially incorrect, and envision this as learning. It is the opposite of learning. It takes time away from learning, and leaves the student believing that his solution, though incorrect, is correct. Far worse than knowing you don't know something, is incorrectly thinking you do know. Only the further discussion on this thread can undo the misinformation.
  2. In the short time I have worked with Polymer, I have found two significant bugs. Badges failed to work on Chrome, and styles are not applied to paper-button. I know, with all humility, that these bugs are trivial in comparison to the far more complex, and beautifully written code produced by the Polymer team (read that as a true compliment, not a snarky remark - I am humbled by the fine work they have produced). However, these bugs are fundamental. To me, as a beginning learner, I always assume that I am doing something wrong. Only after 24 hours of struggle did I finally decide to report the first bug, and then, after 8 hours of struggle did I report the second. That is a tremendous amount of time for someone who has a different full time job. More importantly, my failure (which I now realize was not mine) to get even the most simple example working, not only disheartened me, but also made me want to abandon my use of Polymer.
  3. The lack of a clear answer from the Polymer team motivated you to spend your time answering (again, you have my gratitude), even though there seems to be consensus that it is a real bug. This trial-and-error, and constant confusion is tedious (for me, I don't want to assume it is for others).

In summary, I think the following questions should be addressed at a higher level than the code itself.

  1. How can the spread of misinformation, most notably from workarounds due to flaws in the system, be stemmed?
  2. How can we more clearly and definitively acknowledge a bug when there is one?
  3. How can we ensure that the basic features of the system, those features so instrumental in the early stages of learning, are not subject to failures that make the learning experience painful, wasteful, and flat-out wrong?

I will continue to learn Polymer because I still feel it is the best approach to UI that I have seen. I just wish that learning experience were a bit more direct. My failures, in this case, do not make me a better man, they just waste my time. If I finally do "figure it out", maybe the best thing I could do is write some articles myself. Perhaps, that is the real value of open source, it motivates us to give back.

Kind regards

keanulee commented 8 years ago

Ah yes, this is only an issue when lazy-loading elements (as @abdonrd referenced above). Closing since this isn't a paper-button bug.