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.
    – Shadow Wizard
    Commented Jun 29, 2014 at 7:02
  • 5
    @ShadowWizard It is preserved, but it is 8 spaces wide, is what I mean.
    – Boann
    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.
    – Shadow Wizard
    Commented Jun 29, 2014 at 7:23
  • @Caleb Firefox. And yes I'm sure that nothing is changing the default behavior.
    – Boann
    Commented Jun 29, 2014 at 7:26
  • 1
    @ShadowWizard hello = eight spaces wide.
    – Boann
    Commented Jun 29, 2014 at 7:27
  • @Boann no. 4 spaces here. Try different browser.
    – Shadow Wizard
    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.
    – Boann
    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.
    – Shadow Wizard
    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.
    – Boann
    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."
    – Boann
    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.
    – Boann
    Commented Jun 29, 2014 at 8:47
  • 1
    @Caleb, what browser are you using? I get tabs 8 wide in Chrome, Firefox and Safari.
    – Arjan
    Commented Jun 29, 2014 at 8:58
  • For those still confused, related: How does The Editor Handle Tab Characters?
    – Arjan
    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?
    – Arjan
    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.
    – Arjan
    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
2
  • I was wrong about the prefix for Opera; see the comments to my answer.
    – Arjan
    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.)
    – Arjan
    Commented Aug 15, 2015 at 13:34
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.
    – Boann
    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.
    – Arjan
    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.
    – Ry-
    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.
    – Largato
    Commented Jun 30, 2014 at 2:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .