Proper HEAD support by having non-graphical components #6120
Replies: 1 comment 2 replies
-
|
I think I got the idea but I'm not sure about the addition you're suggesting. I mean, technically if you want to render the head and its elements + selecting and updating them, I'd expect it already to be possible. You should extend the view of those components and make them "displayable" (browsers hide them by default). |
Beta Was this translation helpful? Give feedback.
-
|
When using the HTML parser the head is not passed to custom blocks though. (I'm logging every element on passed to my Instead we should have a canvas for components inside the head of the primary document, which are rendered in the body of the secondary canvas. The primary canvas then doesn't render the components, but only includes the resulting HTML. |
Beta Was this translation helpful? Give feedback.
-
|
You just need to extend the head. |
Beta Was this translation helpful? Give feedback.
-
I read in some issues (from 2018) that GrapesJS by default ignores anything outside body. The argument was that it is a page editor not a metadata editor.
Currently there is some code that gives partial support for full documents or other workarounds:
asDocumentimport does some saving of theheadcontent.headto thebodyso it works properly.Currently components exist in the wild that model non-visible contents. Like a component for google tag manager (not a fan, just using it as an example).
Proposal
Use this as a base for discussion, it has holes and is not even 90% thought through.
What about just iterating over elements in the
<head>just like elements in the body.Instead of rendering the components to the page canvas we just create an extra canvas (like a
metadatatab in the editor).This is where these components could then render their UI, again via the normal API.
The main canvas would then render the head components' HTML.
This would enable interesting usages like using an image picker to pick a favicon. Or using a
LinkTagBlockto include a stylesheet.From a framework perspective not a lot of changes are required as far as I can tell; the component API needs little to no changes.
In "userland" one could even implement this, simply but ugly:
Beta Was this translation helpful? Give feedback.
All reactions