Rename Variants to be more intuitive

[appreciated]

Match with the names from the material guidelines

• Overlay ~> Modal
• Permanent ~> Responsive
• Dismissable ~> Default

The App-Layout supports by default mobile devices while the examples shown at the material guidelines don't.

[probert94]

@appreciated The current Default more or less mathces the Material Design Modal. It goes over the content and is closed as soon as I click outside. The dissmisible instead should act like a permanent until you manually close it. In the polymer app-layout demo, this is done by setting the forceNarrow when I click the toggle. The difference between the current Overlay and the Default is only the dark backdrop and the fact, that it is not beneath app-header, as the other behaviours. Also, on a mobile most behaviours are pretty much the same, so the same code is used in multiple behaviours.

So I guess it should be possible to reduce the number of behaviours and instead make them configurable. This would make it easier to maintain the plugin and might make it easier for the users too.

Suggestion: Following behaviours could be created:

• LeftBeneath: Left layout with drawer beneath the app-toolbar. Using a property mode it could be configured to be:
  • modal: Open drawer above content, using a dark backdrop. Closes on click outside.
  • permanent: Drawer is permanently opened, side-by-side with the content
  • dissmisible: Drawer is opened, side-by-side with content, but can be closed by calling toggle()
• Left: Same as LeftBeneath except that it is not beneath the app-toolbar
• LeftDouble: Same as Left except, that the app-toolbar is on the side.
• LeftHybrid: Might become some kind of setting for the other behaviours too?
• Top: As is For mobile, all modes could become modal, as soon as responsiveWidth is reached.

[appreciated]

Maybe we could use the component themes to archive this 🤔. While also dropping some wierd solutions as LEFT

Maybe an even bigger simplification: Just two behaviours:

• LEFT
• TOP with two different builders.

Their corresponding themes, which can be combined:

• LEFT
  • modal (+beaneath?)
  • responsive
  • hybrid
  • no-app-bar
  • double
• TOP
  • large

For mobile, all modes could become modal, as soon as responsiveWidth is reached. I disagree in this point, the top behaviours serve a different purpose than the left behaviours and they shouldn't become modal at any width.

[probert94]

I disagree in this point, the top behaviours serve a different purpose than the left behaviours and they shouldn't become modal at any width.

I was just talking about the left-behaviours here, of course the top should not become a left-behaviour on mobile.

Maybe we could use the component themes to archive this 🤔. While also dropping some wierd solutions as LEFT

The problem with this is, that the html-templates are slightly different for some of the behaviours. The beneath for example needs to have the app-toolbar-tag before the app-drawer-layout. But using different builders should probably be possible.

Another solution would be to strictly wrap the components of polymer/app-layout and let the users create the full app-layout out of those wrappers. This would offer full control but would also require a lot more code. But there could still be some ready-to-use variants for users who don't need much customization.

[appreciated]

The problem with this is, that the html-templates are slightly different for some of the behaviours. The beneath for example needs to have the app-toolbar-tag before the app-drawer-layout. But using different builders should probably be possible.

Maybe there is a variant that actually can represent every of the behaviours, but for some it wouldn't be the "minimalist" template.

Another solution would be to strictly wrap the components of polymer/app-layout and let the users create the full app-layout out of those wrappers. This would offer full control but would also require a lot more code. But there could still be some ready-to-use variants for users who don't need much customization.

In my opinion the behaviours are "too far away" from the actual app-layout. I even think doing this without any templates is pretty much impossible, since some styles cannot be applied with the Elements API. Also applying styles on the Java-Side is dirty.