Collapsing <head> Behavior? #15
Replies: 4 comments 6 replies
-
|
+1 to the overall concept. One potential pain point that I’d like to see expanded upon would be what people have been experiencing in CSS: expected load order. People have different assumptions about the order in which CSS is collected when imported across multiple pages & components. Merging |
Beta Was this translation helpful? Give feedback.
-
|
Overall, I was hoping that all |
Beta Was this translation helpful? Give feedback.
-
|
I'm a big fan of how the general idea of something similar to One big question would be if priority is given based on a depth-first or breadth-first search. i.e. What's the title on this page? <body>
<div>
<div>
<head>
<title>Other title</title>
</head>
<div>
<div>
<head>
<title>Best title ever</title>
</head>
</body> |
Beta Was this translation helpful? Give feedback.
-
|
It would hope it 'works like the web', which means parsing order (I think). In the example, this would appear as tho it were depth first. This can be observed in a browser with the example code. Based on my understanding of the proposal, in the example I would expect something like this:
|
Beta Was this translation helpful? Give feedback.
-
All for matching existing browser behavior here! This is one of those corner cases that I never knew if there was a spec for (and apparently never tried), or if browsers ever bothered to make sure they actually match the spec 😄 @FredKSchott I could see that being a really useful warning behind a verbose flag or similar, I'd just be hesitant to always log the warning since there are reasons why it would be done intentially (it's pretty common to override |
Beta Was this translation helpful? Give feedback.
-
|
That's a good point, I like the idea of overriding key head elements for that use-case. As a feature, we would just need to be aware of which elements to overwrite (title, meta tags by name, etc). I think that can be considered a separate feature request from this proposal, but I'm also not opposed to combining with this RFC if there's interest and that idea is not controversial. |
Beta Was this translation helpful? Give feedback.
-
|
@jonathantneal check out the RFC, would love your thoughts! I like how detailed your comment is on the parse order behavior, maybe we could bring some of that into the RFC. FYI I've shifted a bit from when we last talked on the topic of outputting HTML without a |
Beta Was this translation helpful? Give feedback.
-
|
Now that there's an RFC, it would be great to move this convo into that PR so that the feedback here isn't lost. |
Beta Was this translation helpful? Give feedback.
-
|
Turned into an RFC! #26 |
Beta Was this translation helpful? Give feedback.
-
@jonathantneal and I were chatting about #12 and discussing
<head>behavior & bugs in Astro, and how Svelte solves this via<svelte:head>. We came to the realization that only supporting<head>in your top-level pages (and not in components) doesn't make sense for anyone using a common layout component, which can act as a component but often defines the entire<head>. This is a very common use-case for Astro users, especially as we plan to lean more into common layouts as a way to do Astro themes: https://docs.astro.build/core-concepts/layouts/An idea that we came to was to just always collapse the
<head>values of any components in the tree into the final page<head>of the rendered HTML. This would solve for our layout use-case, and also give us more flexibleheadinjection inside of components at the same time.The main reasoning why this "magic" feels okay is that
<head>has no valid use-case (that we are aware of) inside a component template, since nesting a<head>inside of a<body>would be invalid.Is there buy-in for this idea, conceptually? I can flesh this out into a full RFC if so, but I wanted to do a quick temperature check before writing more.
Credit to @jonathantneal who (iirc) first proposed this in our convo!
Beta Was this translation helpful? Give feedback.
All reactions