[whatwg] Proposal: target=_reference
Summary: I propose target=_reference, which would open a link in a secondary viewport, for example a closable pane at the bottom of a browser window. This would be much less annoying and intimidating than target=_blank. It could be used immediately for providing help, and for linking to privacy policies, terms of use, etc within forms. Eventually it could also be used for footnotes and endnotes. On Apr 21, 2008, at 6:21 AM, Ian Hickson wrote: ... On Sat, 28 Apr 2007, Lachlan Hunt wrote: ... * Opening help windows. e.g. for help with forms. - There are much more user friendly ways of offering help to users without popups. ... I agree with your comments. ... I've changed the spec to make _blank legal but to also encourage browsers to not create a new window when one is requested. I've just come across this problem myself when designing a Web site's help system. For a vanilla form -- a vertical series of labelled text fields, checkboxes, and so on -- there are indeed friendlier ways of offering help than in a popup window. For example, a (What's this?) link next to a control might make visible a section under the control containing extra help, without obscuring the rest of the form. That is what we planned initially. But in a page that's less like a form and more like an application, there often isn't room to do this. The example that defeated our expanding-section plan was needing to explain the eight possible choices for a select menu, where the menu was the sole contents of each cell in a table column. The help link for that belonged in the column's header cell, but then where should the help itself appear? Not enough room in the header cell, or anywhere else in the table itself. And displaying it below the table risked it being off-screen and not seen, if the table was tall enough. There's a similar problem with help links that appear in any small sidebar or other narrow area. So our current plan is to use a Facebook-style fake popup window, a box that floats above the rest of the page content and is dismissed with an OK button. This has two important advantages over target=_blank: * If you close or navigate away from the page, the help doesn't need to be closed separately. * If you switch to a different window or tab, the help isn't flopping around unneeded. But it also has three disadvantages compared with target=_blank: * It's impossible to arrange the application and the help side by side, such that they don't obscure each other. * Whatever interface we provide for closing the help window, it's inconsistent with someone's platform conventions, and inconsistent with other Web sites that do something similar. * It's literally thousands of times harder to implement. What would an interface look like that avoided these disadvantages? It would disappear whenever the page was closed, navigated away from, or switched away from. It wouldn't obscure the page content. It would be consistent with platform conventions. And it would be just as easy for authors to implement as target=_blank is. The obvious solution, for large-screen browsers, is a pane that appears at the bottom of the browser window -- like the docked palettes in some drawing programs, or the Firebug add-on in Firefox. This pane would disappear along with the rest of the page as soon as you went to a new page. The browser would be in charge of giving it a Close button that matches OS conventions. And a browser might also (but wouldn't need to) let you drag it from the bottom to the side of the window, or even undock it into its own floating window (though this should still disappear when you closed the main page or navigated to another page). For small-screen browsers, such as those in phones, it would be a separate screen that -- unlike target=_blank -- had a browser-supplied OK button, and when closed always returned you to the screen whence it was opened, preferably in exactly the state it was in when you left it. To support this, I propose target=_reference, referring to a secondary viewport that is strongly associated with the primary viewport from which it is opened. A browser must provide an obvious mechanism for closing this secondary viewport separately from the primary one; for the author to do so should be non-conformant. And if the primary viewport is closed, or navigates to a new resource (not just a separate fragment of the same resource), the secondary viewport should close automatically. Only one secondary viewport should be available per primary viewport: within the secondary viewport, target=_reference should refer to the same viewport, not to a new one. Web application developers could start using target=_reference immediately for providing help, since the way current browsers treat it -- opening a separate window -- would be an acceptable fallback. (If developers didn't consider it acceptable fallback, they could
Re: [whatwg] postMessage feedback
(sigh, messed up sender address so the original got rejected from the whatwg list, apologies for the duplicate message...) Ian Hickson wrote: I haven't changed the target of the event, it's still the Document object. This is a little odd, though, would people rather I made it the body element with an auto-forward to the Window object, like the 'load' event and so forth? That would allow onmessage= handles to be written. I've mentioned this on IRC but should probably mention it here so it's in the record, so to speak. I don't see a strong use case for an onmessage attribute. Event handler attributes are useful for quick little things, but accepting messages from other sites seems neither quick (aside from free-for-all walls I can't think of things you'd want to do that wouldn't be fairly involved) nor little (you need the origin check at a minimum, then you have to do whatever you're going to do, and it's a lot to stuff in an attribute -- and if you're just delegating to another method, why not just set the method as handler programmatically?). I don't think having to do it via script is particularly burdensome. Jeff
Re: [whatwg] postMessage feedback
On Apr 26, 2008, at 10:00 AM, Jeff Walden wrote: Ian Hickson wrote: I haven't changed the target of the event, it's still the Document object. This is a little odd, though, would people rather I made it the body element with an auto-forward to the Window object, like the 'load' event and so forth? That would allow onmessage= handles to be written. I've mentioned this on IRC but should probably mention it here so it's in the record, so to speak. I don't see a strong use case for an onmessage attribute. Event handler attributes are useful for quick little things, but accepting messages from other sites seems neither quick (aside from free-for-all walls I can't think of things you'd want to do that wouldn't be fairly involved) nor little (you need the origin check at a minimum, then you have to do whatever you're going to do, and it's a lot to stuff in an attribute -- and if you're just delegating to another method, why not just set the method as handler programmatically?). I don't think having to do it via script is particularly burdensome. If anything this event should dispatch to the window, not the document, since that is what gets the postMessage call. But posting to the document and bubbling to the window seems ok too. Regards, Maciej
Re: [whatwg] postMessage feedback
Maciej Stachowiak wrote: If anything this event should dispatch to the window, not the document, since that is what gets the postMessage call. But posting to the document and bubbling to the window seems ok too. The event currently doesn't bubble to accommodate event-source: http://lists.whatwg.org/htdig.cgi/commit-watchers-whatwg.org/2008/000436.html So right now, either you use a bubbling listener (capturing works too, although the web may end up dictating that that's a bug that won't be fixt) on the document or a capturing listener (ugh) on window or you don't get it. I'm not entirely sure why the event doesn't bubble for postMessage; it seems like a postMessage event doesn't necessarily have to do the same thing as an event-source event, but maybe there's precedent here that I don't know. As far as I can tell the event is dispatched at the document only because Opera's original implementation had postMessage on document. I sort of prefer dispatching to the window as well, but that change would have to be made ASAP to make Firefox 3. It's a one-line change (+30ish for addEventListener calls in tests, also easy to do), as is the bubbling change, but it's extraordinarily late for us to make these changes (async cuts it very, very fine as-is), and nobody would be happy if the spec converged on something that Firefox 3 didn't actually implement. Jeff -- Life would be so much easier if humans had a natural affinity for remembering 128-bit integers.
Re: [whatwg] postMessage feedback
On Apr 26, 2008, at 3:07 PM, Jeff Walden wrote: Maciej Stachowiak wrote: If anything this event should dispatch to the window, not the document, since that is what gets the postMessage call. But posting to the document and bubbling to the window seems ok too. The event currently doesn't bubble to accommodate event-source: http://lists.whatwg.org/htdig.cgi/commit-watchers-whatwg.org/2008/000436.html So right now, either you use a bubbling listener (capturing works too, although the web may end up dictating that that's a bug that won't be fixt) on the document or a capturing listener (ugh) on window or you don't get it. I'm not entirely sure why the event doesn't bubble for postMessage; it seems like a postMessage event doesn't necessarily have to do the same thing as an event-source event, but maybe there's precedent here that I don't know. As far as I can tell the event is dispatched at the document only because Opera's original implementation had postMessage on document. I sort of prefer dispatching to the window as well, but that change would have to be made ASAP to make Firefox 3. It's a one-line change (+30ish for addEventListener calls in tests, also easy to do), as is the bubbling change, but it's extraordinarily late for us to make these changes (async cuts it very, very fine as- is), and nobody would be happy if the spec converged on something that Firefox 3 didn't actually implement. I hope this can be addressed soon, and I feel your pain. But in Safari 3.1 we actually dropped postMessage at the last minute because of too many spec changes, and the spec changed in major ways after Opera actually shipped their implementation, so it's not like changes here are unprecedented and certainly Firefox is not being singled out. (On the substance, I think dispatching to the window would be better based on your comments.) Cheers, Maciej
