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

Created on 17 Mar 2017 · 15Comments · Source: whatwg/html

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 -
https://github.com/w3c/web-platform-tests/pull/5145

navigation

Source

phistuck

All 15 comments

More tests: https://github.com/w3c/web-platform-tests/pull/5150.

Bugs filed thus far by @lyzadanger:

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

annevk on 20 Mar 2017

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...

bzbarsky on 20 Mar 2017

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.

zcorpan on 20 Mar 2017

👍1

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

phistuck on 20 Mar 2017

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 on 20 Mar 2017

@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

zcorpan on 20 Mar 2017

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.

bzbarsky on 20 Mar 2017

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

@cdumez @tkent-google WDYT?

zcorpan on 24 Mar 2017

👍1

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.