#Leading and trailing whitespace not trimmed from html

19 messages ยท Page 1 of 1 (latest)

coral crater
#

Hello! I posted this on #general and they said to post it here.

I'm playing around with Astro for the first time, and something very weird is happening. It could be a bug, in which case I'll open an issue, but I can't help but feel I must be missing something obvious...

  • I start with npm create astro@latest and accept recommended settings
  • Start the dev server with npm start
  • Inspect the index page in dev tools
  • Here's the problem: html text has leading and trailing whitespace.
    • It's as if the whitespace from the editor isn't being trimmed - it only happens when the editor (vscode on wsl2 in my case) auto-formats the opening and closing tag on different lines.

(see image)

So... am I being an idiot and missing something, or shall I open an issue?

pure nexus
#

I'm not sure I quite follow, but in HTML (and so, in Astro) whitespace is never trimmed

coral crater
#

Hi @pure nexus, sorry if I've not explained this well

If you look at the screenshot in the post, there's leading (before the first " To") and trailing (after the "above. ") whitespace. (This is made very clear if you set white-space: pre-wrap)

What's happening is that this:

<p>Some text</p>

is rendered without leading/trailing whitespace as "Some text", but this:

<p attribute="string" class="another string to cause a line break">
  Some Text
</p>

is rendered with leading/trailing whitespace as " Some text ".

Does that make sense? Thanks for your swift reply!

red aurora
#

@coral crater before opening an issue, can you reproduce this in a minimal example with a raw html page and an .astro page where the issue can be seen. We can have a look and check. For filing an issue a minimal repo is mandatory anyway.

coral crater
#

@red aurora sure!

It's just the basic app that's generated by npm create astro@latest, I've not edited it.

I wasn't sure if this was just in development so I deployed it to Netlify. You can see it very easily in the browser:

  • Go to the netlify link above
  • Inspect the first p element and expand to see the whitespace
  • To make it really obvious just set white-space: pre-wrap
red aurora
#

@coral crater @pure nexus so here what I notice is that Astro compiler adds quotes when there is a middle tag, e.g.
but the end result in the DOM is the same given the underlying assumption of the standard referred to by Erika (she/her).
so from my perspective, I do not see any violation subject to a bug, unless you provide an example that does differ at the DOM level.

coral crater
#

Yeah the quotes are expected, it's the whitespace that's the problem.

I don't know whether this is a bug or not - I can see the same behaviour on the Astro website, for example - but there's obviously something going on here, because we can't have

<p>{text}</p>

rendering differently to

<p>
  {text}
</p>

Fair enough if this is some decision Astro have taken that other frameworks have treated differently, but then I need a workaround as the end result is intolerable.

pure nexus
#

This is how it works in HTML ๐Ÿ˜…

#

This happens in every single templating language that compiles down to HTML

red aurora
#

maybe you can explain more on why is this intolerable and how does it affect your end product, Astro team have always been listening to end user use cases, even if this is not a bug, it can be considered as an improvement (RFC), but the condition is that the added value has to be clear and convincing which is not the case in this post.

pure nexus
#

For what it's worth, I doubt we would divert from HTML's rules on this. We generally strive towards respecting them more if anything

red aurora
#

I also do not think deviating from the standard is an option.

#

I also understand that pipelines with Astro in the middle wish to have some underlying assumptions while Astro's compiler prefer to take advantage of the standard's freedom.

coral crater
#

Thank you both for taking the time to look into this. I've been having a little poke around and:

  • I can see this behaviour on the Mustache website
  • ... but not on the Handlebars website
  • This is definitely not how it works in React though (which is where I'm coming from)

So first of all, that's what I've done to work around this - I've just put it into a react component and there's no leading/trailing whitespace, as expected (well, expected by me at any rate ๐Ÿ˜€ ).

But the reason that it's intolerable is that code editors format your html and insert line breaks to make the code more readable - if those line breaks are reflected as added whitespace in the rendered html, then there will be inconsistent behaviour when you set the whitespace in CSS.

Take the following:

<ul class="whitespace-pre-wrap">
  <li>Some short text</li>
  <li>
    Some long text which causes the formatter to insert line breaks
  </li>
</ul>

As you can see from the screenshot, this is a problem.

In general, I wouldn't expect code editor visual formatting to make a difference to my rendered html.

But anyway, I have my workaround, I'll just have to use react for components where I'm doing stuff with whitespace. Sorry to have wasted your time, thanks again for looking into it ๐Ÿ™

pure nexus
#

JSX doesn't follow HTML whitespace sensitivity, hence why you don't see it in React ๐Ÿ˜„