I may have found a bug related to `box-sizing`? | Astro Lounge | Page 1

main stone Jul 21, 2024, 8:05 PM

#

Hey! Is this a bug related to how .astro files handle box-sizing: border-box; or am I misunderstanding something?

Take a look at the attached .astro file. When previewing this file in the dev server, the gray box exceeds the dimensions of my viewport and results in horizontal and vertical scrolling.

However, if you convert that same file into .html and view it in your browser, it acts as expected: the gray box is fully contained within the viewport without scrolling.

Thanks!

Edit: Adding the code here for convenience:

<!doctype html>
<html lang="en">
<head>
<style>
  html {
    -webkit-box-sizing: border-box;
    box-sizing: border-box;
    font-size: 100%;
  }
  *,
    ::after,
    ::before {
    -webkit-box-sizing: inherit;
    box-sizing: inherit;
  }
  body { margin: 2rem; }
  .box {
    /* This width shouldn't(?) affect the layout. As a .astro file it does, as a .html file it does not */
    width: 100%;

    /* This height calculation should not result in vertical scrolling. As a .astro file it does, as a .html file it does not */
    height: calc(100vh - 4rem);

    /* Hiding this padding value "fixes" the issue in the .astro file, but padding shouldn't(?) affect the box width */
    padding: 3rem;

    background: #ccc;
  }
</style>
</head>
<body>
  <div class="box"><p>Hello, world!</p></div>
</body>
</html>

📎 box-sizing-bug.astro

willow terrace Jul 21, 2024, 8:21 PM

#

The * is overwriting the html 's box sizing attributes.

#

This is because * will capture every tag, including the <html> tag. So you're effectively telling the html tag to inherit from the browser's defaults.

#

This is usually why resets do the following

* {
  box-sizing: border-box;
}

html {
  font-size: 100%;
}

#

https://stackblitz.com/edit/astro-jvvcot?file=src%2Fpages%2Findex.astro Here is a stackblitz I used to experiment on this.

main stone Jul 21, 2024, 8:43 PM

#

@willow terrace Oh excellent, thanks, I didn't realize * was overriding html. Any thoughts on why when I convert the incorrect file to .html it renders correctly in my browser despite the issue you caught?

Edit: Ok this is bizarre... when I copy your updated file into my local Astro instance and run the dev server, I still see the original issue (despite it working perfectly in your stackblitz).

willow terrace Jul 21, 2024, 9:14 PM

#

main stone <@342740505693519893> Oh excellent, thanks, I didn't realize `*` was overriding ...

you definitely don't need the -webkit prefix by the way.

willow terrace Jul 21, 2024, 9:14 PM

#

main stone <@342740505693519893> Oh excellent, thanks, I didn't realize `*` was overriding ...

Perhaps something is cached. Have a look at the actual HTML and CSS in the browser.

main stone Jul 21, 2024, 10:06 PM

#

@willow terrace I cleared the cache in Chrome and tried again. Same issue. If it's not a hassle, do you mind trying to preview the file with the dev server on your local machine? Because when I inspected the code on localhost:4321, it looked like the * is being stripped away. I'm on v4.11.3 if it helps.

willow terrace Jul 21, 2024, 10:31 PM

#

main stone <@342740505693519893> I cleared the cache in Chrome and tried again. Same issue....

Stripped away how? What is it doing?

main stone Jul 21, 2024, 10:51 PM

#

@willow terrace Screenshot below. This is what I see in Chrome dev tools. Looks like the * is removed. This is also after fully clearing browser cache and creating a new Astro project.

[data-astro-cid-j7pv25f6],::after[data-astro-cid-j7pv25f6],::before[data-astro-cid-j7pv25f6] {
    box-sizing: border-box
}

#

tawny parrot Jul 21, 2024, 11:20 PM

#

If it's a global style why not put it in a global css file and use it that way?

I don't know if it will fix anything you're experiencing though

main stone Jul 21, 2024, 11:27 PM

#

tawny parrot If it's a global style why not put it in a global css file and use it that way? ...

@tawny parrot For sure! I agree. I created this very basic page just to illustrate the issue I was experiencing. But in my actual project I do use a global CSS file.

willow terrace Jul 22, 2024, 12:27 AM

#

Try removing the comments. Perhaps there is a formatting issue and the comment * is confusing it

willow terrace Jul 22, 2024, 1:45 AM

#

Also see if putting the selectors all on one line matters versus mult line

velvet parrot Jul 22, 2024, 1:47 AM

#

It looks like the compiler is replacing * with [data-astro-cid-j7…] which will scope the wildcard selector to all elements if the elements are defined within the file you write the style in. If you use :global(*) instead, that should fix the discrepancy.

#

Alternatively you can change <style> to <style is:global>

#

This is your wildcard * selector after compilation

willow terrace Jul 22, 2024, 1:51 AM

#

yeah, that's what I noticed in your screenshot earlier.

#

My guess is the * is getting confused with a comment. hence try reducing the example and removing CSS comments. I'll see if I can reproduce this in stackblitz.

velvet parrot Jul 22, 2024, 1:53 AM

#

It’s not getting confused with a comment, Astro scopes styles by default and that includes the wildcard selector

#

https://docs.astro.build/en/guides/styling/#scoped-styles

Docs

Styles & CSS

Learn how to style components in Astro with scoped styles, external CSS, and tooling like Sass and PostCSS.

willow terrace Jul 22, 2024, 1:56 AM

#

velvet parrot It’s not getting confused with a comment, Astro scopes styles by default and tha...

but the issue here seems to be that the scope is still missing the wildcard; wouldn't it look like the following?

[data-astro-cid-xxx] *

#

Instead it's just

[data-astro-cid-xxx]

velvet parrot Jul 22, 2024, 1:59 AM

#

[data-astro-cid-xxx] * would target all children of [data-astro-cid-xxx] elements but not the element itself. Because that cid data attribute gets applied to every element in this view, * and the data attribute are effectively equivalent, or should be.

willow terrace Jul 22, 2024, 2:01 AM

#

Okay, so right now it's scoping for itself but not any descendents.

velvet parrot Jul 22, 2024, 2:01 AM

#

But obviously not the behavior OP wants or expects, which is why a global flag is necessary to tell Astro not to scope the rule.

#

Yeah any child views wouldn’t get that rule applied

willow terrace Jul 22, 2024, 2:02 AM

#

Sure; however, this still seems to be an issue with scoping.

#

If I use * on scoped css, I'd expect the namespacing to include it as [scoped-xxx], [scoped-xxx] * so that it's behaviour is the same as a top level *

#

because where the OP is scoping from is technically the top of the document anyways; so it should behave more or less like a global style and apply to itself and all its descendents. Right?

velvet parrot Jul 22, 2024, 2:11 AM

#

You still need to use :global(*) for that behavior. If the behavior was changed the way you suggest, then styles would leak from the scoped elements into unscoped descendants. (Which in this case is desired, but might not always be)

#

I agree this is kind of confusing behavior though

willow terrace Jul 22, 2024, 3:18 AM

#

Ah I see. I thought leaking into sub-elements was expected behaviour even with scoped styles. Like, the styles are scoped to the parent and anything inside is going to inherit from that. I didn't realize that's trying to be avoided.

#I may have found a bug related to `box-sizing`?