Re: [whatwg] Target Attribute Values
On Sat, 05 May 2007 01:48:51 +0200, Sander Tekelenburg [EMAIL PROTECTED] wrote: Unfortunately when the link action is JS we can only say that it will run a script. So it's actually better usability if the site can use target=_blank compared to using window.open(), at least in Safari. Sorry, I know very little of javascript. Are you saying it is technically impossible for a UA to know beforehand what a script will do? This doesn't just apply to JavaScript: http://en.wikipedia.org/wiki/Halting_problem -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Target Attribute Values
Matthew Paul Thomas wrote: For example, forms sporting those By submitting this form you accept our __terms of service__ and __privacy policy__ links I mentioned earlier are quite often sent over HTTPS. These are not cached by mainstream browsers, because the browser vendors have caved to bank Webmasters who threatened to block them if they were too HTTP-compliant. So if such a browser was configured to open those links in the same window, it would necessarily forget everything you'd entered in the form, which would be annoying. I suppose a logical behavior might therefore be for such UAs to open /all/ new links out of a HTTPS form in a new window, target attribute or no target attribute. -- Benjamin Hawkes-Lewis
Re: [whatwg] Target Attribute Values
Sander Tekelenburg wrote: , and encourage UAs to indicate when a link will open in a different top-level browsing context (e.g. by double-underlining instead of single-underlining). FWIW, iCab[*] indicateds such cases by a change of cursor upon hovering over the link. (You get the same cursor when you Cmd-click or Cmd-Shift-click the link, to load it in a new window on purpose.) This way you can keep such UA functionaility in the chrome -- no need to mess with the content's presentation itself. [*] http://icab.de/ Hmm. We'd need to think up a variation of that for when navigating by keyboard or switch rather than mouse. (I can't work out how to tab between anchors in iCab, so I can't see how it handles such cases, if at all. -- Benjamin Hawkes-Lewis
Re: [whatwg] Target Attribute Values
On Apr 29, 2007, at 9:21 AM, Sander Tekelenburg wrote: At 00:36 +1200 UTC, on 2007-04-30, Matthew Paul Thomas wrote: [...] If _blank is allowed, I would prefer the specification to discourage authors from using _blank when another solution is practical (e.g. using a details element in the original page) Yes, having the spec list common (ab)use cases and pointing authors to better options for those would be good. , and encourage UAs to indicate when a link will open in a different top-level browsing context (e.g. by double-underlining instead of single-underlining). FWIW, iCab[*] indicateds such cases by a change of cursor upon hovering over the link. (You get the same cursor when you Cmd-click or Cmd-Shift- click the link, to load it in a new window on purpose.) This way you can keep such UA functionaility in the chrome -- no need to mess with the content's presentation itself. Safari indicates in the status bar hover feedback when a link will open in a new window, new frame or new tab, or if it will download, if we can tell based on target setting and the user's currently depressed modifier keys. Unfortunately when the link action is JS we can only say that it will run a script. So it's actually better usability if the site can use target=_blank compared to using window.open(), at least in Safari. We also let you override opening in a new window via target to open in a new tab instead using the Cmd key, but we don't have a set of modifiers to open in the current tab in the current window. I suppose that might be useful in some cases. We also don't support that for window.open(), though it might be useful in some cases. Regards, Maciej
Re: [whatwg] Target Attribute Values
At 09:10 +0100 UTC, on 2007-05-04, Benjamin Hawkes-Lewis wrote: [...] keyboard or switch rather than mouse. (I can't work out how to tab between anchors in iCab I might be mistaken but I don't think that's currently poissible in iCab. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Target Attribute Values
At 01:32 -0700 UTC, on 2007-05-04, Maciej Stachowiak wrote: On Apr 29, 2007, at 9:21 AM, Sander Tekelenburg wrote: [...] FWIW, iCab[*] indicateds such cases by a change of cursor [...] Safari indicates in the status bar hover feedback when a link will open in a new window, new frame or new tab, or if it will download, if we can tell based on target setting and the user's currently depressed modifier keys. Ah, yes. I forgot. I quite like that behaviour. However, by default the entire Status Bar isn't visible in Safari, so just how many users actually benefit from this is the question ;) Unfortunately when the link action is JS we can only say that it will run a script. So it's actually better usability if the site can use target=_blank compared to using window.open(), at least in Safari. Sorry, I know very little of javascript. Are you saying it is technically impossible for a UA to know beforehand what a script will do? [...] we don't have a set of modifiers to open in the current tab in the current window. I suppose that might be useful in some cases. Definitely. iCab allows that through the contextual menu (Link-Open in This Window). It might be faster if it can also be done with modifier keys. Something along the lines of making Cmd-Opt-click to mean open in same window, no matter what. Assuming that doesn't conflict with existing behaviour, of course. In any case, for Safari especially, it will need to be self-explanatory, as that's its killer-app-aspect. A non-indicated key combo wouldn't be approriate. But an option in the contextial menu, indicating the alternative key combo, probably would be. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Target Attribute Values
On May 4, 2007, at 4:48 PM, Sander Tekelenburg wrote: At 01:32 -0700 UTC, on 2007-05-04, Maciej Stachowiak wrote: Safari indicates in the status bar hover feedback when a link will open in a new window, new frame or new tab, or if it will download, if we can tell based on target setting and the user's currently depressed modifier keys. Ah, yes. I forgot. I quite like that behaviour. However, by default the entire Status Bar isn't visible in Safari, so just how many users actually benefit from this is the question ;) I think the kind of users who would benefit are also likely to know how to find the setting. Unfortunately when the link action is JS we can only say that it will run a script. So it's actually better usability if the site can use target=_blank compared to using window.open(), at least in Safari. Sorry, I know very little of javascript. Are you saying it is technically impossible for a UA to know beforehand what a script will do? Yes. Figuring out what arbitrary code will do without executing it is mathematically proven to be impossible. You can make an approximation for a limited subset of cases, and I suppose if we wanted to we could copy the whole browser scripting environment and simulate execution, but that seems like an extreme solution to the problem. [...] we don't have a set of modifiers to open in the current tab in the current window. I suppose that might be useful in some cases. Definitely. iCab allows that through the contextual menu (Link- Open in This Window). It might be faster if it can also be done with modifier keys. Something along the lines of making Cmd-Opt-click to mean open in same window, no matter what. Assuming that doesn't conflict with existing behaviour, of course. We already have quite a few link click modifiers taken, including Cmd- Opt-click. I'll make a feature suggestion to add something. Regards, Maciej
Re: [whatwg] Target Attribute Values
On May 5, 2007, at 12:45 PM, Maciej Stachowiak wrote: On May 4, 2007, at 4:48 PM, Sander Tekelenburg wrote: At 01:32 -0700 UTC, on 2007-05-04, Maciej Stachowiak wrote: ... [...] we don't have a set of modifiers to open in the current tab in the current window. I suppose that might be useful in some cases. Definitely. iCab allows that through the contextual menu (Link-Open in This Window). It might be faster if it can also be done with modifier keys. ... We already have quite a few link click modifiers taken, including Cmd-Opt-click. I'll make a feature suggestion to add something. ... In Safari, as in Firefox, you can already ensure a link opens in the same window by dragging it and dropping it on the address field. So there are multiple reasonable ways for a UA to implement it, just as there are multiple reasonable ways for a UA to indicate whether a link is specified to open in a new window in the first place. So it is fair for HTML5 to encourage those things, but beyond that, this discussion may be getting a bit off-topic. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Target Attribute Values
On Apr 28, 2007, at 11:37 PM, Smylers wrote: Spartanicus writes: ... Would perhaps a spec conformance requirement that browsers should offer users a config option to opt out of windows being opened via target values be an alternative? ... But _requiring_ user agents to offer opt-outs seems excessive, and possibly beyond the jurisdiction of the spec. It seems likely that user demand will lead mainstream web-browsers to offer options like this anyway, ... Actually they probably wouldn't, because it would break the Web in ways that weren't obviously the result of the option being set. And every option has some people who set it accidentally. For example, forms sporting those By submitting this form you accept our __terms of service__ and __privacy policy__ links I mentioned earlier are quite often sent over HTTPS. These are not cached by mainstream browsers, because the browser vendors have caved to bank Webmasters who threatened to block them if they were too HTTP-compliant. So if such a browser was configured to open those links in the same window, it would necessarily forget everything you'd entered in the form, which would be annoying. but if somebody wanted to produce a web browser that, say, was so minimalist it didn't offer any user preferences at all, surely that's up to the browser manufacturer? There are already many Internet kiosks that provide no user-visible options at all. But then, sometimes they don't offer multiple windows either. ... Surely whether target=_blank or even target=help is treated different from target=top can at best be a hint? Surely it isn't a requirement of HTML that user-agents implement multiple content windows? That may not be appropriate for some environments, perhaps: ... Yeah, it limits the Web to those UAs for which multiple top-level browsing contexts make sense. Breaking the Web vs. limiting access to the Web, ugh. If _blank is allowed, I would prefer the specification to discourage authors from using _blank when another solution is practical (e.g. using a details element in the original page), and encourage UAs to indicate when a link will open in a different top-level browsing context (e.g. by double-underlining instead of single-underlining). -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Target Attribute Values
At 00:36 +1200 UTC, on 2007-04-30, Matthew Paul Thomas wrote: [...] If _blank is allowed, I would prefer the specification to discourage authors from using _blank when another solution is practical (e.g. using a details element in the original page) Yes, having the spec list common (ab)use cases and pointing authors to better options for those would be good. , and encourage UAs to indicate when a link will open in a different top-level browsing context (e.g. by double-underlining instead of single-underlining). FWIW, iCab[*] indicateds such cases by a change of cursor upon hovering over the link. (You get the same cursor when you Cmd-click or Cmd-Shift-click the link, to load it in a new window on purpose.) This way you can keep such UA functionaility in the chrome -- no need to mess with the content's presentation itself. [*] http://icab.de/ -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Target Attribute Values
On 4/28/07, Ian Hickson [EMAIL PROTECTED] wrote: I also made it non-conforming for window.open(). window.open() without a target argument implies _blank AFAICT, so this seems O.K. -- Michael
Re: [whatwg] Target Attribute Values
Ian Hickson [EMAIL PROTECTED] wrote: 2) Afaik currently any attribute value for the target attribute which hasn't been defined opens a new window. If _blank were made non conforming authors would imo resort to using non defined names which has the same result in practice, but which makes filtering such methods out on the user end much harder. If people widely blocked _blank, then authors would start using the names anyway. So that doesn't really change anything in practice. People blocking _blank would indeed be rare, even more so author's awareness of this, but I'd put the number of authors who test for conformance as significantly higher. Those authors are imo likely to look for a conformant alternative that works. I've argued my socks off trying to convince authors that they should leave opening new windows to users, but there are an awful lot of them who for various reasons insists on doing just that. It would be interesting to hear the needs of these authors. Can anyone elaborate? We might well need to re-allow it in the end, I'm curious to hear why people use it. In the many discussions with authors I've had on this issue, I've not yet encountered a reason for this practice that stood up to scrutiny, but regularly the lack of rationale and pointing out the negatives doesn't stop people from opening new windows despite it having been pointed out that doing so is bad practice. The most common reasons given are: 1) I like [often off-site] links opening in a new window, others will too. 2) When moving to another site, not opening a new window would cause my site to disappear (sometimes accompanied with the argument that this would confuse people). -- Spartanicus
Re: [whatwg] Target Attribute Values
On Apr 28, 2007, at 4:12 PM, Maciej Stachowiak wrote: ... One valid reason to use _blank instead of a named target to open a new window is the fact that the top-level frame namespace is global, and you don't want to collide with windows opened by other web apps, or even other instances of your own web app. ... Ever since I first visited two Web pages that accidentally opened external links in the same window as each other, I've assumed that the top-level frame namespace being global was a bug, with under-specification of the target= attribute in HTML4 as a contributing factor. I suggest that WA1 specify that the frame namespace is per-top-level-browsing-context, not global. (Even if it is global in all extant browsers, I doubt that any applications rely on that behavior.) Otherwise, what is a Web application developer supposed to do to ensure that the application's help links reuse only its own help window, and don't accidentally obliterate those of other apps or even other open windows in the same app? Generate a per-page UUID prefix for all its target= attribute values? :-) -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Target Attribute Values
On Apr 28, 2007, at 2:04 AM, Matthew Paul Thomas wrote: On Apr 28, 2007, at 4:12 PM, Maciej Stachowiak wrote: ... One valid reason to use _blank instead of a named target to open a new window is the fact that the top-level frame namespace is global, and you don't want to collide with windows opened by other web apps, or even other instances of your own web app. ... Ever since I first visited two Web pages that accidentally opened external links in the same window as each other, I've assumed that the top-level frame namespace being global was a bug, with under- specification of the target= attribute in HTML4 as a contributing factor. I suggest that WA1 specify that the frame namespace is per-top- level-browsing-context, not global. (Even if it is global in all extant browsers, I doubt that any applications rely on that behavior.) Otherwise, what is a Web application developer supposed to do to ensure that the application's help links reuse only its own help window, and don't accidentally obliterate those of other apps or even other open windows in the same app? Generate a per- page UUID prefix for all its target= attribute values? :-) In principle this sounds like a good idea. But I think there may well be web apps that depend on top-level frame names being visible in all windows, particularly enterprise apps which are generally only deployed on intranets. It is worth doing some research to find out if this is the case and determine the scope of the dependency. Perhaps it could be limited to one top-level frame namespace for the set of windows from a single domain. Regards, Maciej
Re: [whatwg] Target Attribute Values
On Apr 28, 2007, at 5:29 PM, Bill Mason wrote: ... I can tell you my experience at the company I'm currently working for, as to why they mandate using _blank in some circumstances. (Disclaimer: I don't endorse the policy, I just have to live with it.) ... 1) Fear that the user will follow some link away from our pages, and never return to complete the form. (I think this comes from sales and/or marketing personnel.) A common solution to that is to minimize links on the form, even to the point of removing most global navigation. Sometimes form-specific links are necessary (e.g. By submitting this form you agree to our __terms of service__ and __privacy policy__), but links like those should use named targets rather than _blank (because if someone opens one of those links twice it's a mistake, they don't actually want two copies open). 2) Complaints from users who would follow the surrounding links elsewhere and then lose their way back to the application form. (This would primarily occur when they started the application form -- which is typically multiple pages -- and go off following some other link to find some piece of information about the application process, finally losing their way to how they got into the form in the first place.) In both cases, I have no idea why the back button isn't enough for everyone involved, or how people got lost in spite of having a back button. ... Because the Back button is a horribly awkward interface for navigating, especially for getting back to pages you visited a few minutes ago. (In some browsers the Back button has a visible associated menu, but it's hard to open -- and it relies on page titles, which readers probably didn't notice when first scanning those pages, again because of poor browser design.) Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Target Attribute Values
It's worth speculating how this would work in an alternate universe where authors cared more about usability and user agents made more intelligent use of HTML. Most of the usecases mentioned involve differentiating sets of links, and deciding how they should be treated on behalf of users. HTML includes many ways of classifying anchor links into groups (rel/rev, type, hreflang, class), such that users really ought to be able to make such decisions for themselves. In the mirrorverse, user agents would come with customizable behaviours for classifications such as: rel=external rel=help type=application/pdf -- Benjamin Hawkes-Lewis
Re: [whatwg] Target Attribute Values
Lachlan Hunt writes: Charles Iliya Krempeaux wrote: In the online advertising business, ads are usually put in iframe s for security reasons... So... if you didn't use a _blank for the target, the landing page for the ad would open up in the tiny iframe (instead of a new window). That's a use case for _top or _parent, not _blank. Yes. But also clicking on adverts can often be quite different from clicking on other links in a site: * Usually adverts are not the reason a user visits a site, so if she sees an advert that intrigues her then she is likely to be in the middle of doing something else, or has a pending task at the current site. So it can be helpful for the advert to open elsewhere, then whether she looks at the advert first or finishes with the current site, t'other one will be there waiting for her. * Links within a site generally lead to pages with navigation to elsewhere on the site, often including back to where a user has come from. Many users are probably now used to it being 'safe' to click on an advert without losing what they are currently doing. If adverts started using _top and overwriting what's in the current window that could be confusing. Smylers
Re: [whatwg] Target Attribute Values
Spartanicus writes: As a user I detest new windows opening without having chosen to do that myself. Would perhaps a spec conformance requirement that browsers should offer users a config option to opt out of windows being opened via target values be an alternative? It could avoid the seemingly unwin'able argument with authors who insist on doing this, and give users the final say Surely users always have the final say anyway? For example browsers can let users prover CSS that overrides websites, or GreaseMonkey extensions -- or even users middle-clicking on links to open them in a new window. As long as a user agent can follow the spec, it offering features for users to override webpages surely isn't a spec violation? But _requiring_ user agents to offer opt-outs seems excessive, and possibly beyond the jurisdiction of the spec. It seems likely that user demand will lead mainstream web-browsers to offer options like this anyway, but if somebody wanted to produce a web browser that, say, was so minimalist it didn't offer any user preferences at all, surely that's up to the browser manufacturer? It might be a bad UI, but this spec isn't about browser UI. If a manufacturer comes up with a browser in which the the Up key scrolls down the page (and vice versa) and where clicking on any link requires solving a mini sudoku puzzle before the target page renders, the browser should attract criticism for many reasons; but not necessarily for HTML spec violation. Surely whether target=_blank or even target=help is treated different from target=top can at best be a hint? Surely it isn't a requirement of HTML that user-agents implement multiple content windows? That may not be appropriate for some environments, perhaps: * terminal-based browsers, such as Lynx * One Laptop Per Child UI, where everyting runs full-screen * mobile phone browsers * televisions with web access Smylers
Re: [whatwg] Target Attribute Values
Lachlan Hunt writes: You're assuming there is actually a valid use case for the popup in the first place. But as you've already pointed out, browsers can offer users who never want to have links automatically open anywhere than the current window, so webpages' hints are completely ignored anyway. Similarly for those users who want tabs instead of windows, or always want new tabs on all links, or always want new pages for off-domain links, or ... So target (except for frames within a page) is only relevant for users who like some things to open in new windows, and trust webpages to offer hints on which links are appropriate for this. As such, the views of people who never want new windows don't need to be taken into account here -- because they won't be affected whatever happens! Smylers
Re: [whatwg] Target Attribute Values
Smylers [EMAIL PROTECTED] wrote: But _requiring_ user agents to offer opt-outs seems excessive, and possibly beyond the jurisdiction of the spec. Possibly, but then what's the point of making _blank non conforming if it is not trying to be a benefit to users by discouraging its use. It has nothing to do with client interoperability, real world web browsers will continue to support _blank regardless. if somebody wanted to produce a web browser that, say, was so minimalist it didn't offer any user preferences at all, surely that's up to the browser manufacturer? Possibly, the HTML4 spec mentions a browser UI facility to select between alternate stylesheets as a should. The CSS2.1 draft lists it as a must in the UA conformance section, it is also a CSS conformance requirement to offer a UA UI facility to turn off stylesheets. Browser manufacturers can ignore such, the only effect is that they can't claim to be spec conforming. User demand for such UI features expressed to the manufacturer is one way to get such features implemented. Other web specs have seen fit to add their weight to get UI features implemented. -- Spartanicus
Re: [whatwg] Target Attribute Values
Spartanicus writes: Smylers [EMAIL PROTECTED] wrote: But _requiring_ user agents to offer opt-outs seems excessive, and possibly beyond the jurisdiction of the spec. Possibly, but then what's the point of making _blank non conforming if it is not trying to be a benefit to users by discouraging its use. Well that's begging the question: Ian has (tentatively) made it non-conforming while saying there are arguments for not doing. There's also a difference between marking something as non-conforming (because there's a better alternative which should be used instead), and completely blocking the old way of doing it. For example, we could agree that it would benefit users by authors no longer using the i element (instead picking em or dfn or cite or whatever is appropriate); but it wouldn't benefit users for browsers to completely ignore i tags, rendering its contents in Roman such that users can't discern there was any mark-up there. If target=_blank is ignored users can't tell that the author intended some behaviour there. Or perhaps a help link has target=_blank and is labelled with opens in new window -- which could be dangerous if a user believed that label, only to lose her partly completed form. Smylers
Re: [whatwg] Target Attribute Values
On Sat, 28 Apr 2007 00:55:30 -0400, Lachlan Hunt [EMAIL PROTECTED] wrote: e.g. in Firefox, setting the pref browser.link.open_newwindow to 1 causes any links with target= that would normally open a new window, to open in the current tab. There are a few other prefs to control window.open() as well. open_newwindow=1 -suppressing- new windows? Holy counterintuitive, Batman! Or is that just a typo on your part? -- J. King http://jking.dark-phantasy.com/
Re: [whatwg] Target Attribute Values
Smylers [EMAIL PROTECTED] wrote: Possibly, but then what's the point of making _blank non conforming if it is not trying to be a benefit to users by discouraging its use. There's also a difference between marking something as non-conforming (because there's a better alternative which should be used instead), and completely blocking the old way of doing it. No-one has suggested that, I suggested a user configurable option to prevent HTML code resulting in opening a new window. There is already at least one browser that offers such an option. If target=_blank is ignored users can't tell that the author intended some behaviour there. That's a good thing if (as seems to be the case) it is agreed that nothing will break by opening the link in the same window. Or perhaps a help link has target=_blank and is labelled with opens in new window -- which could be dangerous if a user believed that label, only to lose her partly completed form. Such a label classifies as an authoring error, just as a href=foothis link blows up the world/a, plus calling such dangerous is imo much too strongly put, more so because the user has deliberately enabled the config setting that prevents this. -- Spartanicus
Re: [whatwg] Target Attribute Values
Smylers wrote: Lachlan Hunt writes: You're assuming there is actually a valid use case for the popup in the first place. But as you've already pointed out, browsers can offer users who never want to have links automatically open anywhere than the current window, so webpages' hints are completely ignored anyway. ... So target (except for frames within a page) is only relevant for users who like some things to open in new windows, and trust webpages to offer hints on which links are appropriate for this. As such, the views of people who never want new windows don't need to be taken into account here -- because they won't be affected whatever happens! You're ignoring the users who don't like popups, but don't know how to prevent them using those *hidden prefs* I mentioned. J. King wrote: On Sat, 28 Apr 2007 00:55:30 -0400, Lachlan Hunt [EMAIL PROTECTED] wrote: e.g. in Firefox, setting the pref browser.link.open_newwindow to 1 causes any links with target= that would normally open a new window, to open in the current tab. There are a few other prefs to control window.open() as well. open_newwindow=1 -suppressing- new windows? Holy counterintuitive, Batman! Or is that just a typo on your part? It's not a boolean value, so 1 != true. http://kb.mozillazine.org/About:config_entries -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Target Attribute Values
Matthew Paul Thomas wrote: On Apr 28, 2007, at 5:29 PM, Bill Mason wrote: ... I can tell you my experience at the company I'm currently working for, as to why they mandate using _blank in some circumstances. (Disclaimer: I don't endorse the policy, I just have to live with it.) ... 1) Fear that the user will follow some link away from our pages, and never return to complete the form. (I think this comes from sales and/or marketing personnel.) A common solution to that is to minimize links on the form, even to the point of removing most global navigation. Sometimes form-specific links are necessary (e.g. By submitting this form you agree to our __terms of service__ and __privacy policy__), but links like those should use named targets rather than _blank (because if someone opens one of those links twice it's a mistake, they don't actually want two copies open). While I agree in principle that minimizing links would be a good solution, it unfortunately conflicts with this company's position in this business space. Our of our major selling points is that, unlike our major competitors in this area, we do customize our forms etc. to match the look of the customer's site exactly. And the customers who use our services like that because they prefer the path of the applicant from the school's admission pages to our hosted application pages to be seamless (i.e. the pages look the same/the transition is not particularly noticeable). So to start minimizing the links -- which would basically mean making our pages and the customer's pages a mismatch -- would basically remove one of our major points of differentiation between ourselves and our competitors. 2) Complaints from users who would follow the surrounding links elsewhere and then lose their way back to the application form. (This would primarily occur when they started the application form -- which is typically multiple pages -- and go off following some other link to find some piece of information about the application process, finally losing their way to how they got into the form in the first place.) In both cases, I have no idea why the back button isn't enough for everyone involved, or how people got lost in spite of having a back button. ... Because the Back button is a horribly awkward interface for navigating, especially for getting back to pages you visited a few minutes ago. (In some browsers the Back button has a visible associated menu, but it's hard to open -- and it relies on page titles, which readers probably didn't notice when first scanning those pages, again because of poor browser design.) So if that is the case (I'm not entirely convinced, but I don't want to turn the thread into an analysis of the back button), then when building pages for my company I have this situation: 1) Users follow links off our pages, and complain that they get lost and can't find their way back to our pages. 2) I cannot pare links out of the design to keep users from getting lost, or change to add warnings/advisories about leaving for another site if you follow those links (which was a topic elsewhere) [1]. Unless you count sticking advisories in the title attribute of the a tags, which I do since it's basically the only option I have. I doubt they get noticed much in practice. 3) The back button is not considered reliable as a navigation aid if target=_blank is not in use. That, in a nutshell, would be my company's use case for target=_blank. [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/011095.html -- Bill Mason Accessible Internet [EMAIL PROTECTED] http://accessibleinter.net/
Re: [whatwg] Target Attribute Values
Hello, Here's one use case In the online advertising business, ads are usually put in iframes for security reasons. (So the ad can't tell what page it's on... get user cookies from that domain... etc.) So... if you didn't use a _blank for the target, the landing page for the ad would open up in the tiny iframe (instead of a new window). See ya On 4/26/07, Lachlan Hunt [EMAIL PROTECTED] wrote: Hi, This is regarding the valid browsing context names, used for the target attribute [1]. Why is _blank still considered a conforming value? On IRC, Hixie mentioned that there are some legitimate use cases, but didn't list any. I've argued against popups many times before and heard many arguments for them, but I'm yet to hear of any legitimate use cases. If there are any, what are they? _new is also not specced, yet it is widely used and treated as a magic value like _blank in Firefox. Maybe it should be specced the same as _blank. However, IE, Opera and Safari didn't appear to treat it as such, so maybe it's not needed. http://www.whatwg.org/specs/web-apps/current-work/#valid8 -- Lachlan Hunt http://lachy.id.au/ -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Target Attribute Values
Charles Iliya Krempeaux wrote: Here's one use case In the online advertising business, ads are usually put in iframes for security reasons... So... if you didn't use a _blank for the target, the landing page for the ad would open up in the tiny iframe (instead of a new window). That's a use case for _top or _parent, not _blank. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Target Attribute Values
On Thu, 26 Apr 2007, Lachlan Hunt wrote: Why is _blank still considered a conforming value? On IRC, Hixie mentioned that there are some legitimate use cases, but didn't list any. I've argued against popups many times before and heard many arguments for them, but I'm yet to hear of any legitimate use cases. If there are any, what are they? I've removed _blank from the list of valid values. _new is also not specced, yet it is widely used and treated as a magic value like _blank in Firefox. Maybe it should be specced the same as _blank. However, IE, Opera and Safari didn't appear to treat it as such, so maybe it's not needed. _new isn't supported in IE. I couldn't work out why Firefox supports it. I've not added it. On Thu, 26 Apr 2007, Spartanicus wrote: As a user I detest new windows opening without having chosen to do that myself. But I'd question the wisdom of making _blank non conforming. 1) At least _blank allows me to filter it out before sending it to my browser. 2) Afaik currently any attribute value for the target attribute which hasn't been defined opens a new window. If _blank were made non conforming authors would imo resort to using non defined names which has the same result in practice, but which makes filtering such methods out on the user end much harder. If people widely blocked _blank, then authors would start using the names anyway. So that doesn't really change anything in practice. I've argued my socks off trying to convince authors that they should leave opening new windows to users, but there are an awful lot of them who for various reasons insists on doing just that. It would be interesting to hear the needs of these authors. Can anyone elaborate? We might well need to re-allow it in the end, I'm curious to hear why people use it. Would perhaps a spec conformance requirement that browsers should offer users a config option to opt out of windows being opened via target values be an alternative? It could avoid the seemingly unwin'able argument with authors who insist on doing this, and give users the final say This doesn't have to be in the spec, since it isn't required for interop. On Fri, 27 Apr 2007, Matthew Paul Thomas wrote: For most desktop applications in-depth help is presented in a separate window, so this will also likely be desirable for Web applications that do not consist of scrollable pages. (In those that do consist of scrollable pages, help would generally be better embedded in the pages themselves, perhaps as expandable sections.) So that's a use case for popup windows, but not necessarily a use case for _blank, because help windows are usually reused (akin to target=myappnamehelp rather than target=_blank). Indeed. Charles Iliya Krempeaux wrote: In the online advertising business, ads are usually put in iframes for security reasons. (So the ad can't tell what page it's on... get user cookies from that domain... etc.) So... if you didn't use a _blank for the target, the landing page for the ad would open up in the tiny iframe (instead of a new window). On Fri, 27 Apr 2007, Lachlan Hunt wrote: That's a use case for _top or _parent, not _blank. Indeed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Target Attribute Values
On Apr 27, 2007, at 8:49 PM, Ian Hickson wrote: On Thu, 26 Apr 2007, Lachlan Hunt wrote: Why is _blank still considered a conforming value? On IRC, Hixie mentioned that there are some legitimate use cases, but didn't list any. I've argued against popups many times before and heard many arguments for them, but I'm yet to hear of any legitimate use cases. If there are any, what are they? I've removed _blank from the list of valid values. Won't this just lead authors (who care about conformance) to use window.open(), with equally bad results that it's harder for the UA to control? This move seems to be taking the opposite of the logic behind the ping attribute. One valid reason to use _blank instead of a named target to open a new window is the fact that the top-level frame namespace is global, and you don't want to collide with windows opened by other web apps, or even other instances of your own web app. Regards, Maciej
Re: [whatwg] Target Attribute Values
Ian Hickson wrote: On Thu, 26 Apr 2007, Spartanicus wrote: As a user I detest new windows opening without having chosen to do that myself. But I'd question the wisdom of making _blank non conforming. 1) At least _blank allows me to filter it out before sending it to my browser. Filtering out the value _blank is an ineffective way of blocking popups. Some browsers have prefs to control it. e.g. in Firefox, setting the pref browser.link.open_newwindow to 1 causes any links with target= that would normally open a new window, to open in the current tab. There are a few other prefs to control window.open() as well. 2) Afaik currently any attribute value for the target attribute which hasn't been defined opens a new window. If _blank were made non conforming authors would imo resort to using non defined names which has the same result in practice, but which makes filtering such methods out on the user end much harder. In practice, authors use a wide variety of values to get popups anyway. _new, newwindow, popup, etc. are all fairly commonly used, among many others. I've argued my socks off trying to convince authors that they should leave opening new windows to users, but there are an awful lot of them who for various reasons insists on doing just that. It would be interesting to hear the needs of these authors. Can anyone elaborate? We might well need to re-allow it in the end, I'm curious to hear why people use it. The major reasons for popups that I can remember include: * Links to external sites, so that users don't leave the previous site. - It's far better to inform the user that they're going to an external site and let them decide for themselves if they want a new window. * Opening help windows. e.g. for help with forms. - There are much more user friendly ways of offering help to users without popups. * Photo galleries, where clicking on the thumbnail opens the larger version in a popup. - There are much more user friendly alternatives that don't require popups. (Just imagine how hard Flickr would be to use if they opened popups for every photo!) * Links to files that require external apps, which commonly open within the browser. e.g. PDF, Word docs, etc. - Jakob Nielsen promotes this one for flawed usability reasons, but whether or not such a file opens within the browser is entirely dependent upon the UA config. * Advertisements - These are just annoying. * To give users windows without chrome (using window.open()), sometimes to prevent the use of the back button. - Such uses usually indicate broken back end implementations and/or the complete failure to think about usability. On Apr 27, 2007, at 8:49 PM, Ian Hickson wrote: On Thu, 26 Apr 2007, Lachlan Hunt wrote: Why is _blank still considered a conforming value? On IRC, Hixie mentioned that there are some legitimate use cases, but didn't list any. I've argued against popups many times before and heard many arguments for them, but I'm yet to hear of any legitimate use cases. If there are any, what are they? I've removed _blank from the list of valid values. Won't this just lead authors (who care about conformance) to use window.open(), with equally bad results that it's harder for the UA to control? This move seems to be taking the opposite of the logic behind the ping attribute. Yes, unfortunately. We have already seen that occur with authors using HTML 4.01 Strict. target=_blank is less evil than window.open(), so it may indeed be more pragmatic just to concede that authors are going to use popups in one way or another, and just allow it. Sigh. :-( One valid reason to use _blank instead of a named target to open a new window is the fact that the top-level frame namespace is global, and you don't want to collide with windows opened by other web apps, or even other instances of your own web app. You're assuming there is actually a valid use case for the popup in the first place. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Target Attribute Values
On Fri, 27 Apr 2007, Maciej Stachowiak wrote: Won't this just lead authors (who care about conformance) to use window.open(), with equally bad results that it's harder for the UA to control? I also made it non-conforming for window.open(). This move seems to be taking the opposite of the logic behind the ping attribute. Indeed. One valid reason to use _blank instead of a named target to open a new window is the fact that the top-level frame namespace is global, and you don't want to collide with windows opened by other web apps, or even other instances of your own web app. Also true. These are strong arguments for putting _blank back. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Target Attribute Values
Ian Hickson wrote: On Thu, 26 Apr 2007, Lachlan Hunt wrote: I've argued my socks off trying to convince authors that they should leave opening new windows to users, but there are an awful lot of them who for various reasons insists on doing just that. It would be interesting to hear the needs of these authors. Can anyone elaborate? We might well need to re-allow it in the end, I'm curious to hear why people use it. I can tell you my experience at the company I'm currently working for, as to why they mandate using _blank in some circumstances. (Disclaimer: I don't endorse the policy, I just have to live with it.) The area I work in is with the company's ASP division. We host (primarily) online application forms for colleges. They give us their paper form, and we build them an online form using the look of their web site, build supplemental instructions pages, etc. [1] When we build the form/pages to the look in question, the mandate is always that links that leave our domain (which primarily means the links in the school's surrounding navigation back to various pages on the school's site) are always given a _blank target to open in a new window. The reasons we (the team of web developers) are given for this are twofold: [2] 1) Fear that the user will follow some link away from our pages, and never return to complete the form. (I think this comes from sales and/or marketing personnel.) 2) Complaints from users who would follow the surrounding links elsewhere and then lose their way back to the application form. (This would primarily occur when they started the application form -- which is typically multiple pages -- and go off following some other link to find some piece of information about the application process, finally losing their way to how they got into the form in the first place.) In both cases, I have no idea why the back button isn't enough for everyone involved, or how people got lost in spite of having a back button. Anyway, I recount all this not because I think it argues for keeping _blank, but just to offer an example from real life about its use. [1] Example: http://www.applyweb.com/apply/oxyt/ [2] As I recall them, anyway. This discussion hasn't been had internally for awhile because we in web development are simply not going to win the argument with the higher powers to not _blank every external link. -- Bill Mason Accessible Internet [EMAIL PROTECTED] http://accessibleinter.net/
Re: [whatwg] Target Attribute Values
On Apr 27, 2007, at 9:55 PM, Lachlan Hunt wrote: The major reasons for popups that I can remember include: * Links to external sites, so that users don't leave the previous site. - It's far better to inform the user that they're going to an external site and let them decide for themselves if they want a new window. What about webmail? My desktop application Mail client opens in a new browser window when I click a link in a mail message. It seems reasonable for a web-based mail client to do the same. I guess it would be nice to have a preference or a way to override this, but it doesn't seem fundamentally unreasonable. I do agree that many uses of pop-up windows are broken. But target is actually less problematic than window.open, since it avoids some of the most abusive scenarios. For example, some pages put an onclick handler on every link on the page. Then they use window.open to open an ad popup in addition to the normal navigation. target can't be abused that way. Similarly for removing the window chrome. So in general, at the margin, it's probably unwise to create a scenario where conformance checkers encourage authors to use window.open instead of target. Regards, Maciej
Re: [whatwg] Target Attribute Values
On Apr 27, 2007, at 10:24 PM, Ian Hickson wrote: On Fri, 27 Apr 2007, Maciej Stachowiak wrote: Won't this just lead authors (who care about conformance) to use window.open(), with equally bad results that it's harder for the UA to control? I also made it non-conforming for window.open(). Making particular script argument values non-conforming is not very effective, since you can't, in general, make a conformance checker for script API use. So making it non-conforming but still requiring UA support is effectively just a hint to conscientious authors not to use it. Regards, Maciej
[whatwg] Target Attribute Values
Hi, This is regarding the valid browsing context names, used for the target attribute [1]. Why is _blank still considered a conforming value? On IRC, Hixie mentioned that there are some legitimate use cases, but didn't list any. I've argued against popups many times before and heard many arguments for them, but I'm yet to hear of any legitimate use cases. If there are any, what are they? _new is also not specced, yet it is widely used and treated as a magic value like _blank in Firefox. Maybe it should be specced the same as _blank. However, IE, Opera and Safari didn't appear to treat it as such, so maybe it's not needed. http://www.whatwg.org/specs/web-apps/current-work/#valid8 -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Target Attribute Values
Lachlan Hunt [EMAIL PROTECTED] wrote: This is regarding the valid browsing context names, used for the target attribute [1]. Why is _blank still considered a conforming value? On IRC, Hixie mentioned that there are some legitimate use cases, but didn't list any. I've argued against popups many times before and heard many arguments for them, but I'm yet to hear of any legitimate use cases. If there are any, what are they? _new is also not specced, yet it is widely used and treated as a magic value like _blank in Firefox. Maybe it should be specced the same as _blank. However, IE, Opera and Safari didn't appear to treat it as such, so maybe it's not needed. As a user I detest new windows opening without having chosen to do that myself. But I'd question the wisdom of making _blank non conforming. 1) At least _blank allows me to filter it out before sending it to my browser. 2) Afaik currently any attribute value for the target attribute which hasn't been defined opens a new window. If _blank were made non conforming authors would imo resort to using non defined names which has the same result in practice, but which makes filtering such methods out on the user end much harder. I've argued my socks off trying to convince authors that they should leave opening new windows to users, but there are an awful lot of them who for various reasons insists on doing just that. Would perhaps a spec conformance requirement that browsers should offer users a config option to opt out of windows being opened via target values be an alternative? It could avoid the seemingly unwin'able argument with authors who insist on doing this, and give users the final say Mozilla already offers such an opt out afaik. -- Spartanicus
Re: [whatwg] Target Attribute Values
Spartanicus wrote: Would perhaps a spec conformance requirement that browsers should offer users a config option to opt out of windows being opened via target values be an alternative? It could avoid the seemingly unwin'able argument with authors who insist on doing this, and give users the final say That falls into the realm of the User Agent Accessibility Guidelines, which already cover this topic: http://www.w3.org/TR/UAAG10/guidelines.html#tech-limit-viewports -- Bill Mason Accessible Internet [EMAIL PROTECTED] http://accessibleinter.net/
Re: [whatwg] Target Attribute Values
On Apr 26, 2007, at 7:34 PM, Lachlan Hunt wrote: ... Why is _blank still considered a conforming value? On IRC, Hixie mentioned that there are some legitimate use cases, but didn't list any. I've argued against popups many times before and heard many arguments for them, but I'm yet to hear of any legitimate use cases. If there are any, what are they? ... For most desktop applications in-depth help is presented in a separate window, so this will also likely be desirable for Web applications that do not consist of scrollable pages. (In those that do consist of scrollable pages, help would generally be better embedded in the pages themselves, perhaps as expandable sections.) So that's a use case for popup windows, but not necessarily a use case for _blank, because help windows are usually reused (akin to target=myappnamehelp rather than target=_blank). -- Matthew Paul Thomas http://mpt.net.nz/
