Newlines as whitespace text

[RReverser]

Currently contents like

<b>{this.title}</b> <span>123</span>

are converted to

React.DOM.b(null, this.title), " ", React.DOM.span(null, "123")

which is logical and expected since whitespace might change the layout (i.e. inside element with white-space: pre and in other cases).

However:

<pre>
    <b>{this.title}</b> <span>123</span>
</pre>

is converted to

React.DOM.pre(null, 
    React.DOM.b(null, this.title), " ", React.DOM.span(null, "123")
)

so whitespaces across newlines are inserted only in code, but not treated as regular text, which means we loose them completely in generated layout.

Shouldn't we treat them as text too?

[syranide]

This is entirely intentional, facebook/react#480.

Summary: Indenting/beautifying code should never affect the outcome, especially as it means all indentation has to carry over into the final code and cannot be minified away (yuck!). While there are a handful of cases where you might want the newlines to affect outcome, those are far better handled explicitly by {' '} or {'\n'}.

PS. This belongs in React as sebmarkbage believes whitespace rules are best left outside of the spec.

[RReverser]

PS. This belongs in React as @sebmarkbage believes whitespace rules are best left outside of the spec.

Ah, if we leave this outside the spec, then fine. Because for implementations like @vjeux / JSXDOM, preserving all the whitespaces is critical IMO as it's expected to replicate HTML behavior (and this is not currently supported by esprima-fb even as an additional option).

Though, even for React things like {'\n'} in JSX look ugly personally to me, and even worse that easily-gzipped whitespace overhead in generated JS. Reminds dark middle-age times of React when we really had to use {' '} for every single space that needs to be preserved.

[syranide]

I can count the number of times I've had to use {'\n'} on one hand (and I still prefer it, it's explicit; explicit > ugly) and the thousands of times it would have otherwise inserted unwanted white-space. If you're trying to insert tons of white-space: pre-text use a string or template string even, problem solved.

I think the fact that it is easily gzipped is irrelevant, it shouldn't be there, and it has to be reproduced in the DOM which has a very real performance cost. On the order of one TextNode for every element, that's not acceptable. Not being able to structure code sensibly but having to worry about affecting layout/performance is rediculous, regardless of whether that's how HTML behaves or not.

HTML sucks in many ways (and sometimes because it has to), there's no reason to keep the bad things when we have all of JavaScript at our disposal to solve practical problems in better ways.

[RReverser]

I think the fact that it is easily gzipped is irrelevant, it shouldn't be there

I thought it was the reasoning why you didn't want to see it there. Can't see any other meaningful reasons.

it has to be reproduced in the DOM which has a very real performance cost

Not really - text nodes are lightweight and fast to insert/render + this part will be usually static and not changed in time.

HTML sucks in many ways (and sometimes because it has to), there's no reason to keep the bad things when we have all of JavaScript at our disposal to solve practical problems in better ways.

IMO we are building tools that allow to work with HTML DOM in really simple and fast way. But we shouldn't change semantics of HTML on our own only because we don't like some of it's parts.

One of strong parts of React that many teams see is that layout guy (the one that knows only HTML/CSS and saw some templating solutions) can easily open any React component and work with JSX block as with regular layout, just being told to use className instead of class, htmlFor instead of for and {...} for templating.

Just that simple.

He shouldn't rack his brain on why layout is different from what he wrote in that block and definitely shouldn't google how to insert extra whitespace in the layout (it's not just about white-space: pre - we don't even have single whitespace inserted between elements that are on different lines).

[syranide]

He shouldn't rack his brain on why layout is different from what he wrote in that block and definitely shouldn't google how to insert extra whitespace in the layout (it's not just about white-space: pre - we don't even have single whitespace inserted between elements that are on different lines).

Pretty much every single project I've ever worked on has used a post-process for stripping white-space out, it's has worked fantastically to get consistently pixel-perfect layouts, across all browsers. Pretty much every out-sourced HTML-file I've received that hasn't had it applied has had magic numbers and offsets tweaked by designers to compensate for implicit white-space. Worse than that, the offsets introduced by unwanted implicit white-space are font-size/line-height dependent, there is no excuse for that.

What if he didn't want white-space inserted between these?

<span className="count">10</span>+
<span className="extra">15</span>/
<span className="total">40</span>=
<span className="total">25</span>

Oh right:

<span className="count">10</span>+<span className="extra">15</span>/<span className="total">20</span>=<span className="total">20</span>

But if he really does:

<span className="count">10</span>{' + '}
<span className="extra">15</span>{' / '}
<span className="total">40</span>{' = '}
<span className="total">25</span>

This is much more flexible and precise, you can have as many spaces (or tabs, newlines) before and after as you want. You can realistically even use white-space: pre-wrap as a default style for your entire app, there is no unwanted white-space. HTML offers none of this unless you write everything on a single line.

IMO we are building tools that allow to work with HTML DOM in really simple and fast way. But we shouldn't change semantics of HTML on our own only because we don't like some of it's parts.

We've added valueLink, changed the meaning of value, onChange, etc. <textarea> uses value instead of children. style is an object with camelCase-keys, not a CSS-string (and they're not equivalent), float should be used instead of cssFloat and classSet will probably make an appearance in the future. All attributes are camelCased. JSX requires <input /> instead of <input>. The list goes on.

The ReactDOM-implementation is tailored to everyone's best interests and I'm certain it will continue to be. AFAIK there is no written goal of implementing HTML DOM 1:1 and React diverted away from that day 1. If that's what someone really wants, then just fork JSX or add your own JSX preprocessor (the current JSX white-space rules are completely compatible). To my knowledge no one has and no one has complained.

[RReverser]

Pretty much every single project I've ever worked on has used a post-process for stripping white-space out, it's has worked fantastically to get consistently pixel-perfect layouts, across all browsers. Pretty much every out-sourced HTML-file I've received that hasn't had it applied has had magic numbers and offsets tweaked by designers to compensate for implicit white-space.

Looks like me and you had really different experience and projects.

What if he didn't want white-space inserted between these?

No need to put everything on one line - it's easy to:

<span className="count">10</span>+{
}<span className="extra">15</span>/{
}<span className="total">40</span>={
}<span className="total">25</span>

Very explicit, just like you like, but turned into different direction :) And no need to put any special escaped characters inside.

The list goes on.

Most of these are really React-specific extensions and yes, some of them have same names as HTML attrs so need to be learned specifically. Things like valueLink are more about JS part and have nothing to do with HTML itself, and classSet is also separate convenient addition that doesn't break anything.

Still, let's get abstracted from React - I've created issue in JSX because I'm currently more interesting in spec for other implementations and parsers, and don't really want to spend time discussing React here :)

If @sebmarkbage says that we just keep whitespace handling outside the spec, then I'm fine with closing this issue and continuing own work with preserved whitespaces. But I want to follow same spec as close as possible, so if whitespace handling used in React is meant to be standard for any JSX implementations, then would be nice to add this explicitly to spec and remove it in own project, too.

[syranide]

I know that at least all of these suffer from it:

<div style="font-size: 100px">
  <span style="font-size: 10px; background: #ff0000">Button #1</span>
  <span style="font-size: 10px; background: #00ff00">Button #2</span>
</div>

These two doesn't even render the same:

<div style="font-size: 100px">
  <span style="font-size: 10px; background: #ff0000">
    Button #1
  </span>
  <span style="font-size: 10px; background: #00ff00">
    Button #2
  </span>
</div>

<div style="font-size: 100px">
  <div style="font-size: 10px; background: #ff0000; display: inline-block">Button #1</div>
  <div style="font-size: 10px; background: #00ff00; display: inline-block">Button #2</div>
</div>

<div style="font-size: 100px">
  <img src="error.jpg" width="10" height="10" style="background: #ff0000">
  <img src="error.jpg" width="10" height="10" style="background: #00ff00">
</div>

Note that lack of explicit padding in the code, also tweak the outer font-size and watch.

PS. They are not made up fantasy edge-cases, you find them everywhere.

[sebmarkbage]

See #6 for why white-space behavior is unspecified. Basically, the fact that we have this controversy here is the primary reason to leave it out of the spec for now.

It's kind of inconvenient that this is underspecified because this tends to be built into the parser rather than the transformation step. However, for many use cases this doesn't matter. E.g. syntax highlighters doesn't care.

Perhaps we need to document WHY white-space isn't specified?

I'd recommend that we open up an issue on React where we can discuss this in the context of React specifically (which doesn't involve JSXDOM and other use cases). There are more interesting aspects of this when a composite component has to reason about the extra white-space.

[RReverser]

See #6 for why white-space behavior is unspecified.

Oh, didn't find it on my own. Sorry for that.

It's kind of inconvenient that this is underspecified because this tends to be built into the parser rather than the transformation step.

Exactly. That's why I proposed preserving whitespaces on parser level - this would be suitable as for transformers that do care about preserving them (yay JSXDOM!) as well as for transformers that intentionally don't (React's jstransform can easily strip parsed whitespaced that contain \n).

Perhaps we need to document WHY white-space isn't specified?

Yeah, even this would be helpful. At least others could find information on same question on the main page instead of opening another issue.

I'd recommend that we open up an issue on React where we can discuss this in the context of React specifically (which doesn't involve JSXDOM and other use cases).

Might make sense. As I said previously, at this moment I'm interested in this question on spec+parser level, abstracted from React, but if you create one, please /cc me, would be interesting to track and/or participate.

[syranide]

Exactly. That's why I proposed preserving whitespaces on parser level

AFAIK it is preserved by the parser, it's the JSX transform that strips it. Although we discussed (and actually agreed on) moving it to the parser instead in facebook/react#1514 facebookarchive/esprima#19, as HTML-entities should be decoded after stripping white-space and it actually makes most sense to do both in the parser.

[RReverser]

@syranide Sorry, I might not remember details of topic being discussed ~2 months ago but didn't we discuss trimming whitespaces on ends of content and not whitespaces in between?

[garthk]

I'd like to see whitespace inserted on all newlines that aren't between adjacent tag boundaries, before the first non-whitespace text in a tag, or after the last non-whitespace text in a tag. It's least surprising, and (unless I'm missing something) can be done without harm to the list of edge cases above.

Consider:

<p>
a
b
c
<p>

yields:

React.createElement("p", null, 
"a" + ' ' +
"b" + ' ' +
"c"
)

Given that, I'm shocked when the spaces disappear when I replace one line in the text with a tag:

<p>
a
<a>b</a>
c
</p>

yields:

React.createElement("p", null, 
"a", 
React.createElement("a", null, "b"), 
"c"
)

What harm am I missing, apart from possibly lending moral support to an HTML feature @syranide calls "horrible" in facebook/react#480, that would come if we preserved whitespace for the following newlines?

• between text and begin-tags, e.g. text\n<div>
• between end-tags and text, e.g. </div>\ntext

EDIT: I dimly recall getting annoyed about whitespace being preserved before some tag inside an anchor, once. I'm not sure it's more annoying than having to scatter {' '} everywhere. More examples may persuade me otherwise.

[syranide]

@garthk I'm not a fan of whitespace rules for text at all, to lend some more context #28 (and #8 #35).

... would come if we preserved whitespace for the following newlines?

If you were to have that there would no longer be a way not to have whitespace between text and tags (except for making the entire string an expression), whereas the current way allows you to easily add whitespace you think it should be there and you'll also be explicit for others benefit. The verbosity and side-effects of {' '}is undesirable though (hence why I'd like to see #28 or whatever) but the alternative is far worse in my opinion.

Inserting whitespace between text lines makes quite a lot of practical sense, it's almost certainly what you wanted as you break on space when lines get too long and if you don't like it you can just put {} at the end and it's gone. Whereas foo\n<tag>bar</tag> having a whitespace but not <b>foo</b>\n<tag>bar</tag> feels ambigious and means that using newlines to structure your code affects the outcome of it (which is part of what I think is horrible).

I think it's important to remember, especially now with React-Native, that HTML whitespace rules makes absolutely no sense for frontends other than HTML, JSX is not a markup language.

tl;dr I don't like the whitespace rules, but IMHO it's the best compromise. I think an alternative (not strictly HTML) approach is necessary.

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.