In the comments so far, there seems to be some confusion on what this is. The Chrome Sidebar API is an API for Chrome extensions, adding a sidebar surface to Chrome.
The proposed API allows Chrome extensions to access and control a sidebar panel - a per-tab split-pane HTML container to the right (to the left in RTL environment) of the main page content with the ability to resize horizontally.[1]
In short, it provides extensions an alternative to using popups or injecting HTML directly into web pages in order to display something to the user.
With it, you could for instance (re-)implement something like the old Side Tabs feature, which was removed from Chrome because the complexity of a tree-style interface in terms of usage is beyond what most users need or want, and in terms of implementation is more than passes the cost/benefit test for building into Chrome natively as an option.[2]
We had a sidebar extension on Chrome called Teamgum[1]. But it was removed from store last month because we were using remote iframes. And when we asked for more explanation nothing from their end. And now I see they are developing there own sidebar.
If successful, it will be interesting to see how Chrome evolves for developers to compete.
(I was reminded of this because the Firefox sidebar was always wildly popular - I know lots of people that continue to use it specifically for that purpose)
I use Firefox by default with an add-on 'Vertical Tabs'. This moves all tabs away from the top into a narrow sidebar.
Screens are more wide then tall and for me my vertical space is more valuable. Every line that holds only static info (address bar, open tabs) is not strictly needed at all times, so I want them either to popup (like the menu bar in full screen view) or at least move to the sides ('cheaper' space).
I am somewhat surprised this is not more common opinion.
I use Tree Style Tabs as well. As you said, vertical space is a premium.
Back in the day (and perhaps still), there were user chrome tweaks you could make to hide the address bar until you hover over it.
I am currently experimenting with 'Toolbar Autohide' (Firefox). It also hides the address bar and other tools. Meaning I now have the complete vertical screen space available for website content.
Vertical space is not really at a premium when it comes to viewing static documents under access to a scroll wheel.
Why does the developer console open on the bottom, constraining your vertical space? Because there is such a dearth of horizontal space that that it would be uncomfortable to do otherwise. The reason things keep eating up vertical space is because that's the only space that's not at a premium.
For me, vertical space IS at a premium. Especially when browsing the web. How many web pages do you see utilizing the full width of the monitor? Very few, which is also the reason I choose to dock my developer console to the right instead of the bottom. This also doubles as an easy way to resize the viewport when testing responsive design/media queries without resizing the entire window.
Most monitors are 16:9 with the 16 being the horizontal dimension. It's also difficult to read very long lines of text, so my browser windows tend to be narrow and tall. When I use the developer console, I pop it out into another window and put it next to the original window.
> Most monitors are 16:9 because horizontal space is more important than vertical.
Most monitors are 16:9 because that aspect ratio fits certain popular entertainment media content that people consume, and a significant usage of general purpose computers is consuming that content (and, also, a significant use outside of general purpose computers of displays is for consuming that content, which effects the economics of producing panels.)
That doesn't necessarily reflect the relative value of horizontal vs. vertical space in other applications.
With a 1080p display, my windows only use half the screen, and I hardly ever feel that it's too narrow. What pages are you browsing that benefit from being wide?
That's the exact logic that MS had when they added the sidebar to Vista. It sounds good, but for some reason no one ended up actually interested in using it.
From my point of view, the OS is a completely different thing then the browser. Because an OS is not specifically vertically oriented, where websites (for 99% ?) are. Therefore I do not like some kind of default sidebar in my OS.
I remember using a Vista machine for a short while and immediately looking for a way to disable it (also because it kept asking for widgets to put in there, if I am not mistaken; but that is besides the point).
It's that whole 80/20 thing. Most features of products go unused. So Chrome has finally reached a level of maturity where it can concentrate on rarely used features.
> It's funny to see they're going to release one now that nobody cares about it.
But that's because up until now we couldn't care about it anyway if Chrome didn't support it. Sidebars can easily make a comeback if the functionality proves to be useful, and I can picture many extension developers experimenting with it if it's made available.
Additionally, we’ve seen numerous extensions create sidebars by injecting HTML content into the current page. It is likely that the majority of sidebar extensions would use a native sidebar if available. Here’s a sample of some of our favorite sidebar extensions...
Some of these tools charge over $5,000/yr/seat and have hundreds of large corporations like Facebook, eBay, Salesforce, Pinterest, Twitter, and Netflix using their software, which demonstrates the immense value that can be provided by a sidebar.
Finally! Our customers have been begging us to provide this for years. We build "Employee Engagement" (aka gamification) tools that extend various CRMs. Not all of them support a way to extend the UI but a sidebar would be perfect.
We currently have a free-floating chrome application which looks like a detached sidebar. The problem is our customers want to see it all the time and don't want it to go behind or on top of the browser. As far as I know, there's no good way to "dock" it to the side of a screen and prevent other applications from using that space.
Looks good, now they need a way to hide the existing tabs (and perhaps the addressbar too) and we can move to a nice slick side-tabs extension for Chrome.
Does anyone know how Honey [1] implemented a sidebar like UI in their chrome extension? It seems pretty solid and I wonder how they got around the current limitations against Sidebars in chrome extensions.
I've been working on a graphical command-line for manipulating webpages with natural language queries (https://contextscript.com). So far I've been using a bookmarklet, which has the benefit of working across browsers, but it has a lot of drawbacks too. If I go the browser extension route, this looks like it would be very useful for developing the UI.
I'm currently working on creating a sidebar app similar to Honey's UI [1]. Have you made any progress implementing the sidebar look? It doesn't seem very documented and even Honey seems to do it in a hacky way.
Sorry I haven't used Honey, and the demo video didn't seem to show a sidebar? Also I actually inherited this codebase, but yeah our sidebar looks good. It just injects a container div into the site.
I remember all the fuss that was made about a sidebar in Windows (was it in Vista?) At the end of the day its just a souped up menu in a different position.
If the user installs an extension that delivers ads, then perhaps it is the user's intention to receive ads? Barring some kind of exploit, this won't be something that a website can do to you.
The proposed API allows Chrome extensions to access and control a sidebar panel - a per-tab split-pane HTML container to the right (to the left in RTL environment) of the main page content with the ability to resize horizontally.[1]
In short, it provides extensions an alternative to using popups or injecting HTML directly into web pages in order to display something to the user.
With it, you could for instance (re-)implement something like the old Side Tabs feature, which was removed from Chrome because the complexity of a tree-style interface in terms of usage is beyond what most users need or want, and in terms of implementation is more than passes the cost/benefit test for building into Chrome natively as an option.[2]
[1]: https://docs.google.com/document/d/102hfWTM5cMl-95PyfGcn89YH...
[2]: https://code.google.com/p/chromium/issues/detail?id=344870#c...