Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Mix in Turbo Frames to built-in elements. #131
base: main
Are you sure you want to change the base?
Mix in Turbo Frames to built-in elements. #131
Changes from all commits
63ff4d9
7d7488e
fec1799
d767b4e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Maybe I'm misunderstanding the motivations behind pre-defining "main default container elements", but what is the value in supporting a generic element like
<div is="turbo-frame-div">
instead of using a<turbo-frame>
in its place?Is this about semantics? Would
<turbo-frame role="region">
be compatible with<section is="turbo-frame-section">
?As I understood the initial version of this PR, it was to add support for
<turbo-frame>
elements within a<table>
element only because browsers hoist<table>
elements in a specialized way compared to other elements. Would it be best to keep this pre-definitions constrained to table elements like<thead>
,<tbody>
,<tr>
,<td>
,<th>
?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.
Often it's about integration into existing setups that have set expectations about DOM structure. Like right now I'm dealing with a sortable setup in Basecamp where we're converting some div's to turbo frames, but the existing JS expects a certain DOM structure that doesn't work with an additional container inserted.
It's similar to the stimulus approach vs custom elements in general.
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.
the
is
attribute is used by custom elements builtin extends ... if this property overrides the attribute no polyfill can possibly upgrade this element later on. Please avoid setting this attribute completely, use a different name for custom elements builtin extends, or set such attribute only ifthis.getAttribute('is')
is not defined yet.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.
That is intentional, and necessary when the element is programatically created, due to this part of that same section of the HTML standard: "when creating a customized built-in element programmatically, the is attribute will not be present in the DOM, since it was not explicitly set".
To implement its own behaviour, Turbo usually depends on the element name. Since that is no longer possible in this case, it must instead depend instead on the is attribute being present in the DOM, to identify the element for update. Setting any other attribute would be a) DOM pollution, and b) a potential namespace clash. Using any other means would break the general design promise of progressively enhancing the HTML we already have, and amount to a redesign of Turbo's core behaviour which is definitely out of scope for this PR.
However I agree that it only needs setting if not already defined.
I hope to revisit this PR sometime this month, maybe with the revised polyfill it can even work on Safari, thanks!
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.
Using CE since 2014 and wrote all polyfills to date that work with built-in extends too, no need to explain me what's the
is
attribute about ;-) and yes, I do that in vanilla-elements too, but the reason I've mentioned that is that the polyfill also does that so you don't need to care.Anyway, a simple check if the attribute is not defined yet is all I am pointing out, and shame on me I didn't check what was the
isValue
value, but if it's the custom element name, as builtin extend, then all good, this shouldn't interfere with the polyfill, I thought it was something else, like Vue 3 abuse it.Apparently it's not 👍