On Tue, Sep 22, 2009 at 10:21 AM, Aaron Boodman <[email protected]> wrote: > 2009/9/22 Erik Kay <[email protected]>: >> 2009/9/22 Jói Sigurðsson <[email protected]>: >>>> Positioning >>>> ========= >>>> It seems like the y coordinate for the position is not necessary. I >>>> think we want to control the vertical positioning wrt the toolstrip. >>> >>> I think it's desired to be able to make a drop-down feel like a >>> natural continuation of an element within the toolbar (think >>> combo-buttons) in which case you either need to specify the y >>> coordinate, or have a way to anchor to a specified DOM element. The >>> former is probably easier and more flexible. >> >> I understand where you're coming from here, but this feels a bit >> fragile and hard to use (computing the right x, y position can be >> tricky) for this case. Attached to the DOM element seems like it's >> something that would be less error-prone for the developer. I think >> the x,y case makes sense for context-menu applications where the >> location is easy to figure out (it's just where you clicked), but note >> my other comment to Jeff about having a different API for context >> menus. >> >> One other bit of pushback is that while I like the idea of trying to >> make popups that can feel like they're connected to the UI of an >> element in the toolstrip, I'd like us to start with a simpler >> implementation that intentionally looks a bit more detached (I have >> some mocks I can show you on this front). Once we get this nailed and >> looking good, then we could revisit this. I'm not saying we shouldn't >> do it, just thinking about logical implementation progression. > > Yes, I would prefer that at most we allow the horizontal offset at > first. I'm really concerned to make this look like an integrated, > polished part of Chrome. The more we generalize things like > positioning the less control we have over that. > > I'm also not concerned about making this work at all for the > extension-url-in-tab-scenario, for the same reason. I think this API > should be toolstrip and browser-action specific for the time being. > > === > > Which brings up browser actions. We (chrome-extensions-team) have > discussed wanting similar functionality for browser actions. This > isn't directly related to your proposal, but extensions guys -- my > thinking is that the popup should *not* be programmatic for browser > actions. That is, you should declare (in your manifest) whether you > have a popup URL for a browser action. We take care of showing it on > click. > > My reasoning is that I want consistency. If we leave it to developers > to listen to click and call chrome.popup.show(), they will do it > differently -- in mouseover or on click, or maybe even in the middle > of a session, without interaction. > > I can imagine use cases for that (showing weather when it changes or > whatever), but I think in most cases those uses would be annoying. > Anyway if we start conservatively, we can always expand. > > Thoughts?
For browser actions, given that it's not HTML up there, I don't think there will be much opportunity for them to do it other than via the declarative mechanism, so I think this sounds right. Yes, they could use it to post notifications via the background page or some such, but as you say, I think it's better to start without that option. Erik --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en -~----------~----~----~----~------~----~------~--~---
