Consider using IDs for `target` #2

imacrayon · 2024-08-01T20:43:07Z

Hey, first off, this is a cool idea I hope it gets some traction. I wanted to leave my two cents here because I've created an Alpine.js plugin (https://alpine-ajax.js.org) with very similar goals.

I'm curious - have you considered limiting target to accept only element IDs? I'm not aware of any existing HTML attribute that references elements using a selector string, but there is precedent for using one or more (space separated) Element IDs like form, aria-*, and popovertarget. I get that targeting classes can be convenient, but practically I haven't come across a serious need for it. I've found that the explicitness of IDs also guards against unintended DOM updates that could happen when using class selectors in a complex UI.

The text was updated successfully, but these errors were encountered:

alexpetros · 2024-08-01T21:09:34Z

Just for my own knowledge—how did you find this? Excited you did! Just curious where the traction is coming from. I might add something to the README encouraging people to open issues if they want to comment on the ideas.

I think this is a good suggestion! I had not considered it, and might include it as an alternative. Some initial thoughts:

IDs are included in CSS selectors, so allowing for other types of selection is purely additive benefit
CSS selectors let you keep your markup uncluttered with IDs on small, simple pages
There isn't a ton of precedent for CSS selectors in pure HTML, but there is lots of precedent in plain JavaScript attribute libraries
Because IDs shouldn't apply to multiple elements, they can be tricky to work with on a dynamic page

I've found that the explicitness of IDs also guards against unintended DOM updates that could happen when using class selectors in a complex UI.

I definitely want to support that design pattern, but also, simple cases should be allowed to be simple! That's one of the nice qualities of HTML. So I don't see why you wouldn't make the whole range of selectors available.

flibustenet · 2024-08-02T06:09:58Z

I confirm also that in many apps using htmx I don't remember using something else than an ID but it's probably just an usage. That said, the example with target=main is convincing. I can imagine also to target with name, form...
Also to write # is more explicit.

But there is an inconsistency in the proposal with the current behavior of target in form and a which is the name of the iframe right ?

alexpetros · 2024-08-02T14:03:13Z

That said, the example with target=main is convincing. I can imagine also to target with name, form...

Exactly! For simple pages, with only one form, you should be able to just write "target the form."

But there is an inconsistency in the proposal with the current behavior of target in form and a which is the name of the iframe right ?

This is addressed by the proposal. If there is a iframe name that matches the value of the target attribute, that takes precedence.

bogdano · 2024-08-02T15:45:13Z

I like the idea of having all the selectors available.

To answer your earlier question-- Carson linked this repo in an answer he gave on a thread in /r/htmx.

imacrayon · 2024-08-02T15:49:44Z

Just for my own knowledge—how did you find this?

Carson mentioned it on Reddit https://www.reddit.com/r/htmx/comments/1ehjw7v/minimal_htmx_for_html_proposal/

There isn't a ton of precedent for CSS selectors in pure HTML, but there is lots of precedent in plain JavaScript attribute libraries

My concern is that if this project is serious about being adopted as an HTML standard, we've got to use HTML conversions, JavaScript is it's own thing.

the example with target=main is convincing.

Ideally you would already have an ID on your <main> element because your page should probably have an accessible skip to content link:

<body>
<a href="#maincontent">Skip to main content</a>
...
<main id="maincontent">

I'd argue there's a lot of simplicity in only using one way to reference any element on the page. The consistency across all of HTML is simple.

flibustenet · 2024-08-02T16:54:08Z

I'd argue there's a lot of simplicity in only using one way to reference any element on the page

You're probably right.
https://www.w3.org/TR/2011/WD-html5-20110525/elements.html#the-id-attribute

...as a way to target an element

Do we know why name was chosen to target an iframe instead of id ?

imacrayon · 2024-08-02T18:16:37Z

Do we know why name was chosen to target an iframe instead of id ?

target actually targets a browsing context not an element so <a target=“my_context”> opens in a context (tab) named “my_context”. Contexts has names, elements have Ids.

I was going to mention this in another issue so this one doesn’t stay off topic but given the logic above, I think using the target attribute might be the wrong approach. Instead it would probably make sense to use a new attribute like responsetarget the same way popovers use popovertarget.

imacrayon · 2024-08-02T18:30:51Z

Actually using name could be a good compromise! name isn’t required to be unique so you get some of the advantage of using a JS-style selector but name maintains consistency with HTML.

flibustenet · 2024-08-02T18:32:04Z

Then it could be possible to target an element in an iframe !
About this issue, popovertarget refer to an ID, it's a new argument to target ID.

alexpetros · 2024-08-17T03:06:29Z

These are all great suggestions. I'm going to include them as alternatives in the proposal itself.

I personally still like target the best, because I think it's the most accurate name for what we're trying to do. But getting to use the most accurate name is often something you have to give up in the name of backwards compatibility, so we'll see. For me personally, the flexibility of using a CSS selector is more important than re-using the target name.

I'd argue there's a lot of simplicity in only using one way to reference any element on the page. The consistency across all of HTML is simple.

Yes, but... there's a reason that getElementById was eclipsed by a much more ergonomic API. This proposal is very pro-simplicity, but I'm not convinced the simplicity you're describing covers important use-cases, nor does it dramatically simplify the API in the common case—it's just less capable for no reason.

Ideally you would already have an ID on your <main> element because your page should probably have an accessible skip to content link:

Not all pages need skip-to-content links: sometimes the page is all content, and sometimes the content is small. It's not a convention that every HTML element needs to have an ID.

My concern is that if this project is serious about being adopted as an HTML standard, we've got to use HTML conversions, JavaScript is it's own thing.

I don't really buy the idea that only JavaScript should have access to CSS selectors because:

They're CSS selectors
Partial page replacement is largely greenfield for HTML; the only precedent for targeting is with a name attribute, which is also not an id
What I'm trying to do is bring useful capabilities (that are currently only available to JavaScript) HTML. The idea that HTML shouldn't have access to it because it doesn't have access to it is just anti-evolution.

The library ecosystem makes use of CSS selectors because it's the most flexible paradigm: unpoly; htmx

flibustenet · 2024-08-17T11:09:19Z

the only precedent for targeting is with a name attribute,

popovertarget=id
<label for=id
<a href=...#id

Maybe there are recent discussions about this choice for popover ?

alexpetros · 2024-08-17T17:09:02Z

I meant "targeting the destination of requests" but I take your point! I'm not saying there's no precedent for "selecting a thing in the DOM based on an ID", that would obviously be silly. I just think it's too limited to really accomplish what I'd like to see this do.

imacrayon · 2024-10-03T15:50:50Z

Yes, but... there's a reason that getElementById was eclipsed by a much more ergonomic API. This proposal is very pro-simplicity, but I'm not convinced the simplicity you're describing covers important use-cases, nor does it dramatically simplify the API in the common case—it's just less capable for no reason.

I agree a query selector has better ergonomics for general use cases, but not for this specific situation. Standards are about paving the cow paths and I can't find the cow path in taking a single HTML fragment returned by the server and spreading it across multiple elements on the page? I think you're trying to optimize for a problem that doesn't exists.

I don't really buy the idea that only JavaScript should have access to CSS selectors because:

They're CSS selectors
Partial page replacement is largely greenfield for HTML; the only precedent for targeting is with a name attribute, which is also not an id
What I'm trying to do is bring useful capabilities (that are currently only available to JavaScript) HTML. The idea that HTML shouldn't have access to it because it doesn't have access to it is just anti-evolution.

I think it's fine for JavaScript to have access to CSS selectors because it's intended to extend/augment both CSS and HTML. (Jeremy Keith describes this as "the pace layers of the web".) I'm not anti-evolution just anti-unnecessary-complexity. I think supporting the query selector API in this case creates more room for confusion than ergonomic advantages, I think it's a weak reason to break a strong precedent in HTML.

Ok, I've got one more framing on this issue, and I'm having trouble finding the right way to express it, so bear with me here...The query selector API is the wrong abstraction for this problem, here's why:

I love HTML because it's so powerful, it can represent a ton of behavior and semantics around UI in such a terse, declarative syntax. I think when developers reach for an attribute like hx-target (target) they're making one of two declarations:

"Put the stuff coming from the server here."
"This stuff coming from the server is a mutation of the same stuff that already exists here."

I think using a query selector optimizes for case 1, it's more expressive and allows you easy toss the stuff that came from the server anywhere on the page. But, I'd argue that case 2 is more commonly the intention behind using target. The two things swapping on the page are often (always?) related. Theses semantics are harder to communicate through a query selector, sure you can write target="#comment", but the browser can't semantically distinguish #comment from .comment, because both of those strings represent a query for a thing, but not the thing itself. However, with target="comment" there's no uncertainty around what we're taking about, comment is comment and it's meaning doesn't change, it provides more clarity in both case 1 and case 2. Hopefully that all is coherent 😅

anentropic · 2025-01-15T14:01:58Z

When the link is clicked, replace <main> with the result of GET /home:

<a href="/home" target="main">Home</a>
<main> <!-- Existing page content --> </main>

This proposal appears to change the meaning of target attribute in anchor tags

Currently <a href="/home" target="main">Home</a> would mean "open the link in the window named main" and opens a new window if no frame with that name already exists (...no?)

I love the idea presented but I wonder if changing the semantics in this way is likely to hinder progress towards getting it accepted as a standard?

This is addressed by the proposal. If there is a iframe name that matches the value of the target attribute, that takes precedence.

I feel like this is confusing and too 'overloaded'. If there's a frame with the same name already does that make the feature unusable? And any existing sites using a named new window target may suddenly find responses unexpectedly loading into an element of the same name instead.

Why not define something more compatible with the existing semantics, e.g. either a new separate attribute or some syntax for appending the query selector after the frame name?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Consider using IDs for `target` #2

Consider using IDs for `target` #2

Consider using IDs for target #2

Consider using IDs for target #2

Comments

Consider using IDs for `target` #2

Consider using IDs for `target` #2