Should target=_blank and window.open('...', '_blank') be case sensitive?

[phistuck]

It is case insensitive only in Firefox (since at most version 3, if not since forever).
JSFiddle -
https://jsfiddle.net/8v7ots9x/

Is this web compatible?
It is always good to have case sensitivity, anyway. ;)

The new tests triggered this -
web-platform-tests/wpt#5145

[annevk]

More tests: web-platform-tests/wpt#5150.

Bugs filed thus far by @lyzadanger:

• https://bugs.webkit.org/show_bug.cgi?id=169747 and https://bugs.webkit.org/show_bug.cgi?id=169748
• https://bugs.chromium.org/p/chromium/issues/detail?id=702178 and https://bugs.chromium.org/p/chromium/issues/detail?id=702188

@bzbarsky what do you think, should we just change this in Firefox to be case-sensitive?

[bzbarsky]

I guess we could do that. Gecko has been case-insensitive here since at least 2000; I expect Netscape was too. But it does look at first glance like everyone else (including IE11) is case-sensitive.

I just checked, and a lot of Firefox addons use "_BLANK" as either a target or in selectors like zone-right a[target="_BLANK"] > img. This last is happening in addons like uBlock. So sites do in fact use non-lowercase spellings here. An example (still based on this uBlock list) is https://www.kuopionpursiseura.fi/ which uses it for the ad-thing right below the site menu on the right.

The catch, of course, is that a non-lowercase spelling will seem to work just like the lowercase spelling in a simple test in all browsers. It's when you click a second link (or do window.open, or whatever) with that the behavior difference appears.

It might be worth looking at uses of _BLANK in httparchive or something and seeing what behavior sites expect at those use points...

[zcorpan]

SELECT * FROM (
SELECT page, url, REGEXP_EXTRACT(body, r'<[aA](?:[rR][eE][aA])?[^>]+\s[tT][aA][rR][gG][eE][tT]\s*=\s*["\']?_([bB][lL][aA][nN][kK]|[sS][eE][lL][fF]|[pP][aA][rR][eE][nN][tT]|[tT][oO][pP])(?:["\'>]|\s)') AS match
FROM [httparchive:har.2017_03_01_android_requests_bodies]
) WHERE match != "null"
AND match != "blank"
AND match != "self"
AND match != "parent"
AND match != "top"

1424 rows. https://gist.github.com/zcorpan/871ce08164fb5078e434cb1b9b88dc4a

I think the _SELF/_PARENT/_TOP ones are probably more interesting than _BLANK, since they give different results on the first click of such a link. I have not yet analyzed these.

[phistuck]

I tried the more simplified target="_BLANK" - 2623 results -
https://bigquery.cloud.google.com:443/savedquery/558355517328:6f9fd9a369f8483a8354859a439c534d

[zcorpan]

http://www.aquariumline.com/	http://www.aquariumline.com/catalog/news_with_scroll.php	Parent

This seems like it indeed intended _parent and so works better in Firefox.

http://www.bazarmajazi.com/	http://www.bazarmajazi.com/	SELF

The tabbed pages at the top, I would say works better in Firefox.

http://www.exler.ru/	https://www.exler.ru/	TOP

This is the Facebook badge, though seems OK to open in a new tab usability-wise for this page... but would be confusing if a page has several different _TOP links and they keep overwriting each other.

http://www.shuud.net/	http://shuud.club/	SELF

Top-left logo, seems like it indeed should be a _self link.

http://www.ccckmit.wikidot.com/	http://ccckmit.wdfiles.com/local--html/main/1e395d9d1baa7e9ed0e8b7a9ac0fc958fb6491ed-5165331601518671118/ccckmit.wikidot.com/	TOP

Also Facebook badge.

http://www.emegteichuud.mn/	http://www.emegteichuud.mn/banner.shtml?name=card1	SELF

This page has several _SELF links, which seem to be intended to be _self.

http://www.cnbcarabia.com/	http://zagtrader.com/external/cnbcarabiadynamic/pricebar2.php?marketId=6	PARENT

Intends _parent.

Well, that is probably enough to give a good enough insight into what website expectations looks like. As far as I can tell they expect case-insensitive and the user experience is a bit better with case-insensitive.

[zcorpan]

@bzbarsky

I just checked, and a lot of Firefox addons use "_BLANK" as either a targer or in selectors like zone-right a[target="_BLANK"] > img.

target is in the list of attributes that match case-insensitively with selectors:
https://html.spec.whatwg.org/#case-sensitivity-of-selectors

[bzbarsky]

target is in the list of attributes that match case-insensitively with selectors:

OK, but the reason the addon had it like that is that the site involved has "_BLANK" as the target.

[zcorpan]

So given the analysis above I think these should be case-insensitive like in Gecko.

@cdumez @tkent-google WDYT?

[cdumez]

I agree with zcorpan, I think we should make these case-insensitive given the analysis. It is also safer for us to align with Gecko than the other way around here.

[tkent-google]

+1 for case-insensitive.

[zcorpan]

https://bugs.chromium.org/p/chromium/issues/detail?id=702178
https://bugs.chromium.org/p/chromium/issues/detail?id=702188
https://bugs.webkit.org/show_bug.cgi?id=169747
https://bugs.webkit.org/show_bug.cgi?id=169748
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11403319/

[phistuck]

What about only making it case insensitive in quirks mode? At least some of those examples are rendered in quirks mode, as far as I can see.

[domenic]

There's no reason to add more quirks to the platform.

[phistuck]

If it allows more customizability, I am not sure I agree. But I certainly do not feel strongly about it anyway, it was just a suggestion.

[annevk]

This also requires changes to "The rules for choosing a browsing context given a browsing context name". I'm hoping to have a PR ready today.