You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 13, 2018. It is now read-only.
Right now we can only "fit" the paper-progress element to the bottom of a core-toolbar. We also need the ability to "fit" a paper-progress element to the top of a core-toolbar. The use case is a progress bar for a fixed footer toolbar that contains transport controls for audio and video, exactly how the google play music app works.
The text was updated successfully, but these errors were encountered:
And yes, this will certainly work for now. I think, though, that in the future it would be nice if this element could support all of it's conceivable use cases by default, to aid in its compositional capability. Pinning a progress bar, or a progress slider for that matter, to the top of a fixed footer seems to me to be a common use case, considering all of the audio/visual components that exist in the wild, not to mention the eventual migration to bottom only controls for overtly large mobile devices ( 5 inches and up) So I kindly suggest considering incorporating these abilities into the element in a future update to the polymer platform :-) But again, thank you for the quick fix.
I assume it's possible to do this with the progress-slider as well then?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Right now we can only "fit" the paper-progress element to the bottom of a core-toolbar. We also need the ability to "fit" a paper-progress element to the top of a core-toolbar. The use case is a progress bar for a fixed footer toolbar that contains transport controls for audio and video, exactly how the google play music app works.
The text was updated successfully, but these errors were encountered: