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? - a --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
