Remove directive tags (components) from the proposal about block-interactivity-experiments

[ockham]

I'm all for removing 👍 For some directives, components/directive tags don't make sense at all (e.g. wp-bind and friends).

I see value in using directive tags for components that are only rendered in the browser (e.g., a hypothetical <wp-graph type="column"> that renders a complex graph component and doesn't need server-side rendering).

My 2 cents: YAGNI 😬 If it's only hypothetical, we don't necessarily need to accommodate for it yet; we can (re-)introduce the concept of a tag directive if/when we feel we actually need it.

maybe we can just talk about directives, instead of directive attributes

I'm all for that.

If we follow that path and later add the directive tags again, I think we'll not be able to name them "directives". 😅

I wouldn't rule that out! We could later introduce them saying that in addition to the previous directives, which were all attributes, we're adding directives that are tags/components themselves; to differentiate them, we'll refer to them as "tag directives", and to the "other" ones as "attribute directives". I think it's sometimes necessary to give an existing notion new meaning; that's fine, as long as we differentiate clearly.

[luisherranz]

Thanks, folks.

Let's consider this decision taken and remove the directive tags/components from the code. I leave this issue open until it is done, but I'll move it to the pending tasks.

[dmsnell]

No @luisherranz I guess it doesn't, and you're right. It's the presence of attribute directives that share a prefix with tag directives that prevents any speedups, but two prefixes for the same system for potential optimization seems unreasonable.

Long-term, if the goal is Core adoption, then special-casing is probably necessary anyway. The Tag Processor could expose $p->next_tag( array( 'contains_directive' => true ) ) and we could avoid the get_attribute_names_with_prefix() silliness that clones attribute names and returns an array only for us to check if it's empty.

[SantosGuillamot]

Thanks for opening this discussion 🙂 It makes sense to me! If they don't add value, the fewer concepts we add, the better. If we remove directive tags, maybe we can just talk about directives, instead of directive attributes. This way, it should be easier to explain and understand.

[luisherranz]

maybe we can just talk about directives, instead of directive attributes

I'd also love to hear opinions about this.

[DAreRodz]

I see value in using directive tags for components that are only rendered in the browser (e.g., a hypothetical <wp-graph type="column"> that renders a complex graph component and doesn't need server-side rendering).

Having said so, you can certainly use a "directive attribute" for that as well (e.g., <div wp-graph="column">) with the only consideration that you would probably have to pass custom props using data-* attributes.

maybe we can just talk about directives, instead of directive attributes

If we follow that path and later add the directive tags again, I think we'll not be able to name them "directives". 😅

[dmsnell]

Hard to suggest not removing unnecessary complexity, but worth also noting that directive tags in general are faster to find than directive attributes. Practically speaking, the consequences here are probably something like needing to eventually special-case directives the Tag Processor in Core to support it.

For now it's all a wash, this is just an historical note.

[luisherranz]

Does it matter if we have to add directive attributes anyway?

EDIT: it's not a rhetorical question

[dmsnell]

@luisherranz I confirmed that Safari, Firefox, and Chrome all requested the images that were under a display: none div.

[luisherranz]

I confirmed that Safari, Firefox, and Chrome all requested the images that were under a display: none div.

I confirmed that <template> doesn't, but I think this is the wrong issue, isn't it? 😄

• #159 (comment)

[luisherranz]

Solved in #217.