11

Markdown renders tabs as 4 spaces, but browsers traditionally render tabs using a width of 8, so they look like 8 spaces in the edit box. It is possible to override the display tab size using the relatively new CSS tab-size property. I'd like for that to be done so that the width of tabs in the edit box is the same as it is in the output.

https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size

http://dev.w3.org/csswg/css-text-3/#tab-size-property

Improve this question
16
  • 2
    Not sure what you mean. If I copy and paste text with a TAB character, the TAB is preserved in the editor. It's not rendered to spaces. Maybe you have some userscript doing it. Commented Jun 29, 2014 at 7:02
  • 5
    @ShadowWizard It is preserved, but it is 8 spaces wide, is what I mean. Commented Jun 29, 2014 at 7:14
  • @Boann no it's not. See this screenshot, the top line got a tab and the second line got four spaces. So for me TAB renders as 3 spaces. Something on your side is wrong. Commented Jun 29, 2014 at 7:23
  • @Caleb Firefox. And yes I'm sure that nothing is changing the default behavior. Commented Jun 29, 2014 at 7:26
  • 1
    @ShadowWizard hello = eight spaces wide. Commented Jun 29, 2014 at 7:27
  • @Boann no. 4 spaces here. Try different browser. Commented Jun 29, 2014 at 7:28
  • 3
    @ShadowWizard No you don't understand. hello is literally eight characters wide in your screenshot, so it proves nothing. Commented Jun 29, 2014 at 7:31
  • OK, no idea what you mean, and I don't want to change the way TAB works for me, so -1 for the feature request. Commented Jun 29, 2014 at 7:51
  • 3
    @ShadowWizard The rendered width of an individual tab character is such that it puts the next character at the column which is the next multiple of the configured tab size. This is what a tab size of 4 does (each arrow is 1 tab character): i.sstatic.net/K3uMu.png. That's how it works in literally every text editor everywhere and in the edit box and in code blocks in the rendered markdown output on SE and always has. I'm not asking to change how it works. I'm just saying that the size is clearly actually literally definitely different between the markdown output and the editor. Commented Jun 29, 2014 at 8:00
  • 4
    For the default size, see w3.org/TR/CSS2/text.html#white-space-model: "All tabs (U+0009) are rendered as a horizontal shift that lines up the start edge of the next glyph with the next tab stop. Tab stops occur at points that are multiples of 8 times the width of a space (U+0020) rendered in the block's font from the block's starting content edge." Commented Jun 29, 2014 at 8:08
  • 3
    I don't quite understand why people don't understand what I'm asking. Here is a post of mine which I intended using tab characters: stackoverflow.com/posts/16846375/edit. Notice, in the edit box, the indentation is 8 characters wide. In the output below, it is 4 characters wide. I'm just suggesting that it be made 4 in the editor too so that there is harmony (at least on this site) and so that editing such posts is easier. That's all. If you prefer to indent with spaces than tabs, then don't worry because this change won't affect you. Commented Jun 29, 2014 at 8:47
  • 1
    @Caleb, what browser are you using? I get tabs 8 wide in Chrome, Firefox and Safari. Commented Jun 29, 2014 at 8:58
  • For those still confused, related: How does The Editor Handle Tab Characters? Commented Jun 29, 2014 at 9:04
  • @ShadowWizard, this won't change the way the Tab key works, but it would change how tabs are shown. It would make what is shown in the editor (textarea) match what is shown in the Markdown preview and in its final result. For most browsers, such is not the case now. Are you sure you prefer a different display width in the edit box (textarea) and in the Markdown results? Commented Jun 29, 2014 at 9:16
  • 1
    It's not about real spaces, @ShadowWizard. With the default tab width of 8, if you type 1 character followed by a tab, then the cursor goes to the 9th column. If you would have typed 5 characters, followed by a tab, you still would end up at the 9th column. However, the SE Markdown preview and renderer would move to the 5th column for the first, and to the 9th for the second example. See the tab characters at the start of the lines in this fiddle, which to me looks like this. Commented Jun 29, 2014 at 9:51

2 Answers 2

Reset to default
12

Very nice, I honestly didn't know about tab-size. That's indeed a no-brainer. Added to the next build.

Improve this answer
4
  • I was wrong about the prefix for Opera; see the comments to my answer. Commented Jun 30, 2014 at 4:42
  • In case you did not realize (like me): it would be nice to do the same when rendering the actual posts, and stop converting tabs to spaces as some things, like makefiles, rely on tabs. (And Python might break on mixing spaces with tabs.) Commented Aug 15, 2015 at 13:34
  • tab-size is missing again in the new frilly editor on Stack Overflow. Commented Jul 10 at 16:46
  • 1
    @Boann Thanks, I've pinged the team working on the editor. Commented Jul 10 at 17:42
7

Nice, if all major browsers support this, to avoid confusion when people switch browsers.

Unfortunately, Internet Explorer has no support, and Firefox needs the -moz prefix, so minitech once suggested the following:

Non-content-destroying fix to at least make indentation less of a guessing game:

.wmd-input { -moz-tab-size: 4; -o-tab-size: 4; tab-size: 4; }

I think the -o prefix for Opera is no longer needed. For me, the above works fine for the latest Chrome, Firefox and Safari, but no cigar for Internet Explorer 11; see this JSFiddle:

I'd say: yes, please.

Improve this answer
4
  • This is odd: For the textarea in the fiddle, -moz-tab-size doesn't seem to work, but when I right-click and do "Inspect Element" on the editor on this site and add the property there, it does. Edit: Sorry, am very tired. It does work properly in Firefox in the fiddle textarea and here. Commented Jun 29, 2014 at 9:02
  • @Boann, it seems IE has no support, and the -moz prefix was actually documented on MDN as well. So I rewrote my answer a bit. Commented Jun 29, 2014 at 10:35
  • 1
    Note that most Opera packages for Linux are still 12.x – not that this isn’t a progressive enhancement. Commented Jun 30, 2014 at 2:47
  • 1
    @minitech and there are Opera users that prefer the Presto engine. Indeed, the security updates for 12 still happens independently of the 15+ updates. Also, there's a link to download 12 in the "opera for desktop" page for Windows too. Commented Jun 30, 2014 at 2:59

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.