Are there plans to start working on this task soon?
I think it might be worth to have a discussion first on what library/framework should be used to implement the MD look-and-feel of bookmarks (as well as any other WebUI pages that will me MD-ified from now on).
Polymer v1 has served this role very well so far (Downloads, History, and soon Settings), but Polymer v2 is almost out, see [1]. Polymer V2 as advertized is a big improvement over V1 based on many lessons that were learned along the way. Also it seems natural that once V2 is out, it will be the main focus, and therefore much more likely to get the necessary support needed from the Polymer team.
So my suggestion is to have this discussion first, before diving into implementation. Thoughts?
[1] https://www.polymer-project.org/1.0/blog/2016-09-09-polymer-2.0
Work on this will commence late November. There should be time to do some preliminary exploration of what it will take to start this project with Polymer 2.0.
After a glance, my concern would be that we'd need some iron or paper elements that haven't been converted, e.g iron-list and iron-pages. Also, any cr-elements that we want to use need to be at least put into hybrid mode and if they have blocked dependencies, then we'd be in a bind as well.
Polymer 2.0 has also been advertised as easy to migrate so I don't think early adoption is entirely necessary. Migrating an existing WebUI would probably lead to a smoother adoption. At the very least, active feature development won't be blocked every time there's a dependency on the Polymer team.
The newer, lighter elements ought to be fine. We have a bunch in cr-elements (paper-listbox, paper-icon-button, paper-menu-button, etc) which we'd probably inherit anyway. There are certainly some elements to avoid, but all in all, the convenience elements are convenient.
For those playing along at home, calamity@ and I are taking over the remaining implementation work on MD Bookmarks. The above bugs more-or-less encompass all the feature work we have on our plates (there's a couple of small things I didn't bother making bugs for).
This bug requires manual review: There is .grd file changes and we are only 42 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid @(ChromeOS), govind@(Desktop)
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Before we approve merge to CL listed at #50, please answer followings:
* Are you planning to disable MD Bookmarks: Disable by default for M61 permanently?
* Also will it be a safe merge?
Yes to both questions. MD Bookmarks will be disabled for M61 permanently (it is currently slated for M62). The CL at #50 is a 1-line fix that disables the new feature and prevents any new code from running, so it is safe to merge.
Thanks!
Any chance the actual bookmark url can be always visible?
It's hidden under a hover in 61, but in the latest canary, you can only find out a bookmark's url by clicking edit?
With the advent of tiny tabs, often urls are more meaningful that page titles
Can we have the 'Order by name' context menu option back? Right-clicking a menu does not display this option.
This is the only thing preventing me from switching to MD bookmarks.
#67: Running it past people.
#68: You can select a folder, and then press the 3-dot menu in the top right of the page to 'Sort by name'.
Actually going to mark this whole bug as fixed since this is enabled by default now. Please file new issues for any other bugs or feature requests.
Comment 1 by dbeam@chromium.org
, Oct 25 2016