Re: [whatwg] Proposal: target=_tab
Hi João, you're right that everything important has been already said. I have withdrawn this proposal because it has been pointed out that it is not backwards compatible and the correct solution will be part of CSS3 anyway (which is much more flexible - we will have not only target-new, but also target-position; I guess you strongly dislike both of them). But the discussion has been interesting anyway. There is probably no point in carrying on because we see the problem from two different standpoints - you want to have the specs as pure as possible while I want them to be as flexible as possible so that it can accommodate any use case you can think of. I kind of understand why simpler standards are better than the longer ones but on the other hand, the lack of _tab or something similar makes my user experience on some websites suboptimal (heck, even frustrating sometimes). If you can't appreciate that different users can have different user preferences (I can't honestly come up with a single reason why a webpage should open a new window instead of tab), you will probably have hard times understanding my points. But your view is quite common as I've learned :) Regards, Borek - Original Message From: João Eiras [EMAIL PROTECTED] To: Borek Bernard [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Thursday, 12 June, 2008 7:17:19 PM Subject: Re: [whatwg] Proposal: target=_tab Hi ! I didn't saw that reply. I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. You're not understanding me: when I say browser, obviously I mean client, client-side, browser, user or whatever you want to call it, as opposed to web application or server-side Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it. Then we're going to bloat a specification due to browser idiosyncrasies ? Allowing a page to control such behavior would be bad. Currently browsers with tabbed interface manage to unclutter the taskbar and desktop, while aggregate pages inside a single window, which is overall good for the user's experience, good for performance, good usability. We'd be providing a mechanism that is not backwards compatible with the current state of the art user agents, although we've seen that new features heavily demanded get implemented quickly, and we'd be providing, again, authors with mechanism to degrade the user's experience. I can't honestly come up with a single reason why a webpage should open a new window instead of tab. All use cases you can come up fit better if new tabs are open. If you don't like the fact that a tab fits the entire window, you can either detach it, your use a user agent that support MDI interface. With all this say now your going to tell me I'm contradicting myself by supporting windows now. No, you'd be wrong. I'd expect a browser to always open tabs if there's a _blank target. Having _target and_tab would require UA's to support two different way of opening new pages: tabbed and detached ones. For me it's all a matter of letting the user control the web page. Considering this discussion is still going to last a bit, and everything significant that could be said by me and others was said, I rest my case. Cheers. 2008/6/12 Kristof Zelechovski [EMAIL PROTECTED]: Programmatically controlling the containment of a new window is a two-edged sword: you can provide for the lame user agent but you can also override user settings. The latter possibility is more painful; upgrading the browser is easier than dealing with an impertinent Web site. IMHO, Chris P.S.: If you want your answer to go to João only, just send it exclusively to him. -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:25 AM To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi João, I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. Please read all my arguments before, it's not true that a user using a tabbed browser always prefers opening new tabs instead of new windows. That's just your user preference. Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it. __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Re: [whatwg] Proposal: target=_tab
2008/6/13 Borek Bernard [EMAIL PROTECTED]: Hi João, you're right that everything important has been already said. I have withdrawn this proposal because it has been pointed out that it is not backwards compatible and the correct solution will be part of CSS3 anyway (which is much more flexible - we will have not only target-new, but also target-position; I guess you strongly dislike both of them). What's lovely about css, is that features like this can be easily disabled with local stylesheet. Overriding _tab would requiring running local script, which greater performance impact, and migh thave unforseen consequences. So css gives greater control, with less effort. But the discussion has been interesting anyway. There is probably no point in carrying on because we see the problem from two different standpoints - you want to have the specs as pure as possible while I want them to be as flexible as possible so that it can accommodate any use case you can think of. It's not about being pure, it's about not giving more control to the webpage than it should have. For a webpage running in a tab or separate window is exactly the same thing. I kind of understand why simpler standards are better than the longer ones but on the other hand, the lack of _tab or something similar makes my user experience on some websites suboptimal (heck, even frustrating sometimes). If you can't appreciate that different users can have different user preferences (I can't honestly come up with a single reason why a webpage should open a new window instead of tab), This is not a user preference. It's the complete opposite. The spec would allow a user preference to be broken by spaning windows or tabs accordingly to the webpage author's liking. Historically, we've seen that giving webpage control over the user's browser in someway can be abused: alert(), open(), oncontextmenu ... you will probably have hard times understanding my points. But your view is quite common as I've learned :) Regards, Borek - Original Message From: João Eiras [EMAIL PROTECTED] To: Borek Bernard [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Thursday, 12 June, 2008 7:17:19 PM Subject: Re: [whatwg] Proposal: target=_tab Hi ! I didn't saw that reply. I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. You're not understanding me: when I say browser, obviously I mean client, client-side, browser, user or whatever you want to call it, as opposed to web application or server-side Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it. Then we're going to bloat a specification due to browser idiosyncrasies ? Allowing a page to control such behavior would be bad. Currently browsers with tabbed interface manage to unclutter the taskbar and desktop, while aggregate pages inside a single window, which is overall good for the user's experience, good for performance, good usability. We'd be providing a mechanism that is not backwards compatible with the current state of the art user agents, although we've seen that new features heavily demanded get implemented quickly, and we'd be providing, again, authors with mechanism to degrade the user's experience. I can't honestly come up with a single reason why a webpage should open a new window instead of tab. All use cases you can come up fit better if new tabs are open. If you don't like the fact that a tab fits the entire window, you can either detach it, your use a user agent that support MDI interface. With all this say now your going to tell me I'm contradicting myself by supporting windows now. No, you'd be wrong. I'd expect a browser to always open tabs if there's a _blank target. Having _target and_tab would require UA's to support two different way of opening new pages: tabbed and detached ones. For me it's all a matter of letting the user control the web page. Considering this discussion is still going to last a bit, and everything significant that could be said by me and others was said, I rest my case. Cheers. 2008/6/12 Kristof Zelechovski [EMAIL PROTECTED]: Programmatically controlling the containment of a new window is a two-edged sword: you can provide for the lame user agent but you can also override user settings. The latter possibility is more painful; upgrading the browser is easier than dealing with an impertinent Web site. IMHO, Chris P.S.: If you want your answer to go to João only, just send it exclusively to him. -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:25 AM To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi João, I'm not sure why you keep insisting that it's up
Re: [whatwg] Proposal: target=_tab
I've been following this discussion for a while and I agree a new '_tab' target is not necessary. To my mind _blank implies a new browser canvas. There are two implementations for creating a new canvas these days; a new window, or a new tab. The key question is: what does _blank mean? Does it only mean 'a new window'? Or does it mean 'a new canvas'? To my mind it means the latter. I don't see why HTML should bother with user experience (new tab, or new window). This has more to do with style sheets (also this is arguably to my mind). -jorgen On Jun 13, 2008, at 10:03 AM, João Eiras wrote: 2008/6/13 Borek Bernard [EMAIL PROTECTED]: Hi João, you're right that everything important has been already said. I have withdrawn this proposal because it has been pointed out that it is not backwards compatible and the correct solution will be part of CSS3 anyway (which is much more flexible - we will have not only target-new, but also target-position; I guess you strongly dislike both of them). What's lovely about css, is that features like this can be easily disabled with local stylesheet. Overriding _tab would requiring running local script, which greater performance impact, and migh thave unforseen consequences. So css gives greater control, with less effort. But the discussion has been interesting anyway. There is probably no point in carrying on because we see the problem from two different standpoints - you want to have the specs as pure as possible while I want them to be as flexible as possible so that it can accommodate any use case you can think of. It's not about being pure, it's about not giving more control to the webpage than it should have. For a webpage running in a tab or separate window is exactly the same thing. I kind of understand why simpler standards are better than the longer ones but on the other hand, the lack of _tab or something similar makes my user experience on some websites suboptimal (heck, even frustrating sometimes). If you can't appreciate that different users can have different user preferences (I can't honestly come up with a single reason why a webpage should open a new window instead of tab), This is not a user preference. It's the complete opposite. The spec would allow a user preference to be broken by spaning windows or tabs accordingly to the webpage author's liking. Historically, we've seen that giving webpage control over the user's browser in someway can be abused: alert(), open(), oncontextmenu ... you will probably have hard times understanding my points. But your view is quite common as I've learned :) Regards, Borek - Original Message From: João Eiras [EMAIL PROTECTED] To: Borek Bernard [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Thursday, 12 June, 2008 7:17:19 PM Subject: Re: [whatwg] Proposal: target=_tab Hi ! I didn't saw that reply. I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. You're not understanding me: when I say browser, obviously I mean client, client-side, browser, user or whatever you want to call it, as opposed to web application or server-side Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it. Then we're going to bloat a specification due to browser idiosyncrasies ? Allowing a page to control such behavior would be bad. Currently browsers with tabbed interface manage to unclutter the taskbar and desktop, while aggregate pages inside a single window, which is overall good for the user's experience, good for performance, good usability. We'd be providing a mechanism that is not backwards compatible with the current state of the art user agents, although we've seen that new features heavily demanded get implemented quickly, and we'd be providing, again, authors with mechanism to degrade the user's experience. I can't honestly come up with a single reason why a webpage should open a new window instead of tab. All use cases you can come up fit better if new tabs are open. If you don't like the fact that a tab fits the entire window, you can either detach it, your use a user agent that support MDI interface. With all this say now your going to tell me I'm contradicting myself by supporting windows now. No, you'd be wrong. I'd expect a browser to always open tabs if there's a _blank target. Having _target and_tab would require UA's to support two different way of opening new pages: tabbed and detached ones. For me it's all a matter of letting the user control the web page. Considering this discussion is still going to last a bit, and everything significant that could be said by me and others was said, I rest my case. Cheers. 2008/6/12 Kristof Zelechovski [EMAIL PROTECTED]: Programmatically controlling the containment of a new window is a two-edged sword: you can
Re: [whatwg] Proposal: target=_tab
Hi João, I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. Please read all my arguments before, it's not true that a user using a tabbed browser always prefers opening new tabs instead of new windows. That's just your user preference. Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it. I will happily discuss specific issues that you have with this but please, I think we have seen enough generic statements in this thread. Regards, Borek - Original Message From: João Eiras [EMAIL PROTECTED] To: Kristof Zelechovski [EMAIL PROTECTED]; Borek Bernard [EMAIL PROTECTED]; Ian Hickson [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Wednesday, 11 June, 2008 9:15:47 PM Subject: Re: [whatwg] Proposal: target=_tab As mentioned multiple times, that up to the user agent, or browser if you prefer, to control. Users with browsers with tabbed interface want tabs and that it. Leaving such usability in control of a webpage is bad. All browser that support tabs allow the user to choose if they want the browser to open new windows of just tabs. Na , Kristof Zelechovski [EMAIL PROTECTED] escreveu: You can use A.click instead of window.open. I have ignored the keyboard shortcut requirement because it is irrelevant. I agree that modifying window.open to support tabs would be more consistent; I just wanted to make you realize that neither is it strictly necessary nor does it require any support from JS itself (your postulated modification of the window.open interface method is perfectly suited for the current JS language, I hope?). HTH, Chris -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:27 AM To: Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Re: [whatwg] Proposal: target=_tab
Programmatically controlling the containment of a new window is a two-edged sword: you can provide for the lame user agent but you can also override user settings. The latter possibility is more painful; upgrading the browser is easier than dealing with an impertinent Web site. IMHO, Chris P.S.: If you want your answer to go to João only, just send it exclusively to him. -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:25 AM To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi João, I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. Please read all my arguments before, it's not true that a user using a tabbed browser always prefers opening new tabs instead of new windows. That's just your user preference. Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it.
Re: [whatwg] Proposal: target=_tab
Hi ! I didn't saw that reply. I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. You're not understanding me: when I say browser, obviously I mean client, client-side, browser, user or whatever you want to call it, as opposed to web application or server-side Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it. Then we're going to bloat a specification due to browser idiosyncrasies ? Allowing a page to control such behavior would be bad. Currently browsers with tabbed interface manage to unclutter the taskbar and desktop, while aggregate pages inside a single window, which is overall good for the user's experience, good for performance, good usability. We'd be providing a mechanism that is not backwards compatible with the current state of the art user agents, although we've seen that new features heavily demanded get implemented quickly, and we'd be providing, again, authors with mechanism to degrade the user's experience. I can't honestly come up with a single reason why a webpage should open a new window instead of tab. All use cases you can come up fit better if new tabs are open. If you don't like the fact that a tab fits the entire window, you can either detach it, your use a user agent that support MDI interface. With all this say now your going to tell me I'm contradicting myself by supporting windows now. No, you'd be wrong. I'd expect a browser to always open tabs if there's a _blank target. Having _target and_tab would require UA's to support two different way of opening new pages: tabbed and detached ones. For me it's all a matter of letting the user control the web page. Considering this discussion is still going to last a bit, and everything significant that could be said by me and others was said, I rest my case. Cheers. 2008/6/12 Kristof Zelechovski [EMAIL PROTECTED]: Programmatically controlling the containment of a new window is a two-edged sword: you can provide for the lame user agent but you can also override user settings. The latter possibility is more painful; upgrading the browser is easier than dealing with an impertinent Web site. IMHO, Chris P.S.: If you want your answer to go to João only, just send it exclusively to him. -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:25 AM To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi João, I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. Please read all my arguments before, it's not true that a user using a tabbed browser always prefers opening new tabs instead of new windows. That's just your user preference. Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it.
Re: [whatwg] Proposal: target=_tab
Hi Adrian, That is actually a very good point, I missed that. In fact, it means that _tab should not be part of HTML spec because it would possibly make things even worse than they currently are (opening GReader links in new _tabs in old browsers would lead to losing the opened articles) . I still believe that there should be a way to instruct the browser to open a new tab and the before mentioned CSS3 target-new is probably the best way (if not only one) to go. Thanks, Borek - Original Message From: Adrian Sutton [EMAIL PROTECTED] To: whatwg@lists.whatwg.org Sent: Tuesday, 10 June, 2008 10:29:54 PM Subject: Re: [whatwg] Proposal: target=_tab From my brief testing, _tab opens a new window so it should be backwards compatible. It's deceptively close but not quite backwards compatible. _tab will cause the link to open in the frame called _tab and if it doesn't exist it creates it, as a new window. So the first link works perfectly and opens a new window but the second link you click will replace the first one since there is now a frame called _tab. Regards, Adrian Sutton. __ Adrian Sutton, CTO US: +1 (650) 292 9659 x717 UK: +44 (20) 8123 0617 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/ __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Re: [whatwg] Proposal: target=_tab
Once you have support in CSS, you can use DOM+CSS from JS. No particular support within JS is required. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Borek Bernard Sent: Wednesday, June 11, 2008 10:37 AM To: Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Ian, What do you think about the GReader use case? In my eyes, it makes the _tab scenario quite valid. But, as mentioned by Adrian Sutton, there would be technical problems with older browsers so this proposal has to be scrapped. On the HTML/CSS level, this will be eventually handled by the 'target-new' property (which will be more flexible than target=_tab as well) and I hope it will find its way into JavaScript too, eventually. P.S. Sorry for not maintaining the thread sequence correctly, I couldn't figure out how to do that (that's why I used the forum instead of the mailing list in the first place :) --- Borek
Re: [whatwg] Proposal: target=_tab
In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. In general, it's best to let users decide where the link should open. Absolutely agreed. What is interesting though is that authors can let open new windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this functionality, that may ultimately impede user experience, can really be considered structural, presentational, /and/ behavioral. -- Jens Meiert http://meiert.com/en/
Re: [whatwg] Proposal: target=_tab
Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek - Original Message From: Kristof Zelechovski [EMAIL PROTECTED] To: Borek Bernard [EMAIL PROTECTED]; Ian Hickson [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Wednesday, 11 June, 2008 10:42:41 AM Subject: Re: [whatwg] Proposal: target=_tab Once you have support in CSS, you can use DOM+CSS from JS. No particular support within JS is required. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Borek Bernard Sent: Wednesday, June 11, 2008 10:37 AM To: Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Ian, What do you think about the GReader use case? In my eyes, it makes the _tab scenario quite valid. But, as mentioned by Adrian Sutton, there would be technical problems with older browsers so this proposal has to be scrapped. On the HTML/CSS level, this will be eventually handled by the 'target-new' property (which will be more flexible than target=_tab as well) and I hope it will find its way into JavaScript too, eventually. P.S. Sorry for not maintaining the thread sequence correctly, I couldn't figure out how to do that (that's why I used the forum instead of the mailing list in the first place :) --- Borek __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Re: [whatwg] Proposal: target=_tab
On Wed, 11 Jun 2008, Jens Meiert wrote: In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. In general, it's best to let users decide where the link should open. Absolutely agreed. What is interesting though is that authors can let open new windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this functionality, that may ultimately impede user experience, can really be considered structural, presentational, /and/ behavioral. I have no idea what you mean or how it affects the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: target=_tab
What is interesting though is that authors can let open new windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this functionality, that may ultimately impede user experience, can really be considered structural, presentational, /and/ behavioral. I have no idea what you mean or how it affects the spec. And you don't have to as it was just a side note. HTML 5 won't resolve this anyway. -- Jens Meiert http://meiert.com/en/
Re: [whatwg] Proposal: target=_tab
On Wed, 11 Jun 2008, Jens Meiert wrote: What is interesting though is that authors can let open new windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this functionality, that may ultimately impede user experience, can really be considered structural, presentational, /and/ behavioral. I have no idea what you mean or how it affects the spec. And you don't have to as it was just a side note. HTML 5 won't resolve this anyway. Ah. Ok then. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: target=_tab
You can use A.click instead of window.open. I have ignored the keyboard shortcut requirement because it is irrelevant. I agree that modifying window.open to support tabs would be more consistent; I just wanted to make you realize that neither is it strictly necessary nor does it require any support from JS itself (your postulated modification of the window.open interface method is perfectly suited for the current JS language, I hope?). HTH, Chris -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:27 AM To: Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek
Re: [whatwg] Proposal: target=_tab
As mentioned multiple times, that up to the user agent, or browser if you prefer, to control. Users with browsers with tabbed interface want tabs and that it. Leaving such usability in control of a webpage is bad. All browser that support tabs allow the user to choose if they want the browser to open new windows of just tabs. Na , Kristof Zelechovski [EMAIL PROTECTED] escreveu: You can use A.click instead of window.open. I have ignored the keyboard shortcut requirement because it is irrelevant. I agree that modifying window.open to support tabs would be more consistent; I just wanted to make you realize that neither is it strictly necessary nor does it require any support from JS itself (your postulated modification of the window.open interface method is perfectly suited for the current JS language, I hope?). HTH, Chris -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:27 AM To: Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek
Re: [whatwg] Proposal: target=_tab
For the record: I do not advocate the original recommendation; I only hypothesized about what can be achieved with CSS instead. I never recommended actually doing it. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joao Eiras Sent: Wednesday, June 11, 2008 9:16 PM To: Kristof Zelechovski; 'Borek Bernard'; 'Ian Hickson'; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab As mentioned multiple times, that up to the user agent, or browser if you prefer, to control. Users with browsers with tabbed interface want tabs and that it. Leaving such usability in control of a webpage is bad. All browser that support tabs allow the user to choose if they want the browser to open new windows of just tabs. Na , Kristof Zelechovski [EMAIL PROTECTED] escreveu: You can use A.click instead of window.open. I have ignored the keyboard shortcut requirement because it is irrelevant. I agree that modifying window.open to support tabs would be more consistent; I just wanted to make you realize that neither is it strictly necessary nor does it require any support from JS itself (your postulated modification of the window.open interface method is perfectly suited for the current JS language, I hope?). HTH, Chris -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:27 AM To: Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek
Re: [whatwg] Proposal: target=_tab
In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. Wondering: How is CSS 3's Hyperlink Presentation Module [1] (and its target-new property) supposed to fit in, /theoretically/ allowing us to drop @target altogether? [1] http://www.w3.org/TR/css3-hyperlinks/ -- Jens Meiert http://meiert.com/en/
Re: [whatwg] Proposal: target=_tab
IMO, both _blank and _tab should always open in the same window, under a new tab. Else that would be bad usability. Browsers currently already support this. So, I think it's therefore redundant. Na , Simon Pieters [EMAIL PROTECTED] escreveu: In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. Use case for opening a new window with specified size: help popup. Use case for opening a new window without specified size: print page. Use case for opening a new tab: links in GReader for later reading. Demand for this feature: http://www.google.com/search?q=_tab
Re: [whatwg] Proposal: target=_tab
Simon Pieters wrote: In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. I don't believe it should be up to the document author to distinguish between a page opened up in a new window or new tab, since that is entirely a browser interface issue. Since several browsers already treat _blank in that way anyway, introducing a new keyword doesn't seem particularly useful. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Proposal: target=_tab
Wondering: How is CSS 3's Hyperlink Presentation Module [1] (and its target-new property) supposed to fit in, /theoretically/ allowing us to drop @target altogether? That looks great (didn't know of that!), that would sort out the HTML/CSS part of game (although implementing target=_tab would be probably easier for browser vendors than implementing CSS3). We would still need something equivalent in JavaScript though -- but I'm not sure how that is related to WHATWG. Borek __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Re: [whatwg] Proposal: target=_tab
From my brief testing, _tab opens a new window so it should be backwards compatible. - Original Message From: João Eiras [EMAIL PROTECTED] To: Borek Bernard [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Tuesday, 10 June, 2008 6:03:51 PM Subject: Re: [whatwg] Proposal: target=_tab This approach however has two problems: - user agent that don't support _tab which would have to interpret as _blank, or _self, so this case need to be predicted in the spec, if any - that value is not backwards compatible. I'd expect for an user agent that does not support tabs to open a new window, but a unknwon target opens in the same window, so you'll probably will have to make up something different. Na , Borek Bernard [EMAIL PROTECTED] escreveu: IMO, both _blank and _tab should always open in the same window, under a new tab. ... Browsers currently already support this. So, I think it's therefore redundant. As you stated, that is your user preference and my preference can be different. You are lucky that your preference fits in current browsers' feature set, I have argued in the forum post linked before [1] that I don't think it's reasonable to expect the required level of browser customizeability any time soon. [1] http://forums.whatwg.org/viewtopic.php?t=186 --- Borek __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Re: [whatwg] Proposal: target=_tab
From my brief testing, _tab opens a new window so it should be backwards compatible. It's deceptively close but not quite backwards compatible. _tab will cause the link to open in the frame called _tab and if it doesn't exist it creates it, as a new window. So the first link works perfectly and opens a new window but the second link you click will replace the first one since there is now a frame called _tab. Regards, Adrian Sutton. __ Adrian Sutton, CTO US: +1 (650) 292 9659 x717 UK: +44 (20) 8123 0617 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Proposal: target=_tab
On Tue, 10 Jun 2008, Simon Pieters wrote: In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. Use case for opening a new window with specified size: help popup. Use case for opening a new window without specified size: print page. Use case for opening a new tab: links in GReader for later reading. Demand for this feature: http://www.google.com/search?q=_tab In general, it's best to let users decide where the link should open. In cases where the author really wants to open a new top-level browsing context, _blank already provides that option. Help popups are probably better done using inline floating iframes inside aside. Browsers having tabs, windows, or any number of other UI constructs should not be an issue that Web authors need to deal with. Thus, I don't think _tab makes much sense. [snip a number of arguments much like the above] -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
