Expose iron-image position and sizing properties

[kristfal]

There is currently no means of styling the position of image in the card due to iron-image properties not exposed.

These properties should be exposed to give developers better control of the content presented to the user.

[bicknellr]

Check out the comments in #50. The iron-image in paper-card is meant to cover a pretty basic use case: full width with the aspect ratio maintained. The --paper-card-header-image mixin is a good option if you want to tweak this a bit. Have you tried adding your own iron-image?

[kristfal]

Hey @bicknellr,

adding a custom iron-image works just fine, no problem there.

However using the --paper-card-header-image mixin to change image the height dimension will in many cases require positional/alignment control of the underlying image. By default, the image now aligns to top – which makes the iron-image component of this element problematic to use if you want to show multiple cards with the same image height that has different underlying image dimensions.

From a developer's POV, I'd prefer to either have the entire iron-image API exposed or the iron-image removed completely from this element.

This current middle ground stance might be useful for specific use cases, but for those with other requirements, the inclusion of the iron-image component is an unnecessary performance overhead. If you do want to follow this middle ground and keep a simple API, I'd hope that the iron-image alignment would default to center and the sizing property default to cover if a height css property is set in the mixin.

Let me know what you think, and feel free to close this issue and PR #62.

[bicknellr]

Have you looked at paper-material? It's used by paper-card to match up with the Material Design spec for container elements (just box-shadow, lul). I think you're right about the image's defaults - centered + 'cover' sounds like a good idea.

[bicknellr]

Oh, we already expose a ton of other properties of the image... That's what you were getting at. Yeah, this feels kind of weird to provide access to only about half of the iron-image API through proxy properties.

I remember overhearing some discussion about exposing whole wrapped components when we want them to be highly customizable. (I believe iron/paper-input was what brought this up; paper-input contains iron-input and has to expose a ton of random properties with weird behaviors.) This would preclude using the data-binding system to work with the exposed component though, but it might be a reasonable tradeoff so that changes to the API of a lower-level component don't have to be made in every component that doesn't actually use it and just happens to transitively depend on / expose it. What are your thoughts on something like that?

[kristfal]

Exposing the entire component sounds good. Can't really envision how it would be done without data-bindings, a proposal would be awesome, but the customization option is regardless very welcome.

[ruckc]

I have an issue where trying to use HiDPI images in a paper-card. Since I can't set the height/width properly, I have to downsize my images which ruins the ideal HiDPI look. Ideally I would just need a image sizing percentage or scale (33% or 0.33) property exposed to size the image properly for the various HiDPI screens. Though Ideally i'd just be able to set height or width or both, and let the iron-image do the remainder of the scaling automatically.

[tonlie]

+1 to exposing more iron-image properties. Found a problem trying to set a placeholder image that shows, while the header image is loading. Even though it's mentioned in the docs (see Here @ preloadImage Property), it doesn't work.

Looking into paper-cards source, there is no way of setting the placeholder image property in the iron-image through the paper-card. I tried adding a placeholderImage property to paper-card which passes it on to the iron-image, still no luck.

Polymer somehow treats an iron-image wrapped in the paper-card different to non-wrapped ones. This also shows in the way the image src link is handled, as for a normal image the relative path is enough, while the wrapped image somehow can't build the proper image URL and therefore needs more parts of the URL, e.g.:

• a non-wrapped iron-image only needs: "img/normal_800.jpg"
• paper-cards image needs: "src/my-app/img/normal_800.jpg"

Aditionally, the property "sizing="cover"" isn't exposed and if set manually in paper-card breaks the whole image, so it displays nothing.

So the either the docs should get updated or the placeholder functionality should be properly implemented. Also, the bug regarding the URL should be addressed, as it can be very frustrating to figure out, why the image isn't showing, as it is hard to debug.

[herbalizer404]

+1 It's impossible to set the sizing of the placeholder to cover for example, so the placeholder is displayed as a background-repeat.