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

Add WAAnchorTag>>openInNewTab #1124

Closed
jecisc opened this issue May 30, 2019 · 11 comments
Closed

Add WAAnchorTag>>openInNewTab #1124

jecisc opened this issue May 30, 2019 · 11 comments

Comments

@jecisc
Copy link
Member

jecisc commented May 30, 2019

I think some syntactic sugar "openInNewTab" would be interesting in anchors.

jecisc added a commit to jecisc/Seaside that referenced this issue May 30, 2019
@marschall
Copy link
Contributor

We had this in the past and intentionally removed it because it goes against web development best practices, letting the user decide how he wants to open a link.

@jecisc
Copy link
Member Author

jecisc commented May 31, 2019

I think that in some cases it can be useful because if you have a page with a fork the user need to fill and add a link where the user can get more informations, in any case you do not want to open the link in the current page, else it would discard everything the user already filled.

But if you think Seaside should really not implement it I’m fine with it. It’s not hard to find how to do it in case we really need it.

@marschall
Copy link
Contributor

I'm kinda split. On one hand having it encourages its use on the other hand if people are using it anyway it makes sense to add it.

Do you use it in your applications?

@jbrichau
Copy link
Member

jbrichau commented Jun 1, 2019

I'm in favour of adding it. Basically, if you need it, you are going to implement it yourself in the same way, so it makes sense to add an abstraction for it to Seaside. Users will most often ask the developer to make certain links open new tabs instead of having them have to do it.

@jecisc
Copy link
Member Author

jecisc commented Jun 1, 2019

I use it in one application. Probably in another one later.
I can update the PR to add a warning in the comment. Not sure everyone will read it but it’s better than nothing.

@jbrichau
Copy link
Member

jbrichau commented Jun 1, 2019

There was a question and two possible solutions recently on the mailinglist: http://lists.squeakfoundation.org/pipermail/seaside/2019-February/033334.html

@jecisc
Copy link
Member Author

jecisc commented Jun 1, 2019

@jbrichau I don't know if you saw that I already opened a PR for that.

@jbrichau
Copy link
Member

jbrichau commented Jun 1, 2019

@jecisc Yes, I saw it. I just pointed to the discussion, as there is another solution using a presenter (which I need to discover a bit myself what exactly that is doing though..., which is why I put it in here).

@jbrichau
Copy link
Member

jbrichau commented Jun 2, 2019

I refreshed my memory on the popupAnchor. We also never use that one but use the target="_blank"

Now, there are several meanings to the target attribute. My impression is that it would be cleaner if we can add them all instead of just this one (see https://www.w3schools.com/html/html_links.asp). We might also want to avoid using the name 'tab' as it is not guaranteed that a new tab or a new window opens.

Suggestions:

  • #targetNew for target="_blank"
  • #targetSelf for target="_self"
  • #targetParent for target="_parent"
  • #targetTop for target="_top"
    This then also remains consistent if you want to use #target: with a named frame.

@marschall
Copy link
Contributor

@jbrichau that makes sense. If I may ask, why #targetNew and not #targetBlank?

@jbrichau
Copy link
Member

jbrichau commented Jun 3, 2019

@marschall typo :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants