Set height to 100vh

[robdodson]

I've heard from a number of users that core-header-panel is confusing to use because you have to set it to fill the viewport somehow. Typically that's done by setting the html and body height to 100% and setting core-header-panel to have a height of 100%.

Setting a default of 100vh lets the user get up and running with core-header-panel immediately, the only gotcha is they have to remove margin from the body or it will create double scrollbars. I added a comment to the docs which points them to the fullbleed attribute.

cc @arthurevans

[dwyer]

Thanks, I actually came here to see if this was being discussed. It is indeed confusing. I just started experimenting with core-toolbar and core-header-panel elements as recommended in your awesome I/O talk and to discover after an hour of troubleshooting that such a simple first step required an undocumented CSS hack really killed the magic for me. If it is documented somewhere, I apologize, but I had to compare my code to samples to figure it out.

Are there any more gotchas such as this to be aware of before I dig deeper?

[robdodson]

We've just updated core-toolbar to have a default background color and hopefully we can land this tweak as well. There are still rough spots in our docs that we're trying to clean up based on new user feedback. Apologies for that, we're still in the developer preview phase so our element sets have some more refining to go. If you see things that look wonky please file an issue. In many instances, the team may be accustomed to how an element works and they might not notice something that feels weird.

[dwyer]

No worries. Do you happen to have a mailing list or discussion group for everything under the Polymer/core-elements/paper-elements umbrella? I'd like to contribute if I can, but there's just too many different issue trackers to follow. Thanks.

[robdodson]

We don't have a specific list for the paper or core elements, but polymer-dev https://groups.google.com/forum/#!forum/polymer-dev is where all discussions pretty much go down. We typically prefer that troubleshooting questions be directed to StackOverflow and tagged with 'polymer' so they're easier for others to find. It may be good to consolidate the core and paper element issue trackers into some kind of list so there's a steady stream that folks can follow... we'll have to think about that. If you have any ideas for how we could improve communication please let us know :)

On Sat, Jun 28, 2014 at 3:21 PM, Casey Dwyer notifications@github.com wrote:

No worries. Do you happen to have a mailing list or discussion group for everything under the Polymer/core-elements/paper-elements umbrella? I'd like to contribute if I can, but there's just too many different issue trackers to follow. Thanks.

— Reply to this email directly or view it on GitHub https://github.com/Polymer/core-header-panel/pull/3#issuecomment-47440114 .

[enriquemorenotent]

+1

I just wrote a question about this problem on StackOverflow, because I couldn't understand why it was not working out of the box.

[sjmiles]

Like all of our components, core-header-panel is intended to be arbitrarily composable. Therefore, size and position should be controlled by it's owner.

Setting a height of 100vh would violate this rule. Making that work properly also involves manipulating body styling, which is a scope violation for a basic element.

Having said that, controlling body styling and fitting to a page is appropriate for something like the scaffold elements, which are intended to provide turnkey styling.

There are various elements which by their very nature require the user to provide a size (e.g. list, or most anything that's intended to scroll). I recognize it's troublesome when they start off invisible because of zero height, so I'm inclined to test putting a small min-height on such elements, with the hope that at least the user can see right away that height is the problem.

Fwiw, it would be nice to have the notion of elements that fit to a container by default, but CSS is actively hostile to this concept (iow, the container must participate, as with the body styling requirement above).

[frankiefu]

I agree with sjmiles' comment. Also I think we can provide more scaffold elements to help users to get started.

[enriquemorenotent]

Like all of our components, core-header-panel is intended to be arbitrarily composable. Therefore, size and position should be controlled by it's owner.

The size can still be controlled and modified by the owner. Isn't this more about giving a "default" value, so that it shows something usable?

The way I see it, (visual) web components on it's simple form still should offer something usable.

[robdodson]

Setting a height of 100vh would violate this rule. Making that work properly also involves manipulating body styling, which is a scope violation for a basic element.

At 100vh it fills the screen but has a bit of the browser default margin around it. At that point it's very clear that you just need to pop the margin off of body and things will look right. IMO, that's a better default than an arbitrary min-height that everyone will have to override anyway (and they'll still have to set body to 100%).

My experience from observing and talking to a handful of developers indicates that they all wanted to have core-header-panel fill the page (or in case of <core-drawer-panel>, fill either the drawer or main area).

I think this still leaves the element arbitrarily composable, don't you have to set a height eventually anyway?

FWIW, I created a different branch which sets the default height to 100% and documents how to get the element to fill the screen. I'm not sure if that is any better than 100vh but I think either branch would be an improvement over what we currently have.

[sorvell]

This is the pattern we recommend for this use case. It does push the concern to the user, but this makes the element most flexible.

<body fullbleed vertical layout>
   <core-header-panel flex>
    ...