Configure whitespace display css for custom components

[henry-alakazhang]

--html-whitespace-sensitivity css is nice when working with native HTML as it sets the display status properly (most of the time)

However, for custom components, it seems to always err on the side of caution and defaults to inline.

It would be nice if it were possible to set default display for custom JSX/NG/Vue? components. This would be nice for codebases where many components may be used in place of HTML elements.

Prettier 1.15.1
Playground link

--parser angular

Input:

<div>
  Something
</div>

<span>
  Something
</span>

<custom-inline>
  Something
</custom-inline>

<custom-block>
  Something Else
</custom-block>

<!-- display: block -->
<custom-block>
  Something Else
</custom-block>

<!-- it would be nice to set custom-block as "block" always -->

Output:

<div>Something</div>

<span> Something </span>

<custom-inline> Something </custom-inline>

<custom-block> Something Else </custom-block>

<!-- display: block -->
<custom-block>Something Else</custom-block>

<!-- it would be nice to set custom-block as "block" always -->

[christianmemije]

Somewhat related, it would also be nice to declare certain custom components (e.g. <pre-like-component/>) that are meant to act like a <pre/> element to remain pre-formatted and not inlined. This would also be helpful for custom JSX/NG/Vue components.

Playground link

[mashpie]

There might be tons of examples on custom elements that now get treated as standard html, but should be not - not an easy task (examples on vue-i18n):

Playground vue-i18n as inline-yaml

Playground vue-i18n as inline-json

in that case it could help to specify desired lang as

<i18n lang="yaml">
en:
  welcome: Welcome!
de:
  welcome: Willkommen!
</i18n>

or

<i18n lang="json">
{
    "en": {
        "welcome": "Welcome!"
    },
    "de": {
        "welcome": "Willkommen!"
    }
}
</i18n>

still there are a few more special cases imaginable (esp. as some packages/libs might not stick to official html/css specs), which makes me think a simple --html-ignore: i18n,custom-block option is the only common workaround and maybe even fastes to implement?

// 2-cents-end

[diminutivesloop]

It would be helpful if this supported non custom elements as well. In our codebase the styling we use to add custom markers to list items causes them to be whitespace sensitive and currently the only solution to avoid misaligned list items is to set htmlWhitespaceSensitivity to strict.

[alexander-akait]

@thorn0 What about do not apply html-whitespace-sensitivity option to custom components by default (or use strict)? I think it is real unsafe and can lead to broken code. On second step we can implement options/ability to describe custom components and their default display?

[thorn0]

@evilebottnawi It's already strict (inline) for custom (unknown) elements. So this issue is about your second step.

[diminutivesloop]

@evilebottnawi It's already strict (inline) for custom (unknown) elements. So this issue is about your second step.

This doesn't appear to be documented anywhere.
https://prettier.io/docs/en/options.html#html-whitespace-sensitivity
https://prettier.io/blog/2018/11/07/1.15.0.html#whitespace-sensitive-formatting

[Yogu]

This doesn't appear to be documented anywhere.

https://prettier.io/docs/en/options.html#html-whitespace-sensitivity

It is, just in the page you linked. The initial value for display is inline, it's just specified to be block for the standard block-evel elements. So custom elements have a default display value of inline, and strict is used. However, strict is not safe for white-space: pre, and so it is not for e.g. the `i18n element mentioned above.

However, applying a pre-safe formatting rule to all custom elements would basically stop prettier from working in a file that makes heavy use of custom elements, e.g. an angular template, because prettier could no longer really format them.

That being said, an option for overrides would be really good, but it should probably be easy to use a pre-compiled list (or a combination of them) from dependencies like @angular/material or your own UI frameworks.

Prettier currently prints a lot of code like this in our codebase:

        <nx-card-content>{{
            'view.recursionLimitReached.description' | translate
        }}</nx-card-content>

I think this is pretty hard to read. I would reformat it manually to

        <nx-card-content>
            {{ 'view.recursionLimitReached.description' | translate }}
        </nx-card-content>

But if the line gets shorter and you later decide to put it into one line by removing the line break, prettier keeps the spaces which makes it ugly again

        <nx-card-content> {{ 'view' | translate }} </nx-card-content>