`Component.preserveWhitespace = false` is too aggressive and not context aware

[cedx]

Same issue as the TypeScript flavor of Angular: angular/angular#21049
(read the feed for the full explanation of the problem).

I've tried to apply preserveWhitespace: false to my components, and ALL OF THEM have rendering glitches (i.e. words linked together).

A markup like: Foo <strong>Bar</strong> Baz (display: "Foo Bar Baz")...
...is processed to: Foo<strong>Bar<strong>Baz (display: "FooBarBaz").

If I want to have a proper display of my texts, I need to add an insane amount of &ngsp;/ .

I think that preserveWhitespace: false should ignore the (first) preceding/leading whitespace before/after tags within an inline formatting context.

[matanlurey]

That's surprising that all of them have glitches. Could you just use : true on some?

/cc @alorenzen

[alorenzen]

Because of the need for using an internationalization library like package:intl, most of our clients aren't actually doing a lot of inline text formatting in their templates. So we haven't found this to be an issue in practice for most teams.

I personally don't like the idea of treating some tags differently than others. Then, we're getting back towards being a full HTML compliant parser, which is certainly not a goal.

[cedx]

That's surprising that all of them have glitches.

@matanlurey Unfortunately, the project I'm working on has inline tags in almost every component template (it's more a showcase site than a web application). I have control over the Dart code but not the HTML design (there's a lot of <strong>, <em> and other inline tags).

most of our clients aren't actually doing a lot of inline text formatting in their templates

@alorenzen I had the opposite experience. For example, in my previous job, the translation was done by external translators using the Smartling system, which has a smart editor that is "HTML aware" (it properly extracts and shows text from the HTML tags, and inserts the translations back into those tags).
So, it was very common to embed HTML in source messages (like <strong> tags, but also <a> links: this allows you to translate an entire content, instead of dividing that content into X sections to translate).

If you look at the original AngularTS issue, you'll see that preserveWhitespace = false is also problematic in some translation contexts.

Then, we're getting back towards being a full HTML compliant parser, which is certainly not a goal.

I like the @Goodwine 's proposal of introducing another property (let's say spaceCollapsing, or change the existing preserveWhitespace property) that let customize the whitespace processing:

• preserve == preserveWhitespace = true
• remove == preserveWhitespace = false
• collapse : whitespace is reduced to a single space (thus preserving inline formatting contexts)

This change should be lightweight and easy to implement.

[furrary]

A markup like: Foo <strong>Bar</strong> Baz (display: "Foo Bar Baz")...
...is processed to: Foo<strong>Bar</strong>Baz (display: "FooBarBaz").

I find this really counter intuitive. IMO, if AngularDart aims to beproductivethis is not the way to go. We still use .html, so we need to respect some of its fundamental.

Because of the need for using an internationalization library like package:intl, most of our clients aren't actually doing a lot of inline text formatting in their templates. So we haven't found this to be an issue in practice for most teams.

It may not be your intention, but these sentences make me feel like the Dart team only care about large companies who write websites in global scale and don't really care about other people out there.

[matanlurey]

@furrary:

but these sentences make me feel like the Dart team only care about large companies who write websites in global scale and don't really care about other people out there.

To be clear, you can always use preserveWhitespace: true.

We need to be careful here, because we really don't want this to end up being too configurable (i.e. too many states or an enum of options), and at the same time, don't want it to be confusing (it clearly is today, I agree with you here). I'll speak to the rest of the team this week and try to get a consensus on how to move forward.

[ninachen]

We have a fair amount of inline text formatting in our templates and do run into this. As a counterpoint, though, the presence of whitespace in HTML can be an active hindrance.

Here's an example with undesirable whitespace: https://codepen.io/anon/pen/vdKWYa

Because we wish to keep the different DOM elements on separate lines for readability, the newline gets rendered as actual whitespace, which is undesirable in this case. So rather than using one of many possible hacky solutions[0] to get rid of the whitespace, it's great that preserveWhitespace: false absolves this problem while making the HTML file smaller to boot.

Personally, I'd much rather have to stick some   in the template than have to jump through hoops to get the template not to render the whitespace when it's unwanted. Or if the template has tons of whitespace that it wants to preserve, it can turn the option back on, as @matanlurey suggested.

[0] https://davidwalsh.name/remove-whitespace-inline-block

[Goodwine]

I disagree, the preserveWhitespace:false feature is buggy IMO.

The reason for its existence is letting us write readable HTML but have the compiler take care of things, basically removing all extra spaces.
The problem is that it's removing more than it should, and it's breaking expectations. It must render exactly the same thing regardless of the preserveWhitespace setting (again, IMO).

If for whatever reason this buggy behavior is seen as a feature to others. Then I believe that the behavior for preserveWhitespace:true should change to normalize all template whitespaces so we can get as much binary size reduction as possible but without being buggy.

[matanlurey]

Just so nobody is frustrated, we have consensus we should do something.

The primary maintainer of the AST code (@alorenzen) is out for a couple weeks, and I'd rather not make any decisions until he returns. Continue to please add your comments here on this bug, and we'll hopefully circle back soon.

[matanlurey]

We've decided @alorenzen will look at this when he gets back ;)

Andrew, see internal team notes, @ferhatb agrees we can loosen - let's chat when back.