Template talk:Angle bracket

Encoding options

math code	<math>\langle</math>{{{1}}}<math>\rangle</math>	$\langle$a$\rangle$	1
	<math>\langle\text{{{{1}}}}\rangle</math>	$\langle {\text{a}}\rangle$	2
HTML entities	{{Unicode|&lang;}}{{{1}}}{{Unicode|&rang;}}	⟨a⟩	3a
	&lang;{{{1}}}&rang;	⟨a⟩	3b
Equivalent with &3008/09; but not defined to be some fixed width.	{{Unicode|&#x2329;}}{{{1}}}{{Unicode|&#x232A;}}	〈a〉	4a
	&#x2329;{{{1}}}&#x232A;	〈a〉	4b
fullwidth CJK	{{Unicode|&#x3008;}}{{{1}}}{{Unicode|&#x3009;}}	〈a〉	5a
	&#x3008;{{{1}}}&#x3009;	〈a〉	5b
mathematical angle brackets	{{Unicode|&#x27E8;}}{{{1}}}{{Unicode|&#x27E9;}}	⟨a⟩	6a
	&#x27E8;{{{1}}}&#x27E9;	⟨a⟩	6b
other template choose one of the right options	{{langle}}{{{1}}}{{rangle}}	⟨a⟩	7

So, I suppose ⟨...⟩ would be the recommended solution? Fut.Perf. ☼ 13:01, 17 November 2013 (UTC)

Sure, if they were supported by Windows. But people keep objecting that they show up as blocks, and we suspect the reason is that XP and Vista can't handle them. But not everyone with those OS's has a problem, so perhaps there are updates which fixed it? — kwami (talk) 13:48, 17 November 2013 (UTC)

Do we have any data on whether the named character entities might be better supported than pure Unicode characters? The old Windows/IE troubles (lack of automatic font substitution) ought to have been a thing of the past since IE7, but apparently IE6 is still used by some 5% of users world-wide (though less than 1% in the US), according to our articles. Fut.Perf. ☼ 14:31, 17 November 2013 (UTC)

I reverted the reintrodduction of the problematic characters. That is the whole point of this template. See core talks at Talk:International_Phonetic_Alphabet#Someone_with_AWB_access:_Please_follow_the_article.27s_own_advice_re:_Angle_Brackets.21

-DePiep (talk) 16:36, 17 November 2013 (UTC)

Ah, I had no idea of that discussion. Kwami didn't link me to it. Can you check whether the named character entities solution would work for you? Fut.Perf. ☼ 17:21, 17 November 2013 (UTC)

Which brackets work for whom is in that discussion. Some four sets are contemplated, plus variant in how to invoke them (math, HTML named entity, etc). No simple single solution ahead. As I said at kwami's talk, better see this being stable before mass-changing article space. But I guess you already got that. -DePiep (talk) 19:25, 17 November 2013 (UTC)

As a curiousity, the answer: &#x27E8/E9; for me show light-grey (transparent?) brackets. FF atop WinXP, no manual fonts installed/manipulated. For me the grey is unacceptable, unless this is an exotic browser setup WP doesn't support fully. -DePiep (talk) 19:31, 17 November 2013 (UTC)

And, to be complete: there is also a thread at WP:VPT. -DePiep (talk) 19:42, 17 November 2013 (UTC)

Unlike Talk:IPA, this seems like the right place to discuss. It’s graphemic notation after all, which occurs in the IPA article only to differentiate examples from phonologic /…/ and […].

Windows XP does not produce the hex box substitutes the IP user sees, Firefox does. One should ask them, whether they see the correct glyphs in the Charmap application. I assume a font problem. Installing, though not using, the most recent supported version of Internet Explorer might help.

The OS does not have to know (nor does it care) whether a certain Unicode position is used or by which character. The whole Unicode 3.2 came after WinXP point is very much moot.

DePiep, your gray result sounds like the brackets are taken from a different font and look unfit. A screenshot might help to understand the problem further. Anyhow, it sounds like substandard but acceptable rendering, given that you are using an OS that is so old the manufacturer – who is known for long-time support, in computer terms – is now ending support for it.

Therefore it seems it’s nowhere near impossible to get acceptable results in Windows XP.

In standard linguist typography, U+27E8|9 are the correct characters to use. The text (Jax) rendering of <math> code uses them, too. U+2329|A and U+3008|9 often look (almost) the same except for spacing. The others are frequent workarounds or mistakes of people who don’t know better or don’t know how.

Inline PNGs distort the line height and fonts mismatch; they should be avoided. Bitmaps are, as far as I remember, the default for users not logged in.

Ergo, let’s have this template use U+27E8 and U+27E9. Like de:Vorlage:Graphem does (although it erroneously used to use U+2329|A or U+3008|9). — Christoph Päper 11:58, 19 November 2013 (UTC)

from Talk:IPA

Added a screenprint. Issue: grey brackets showing. From overview from Talk:IPA. Browser FF25 atop WinXP SP2,3. No font manually added or manipulated (same with my previous box, same issue too). -DePiep (talk) 14:43, 19 November 2013 (UTC)

Looks like Calibri and Doulos are grey too. If you haven't added any fonts, I suppose those are substituted. Perhaps the grey brackets are substituted too? We could perhaps have WP substitute a more appropriate font. What if we used the proper letters, but inside {{unicode}}? The would look like this:

...⟨..|..⟩...

Still grey? — kwami (talk) 19:20, 19 November 2013 (UTC)

Still grey, don't know about substitution. Understand that I can live with it, if my setup is old or exotic. Could be an outcome. I cannot judge which browser situations we should/not cover, I can not follow all the recent talks about this. I note that the IP has a different situation / opinion. For me, I think we tried our best to find a generic solution. -DePiep (talk) 19:28, 19 November 2013 (UTC)

Does it get darker when you magnify it? (Press Ctrl++ repeatedly — to undo, press Ctrl+0.) —LiliCharlie (talk) 22:13, 19 November 2013 (UTC)

Yes, into a dark grey, with a very big zoom. tested the bottom-left (TITUS font). I see also this. I have a colorpicker available ("rainbow", a.k.a. a pipet). While the regular letters have pixel-sharp edge (still in that zoom), the problematic angle has a few greys, when mousehovering across. e.g., from white bg=#F9 (that is, #f9f9f9 = almost white), the angle line shows #D4, #CB and #DC greys next to each other. FWIW. -DePiep (talk) 23:43, 19 November 2013 (UTC)

That’s strange, it should be completely dark at full zoom. Maybe we should try and wrap it into

<span style="color:black !important;"> ... </span>

or in the case of math mark-up

<math style="color:black !important;"> ... </math>

etc. —LiliCharlie (talk) 00:12, 20 November 2013 (UTC)

Eh, the <math>s were OK black, the in-font U+27E8/E9 I was talking about. -DePiep (talk) 00:22, 20 November 2013 (UTC)

Yes:

<span style="color:black"> ... </span>

in my User:DePiep/sandbox shows black angles in bigbig zoom (shows for the eye, could not pick an actual #00 color) . Did not use !important. -DePiep (talk) 00:23, 20 November 2013 (UTC)

Fine. Not using !important is much better, especially for the visually impaired who need to use their own style sheets. Is there anything else left to improve? Groetjes, LiliCharlie (talk) 00:40, 20 November 2013 (UTC)

Dunno what !important does, so I left it out. Now, do I have to do something, or will the template change, or nothing will happen? (I sure could make a case for Keith Richards being plural as in lives, being related in three steps to Newcastle's St. James', and being non-standard English in general.) -DePiep (talk) 07:48, 20 November 2013 (UTC)

[1] by Crissov. Now template uses: {{unicode|⟨}} - Works for me! Great! Also in transclusions. I see nice sweet font-size black angels. Like with wings. -DePiep (talk) 11:30, 20 November 2013 (UTC)

Angelic! — !important gives your definitions priority over later re-definitions (except those that also contain !important). It is widely considered bad programming style and should be used with care and only when absolutely necessary. —LiliCharlie (talk) 12:25, 20 November 2013 (UTC)

Thanks for the ! explanation: always read it like C++ saying: "not important". Note: the template now has the HTML entity to work as intended, never turned into its character. -DePiep (talk) 12:45, 20 November 2013 (UTC)

DePiep, what do you seen in the TOC at yogh? For whatever reason, those look much better to me.

These half-width Chinese brackets are marginally acceptable on my OS/browser, though they look rather out of place because of the forced formatting, and are a different height than the surrounding text. (For instance, they look much better in the TOC of yogh, where they are not formatted, than in the heading itself.) Also, they do not copy&paste true, becoming full-with characters and screwing up the spacing when pasted into text. Compare

oo⟨oo⟩oo

with pasted

oo〈oo〉oo.

— kwami (talk) 12:40, 20 November 2013 (UTC)

yogh looks perfect to me, both in TOC and in the section title. -DePiep (talk) 12:45, 20 November 2013 (UTC)

Here's what's odd: The characters in the TOC are not formatted. So, can we get them to display for you as they do in the TOC, without the clumsy formatting we have in the text? — kwami (talk) 13:29, 20 November 2013 (UTC)

re Kwamikagami: see my User:DePiep/sandbox, including my report to you. Edit there as you think needed. I'm offline now. -DePiep (talk) 17:58, 20 November 2013 (UTC)

&lang; and &rang; are realized as deprecated U+2329 and U+232A (which have canonical decomposition to U+3008 and U+3009) on some browsers that apply the XHTML 1.0 entity definitions, and as U+27E8 U+27E9 on browsers that apply HTML5 entity definitions. Use what you mean by them instead, otherwise it differs from browser to browser. --Moyogo/ (talk) 14:07, 20 November 2013 (UTC)

re Moyogo. Pre-substitution was a cause for the issue at hand. Having them as HTML charname entity (not changed into numeric here in the wiki) seems to solve one issue: it shows good on my & other browsers (pre-producing the U+ number, into whichever set, does not). That is what we have found so far. This also means you could very well be you are right: per browser the substitute is made. But that would also introduce the reasonable expectation that a browser will use a character it knows -- is why it would work out OK.

If (if) this is a solution, there still is the requirement that we do not want that substitution to be made ever on the wiki side (but a lot of edits do just that, often semi-automatic). That is a new issue, unsolved AFAIK. -DePiep (talk) 17:38, 20 November 2013 (UTC)

And this: they are just canonically equivalent with the Chinese pair, but not by its halfwidth property. (Halfwidth as in: half width of a fixed width character). "Canonical equivalent" is also: "à" == "a`", but the second are two characters. -DePiep (talk) 17:42, 20 November 2013 (UTC)

I think what Moyogo points to is this: currently WP doesn’t explicitly define an HTML version on top of its pages, only the non-specific <!DOCTYPE html>, but uses a syntax, e.g. capitalization, that is definitely not HTML 5, and browsers rely on that. However if one day WP starts to use HTML 5 syntax (either implicitly or explicitly) any template using &lang; and &rang; will start to behave quite differently. —LiliCharlie (talk) 18:16, 20 November 2013 (UTC)

DePiep, here is what Safari does: the first &lang; &rang in a paragraph are displayed as U+27E8 U+27E9, all the others following in the same paragraphs are displayed as U+2329 U+232A. This is not reliable in any manner. PS: U+3008, U+3009 and U+2329, U+232A have the East Asian Wide property, they are always wide (not halfwidth). --Moyogo/ (talk) 18:59, 20 November 2013 (UTC)

re LiliCharlie, Moyogo: if that is the outcome (cannot use the html named entity that way), than it be so. I could not see that in M's edit I reverted. I have my doubts, though. There still is no mentioning of target/nontarget browsers. That does also imply that our search for a solution has failed, and this template adds little to IPA presentation. (while kwami is doing more research). After all, it is not an art to describe why a thing fails. The art is to find a solution. -DePiep (talk) 19:20, 20 November 2013 (UTC)

I guess Crissov/Christoph Päper pointed to the solution but was more or less ignored. Please re-read what he was writing above when he mentioned de:Vorlage:Graphem (which by the way uses de:Vorlage:Klammer). —LiliCharlie (talk) 20:46, 20 November 2013 (UTC)

LiliCharlie de:Klammer only adds the closing bracket/quote for whichever opening one you entered in de:Graphem. No other character manipulation in there, it is straight pairing.

de:Vorlage:Graphem does not address the issue at hand here (that is: angle brackets used in IPA do not show well). See also my comment re {{IPAlink}} below. -DePiep (talk) 08:55, 21 November 2013 (UTC)

re Moyogo: you're right, these are Wide. (Which is not Fullwidth behaviour, and which property should not have influence outside of East Asian writing'. btw, the &27E8/E9; pair is Narrow, as is the regular ASCII alphabet. This does not forbid or prescribe us to use any of them.

re Moyogo on Safari: well as you describe it it is reliable (predictable), but it is weird. I'd call that a bug, but when it's a feature the conclusion is the same: let it happen. Safari produces angular brackets all right (probably in different glyphs, but not the wrong glyphs). If we want to prevent this, we'd forced to replace all these named entities (everywhere, wikiwide). That is not a rule I know. So Safari shows angles, and this way my FF-WinXP (setup) does too. Two browser setups down. -DePiep (talk) 04:18, 21 November 2013 (UTC)

DePiep, U+2329, U+232A are the characters we want to use, period. Whether they can is another issue, the one were dealing with. The Wide characters are the ones we don’t want to use, except on CJK wikis or texts. --Moyogo/ (talk) 07:07, 21 November 2013 (UTC)

That could be an outcome of this research. Not a conclusion beforehand, to be enforced in reasoning backwards. -DePiep (talk) 08:24, 21 November 2013 (UTC)

Moyogo. Sure U+2329, U+232A are preferred as a first choice. I know that, because it was programmed long ago in the general {{IPAlink}} template. Now you first guess why I know this by heart (boy, a check says it is over two years ago already).

This template was created recently to explore and address the issue of bad effects of angle brackets (any) in IPA usage, like visibility and availability. So since a few days we are experimenting and researching. That is the point of this template. One can object that it better be in /sandbox not mainspace, but that does not alter the quest. -DePiep (talk) 08:55, 21 November 2013 (UTC)

DePiep, using U+3008 U+3009 or their equivalents in a non CJK context is wrong, it’s a fact, if you come to a different conclusion, you're wrong. --Moyogo/ (talk) 10:32, 21 November 2013 (UTC)

Where did I do or propose that? -DePiep (talk) 18:59, 21 November 2013 (UTC)

I don't know the details, but evidently WP now supplies fonts for ranges that readers don't have installed, as long as the text is formatted as the appropriate language. Couldn't we do something similar here? — kwami (talk) 10:53, 21 November 2013 (UTC)

Unless we want to shove Gentium (or whatever font it is we choose) down everybody's throats, we'd have to do OS detection. Both the implementation hurdles and the bureaucracy you're gonna have to wade through aren't gonna be worth it. Just *** it. Go back to the angles we had. The padding around the new ones is hideous. We're under no obligation to support Microsoft's shitty OS for-***-ever. — Lfdder (talk) 14:09, 22 November 2013 (UTC)

What's wrong with forcing a font? That's what we do when languages are specified. (Gentium wouldn't work, BTW, because they screwed up the encoding even after knowing about it before the last edition, but there are plenty of fonts which do support it.) — kwami (talk) 15:19, 22 November 2013 (UTC)

If we were using webfonts this wouldn't be an issue, but it seems Wikimedia Foundation Design/Typography is going in the direction of Helvetica, Arial for familiarity instead of a more pragmatic solution. --Moyogo/ (talk) 08:50, 23 November 2013 (UTC)

What's the point? Those are the browser defaults (Arial on Windows, Helvetica on Mac, Linux -- who knows?). — Lfdder (talk) 12:05, 27 November 2013 (UTC)

I suppose there's nothing very wrong with it. — Lfdder (talk) 12:05, 27 November 2013 (UTC)

FYI, in Chrome on brand new Windows 8, only the math tags code and the Fullwidth CJK are displayed with actual characters, the others are not defined. Other browsers are fine and fallback on the right fonts. --Moyogo/ (talk) 19:59, 28 November 2013 (UTC)

Whoa. You mean Win8/Chrome does not support the actual mathematical brackets? — kwami (talk) 02:03, 29 November 2013 (UTC)

Yes, in vanilla Win8/Chrome only the math code and CJK brackets work (rows 1 and 2, and row 5 in table at the top of the discussion). HTML entities, U+27E8 U+27E9, or U+2329, U+232A (rows 3, 4 and 6 in table) are not defined. --Moyogo/ (talk) 06:42, 29 November 2013 (UTC)

The Chrome browser ( 31.0.1650.57 m) on Windows Vista SP2 does not display this template correctly; display options 2 (&lang) and 3 (&#x2329;) don't work, though the other three work fine. --Macrakis (talk) 03:15, 4 December 2013 (UTC)

So we don't have anything that works for everyone? Any way to test how many people each option would inconvenience? — kwami (talk) 05:28, 4 December 2013 (UTC)

Can't it be conditional? --Macrakis (talk) 02:38, 5 December 2013 (UTC)

That would be nice. — kwami (talk) 23:30, 5 December 2013 (UTC)

My browser displays mathematical angle brackets correctly, but 3008-9 appear as boxes. Is there a way to fix this? I notice that the test at Help:IPA uses mathematical angle brackets instead of 3008-9. _{(suoı̣ʇnqı̣ɹʇuoɔ · ʞlɐʇ)} nɯnuı̣ɥԀ 21:58, 21 July 2014 (UTC)

Continued

So MediaWiki now pre-converts &lang and &rang to &#x2329 and &#x232A, instead of to &#x27E8 and &#x27E9 as recommended by HTML5. I think the latter look better (not gray), and are more inline with HTML5 specs. -- [[User:Edokter]] {{talk}} 21:44, 29 September 2014 (UTC)

I am going to force this template to use &#x27E8 (⟨) and &#x27E9 (⟩) so that the template no longer emits deprecated Unicode characters. I will also submit a bug to correct the HTML entity pre-cenversion to use the recommended characters. -- [[User:Edokter]] {{talk}} 15:40, 5 October 2014 (UTC)

I have just reverted that edit. &#x27E8 (⟨) and &#x27E9 (⟩) are the only variants from the table at the top of this page that don't display as boxes for me (in Chrome on Windows 7). Given the whole point of this template is to ensure that all users actually get some form of angle brackets, let's fix the display problem before worrying about the deprecated nature of Unicode characters that do actually work — after all, deprecated means prepare to replace, not "stop using this now at all costs" :o) — OwenBlacker (Talk) 12:20, 6 December 2014 (UTC)

Then why did you revert??? &#x27E8 and &#x27E9 were the one being used. Be more specific. If these actually do not work on your system, there is a problem on your end... I'm on XP/Chrome, and I see the brackets just fine. -- [[User:Edokter]] {{talk}} 12:28, 6 December 2014 (UTC)

Screenshot of the table at the top of this page, in Chrome 39 on Windows 7

Gah, I'm an idiot. Sorry, &#x27E8 (⟨) and &#x27E9 (⟩) are the only variants from the table at the top of this page that do display as boxes for me. The version you've restored (reverting my reversion) is the only one that fails to display correctly. (Of all the stupid typos for me to make that's definitely one of the most frustrating! Sorry for the confusion.) — OwenBlacker (Talk) 12:38, 6 December 2014 (UTC)

Well, then we have a problem. The $#23xx characters (which MediaWiki still uses to render &lang and &rang) are obsolete now, In HTML5 and Unicode, meaning future versions of fonts will likely drop the character entirely, so we cannot risk that. On the other hand, support for the $#27xx characters will increase as fonts are updated. In the mean time, if you do have a problem with these characters, consider installing the DejaVu fonts. You don't have to set them as your default font, but I found that Chrome will use it as a fallback font for any character it can't find in the default fonts. -- [[User:Edokter]] {{talk}} 12:53, 6 December 2014 (UTC)

They're not obsolete, they're deprecated; once they're obsolete and a replacement is widely supported, we should absolutely stop using them. But it seems foolish for us to use characters that don't work yet for any significant group of users. That said, as you can see I've customised my CSS and the problem seems to be with Calibri and Arial Unicode MS; looking at the page in IE while logged out means I don't have the problem. Irritatingly, installing DejaVu fonts doesn't seem to have made a difference; I'll have to go look at my user CSS.

I'm still not convinced we should be using the replacement characters yet, if really very common fonts like Calibri and Arial Unicode MS don't yet support them and they're not yet obsolete. Looking on Browserling for Chrome 37 though, the only characters that work there (which is presumably how most Chrome users see the site) are the MathML and the CJK fullwidth variant. It feels like we should probably find out which works best for most users and how that's likely to change before deciding which form is the most appropriate to use, I'd have thought.

— OwenBlacker (Talk) 13:58, 6 December 2014 (UTC)

That is quite some CSS you have there, and I think the problem is with your Unicode font declaration; Remove the !important part, as that also overrided Chrome's client CSS. It shouldn't be needed anyway. Let me know if that works. -- [[User:Edokter]] {{talk}} 14:41, 6 December 2014 (UTC)

In fact, try removing it all together; Chrome has become smart enough to pick the correct font, as you have seen when logged out. -- [[User:Edokter]] {{talk}} 14:43, 6 December 2014 (UTC)

Yeah, partly compensating for my vision (hence the zoom and so on, partly making Wikipedia work how I want and look prettier (there's a lot of Bootstrap in there). Weirdly, it's working perfectly on the template page, but failing in articlespace for me now. Most odd; I'll experiment some more. — OwenBlacker (Talk) 20:46, 6 December 2014 (UTC)

That's just caching, give it time, or clear your cache. Glad it has been solved though. -- [[User:Edokter]] {{talk}} 21:06, 6 December 2014 (UTC)

No, definitely not caching and it's definitely not yet solved. But I'm working on it. — OwenBlacker (Talk) 21:28, 6 December 2014 (UTC)

Hmm, experimenting, I think the problem is that Chrome hasn't realised that DejaVu Sans is installed yet. I'll come back to this some other time :o) — OwenBlacker (Talk) 21:35, 6 December 2014 (UTC)

Since {{Unicode}} is no longer an option, I marked up the …a variants in the table at the top with <del>. — Christoph Päper 17:01, 9 August 2016 (UTC)

Oppose Angle bracket as currently encoded

Many encodings (such as the very common Unicode UTF-8) do not correctly render angle brackets, instead leaving two boxes, whereas they should appear as one of the two below:

1. ⟨ ⟩
2. $\left\langle \right\rangle$

I thus propose and support a change in this template to either one of these formats and prefer number 1. Adavis444 (talk) 18:37, 29 September 2014 (UTC)

I'm afraid your proposal is technically not quite clear. All text on Wikipedia is in Unicode, and transmitted as UTF-8. Whether a character is ultimately rendered correctly on your system depends on what software you use in displaying it, and ultimately on what fonts you have. Your observation of boxes being displayed instead of characters is probably specific to a particular computer with a particular software setup; the next user will see other things. The problem with these characters, as discussed previously, is that there are several different sets of bracket characters defined in unicode, that their definitions (in terms of what kind of context and function each character code is meant to be used for) is often not followed faithfully by software and font implementations, and that those character codes that according to Unicode would be the most appropriate for our purposes are just among those that are least consistently supported in fonts and browsers. Fut.Perf. ☼ 20:46, 29 September 2014 (UTC)

I don't understand why the current situation was ever allowed to come into existence. I am sitting reading this on a computer which displays option 1 above and all options apart from 1 and 2 in the top paragraph (i.e. 3a-6b) as hex in boxes. It's totally unreadable. Why even consider using a multitude of unnecessary versions of angle brackets that display as junk on some computers when you have the maths ones and ASCII '<' and '>', both of which work perfectly for everyone? Kremmen (talk) 14:03, 5 October 2015 (UTC)

Well, the math codes are a poor workaround because they are actually rendered as images, not as text characters – that makes them display reliably, but you cannot do things like copy them via the clipboard, search for them etc. The Ascii characters "<" and ">" are typographically inappropriate because they just don't have the right shape and alignment with enclosed text, and because they will often get mis-parsed in wikitext as html tags. Fut.Perf. ☼ 19:23, 5 October 2015 (UTC)

These are the only sematically correct characters, namely U+27E8 ⟨ MATHEMATICAL LEFT ANGLE BRACKET and U+27E9 ⟩ MATHEMATICAL RIGHT ANGLE BRACKET. All the others are not the correct characters, or are obsolete in Unicode. These ones are the only future-proof version. -- [[User:Edokter]] {{talk}} 16:10, 5 October 2015 (UTC)

So what about past- and present-proof? Is the present not the most important of these three times? Isn't there some way for the template to switch to another bracket pair if one is rendered incorrectly? - HyperGaruda (talk) 19:01, 5 October 2015 (UTC)

Trouble is, there isn't really anything "present-proof" either, from what I can see. If there was any one encoding option that would yield a systematically more reliable user experience than the "correct" one, I'd be all for keeping that for the time being (and switch the template to the more correct option later once font support has caught up), but we've just heard from somebody who reported all the Unicode characters in question were actually missing in their setup. As long as this is dependent on the vagaries of any user's broser setup, local fonts installed and personal css settings, it will hardly be possible to find anything that makes everybody happy. Fut.Perf. ☼ 19:23, 5 October 2015 (UTC)

Mobile browsers and apps

I just checked the Wikipedia apps on an iPad running iOS 8 and on a Samsung phone running Android 4.4.4. The smartphone displays only whitespace for U+27E8/9 and the same full-width chevrons for the other pairs. It’s the same in the built-in browser and Chrome as well. The tablet render technical U+2329/A too wide, too, (and the same as East-Asian U+3008/9), but has nice glyphs and spacing for the mathematical pair in both, Safari and the WP app.

While iOS seems fine, has someone tested the Android situation more thoroughly? I’m not sure that would be enough an issue to think about alternatives (again). — Christoph Päper 17:24, 12 June 2015 (UTC)

My iPad1/iOS5.1/Safari (don't laugh) only displays boxes for U+27E8/9, while rendering the other brackets correctly. Samsung phone/Android 4.2.1/native browser only works correctly with math code and fullwidth CJK. - HyperGaruda (talk) 05:52, 5 October 2015 (UTC)

Webfonts via ULS

We can’t get the glyphs to display everywhere, but I guess we can do better than now. For instance, many people are using out-dated, unsupported, insecure operating systems (e.g. Windows XP) but run a recent version of a modern browser (e.g. Chrome, Firefox) on them. They should be able to benefit from automatically downloaded webfonts. As far as I can tell, Wikipedia should be able to use such because it has the Universal Language Selector extension enabled.

⟨foo⟩

However, I’ve never used that extension and it probably requires administrator privileges to set up a new “language” (ISO 639: und). We should also not compile a font just for two brackets, but probably for a number of technical / mathematical / linguistic symbols. Any volunteers? — Christoph Päper 20:33, 5 October 2015 (UTC)

Angle brackets appear as squares

Tracked in Phabricator
Task T116422

Guys, I think the current situation is a bit silly. I'm using Chrome on Windows 7, and the angle brackets don't appear correctly. They're squares. So I'm sensing the argument above is that for technical correctness, we should be using these &#x27E8; and &#x27E9; characters, and if as a reader your browser doesn't display it properly then tough luck, that's your fault. But that seems a slightly WP:POINTy argument though. Loads of people use Chrome on Win 7 and Win 8.1 (setups known to do this wrongly), and our primary goal is to serve our readers. It's possible this is one of the reasons why WikiMedia is sticking with rendering &lang; as character 9001 or whatever it is. Personally I would favour reverting this template to use &lang; and &rang; until this issue is sorted out for the majority of browsers. Even if this means that technically they get the wrong thing if they copy and paste the character from the page, but it would render more or less correctly. Thanks  — Amakuru (talk) 17:27, 21 October 2015 (UTC)

I’m afraid all the standard Windows fonts lack appropriate characters, but somehow Firefox, Safari etc. still manage to display angle bracket glyphs from some other font – since I don’t have a Windows box I cannot check where they take it from. Chrome – even the latest versions as far as I know – fails for some variants and maybe Opera, too. Anyhow, could you please check whether anything in the testcases works with your setup? — Christoph Päper 18:40, 23 October 2015 (UTC)

Windows 7 should not have any problem displaying angle brackets; either your browser is set to force a font that doesn't support it, or you are missing/have removed your Lucida Sans Unicode font. If every Windows 7/8 user would not see the brackets correctly, this page would be overwhelmed with complaints, but it isn't. So I believe this is a local issue. (I use Chrome on XP, and even my box shows the brackets just fine.) -- [[User:Edokter]] {{talk}} 19:00, 23 October 2015 (UTC)

It's not a local issue, please don't be in denial about this and see other comments above as well (search for "box").

These are the configs I tested, both at work and at home:

Configs tested

	Windows 7	Windows 10
Firefox	Y	Y
IE	Y	Y
Chrome	N	N

Arguably, we should pester Chrome to fix their crap instead (where? How?), but please don't dismiss the issue. Thanks. 84.92.159.90 (talk) 21:33, 26 October 2015 (UTC)

I totally agree. Us website builders should just use &lang and &rang and let the HTML5 use the correct symbol. As written immediately under the encoding options table at the top of the page, that is U+27E8 and U+27E9. Only Chrome messes this up. Firefox and IE work fine! On my iPad Safari works fine too. Puffin and Chrome mess it up. I see this as a bug in Chrome. You want to tell Chrome? Open Chrome and press Alt+Shift+I. My advice in the mean time (so until Google fixes their Chrome-bug): Use U+2329 and U+232A as it is visible in all browsers. On my iPad I get a spacing that is too big, but on my Desktop that does not happen with Chrome, nor with IE, nor with Firefox. Gradenkos (talk) 20:23, 29 October 2015 (UTC)

BTW: Weird... My iPod 4 with Safari did not show &lang en &rang, but does show U+2329 and U+232A without the wide spacing... Gradenkos (talk) 20:23, 29 October 2015 (UTC)

I contacted Google. The issue is known and registered here https://code.google.com/p/chromium/issues/detail?id=3176&q=27E8&colspec=ID+Pri+M+Stars+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&. If you go there you can click on the white star before 'Issue 3176'. This counts as a vote that you want Google to fix it. In the mean time you can keep nagging them with Alt+Shift+I as I wrote on the 29th of October 2015. Gradenkos (talk) 19:26, 26 November 2015 (UTC)

Google has fixed the issue! So use U+27E8 and U+27E9 or &lang and &rang to your heart's content. Gradenkos (talk) 11:23, 2 December 2015 (UTC)

{{braket}} merge?

Comparison of source codes and possible unification

State	Generic / linguistic template	Physics templates	Helper templates
Current	{{angle bracket}} = {{angle brackets}} = {{angbr}} = {{anglebracket}} = {{angle}} = {{infix}} = {{vr}} = {{grapheme}}: &#x27E8;{{{1|}}}&#x27E9;	{{braket}} = {{Dirac notation}}: <span class="nowrap">{{#switch:{{lc:{{{1|}}}}} |ket=&#124;{{{2|}}}{{rangle}} |bra={{langle}}{{{2|}}}&#124; |bra-ket={{langle}}{{{2|}}}&#124;{{{3|}}}{{rangle}} }}</span> {{bra}}: {{braket|bra|{{{1}}}}} {{ket}}: {{braket|ket|{{{1}}}}} {{bra-ket}}: {{braket|bra-ket|{{{1}}}|{{{2}}}}}	{{langle}}: &#x27E8; {{rangle}}: &#x27E9; {{nowrap}} = {{no wrap}} = {{no-wrap}} = {{nowr}} = {{no break}} = {{nobreak}} = {{nobr}}: <span class="nowrap">{{{1}}}</span>
Possible	{{infix}} = {{grapheme}}: {{angle bracket||{{{1}}}}} other redirects unchanged	{{bra}}: {{angle bracket|bra|{{{1}}}}} {{ket}}: {{angle bracket|ket|{{{1}}}}} {{bra-ket}}: {{angle bracket|bra-ket|{{{1}}}|{{{2}}}}}	unchanged
	{{angle bracket}} nested variant: <span class="nowrap">{{#switch:{{lc:{{{1|}}}}} |bra|( ={{langle}}{{{2|}}}{{!}} |ket|) ={{!}}{{{2|}}}{{rangle}} |bra-ket|(-) ={{langle}}{{{2|}}}{{!}}{{{3|}}}{{rangle}} |()| ={{langle}}{{{2|}}}{{rangle}} |#default ={{langle}}{{{1|}}}{{rangle}} }}</span>
	{{angle bracket}} flat variant: <span class="nowrap">{{#switch:{{lc:{{{1|}}}}} |bra|( =&#x27E8;{{{2|}}}&#124; |ket|) =&#124;{{{2|}}}&#x27E9; |bra-ket|(-) =&#x27E8;{{{2|}}}&#124;{{{3|}}}&#x27E9; |()| =&#x27E8;{{{2|}}}&#x27E9; |#default =&#x27E8;{{{1|}}}&#x27E9; }}</span>

The template {{braket}} for Dirac notation in quantum physics does basically provide the same features. It calls {{langle}} and {{rangle}} to get the angle bracket characters. Should they be merged? (Please note that the span and its “nowrap” class make no sense whatsoever in the single character templates.) — Christoph Päper 16:28, 7 December 2015 (UTC)

The nowrap class may extend beyond the last character of the span, so it does have effect. -- [[User:Edokter]] {{talk}} 17:05, 7 December 2015 (UTC)

nowrap makes no sense in inner templates/elements if it’s already specified on an outer one.

Removed class="Unicode" and {{Unicode}} from table. — Christoph Päper 16:55, 9 August 2016 (UTC)

Made more clear where which source code comes from and what was being proposed as a unified template. Fixed an error in the switch statement of the proposal. — Christoph Päper 15:00, 23 November 2017 (UTC)

Revert to non-disruptive version

The version of this template that was protected is precisely the one that was causing the disruption (see the ANI thread and the TfD discussion). I'm requesting that <noinclude>...</noinclude> tags be placed around the TfD notice like that:

<noinclude>{{Tfm/dated|page=Angle bracket|otherpage=Braket|link=Wikipedia:Templates for discussion/Log/2016 August 9#Template:Angle bracket|type=inline}}</noinclude>

Uanfala (talk) 18:03, 20 August 2016 (UTC)

Done — Andy W. (talk · ctb) 18:18, 20 August 2016 (UTC)

Requested move 27 April 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: withdrawn. (non-admin closure) Nardog (talk) 12:47, 4 May 2019 (UTC)

---

Template:Angle bracket → Template:Angbr – as it's shorter and commonly preferred among editors. The current name is not only lengthy but also awkward as it uses the singular form. For what it's worth, "angle bracket" is currently used by 833 articles and "angbr" by 809 articles. Nardog (talk) 21:41, 27 April 2019 (UTC)

oppose per WP:TG: Template function should be clear from the template name, but redirects can be created to assist everyday use of very popular templates. --Netoholic @ 22:21, 27 April 2019 (UTC)

• Oppose - Page titles, which includes templates, should be clear as to what they are. "Angbr" is the exact opposite of that. --Gonnym (talk) 11:00, 28 April 2019 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Brackets rendered incorrectly on Linux in 2019

The brackets are always huge in Firefox 67.0.2 and do not appear in Chromium 75.0.3770.90. It is possible to fix it somehow? Homo Computeris (talk) 14:54, 16 June 2019 (UTC)

@Homo Computeris: It's probably a font issue. I have Linux and Firefox 67, and the brackets aren't huge. — Eru·tuon 16:46, 16 June 2019 (UTC)

You're right, fontconfig dir should have STIX MathJax Main family as fallback for sans. Homo Computeris (talk) 23:21, 16 June 2019 (UTC)

By happenstance I guess, the default sans font in my browser or operating system (DejaVu Sans) displays angle brackets well, so I didn't have to do anything. It doesn't always get combining diacritics right though. — Eru·tuon 01:24, 17 June 2019 (UTC)

Not displaying correctly

"that will display correctly, even on operating systems and browsers that normally cannot display these characters when they are used in text"

For me they appear as boxes with hexadecimal digits. — Preceding unsigned comment added by 86.86.20.136 (talk) 23:35, 20 June 2019 (UTC)

It's an outdated description. The template doesn't do anything special anymore to ensure that the characters appear correctly. — Eru·tuon 00:11, 21 June 2019 (UTC)

Shortcut "vr"

Can anyone explain how this template acquired the shortcut name {{vr}}? Just curious. 𝕁𝕄𝔽 (talk) 13:58, 29 October 2023 (UTC)

You know what? I'm feeling my oats: @W. P. Uzer needs to explain their nearly decade-old deed, for I also cannot figure it out. Remsense诉 07:58, 4 March 2024 (UTC)

I honestly don't remember, and am quite curious myself now. Perhaps it was "br" for bracket, with a "v" in place of a "b" because the letter kind of resembles the angular shape? I doubt it was anything more profound than that. W. P. Uzer (talk) 15:24, 4 March 2024 (UTC)