Link delegation to descendant

[noamr]

As per spec, the a element cannot nest, you cannot put links inside links. This is important from an a11y perspective and for other reasons. However, many websites today (e.g. Reddit, Rotten Tomatoes) implement this kind of link "nesting" on their own with somewhat verbose javascript.

Proposing to discuss finding a web platform solution for this that would take accessibility and ergonomics into account. This solution might look like link delegation

<section link="item1-link">
   <link id="item1-link" href="details?item=1">
</section>

In the above example, the link attribute of the section element "delegates" the link to an a (or area) descendant with the given ID. UAs should implement this by making the section's default click action delegate the click to the item1-link element, and they may support it in other UI such as right-clicking the section.

[SzymonNadbrzezny]

Could someone explain to me what link nesting/link delegation would be used for? I'm looking currently at Reddit and I'm wondering whether the example of post applies, since they link to post and link from post's description are overlaping?

I personally understand the neatness of this behaviour from user perspective, but it's also a bit annoying for me when I'm trying to enter post and I'm redirected or just have image opened up.

EDIT: I'm your average user as far as any accesibility is concerned, but might be also biased since I'm not used to that design choice.

[noamr]

Could someone explain to me what link nesting/link delegation would be used for? I'm looking currently at Reddit and I'm wondering whether the example of post applies, since they link to post and link from post's description are overlaping?

I personally understand the neatness of this behaviour from user perspective, but it's also a bit annoying for me when I'm trying to enter post and I'm redirected or just have image opened up.

EDIT: I'm your average user as far as any accesibility is concerned, but might be also biased since I'm not used to that design choice.

Check for example walmart. You can click on the whole item to go into the item, or click on a particular color to go to the item with that color already selected (when color is applicable). They achieve this with an <a> element on top of the regular content (using z-index). This is not an uncommon pattern on the web, and using z-index tricks for this seems suboptimal...

[gfellerph]

@noamr beat me to it, but I think card components (wich can mean a lot of things) would generally be a use case for this. A lot of times you have markup like this:

<div class="card">
  <img src="..." />
  <h3>Title</h3>
  <p>Description</p>
  <a href="">Read more</a>
</div>

and the requirement is to make the whole card clickable. While you can wrap the <a> tag around the whole card, or make the <a> tag the card itself, the content of the card becomes the accessible name of the card and that's only the start of the problems with that approach. If you overlay the whole card with the <a> tag, all other items become unselectable for pointers (download image, select text for translation or lookup, ...). With the possibility to delegate clicks on <div class="card"> to the link, it would be possible to keep the nice structure and declaratively make the whole card clickable.

@lukewarlow or @keithamus would this be something that invokers could do?

[SzymonNadbrzezny]

Could someone explain to me what link nesting/link delegation would be used for? I'm looking currently at Reddit and I'm wondering whether the example of post applies, since they link to post and link from post's description are overlaping? I personally understand the neatness of this behaviour from user perspective, but it's also a bit annoying for me when I'm trying to enter post and I'm redirected or just have image opened up. EDIT: I'm your average user as far as any accesibility is concerned, but might be also biased since I'm not used to that design choice.

Check for example walmart. You can click on the whole item to go into the item, or click on a particular color to go to the item with that color already selected (when color is applicable). They achieve this with an <a> element on top of the regular content (using z-index). This is not an uncommon pattern on the web, and using z-index tricks for this seems suboptimal...

So they achieve it similarly to how Reddit does it. I'm honestly 50/50 on it because it feels like the result could be very confusing for the end-user especially if the developer didn't take proper measures to make user know they are hovering over something that is also interactable inside card like this.

[noamr]

Check for example walmart. You can click on the whole item to go into the item, or click on a particular color to go to the item with that color already selected (when color is applicable). They achieve this with an <a> element on top of the regular content (using z-index). This is not an uncommon pattern on the web, and using z-index tricks for this seems suboptimal...

So they achieve it similarly to how Reddit does it. I'm honestly 50/50 on it because it feels like the result could be very confusing for the end-user especially if the developer didn't take proper measures to make user know they are hovering over something that is also interactable inside card like this.

In the Walmart case I don't see much "harm" in it. The whole card is clickable, and clicking the color refines the link to something more specific. At Wix we had something similar where a phone number inside a link/card would be automatically clickable as a tel: link. This was really useful for small businesses.

[lukewarlow]

Currently command invokers require a custom element or a button trigger so this sort of thing would work using that API. It also feels a specific and nuanced enough problem to warrant it's own functionality.

I'm wondering if this could be something more generic however. Labels can already extend the click target of a nested/associated form control. Are there other situations like this where expanding the click area without applying other semantics is desired?

Whether this is a good pattern I'm genuinely not sure. But I would anecdotally say it's a common one. Certainly common enough to warrant a discussion even if the outcome is 'we're aware of this pattern here's the reasons it's bad'.

[noamr]

Currently command invokers require a custom element or a button trigger so this sort of thing would work using that API. It also feels a specific and nuanced enough problem to warrant it's own functionality.

I'm wondering if this could be something more generic however. Labels can already extend the click target of a nested/associated form control. Are there other situations like this where expanding the click area without applying other semantics is desired?

The problem with labels specifically is that they require an additional element, which means this can't be used on <tr> or other situations where adding an element would affect parsing. That's why the proposal is going towards an attribute-based approach, but of course everything is open.

[scottaohara]

i'm of two minds about something like this.

First, I have an initial positive reaction to this because wrapping structured content similar to the example card markup in this comment in a hyperlink (<a href>) is a rubbish practice. and the hack of using a positioned hyperlink or hyperlink's before or after pseudo content can be problematic as well.

I also find the use case for tr elements being able to reference a hyperlink within one of their cells as being the intended result of clicking 'anywhere' on the row as being a very common use case that would be nice to account for. It'd help drive home the idea that if one wants to make the row clickable, there MUST be a hyperlink to reference within the row so that it can be consistently accessible. (not all screen readers consistently allow for navigating tables by rows, and rows in and of themselves are not generally expected to be interactive - so the existence of the hyperlink is often essential)

The concern I have for something like this is no different than the concern i have for the current hacks people have to resort to for this 'desired' UX - in that this practice can often result in accidental activations. Speaking for myself, I have often accidentally activated many 'clickable cards' like this as i'm simply trying to swipe/scroll through a UI on my phone. I also have a tendency to accidently click on UI when using my mouse, and generally this is "fine"... except for in these cases where large sections of content that don't visually appear like they should be interactive, are.

Additionally, per the new WCAG 2.2 Target Size minimum SC, i'd be concerned with the potential for undersized targets to exist within the larger clickable target... I could see instances of what the SC currently has exceptions for, not taking something like this into account, since some of those exceptions were created under the present understanding that nested interactive elements aren't valid.
For example, a secondary link within a string of text would often fall short of meeting both the minimum 24 width AND height requirements of the SC (ltr / rtl words commonly meeting the width, but not necessarily the height requirement). Smaller target sizes in that case being more of a potential usability issue. But if the entire section of content is clickable, then the potential for accidental activation for someone trying to click the 'nested' link, but instead hitting the larger 'target' becomes far more likely.

I'm not mentioning the above in any sort of "i think this is a bad idea" sort of way... it's a very common pattern and being able to do this without hyperlink hacks or JS would be nice. But, we should also acknowledge that the 'large clickable pattern' has at least 'minor' usability issues related to accidental activation in some contexts - and absolutely has increased usability issues for those with motor disabilities when there are nested interactive elements.

[noamr]

i'm of two minds about something like this.

First, I have an initial positive reaction to this because wrapping structured content similar to the example card markup in this comment in a hyperlink (<a href>) is a rubbish practice. and the hack of using a positioned hyperlink or hyperlink's before or after pseudo content can be problematic as well.

I also find the use case for tr elements being able to reference a hyperlink within one of their cells as being the intended result of clicking 'anywhere' on the row as being a very common use case that would be nice to account for. It'd help drive home the idea that if one wants to make the row clickable, there MUST be a hyperlink to reference within the row so that it can be consistently accessible. (not all screen readers consistently allow for navigating tables by rows, and rows in and of themselves are not generally expected to be interactive - so the existence of the hyperlink is often essential)

The concern I have for something like this is no different than the concern i have for the current hacks people have to resort to for this 'desired' UX - in that this practice can often result in accidental activations. Speaking for myself, I have often accidentally activated many 'clickable cards' like this as i'm simply trying to swipe/scroll through a UI on my phone. I also have a tendency to accidently click on UI when using my mouse, and generally this is "fine"... except for in these cases where large sections of content that don't visually appear like they should be interactive, are.

Additionally, per the new WCAG 2.2 Target Size minimum SC, i'd be concerned with the potential for undersized targets to exist within the larger clickable target... I could see instances of what the SC currently has exceptions for, not taking something like this into account, since some of those exceptions were created under the present understanding that nested interactive elements aren't valid. For example, a secondary link within a string of text would often fall short of meeting both the minimum 24 width AND height requirements of the SC (ltr / rtl words commonly meeting the width, but not necessarily the height requirement). Smaller target sizes in that case being more of a potential usability issue. But if the entire section of content is clickable, then the potential for accidental activation for someone trying to click the 'nested' link, but instead hitting the larger 'target' becomes far more likely.

I'm not mentioning the above in any sort of "i think this is a bad idea" sort of way... it's a very common pattern and being able to do this without hyperlink hacks or JS would be nice. But, we should also acknowledge that the 'large clickable pattern' has at least 'minor' usability issues related to accidental activation in some contexts - and absolutely has increased usability issues for those with motor disabilities when there are nested interactive elements.

I resonate with all of your concerns, they are all valid! To respond to some of them, I tend to look at the inner click as a progressive enhancement. The whole {card|row|item} is clickable and would lead you to the right place, and the inner click is potentially a refinement of that link, like the Walmart example where the inner link already chooses a color for a shirt that the outer link would lead to.

If the inner link is a progressive enhancement, sometimes missing it and clicking on the outer link by mistake is perhaps acceptable?

[scottaohara]

i think you are thinking of this in the entirely opposite way i am. since the inner element, the actual hyperlink for the item, is the thing that would need to be actionable / keyboard accessible / identified as a hyperlink.

the outer 'card' or row, for instance, is not an interactive element. it should not generally be keyboard accessible, and in many cases wouldn't be expected to be. This is one reason why people 'hack' this now with hyperlinks that overlay the larger clickable area. because it's a hyperlink that people using keyboard or assistive technology would expect to interact with.

additionally, my comments about the potential for nested interactives extends to the fact that often these sorts of components consist of a couple if not a handful of other links / buttons that are secondary actions and not related to the outside click (some might take you to the same page... some don't - or in the case of favoriting, deleting, etc. for such items, those controls might be on the subsequently linked page, but falling back to that is not a reasonably equitable UX if someone is trying to favorite/delete a bunch of items on one page, rather than having to navigate to a page, perform action, navigate back, find new item, perform same action sequence again...). i realize you were not commenting on all of my points, but these would still be usability issues regardless.

so no. i'm afraid we're not aligned in what we'd consider acceptable here. i'm wondering now if i imposed my own assumptions on how this could be helpful and accessible onto something that hasn't actually yet accounted for the latter.

[dbaron]

Yeah, I was also going to ask about the "nested interactive elements" aspect here, but I think @scottaohara beat me to it. I agree it's worth clarifying what your expectations for this sort of thing are regarding tab order and keyboard navigation, exposure to assistive technology (where my understanding is that nested interactive elements are often problematic), exposure to any other UA features that enumerate/navigate links, etc.

[noamr]

Yeah, I was also going to ask about the "nested interactive elements" aspect here, but I think @scottaohara beat me to it. I agree it's worth clarifying what your expectations for this sort of thing are regarding tab order and keyboard navigation, exposure to assistive technology (where my understanding is that nested interactive elements are often problematic), exposure to any other UA features that enumerate/navigate links, etc.

Currently the idea is that the external element would not be part of the tab order / default keyboard navigation, and would only extend the clickable area and potentially additional items in the context menu like "open in a new tab".

[noamr]

i think you are thinking of this in the entirely opposite way i am. since the inner element, the actual hyperlink for the item, is the thing that would need to be actionable / keyboard accessible / identified as a hyperlink.

I think I misrepresented the example. I was thinking of a situation where there is more than one link - one being the "default" link which the enclosing element delegates to, and additional ones that go "deeper", like pre-choosing a color. This would enhance the click area of the default link but won't do much for the other ones.

the outer 'card' or row, for instance, is not an interactive element. it should not generally be keyboard accessible, and in many cases wouldn't be expected to be. This is one reason why people 'hack' this now with hyperlinks that overlay the larger clickable area. because it's a hyperlink that people using keyboard or assistive technology would expect to interact with.

Yup, there are no plans to make these outer elements keyboard interactive. All they do is delegate the click area (and potentially some context menu items) to the link.

additionally, my comments about the potential for nested interactives extends to the fact that often these sorts of components consist of a couple if not a handful of other links / buttons that are secondary actions and not related to the outside click (some might take you to the same page... some don't - or in the case of favoriting, deleting, etc. for such items, those controls might be on the subsequently linked page, but falling back to that is not a reasonably equitable UX if someone is trying to favorite/delete a bunch of items on one page, rather than having to navigate to a page, perform action, navigate back, find new item, perform same action sequence again...). i realize you were not commenting on all of my points, but these would still be usability issues regardless.

Absolutely. Having nested links that act in a way that conflicts with the default link is a usability issue here we have to address. I wonder if having something like this in the web platform gives us more opportunities to address this than letting people hack around it with z-index. If we arrive at the conclusion that it just adds more footguns, we won't do it.

[nmn]

I'm seeing a bunch of concerns about a11y for this pattern. I want to clear the air and explain that we at Meta (while working on facebook.com) arrived at this exact solution to solve our a11y problems.

---

The use-case has been described well. Imagine a card, say to a profile. This card contains a big profile photo followed by the username in large font-size which is also a link to the profile page of this user.

Further down, there are a few action buttons to say, message the user, follow them, etc.

---

The card, as-is, is already accessible. There are no nested interactive elements and everything has the correct labels for screenreader users. Now, if we want to make the whole card clickable and to act as a link to the user's profile what are our options?

1. The best solution so far is to use absolute positioning on the <a> around the username and make it as big as the card itself and then use z-index to ensure the other buttons in the card are on top of this link.
   • If we need non-static positioning on anything between the card itself and the link, this system breaks down.
   • For sighted keyboard users, this messes up the focus ring as it will go around the whole card by default.
   • z-index solutions are risky in general.
2. Another solution is to render a link as a sibling of the card and use absolute position over the whole card.
   • This creates duplicate links to the same content
   • The label for the container needs to be manually set as aria-describedby cannot be used safely. Pointing it to the whole card creates nested links in the screenreader text.

---

So, link delegation ends up being a great and simple solution. After going through many other solutions which were all very challenging I proposed this solution to our a11y team internally and it was our best solution to this problem.

• The outer card container element remains a normal div.
• It does not have any special role.
• It is not focusable
• It does not behave like a link in anyway

It just has a JS click handler which forwards the click to the "target link" within. That's it. It's only a mouse click (and touch) affordance. It automatically ignores any clicks nested interactive elements.

---

So, overall, this proposal doesn't create any new a11y issues. The links within the card should still be big enough and accessible in all the ways links and buttons should be. The card forwarding its clicks to one of them doesn't change the calculus.

Finally, the concern about large clickable targets making things harder to scroll etc, that's a design issue and not directly relevant to this proposal IMO. There are plenty of large buttons and links that are not cards and do not need nested interactive elements.

[scottaohara]

I think I misrepresented the example. I was thinking of a situation where there is more than one link - one being the "default" link which the enclosing element delegates to, and additional ones that go "deeper", like pre-choosing a color. This would enhance the click area of the default link but won't do much for the other ones.

thanks for clarifying @noamr - because yes, your prior message made it seem like someone could progressively enhance this proposal by putting an actual link into the container, but could otherwise define this without having a link in there at all. Your follow up alleviates my concern with this as that just seems a misunderstanding now. I appreciate you acknowledging the increased click area for the 'default' link, but that any other 'nested' targets would be whatever size the author made them - which is where my primary concern is, and will likely be something to address via author/design awareness.

re: @nmn's response... your comment appears to be trying to squash the concerns that came about due to noam's follow up to my original comment. as just mentioned, that seemed to be largely a misunderstanding of what he meant when he said "If the inner link is a progressive enhancement, sometimes missing it and clicking on the outer link by mistake is perhaps acceptable?"

your response seems to be very focused on screen reader accessibility. your ending paragraphs seem a bit dismissive about potential issues for target sizes though... Facebook generally does a good job with ensuring targets within larger interactive targets meet the new wcag 2.2 minimum target size. though instagram is an app i have some issues with accidental clicks (or in my case, taps). The most egregious instances though being websites that have sticky videos with dismiss/minimize buttons overlaid on top. The target of the button is often too small and it's hard to click/tap it and not the video (which may then pause the video one was trying to watch, or if the video also has JS click event / overlaid invisible hyperlink - accidental navigation to a new web page can occur).

I do agree with you though, that my concerns here are not "new" a11y issues... nor as I already mentioned were they meant as opposition to the idea (again - where concern arose was due to the now cleared-up misunderstanding). But my point in bringing up target size issues is so that they can be acknowledged. Raising the potential for someone to have an idea of how such instances could potentially be accommodated through a potential standardization of such a feature. Or at the very least, author guidance be provided to help ensure best practices for sizing of nested targets to at least meet wcag minimums. When these sorts of concerns don't get raised, then it becomes less likely they get addressed in any potential work/explainer/spec text or author guidance.

i hope this helps clarify where i'm coming from here, and that i simply want to make sure we think about more than just the screen reader experience. addressing those concerns might have zero actual impact on how this feature is developed - and may end up simply being a unified understanding a messaging on how authors can use this feature and ensure the best UX they can for any nested targets beyond the primary cta/hyperlink

[nmn]

I understand and appreciate your clarification @scottaohara. Sorry for any miscomprehension on my part.

Raising the potential for someone to have an idea of how such instances could potentially be accommodated through a potential standardization of such a feature.

I have an idea here, but they don't feel actually doable.

• Essentially if the "container element" (what do we call this container that delegates its click? The "delegator container"? We call the component "ContainerPressable") could somehow detect all the clickable child elements and leave larger gaps in its own hit area, that would be pretty awesome.

[jakearchibald]

@nmn I'm struggling to understand:

1. The best solution so far is to use absolute positioning on the <a> around the username and make it as big as the card itself and then use z-index to ensure the other buttons in the card are on top of this link.

…leading to:

So, link delegation ends up being a great and simple solution. After going through many other solutions which were all very challenging I proposed this solution to our a11y team internally and it was our best solution to this problem.

• The outer card container element remains a normal div.
• It does not have any special role.
• It is not focusable
• It does not behave like a link in anyway

It just has a JS click handler which forwards the click to the "target link" within. That's it. It's only a mouse click (and touch) affordance. It automatically ignores any clicks nested interactive elements.

Is the absolute positioning solution still the "best solution so far", or are you saying a simple JS click handler is better? If the absolute solution is still better, why?

[nmn]

@jakearchibald Fair question!

The absolute positioning solution is the commonly used best solution, and the best solution that doesn't depend on JS.

I believe link delegation is actually a better solution.

[scottaohara]

i think that's an important qualifier. absolute positioning is the current "best" solution that doesn't involve JS. I'd argue that using JS is really a better solution for tackling this now... but for the fact it necessitates JS which i know people want to avoid.

[css-meeting-bot]

The Open UI Community Group just discussed Link delegation to descendant, and agreed to the following:

• RESOLVED: Incubate an explainer for a new solution for declarative link delegation

The full IRC log of that discussion

<hdv> masonf: ok I can try and do it justice
<hdv> masonf: thing is, you can't nest anchors
<hdv> masonf: but there are times where you want to act something is clickable
<hdv> masonf: but nesting anchors is bad for all kinds of reasons
<hdv> masonf: so an attribute, something like 'link' can be added to a container that you refer to by idref, so that the container behaves / works like you're clicking on the link
<hdv> masonf: so the link attr would do nothing to the accessibility tree, only the existing link would be in there. Proposal would also be that the keyboard behaviour was @@@
<hdv> masonf: it would need to point inward, as otherwise would be risky
<gregwhitworth> q?
<gregwhitworth> q+
<hdv> namangoel: that covers everything, it is what we ended up doing for Facebook
<hdv> namangoel: outer div is just a div with a click handler, intentionally with no specific semantics
<hdv> masonf: no interactive elements would allow for this
<hdv> namangoel: the use case on Facebook is all cards… eg each cards has a profile and some buttons like follow and message. We want you to be able to click the whole card, and also the buttons in the card
<hdv> namangoel: before we made the whole container a link and it was horrible for accessibility so we reverted that
<hdv> namangoel: one solution that exists elsewhere is an abspos hack
<hdv> namangoel: the problem with that one is that it messes with the focus rings and makes that misleading… and difficult to use in all scenarios eg if you need relative positioned elements inside
<hdv> namangoel: our current solution avoids that
<hdv> namangoel: by making the outer div just have the one click handler and nothing else
<hdv> namangoel: we just forward the click event to the inner element. I don't think we handle right clicks, that's probably worth discussing
<hdv> ack greg
<hdv> gregwhitworth: can I ask why this was deferred?
<frehner> q+
<hdv> masonf: because noam wanted to introduce it
<hdv> gregwhitworth: making this declarative seems to have various benefits
<hdv> gregwhitworth: wrapping the whole thing in an anchor was another way I saw, which was problematic
<hdv> gregwhitworth: I am not opposed to this… agree with masonf we need exclusions, for instance for interactive elements as masonf mentioned
<hdv> masonf: can see pushback go further
<hdv> masonf: what if it would only work on a div?
<hdv> keithamus: is there a reason to do that? or are you talking spiritually?
<hdv> masonf: no literally
<gregwhitworth> q?
<hdv> masonf: because divs (and spans) are non semantic elements which would avoid the messing with existing elements
<gregwhitworth> ack frehner
<hdv> keithamus: does section have semantics?
<hdv> masonf: it's a grouping el
<hdv> masonf: probably makes it easier to get to WHATWG if it applied to a specific list of elements
<hdv> q?
<hdv> frehner: was looking at implementing this pattern but for tables, eg table rows
<keithamus> q+
<hdv> +1 to the table use case! I've had to built this in the past…
<hdv> gregwhitworth: the goal would be, I think, to land an explainer for this feature?
<hdv> masonf: yes and for now to see if there is an interst
<hdv> s/interst/interest
<hdv> masonf: and also, do we want to incubate it here in Open UI
<hdv> gregwhitworth: I kind of want to avoid restricting it prematurely
<hdv> gregwhitworth: I like the premise of frehner's use case
<hdv> gregwhitworth: we should probably look at a few grouping elements… but if there are concrete other use cases that we can justify that's great
<nmn> Let's just restrict it to *not* work on any interactive element at first?
<hdv> gregwhitworth: though with tables it adds a lot of complexities, eg how AT handle tables, could think of v1 vs v2
<masonf> q?
<gregwhitworth> q?
<hdv> masonf: but this attr probably wouldnt do anything with AT, just a click handler
<hdv> namangoel: think we should explicitly exclude it from buttons, links and interactive element… and just add it to generic containers
<hdv> ack keith
<hdv> keithamus: what's bugging me… where does it go…going back to masonf's comment, should it just go on a div? I know it's not an assistive feature, but it kind of is. This is an affordance to mouse users, it is semantically relevant. Seems disjoint to me to only allow on elements that have no semantics, because now suddenly we give divs semantic value within the page
<hdv> keithamus: so kind of wonder if it should be a new element that has this semantic
<gregwhitworth> q+
<masonf> q+
<hdv> keithamus: and then we can look at specifically allowing it in certain positions like table rows
<hdv> keithamus: as opposed to an attribute that goes everywhere
<hdv> masonf: making it an element would make this proposal a lot harder it seems to me?
<gregwhitworth> ack masonf
<hdv> masonf: but agree this may have semantics of some kind… though it seems from the initial proposal that it doesn't have semantics
<masonf> q+ nmn
<hdv> gregwhitworth: I'm not hearing objections to the potential exploration of this
<hdv> gregwhitworth: we'll need to find someone to work on the explainer
<gregwhitworth> ack gregwhitworth
<hdv> masonf: we may have docs already internally
<gregwhitworth> ack nmn
<hdv> nmn: I am also scared of a new element, would complicate things, might need `display:contents` by default or somerthing
<hdv> nmn: so restricting to `div`s and `span`s probably be better. Don't think this would change semantics, just provide convenience for click handling
<keithamus> q+
<hdv> keithamus: I think it depends on your definition of semantics… it changes the behaviour of the element, because the interaction element changes for the element
<gregwhitworth> ack keithamus
<hdv> keithamus: right now, if you click inside of a div, nothing will happen, but with this attr, something will happen… my concern is, if we limit to div, the concept of a div people have kind of changes… from being just a container, to being an element that can house a delegation behaviour
<masonf> q+
<hdv> keithamus: restricting to “non semantic elements” would kind of turn those into “semantic elements”, would almost prefer, not that I like that a lot, see it to be only allowed on, say, a `section`
<gregwhitworth> ack masonf
<hdv> masonf: seems clear to me the explainer needs a section on semantics
<hdv> masonf: I kind of think of this of purely a behaviour… the parallel here is the popover attribute, that you can stick on a div, and makes the behaviour of the div different, not the semantics
<hdv> q+
<hdv> keithamus: if we say semantics = roles, that's one definition of semantics, but there are wider definitions of semantics
<hdv> keithamus: in my opinion popover is semantic
<hdv> masonf: there was a long discussion on this in popover… I hate the word semantic, has too many definitions
<gregwhitworth> hdv: as a philosophy major I love the term semantics, it's ridiculous
<gregwhitworth> hdv: the other definition of semantic that is used in ARIA specs is anything that happens in the accessibility tree so that can apply to popover and I kind of agree with Keith that it does apply semantics but more than being a div
<masonf> q?
<masonf> ack hdv
<gregwhitworth> ack hdv
<gregwhitworth> Proposed Resolution: Incubate an explainer for a new solution for declarative link delegation
<hdv> gregwhitworth: I think we need an explainer
<masonf> +1
<hdv> +1
<gregwhitworth> RESOLVED: Incubate an explainer for a new solution for declarative link delegation
<masonf> My whole VC unit just rebooted, sorry

[noamr]

Explainer PR: #1109