-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Finalize <head>, <body>, <html> #26
Conversation
- an `<html>` tag is always included in the final output | ||
- `<!DOCTYPE html>` | ||
- completely ignored in a component template | ||
- a `<!DOCTYPE html>` tag is always included in the final output |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with this personally, we should search discord just to be sure there aren't people out there wanting to use older doctypes though.
Couple of notes:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can dig it. Left some comments.
Let me see if I can improve the "motivation" section based on your other item of feedback. This section is meant to answer this question.
I believe that this is already not supported based on how layouts work, but I agree that this is making that lack of support explicit. I'll add a note to the Drawbacks section. |
@matthewp @jonathantneal thank you for the feedback and comments on this RFC, and @natemoo-re for giving feedback in person. Based on feedback (and a better understanding of how this all works in the current codebase) I took another pass at this and really re-scoped the RFC:
The RFC is now only focused on simplifying things in the codebase and committing to a more straightforward render behavior. Hopefully the smaller scope makes this easier to review. PTAL when you can! Note: previous RFC draft still available here |
- `<html>`, `<body>`, `<head>` | ||
- compiler: will be left as-is in the component template. | ||
- runtime: will be left as-is in final page HTML output. | ||
- runtime: may warn if duplicate `html`, `body`, and `head` tags are included in final page HTML output. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this may be difficult, remembering that the runtime only see strings of HTML, so not easy to detect multiple tags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can it make more clear that this isn't required, and is just a suggestion of something that is not impossible/blocked by this RFC.
Co-authored-by: Jonathan Neal <[email protected]>
|
||
## Compiler Changes | ||
|
||
- `src/pages` and `src/layouts` will no longer be parsed or rendered differently from other components |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 agree on this
Co-authored-by: Jonathan Neal <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have one lingering concern left. Looking for clarity regarding <!doctype html>
.
Resolved in convo above! |
I am mentioning a use case for hoisting Most of the images on a webpage should be lazily loaded. But some images like banners, hero images, or logos (it should be inline though) should be eagerly loaded. To do this, one should not only tell the browser to eagerly load the image using But when I was implementing this feature I found that unlike So, not only the |
|
||
- runtime: will remove current post-build head injection, which involves a fragile `'</head>'` string find-and-replace. | ||
- compiler: will add a new `head: string` (or: `injectHead(): string`) property to the compiler transform options, which will inject the given HTML string into the bottom of a `<head>` element, if one is return by the compiler. | ||
- runtime: will provide this value head injection value to the compiler, and throw an exception if not used/called exactly once during a page render. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
## Head Injection Changes | ||
|
||
- runtime: will remove current post-build head injection, which involves a fragile `'</head>'` string find-and-replace. | ||
- compiler: will add a new `head: string` (or: `injectHead(): string`) property to the compiler transform options, which will inject the given HTML string into the bottom of a `<head>` element, if one is return by the compiler. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like injectHead()
rather than injectStyles()
/ injectLinks()
because it gives the runtime the freedom to inject anything it needs into the bottom of the head, in whatever order it decides is best.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this should be part of the compiler options though. I would expect this to be part of the runtime code. Either part of the $$result
object or an import, but I think this is an implementation detail that doesn't need to be spelled out in the RFC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, I thought that we needed it to be in the compiler since transform()
returns a final string, but maybe I misunderstood. Agreed, happy to finalize this in the implementation since this RFC is mainly focused on expected behavior.
RFC Notes:
|
@RafidMuhymin Thank you, this is great feedback and something we should figure out a way to support. If you'd like, we can start a new Discussion in this repo to talk about that use-case more. |
@matthewp Yeah, I have no problem doing that if you tell me what's the way of starting a discussion in this repo |
yes please! Happy to revisit that part of this, it came up in the convo and the balance we need to strike is supporting users who are building pages and forgot to add the |
@FredKSchott To confirm/clarify from the comments buried in the review and your notes from the RFC call -- am I understanding correctly that the decision was to auto-add That seems like a sensible compromise to both seamlessly avoid problems when uses forget to add |
Summary
Finalize behavior around
<head>
,<body>
,<html>
, and<!DOCTYPE html>
elements in Astro component templates.Links