Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Higher level \href needed #1001

Closed
ctrlcctrlv opened this issue Jul 31, 2020 · 12 comments
Closed

Higher level \href needed #1001

ctrlcctrlv opened this issue Jul 31, 2020 · 12 comments
Labels
enhancement Software improvement or feature request

Comments

@ctrlcctrlv
Copy link
Member

This issue was split off of #1000.

It refers to the \href command and whether it makes sense, even optimized for print, that no visual change happens by default.

@alerque
Copy link
Member

alerque commented Jul 31, 2020

The commands we started with in SILE are meant to be low level, and we're been working up from there. The \href command dosen't do nothing, it makes links. That's a low level building block on which you can build whatever you want. You can make an image or a random empty box a link too ... the basic mechanism for adding a link doesn't style it. We don't add borders around images or other links either.

Adding another higher level command that both styles and makes a link in one command is something that could go into that package or perhaps is better suited as part of a document class (either per project or re-usable). But no the existing low level command shouldn't do anything more than add the link.

@ctrlcctrlv
Copy link
Member Author

Oh okay @alerque it does make sense. Title changed.

@ctrlcctrlv ctrlcctrlv changed the title url package shouldn't do nothing by default Higher level \href needed Jul 31, 2020
@Omikhleia
Copy link
Member

I am afraid I don't understand what this issue is about, despite reading other referred issue. I suggest clarifying it or rejecting it.

@ctrlcctrlv
Copy link
Member Author

@Omikhleia I'm happy to clarify. SILE's \href command results in no visual change and no clue there is a link there. In #1000 I wrote—

I don't know. Optimizing for print? Is that itself a sane default? ;-)

If you're optimizing for print by default then \href should be adding a footnote with the full URL...I don't know that doing nothing is ever sane.

The issue remains unresolved up to present. I define a command, \Href, which I have wrap it in a color and an hbox but it breaks splitting. I still want this fixed.

@Omikhleia
Copy link
Member

Omikhleia commented Mar 17, 2022

Thanks @ctrlcctrlv

SILE's \href command results in no visual change and no clue there is a link there (...)

This default behavior is perfectly ok with me - I have long URLs in footnotes, which I just want to appear in print (with no visual change EDIT: beyond the mouse pointer changing on hover, in most readers) but also possibly be clickable in the PDF version (as a mere convenience).

(...) but it breaks splitting.

Ah the line-breaking issue, then, I suppose. So is this is a duplicate of #1239 which is tentatively addressed by PR #1334 ?

@ctrlcctrlv
Copy link
Member Author

@Omikhleia I don't agree. It's bizarre not to mark links in some way.

@alerque
Copy link
Member

alerque commented Mar 17, 2022

I think we need both ways: when optimizing for print decorations usually don't make much sense. Optimizing for screen they frequently do. If using the same output for both, the relative utility may vary substantially by project.

@alerque alerque added the enhancement Software improvement or feature request label Mar 17, 2022
@Omikhleia
Copy link
Member

Omikhleia commented Mar 17, 2022

@Omikhleia I don't agree. It's bizarre not to mark links in some way.

I beg to disagree. It's an author decision. One could as well define a command that automatically inserts the URL in a footnote or underlines it, shows an icon on a side (à la Wikipedia, with a W or a world sphere icon) etc. The \href is just a building block for linking and need not have all of these extensive possibilities as options, since it can be used in dedicated commands for that, to achieve exactly that purpose.

EDIT: I certainly won't push for \href[color=..., urlfootnote=true, icon=..., iconside=..,, ...]{lol} :D :D

@alerque
Copy link
Member

alerque commented Mar 17, 2022

Yes, the base command should stick to just the issue of linking with no formatting. If more visual treatment is desired it can be used as a building block in a higher level command. It's possible some of our class(es) could provide such a higher level command with more visual options, but I don't think \href should do anything other than link and potentially deal with wrapping issues by default.

@ctrlcctrlv
Copy link
Member Author

If more visual treatment is desired it can be used as a building block in a higher level command.

Isn't that why issue called Higher level \href needed?

@Omikhleia
Copy link
Member

Additionally, the PDF "standard" way of "marking" link for "accessibility" is to use those ugly boxes/lines we had in #1201 and that we removed (by default) in #1209 - but the options are here to re-enable them ^^

But as stated, I was unsure what this issue was about. And you mentioned "fixing"...

I still want this fixed.

... So I thought you were referring to a bug.

Now, I understand it's a feature request. Why not. What would be the specifications for this enhanced href?

@Omikhleia
Copy link
Member

What would be the specifications for this enhanced href?

Closing due to inactivity.
(Never addressed in 2+ years, and there are many ways (command override, 3rd party package, etc.) to possibly do this seamlessly)

@Omikhleia Omikhleia closed this as not planned Won't fix, can't repro, duplicate, stale Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Software improvement or feature request
Projects
None yet
Development

No branches or pull requests

3 participants