The cons for strategy 2 are undeniable and substantial - the idea of "everything should be part of the href", however, was blown a bit out of proportion in the cause of the discussion. It could be the end game but it's usefulness is limited until the wikidata side actually makes use of these incoming values. Data attributes can be a viable option for augmenting the mark-up with needed information that we decide (temporarily or permanently) not to encode into the links. My argument is not in favor of adding yet another questionable meta requirement but

• to focus on, especially during the MVP phase, one solid way of doing things
• trying not to re-implement native browser behavior with elements not meant for that (e.g. click behavior on spans)
• finding a more elegant solution when roadblocks become evident (2 links in one marked-up area) instead of hoping it will work out somehow

The links (item id, property id) already exist, and we want template editors - for each of them - to specify additional information (editing flow for now).
Due to the fact that wiki syntax is used, we will not be able to add data attributes directly to the hyperlink elements. However, we can add children to the hyperlinks, which then are part of the anchor (see edit pen of the example above).
Given the way HTML works, hyper links can not be nested into each other and hyperlinks natively exhibit click behavior.
If we added the needed data attribute(s) to a child (e.g. a span) of the hyperlinks we seem to be able to arrive at most of the pros without any of the cons - while leaving the door open for a future migration of parameters to the href.

[https://www.wikidata.org/Q123#P456 <span data-data-bridge-edit-flow="overwrite">🖊</span>]

What do you think? @Lucas_Werkmeister_WMDE @Michael

Using an inner element solution makes sense to me, now that the problems of using the outer element solution have become apparent. I would be fine with using that, now seeing how my previously favorited approach is struggling.

But there is one part that confuses me:

In T227463#5316593, @Pablo-WMDE wrote:

If we added the needed data attribute(s) to a child (e.g. a span) of the hyperlinks we seem to be able to arrive at most of the pros without any of the cons - while leaving the door open for a future migration of parameters to the href.

I'm not sure I understand how using an inner child is affecting the possibility of such a future migration, compared to migrating the parameter from an outer parent to the href. Wouldn't the wiki text/template/lua function not needed to be changed either way?

Due to the fact that wiki syntax is used, we will not be able to add data attributes directly to the hyperlink elements. However, we can add children to the hyperlinks, which then are part of the anchor (see edit pen of the example above).

Unfortunately, wikitext also restricts the ability to add data attributes below the hyperlinks. The variant you demonstrated works, but unfortunately adds an external link marker after the link, which I don’t think is an acceptable change. Changing it to internal wikilink syntax works –

[[:d:Q42#P31|<span data-bridge-edit-flow="overwrite">🖊</span>]]

– but only because it uses an emoji character for the edit icon; the parser won’t recognize an image link nested inside a wikilink (or rather, it won’t recognize the outer wikilink):

[[:d:Q42#P31|<span data-bridge-edit-flow="theflow">[[File:OOjs UI icon edit-ltr-progressive.svg|frameless|text-top|10px|link=|alt=Edit this on Wikidata|Edit this on Wikidata]]</span>]]

[[:d:Q42#P31|🖊]]

Adding data attributes on or inside the file link doesn’t work:

[[File:OOjs UI icon edit-ltr-progressive.svg|frameless|text-top|10px|alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q2013?uselang=en#P856|data-bridge-edit-flow="overwrite"|<span data-bridge-edit-flow="overwrite">Edit this on Wikidata</span>]]

<a href="https://www.wikidata.org/wiki/Q2013?uselang=en#P856" title="Edit this on Wikidata" rel="nofollow"><img alt="Edit this on Wikidata" src="https://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/OOjs_UI_icon_edit-ltr-progressive.svg/10px-OOjs_UI_icon_edit-ltr-progressive.svg.png" decoding="async" style="vertical-align: text-top" srcset="https://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/OOjs_UI_icon_edit-ltr-progressive.svg/15px-OOjs_UI_icon_edit-ltr-progressive.svg.png 1.5x, https://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/OOjs_UI_icon_edit-ltr-progressive.svg/20px-OOjs_UI_icon_edit-ltr-progressive.svg.png 2x" width="10" height="10"></a>

In short, I’m unable to find a wikitext trick that lets you produce an internal link containing an image and custom data attributes.

Alternatively, we can go with the outer element variant, but restrict it: instead of saying that any element content is allowed, and a nested link is merely an extra convenient case in which you’re allowed to omit the data-bridge-entity-id and data-bridge-property-id, we could say that the element with a data-bridge-edit-flow attribute must only contain a single hyperlink, from which the entity and property ID are extracted – in other words, turn the common case into the only supported case. This would remove the problem of making non-clickable elements clickable (if the link is required, we can attach the event handler to it, not the element with data-bridge-edit-flow), and is still easy to produce in wikitext (put a suitable <span> around whatever wikitext you currently use to create the edit link).

In T227463#5324714, @Lucas_Werkmeister_WMDE wrote:

Alternatively, we can go with the outer element variant, but restrict it: instead of saying that any element content is allowed, and a nested link is merely an extra convenient case in which you’re allowed to omit the data-bridge-entity-id and data-bridge-property-id, we could say that the element with a data-bridge-edit-flow attribute must only contain a single hyperlink, from which the entity and property ID are extracted – in other words, turn the common case into the only supported case. This would remove the problem of making non-clickable elements clickable (if the link is required, we can attach the event handler to it, not the element with data-bridge-edit-flow), and is still easy to produce in wikitext (put a suitable <span> around whatever wikitext you currently use to create the edit link).

That might work, I think there are selectors that let us select all children of an element, so we could assert that it is only a single link and then overload that link.

In short, I’m unable to find a wikitext trick that lets you produce an internal link containing an image and custom data attributes.

I fooled about wikitext a bit, looked at documentation (1, 2), some other templates (1), and some implementation (1) but share Lucas' observation.

turn the common case into the only supported case. This would remove the problem of making non-clickable elements clickable (if the link is required, we can attach the event handler to it, not the element with data-bridge-edit-flow), and is still easy to produce in wikitext (put a suitable <span> around whatever wikitext you currently use to create the edit link).

This is a good, pragmatic compromise in the light of the apparent external restrictions. Let's do this, if no one objects.
Change to the current state would be the addition of something akin to

"Exclusively hyperlinks which are the only sibling (i.e. no other hyperlink present within it) inside the element marked-up with data-bridge- information will be enhanced by data bridge."

Should we also drop the data-bridge-entity-id and data-bridge-property-id attributes and only get them from the URL?

Should we also drop the data-bridge-entity-id and data-bridge-property-id attributes and only get them from the URL?

Yes. I'm strongly in favor of stripping it to the bare minimum and only add complexity when it is required / provides value.

Sounds good to me

Okay, I’ve updated the DocDraft accordingly.

Thanks!

Late update – I just found out that MediaWiki allows you to suppress the external link marker using the [plainlinks class](https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Plainlinks), so we could’ve gone with the external link approach after all. We don’t have to change anything for that now, but it might be useful if we ever need to come back to this for another reason.