Ability to insert styles at a specific position in <head> #2037

jdb8 · 2020-10-08T07:00:37Z

The problem

I see that @emotion/cache provides a container option, which seems like it's useful for having some control over the DOM element that emotion inserts its <style> nodes into. Unfortunately, I can't find a way to use this for my purpose, which is to control the position of the inserted nodes in the document head.

The reason I need this is to have more fine-grained control over rule ordering in a page that has existing styles (which are sadly often composed with the newer Emotion-generated classnames). I'd like Emotion (both on the server and client) to insert all of its <styles> (both those initially on the page as well as those dynamically inserted later on) at a specific position in the <head>.

Initially I thought I could use the container option, but that seems to have two problems here:

it deals only with nesting inside a container, not adjacent to, and...
it doesn't seem like there are any compatible container elements that accept <style> children in the <head>

Together, these two issues make it hard to find a way to do what I want here with any existing Emotion apis.

Proposed solution

Webpack's style-loader provides an insert option which can be given a function to be run in order to determine the position of any inserted styles. Something like this might work here too.

Alternative solutions

Another option might be to introduce a more flexible version of container - not a full function like style-loader, but an insertAdjacentTo, replaceCommentWith or something similar to allow for more control over the placement?

Additional context

Also, based on my problem statement - if there's any existing way to do what I want in Emotion 10, it goes without saying that I'd be very grateful to hear so :)

The text was updated successfully, but these errors were encountered:

Andarist · 2020-10-08T08:53:27Z

it doesn't seem like there are any compatible container elements that accept <style> children in the

That's not quite true - probably some validators might yell at you, but all browsers supports div elements within the head.

Also, based on my problem statement - if there's any existing way to do what I want in Emotion 10, it goes without saying that I'd be very grateful to hear so :)

It's not possible with Emotion 10 and we do not plan to introduce such an option. However, Emotion 11 - which is just around the corner - has a new prepend option that should fix your problem. Yes - it's a boolean so either your styles are appended or prepended to the container but I don't think much more control is needed over this.

jdb8 · 2020-10-08T20:38:03Z

That's not quite true - probably some validators might yell at you, but all browsers supports div elements within the head.

I had tried with a <div> in the head but saw some weird-looking behaviour where Chrome would show all subsequent <head> elements as if they were in the <body> (when looking at the elements tab in dev tools) - it was unclear if this was just a quirk of devtools or would actually change behaviour for browsers loading the page (or other scripts making assumptions about where elements are located in the page). After posting this issue, I did start playing around with using a meta tag as a container (!) and sure enough it seems to work in the browsers I tested, without the same quirk (but feels even weirder given that meta is a void element in the spec 😱

I'll probably stick with the meta approach - at least until I run into any insurmountable issues - since it seems to work and lets me hydrate to that container, but it's good to hear that Emotion 11 will offer a bit more control. I suppose your suggestion with the Emotion 11 prepend boolean would be to stick with document.head but choose to prepend, which would ensure that all emotion tags would end up at the start of <head> - am I understanding that correctly?

Andarist · 2020-10-08T20:41:44Z

I suppose your suggestion with the Emotion 11 prepend boolean would be to stick with document.head but choose to prepend, which would ensure that all emotion tags would end up at the start of - am I understanding that correctly?

Yes, pretty much that 😃

gregjacobs · 2020-10-31T18:09:07Z

I have another use case for this where we need Emotion's CSS classes to have lower specificity than a user's own CSS classes. We're building a library using Emotion where we want a user's CSS classes to be able to override the styles of our library components.

I noticed that the StyleSheet class (inside @emotion/sheet) has a before property, initially assigned to null, that could easily be provided as an option to the constructor instead.

One could provide head.firstElementChild as the before option in this case to prepend Emotion's <style> tag inside the <head>. This new option would also give the flexibility to place Emotion's <style> tag anywhere in the <head> too relative to another element. Thinking that the interface could be as simple as:

import { createEmotion } from '@emotion/create-emotion';

const emotion = createEmotion({
    container: document.head,
    insertBefore: document.head.firstElementChild
});

Is this a possible change to make in v10? If so, I'd be happy to submit a PR.

Andarist · 2020-10-31T18:59:38Z

Is this a possible change to make in v10? If so, I'd be happy to submit a PR.

We do not plan to introduce this to v10. As mentioned - v11 has the prepend option that solves this problem and I plan to release v11 as stable on 11.11.2020, so 🔜

gregjacobs · 2020-10-31T20:09:54Z

@Andarist kk, thx, good to know that v11 is close then.

Quick question if you happen to know the answer: are there any performance issues in browsers caused by prepending a <style> element and rules in front of existing <style> or <link rel="stylesheet"> elements? (as opposed to appending the rules like the current behavior of Emotion?)

<html>
    <head>
        <style data-emotion="css"></style>        <!-- exists second -->
        <link rel="stylesheet" href="sheet.css">  <!-- exists first -->
    </head>
    <body>
        ...
    </body>
</html>

Do you know of any performance issues either during initial page load, or at a later time by dynamically prepending rules in front of maybe a few thousand existing rules?

Andarist · 2020-10-31T20:32:39Z

I don't know about any perf issues regarding that but I haven't really ever thought about this. My intuition would be that there shouldn't be much of a difference between appending & prepending but I might be wrong.

gregjacobs · 2020-10-31T21:35:02Z

Ah ok, no worries, I'll try to do some testing and will let you know if I find anything

gregjacobs · 2020-11-10T16:29:41Z

@Andarist Did some testing and didn't find any difference in re-render performance in Chrome with prepending, at least in the case that styles are prepended after initial page load. Still need to do a test for initial page load with regular stylesheets + prepending, and in other browsers.

gregjacobs · 2020-11-24T19:28:22Z

Does the new prepend option in v11 cover this use case?

Andarist · 2020-11-24T19:43:27Z

I believe it does - we dont intend to introduce more control over insertion point than what is already provided in v11

oliviertassinari · 2021-05-31T22:20:16Z

@Andarist is the motivation for rejecting the feature in #2037 (comment) lack of bandwidth or concern about the extra complexity involved?

Andarist · 2021-06-01T12:04:16Z

@oliviertassinari mainly about the added complexity. We can reconsider this though - the new API (option?) would have to replace prepend (it would be deprecated) because maintaining multiple options for a very similar thing is not something that I'd like to do. If you care about this then please start a new issue with the initial proposal for the feature.

oliviertassinari · 2021-06-01T12:27:05Z

@Andarist OK, We might POC around to explore the feasibility of bringing this with a PR in the future.

At this point, MUI v5 has about 1% of adoption of v4, so we will hear more about the need for this feature as more developers migrate. We have recently seen an interesting use case with Tailwind, where the TW CSS reset needs to apply before MUI but the TW classes after MUI. Sure we could say that, nop don't use TW with MUI but I don't think that it would be the best strategical direction. Better embrace the alternatives options and make the ones you propose more appealing.

DominikSerafin · 2021-12-02T12:55:30Z

@Andarist @oliviertassinari, I'm migrating to MUI v5 and this became a bit of a problem for me. My styles insertion order should be like this:

Custom reset styles (similar to MUI <CssBaseline>, but with some additional custom resets)
MUI emotion styles
Custom styles (that include overwrites for MUI styles)

Now, this is fairly straightforward during SSR, since I can control where the styles from emotion cache are inserted. However, during CSR there's no way to control where the styles are inserted inside the <head> (other than prepend option, which doesn't help here).

My workaround was to move styles into <body> and use <div> container for emotion styles, but I'd prefer to keep them in <head>.

Sure we could say that, nop don't use TW with MUI but I don't think that it would be the best strategical direction. Better embrace the alternatives options and make the ones you propose more appealing.

I'm not using Tailwind, but my use case is pretty similar, so I agree with this 💯%.

Andarist · 2021-12-02T13:18:29Z

However, during CSR there's no way to control where the styles are inserted inside the (other than prepend option, which doesn't help here).

Since this got merged in and shipped this statement is no longer true. I'm not sure if this option has been exposed in MUI though - you'd have to look there for an answer to that.

DominikSerafin · 2021-12-02T14:32:50Z

@Andarist, I'm using @emotion/cache@11.6.0 directly (as per MUI docs), and the insertionPoint option works great, thank you! Although, it seems docs don't have it documented (yet?).

There's also another somewhat related issue, which probably warrants a new issue in MUI repo (but I don't currently have time to properly submit it with minimal repro, etc.), but just FYI:

Some animations (seems to be from MUI LinearProgress) are still appended at the end of <head>, regardless if prepend, container or insertionPoint is configured.

And on the server render, these animations are at the beginning of constructStyleTagsFromChunks output (which seems OK):

@oliviertassinari

Andarist · 2021-12-02T21:59:49Z

Interesting - would love to get a repro case for that, I could then investigate this quickly.

jdb8 added feature request needs triage labels Oct 8, 2020

Andarist removed the needs triage label Oct 8, 2020

Andarist closed this as completed Nov 24, 2020

oliviertassinari mentioned this issue May 31, 2021

[v5] CSS injection order is wrong mui/material-ui#24109

Closed

sebald mentioned this issue Oct 13, 2021

Re-introducing @emotion/react [Summary Issue] marigold-ui/marigold#1395

Closed

18 tasks

mnajdova mentioned this issue Oct 20, 2021

Add insertionPoint option in EmotionCache #2521

Merged

4 tasks

paales mentioned this issue Jan 7, 2022

Injection order of tss and regular styles are in the wrong order for a short while garronej/tss-react#52

Closed

sgarcia-dev mentioned this issue Jul 27, 2022

Add configuration option to <ChakraProvider> to prepend, not append, Emotion's <style> tags to the <head> chakra-ui/chakra-ui#6381

Open

lachlanjc mentioned this issue Apr 10, 2024

Add styles to HEAD, not to BODY system-ui/theme-ui#2499

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ability to insert styles at a specific position in <head> #2037

Ability to insert styles at a specific position in <head> #2037

jdb8 commented Oct 8, 2020

Andarist commented Oct 8, 2020

jdb8 commented Oct 8, 2020

Andarist commented Oct 8, 2020

gregjacobs commented Oct 31, 2020

Andarist commented Oct 31, 2020

gregjacobs commented Oct 31, 2020

Andarist commented Oct 31, 2020

gregjacobs commented Oct 31, 2020

gregjacobs commented Nov 10, 2020

gregjacobs commented Nov 24, 2020

Andarist commented Nov 24, 2020

oliviertassinari commented May 31, 2021

Andarist commented Jun 1, 2021

oliviertassinari commented Jun 1, 2021 •

edited

DominikSerafin commented Dec 2, 2021 •

edited

Andarist commented Dec 2, 2021

DominikSerafin commented Dec 2, 2021 •

edited

Andarist commented Dec 2, 2021

Ability to insert styles at a specific position in <head> #2037

Ability to insert styles at a specific position in <head> #2037

Comments

jdb8 commented Oct 8, 2020

Andarist commented Oct 8, 2020

jdb8 commented Oct 8, 2020

Andarist commented Oct 8, 2020

gregjacobs commented Oct 31, 2020

Andarist commented Oct 31, 2020

gregjacobs commented Oct 31, 2020

Andarist commented Oct 31, 2020

gregjacobs commented Oct 31, 2020

gregjacobs commented Nov 10, 2020

gregjacobs commented Nov 24, 2020

Andarist commented Nov 24, 2020

oliviertassinari commented May 31, 2021

Andarist commented Jun 1, 2021

oliviertassinari commented Jun 1, 2021 • edited

DominikSerafin commented Dec 2, 2021 • edited

Andarist commented Dec 2, 2021

DominikSerafin commented Dec 2, 2021 • edited

Andarist commented Dec 2, 2021

oliviertassinari commented Jun 1, 2021 •

edited

DominikSerafin commented Dec 2, 2021 •

edited

DominikSerafin commented Dec 2, 2021 •

edited