openui / open-ui

Maintain an open standard for UI and promote its adherence and adoption.
https://open-ui.org
Other
3.59k stars 191 forks source link

Create link-area-delegation-explainer.md #1109

Closed noamr closed 1 month ago

noamr commented 1 month ago

See #1104

noamr commented 1 month ago

Two questions I had after reading this (I'll let you judge if they should be in the explainer).

You mean three questions? :)

  • What happens with nested linkarea elements?

Good question. I think it bubbles in such a way that the nearest one to the target wins. Will add it to the explainer!

  • Are there any default UA styles?

Probably not ATM

  • Does hovering the linkarea trigger hovering on the related link?

Will add as an open question

This seems very similar to command and commandFor. Could it just be:

<section class="card" command="click" commandFor="card123-title">
  <a href="/post?id=123" id="card123-title">Post Title</a>
  <img>
  <button>Join</button>
  <button>Share</button>
</section>

In that way, you could also make the default action of a table row to toggle a checkbox within the first table cell.

That's an interesting thought! I wonder if commandfor handles all the use cases here, and if this is just about clicks

jakearchibald commented 1 month ago

You mean three questions? :)

Haha I thought of the third along the way

  • Are there any default UA styles?

Probably not ATM

You'll struggle to add them later. But fwiw I don't think it needs any.

That's an interesting thought! I wonder if commandfor handles all the use cases here, and if this is just about clicks

Even if it does, avoiding the need for a unique ID per table row (or whatever) is a big DX win.

Even if things don't go the commandfor route, being able to target buttons/checkboxes is still useful.

mfreed7 commented 1 month ago
  • Are there any default UA styles?

Probably not ATM

You'll struggle to add them later. But fwiw I don't think it needs any.

I agree with both points - hard to do later, but also, I don't think you need/want them. Feels like this doesn't change how the element looks, just how it behaves, at least by default.

That's an interesting thought! I wonder if commandfor handles all the use cases here, and if this is just about clicks

At the moment, command/commandfor are only supported on buttons. This would explicitly be for not-buttons, since you can't nest a link inside a button. It feels like the shape of the API is similar, but perhaps this is different enough that it'll be less confusing to have a dedicated/different attribute?

Even if things don't go the commandfor route, being able to target buttons/checkboxes is still useful.

This is a good point - basically it seems like maybe you can target things that can be click targets? That raises the (most difficult) question about the name of the attribute - in that case link doesn't make sense anymore.


I'll approve this so it can be a landed explainer. These are all great questions to raise as issues against it.

jakearchibald commented 1 month ago

At the moment, command/commandfor are only supported on buttons. This would explicitly be for not-buttons, since you can't nest a link inside a button. It feels like the shape of the API is similar, but perhaps this is different enough that it'll be less confusing to have a dedicated/different attribute?

command/commandfor could easily be added to other elements, if that's the only issue.

command/commandfor is a way to declaratively state a link between an activator and activatee. That seems to be what we're talking about with this link feature.

noamr commented 1 month ago

Did a quick edit pass and left some comments along the way. (I promised to help!)

The CSS proposal made me think about anchor positioning and how that makes the status quo a bit better than what we've discussed so far. It should let us avoid the problem of needing position: static on intermediate elements. The focus ring issues remain, of course.

Thanks! I think I accepted all your edits? I left some comments unresolved so that it can be a discussion after the PR is merged, it's hard to have this entire discussion on the initial merge.

noamr commented 1 month ago

@jakearchibald @nmn care to follow up on your great comments with PRs on the explainer? That would be easier to manage... otherwise I'll try to incorporate them later on.

scottaohara commented 1 month ago

oh boo. i was doing a pretty big review / suggestions to this. guess i'll just make a pr now

scottaohara commented 1 month ago

also it appears this explainer was created in the root folder... my PR will also merge it to the correct location.

noamr commented 1 month ago

also it appears this explainer was created in the root folder... my PR will also merge it to the correct location.

Go for it! That would be great. Thanks for participating, sorry for the in-flight collision.