3.8 up-defer shouldn't requires click about unpoly HOT 7 CLOSED

I cannot reproduce this. [up-defer] loads immediately for me, no click required:

https://glitch.com/edit/#!/band-heliotrope-trout
https://band-heliotrope-trout.glitch.me/

from unpoly.

Hi @triskweline,

OK, I see now it's working in a simple version.

Here an example (my use case) where it doesn't load immediatly:
https://glitch.com/edit/#!/marsh-honeysuckle-headlight
https://marsh-honeysuckle-headlight.glitch.me/

plus the wired cursor: pointer.

Sorry to not send the example in the first place, but I got the assumption that the click requirement was the standard undocumented behavior.

from unpoly.

Ahhhhhhhh damn I have missed the # in up-target - Indeed it's loading immediatly - Sorry my fault 🤯

But the wired cursor: pointer is still a thing. Can this be done via up-source instead?

PS: fixed the glitch.

from unpoly.

But the wired cursor: pointer is still a thing.

The pointer cursor is a CSS rule in unpoly.css. We can change the rule to select on [up-href]:not([up-defer]) instead.

Can this be done via up-source instead?

It could. But I'd rather change [up-poll] to also use [up-href] so it's consistent everywhere.

The [up-source] attribute contains the URL a fragment is loaded from, and is set by Unpoly automatically. Seeing the confusion in this issue I'm thinking it should probably not be set by the user.

from unpoly.

Hi @triskweline,

I was under the impression that up-href is for navigating (following) a link (by the user) as described here https://unpoly.com/up-href. It basically implies a user interaction to navigate to.

Not tested, but I would guess, an element defined as up-defer up-href="..." would be clickable (no matter if styled with mouse pointer or not) and if it gets clicked it would probably dispatch an up:link:follow as well - not tested.

On the other hand, I understood up-source more like the source of the content without any navigation implications. (no matter if it has been loaded already or not)

from unpoly.

I was under the impression that up-href is for navigating (following) a link (by the user) as described here https://unpoly.com/up-href. It basically implies a user interaction to navigate to.
On the other hand, I understood up-source more like the source of the content without any navigation implications. (no matter if it has been loaded already or not)

I understand where you're coming from.

My point is this: Unpoly's design goal is to reuse and enhance existing HTML semantics where possible. The [up-defer] attribute was modelled as a "link that follows itself automatically". We even recommend using a standard link if graceful degredation matters to you:

<a id="menu" up-defer href="/menu">load menu</a>

Not tested, but I would guess, an element defined as up-defer up-href="..." would be clickable (no matter if styled with mouse pointer or not) and if it gets clicked it would probably dispatch an up:link:follow as well - not tested.

Yes it would. This must be avoided by the implementation.

from unpoly.

Also thinking about requiring to pair [up-href] with [up-follow] to make non-interactive elements behave like a link. This would be a breaking change though.

from unpoly.