Make WordPress Core

Opened 10 years ago

Closed 5 years ago

Last modified 5 years ago

#28732 closed defect (bug) (wontfix)

There's no way to open the "theme details" or previewer in a new tab.

Reported by: iseulde's profile iseulde Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.8
Component: Themes Keywords:
Focuses: accessibility Cc:

Description

E.g. when you use command + click on a mac, it should open a new tab. The "modal" acts like a separate page because it has its own url and does not overlap the main navigation, so it makes sense to me to have that option.

This is useful when you want to compare some themes, or want to come back to it later.

Attachments (2)

28732.patch (668 bytes) - added by polevaultweb 9 years ago.
28732.diff (4.7 KB) - added by polevaultweb 9 years ago.

Download all attachments as: .zip

Change History (22)

#1 @iseulde
10 years ago

  • Summary changed from There's no way to open the "theme details" or customiser in a new tab. to There's no way to open the "theme details" or previewer in a new tab.

#2 @obenland
9 years ago

Should only be a matter of changing that span to an anchor, correct?

@polevaultweb
9 years ago

#3 @polevaultweb
9 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

Patch added that handles this in JS, as the modal is displayed on the click of the element whatever the type, span or anchor.

#4 @polevaultweb
9 years ago

@iseulde it would be great to get your eyes on this patch, thanks

#5 @iseulde
9 years ago

  • Focuses accessibility added
  • Keywords needs-patch good-first-bug added; has-patch needs-testing removed
  • Milestone changed from Awaiting Review to Future Release

Thanks @polevaultweb!

It's better to change this to an anchor. There are also some other combinations that should work such as ctrl+click, which should open a context menu. The arrow buttons in the modal should also be anchors.

@polevaultweb
9 years ago

#6 @polevaultweb
9 years ago

  • Keywords needs-testing 2nd-opinion added; good-first-bug removed

New patch added that changes the relevant spans to anchors and allows the customiser preview to be also opened in a new tab.

Ctrl+click for me actually does open the context menu - is that correct?

Happy to add other combos if necessary. If we do, or anyway, it might be a good idea to abstract the code that handles the new tab clicking to a method that can be used by the theme.js, customize-loader.js and the other scripts? What would be the best place for this? theme.js requires wp-a11y.js which seems like a good place, but would need to ensure the other script requires it. Let me know your thoughts @iseulde

#7 follow-up: @afercia
9 years ago

My personal opinion is none of the buttons should be changed in an anchor. I'd agree to change the spans in buttons. Will propose the Accessibility team to discuss this ticket in the next Slack meeting next Monday, anyone more than welcome to join the discussion :)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


9 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


8 years ago

#10 @joedolson
8 years ago

After discussing this in the accessibility team meeting, we feel that while having a tool to compare themes is a good idea, the current tool is not designed for that purpose, and that rather than hacking a change to fake theme comparisons, we should explore what would make a great theme comparison tool. We agreed that this solution has some great potential, but should be considered as a more extensive change to the theme previewer.

#11 in reply to: ↑ 7 ; follow-up: @obenland
8 years ago

Replying to afercia:

My personal opinion is none of the buttons should be changed in an anchor.

Can you elaborate? The link wouldn't be a dummy, it would actually link to the preview.

#12 in reply to: ↑ 11 ; follow-up: @afercia
8 years ago

Replying to obenland:

Can you elaborate? The link wouldn't be a dummy, it would actually link to the preview.

Technically, links should point to a Web resource identified by a URI. So my question is: is what's displayed inside the preview modal a real Web resource? Or it's just something that is displayed on the same page? For me, it's the latter. For example, those dummy links won't work when JavaScript is off because they don't point to a real Web resource. Also, would textual browsers, crawlers, or any other alternate software be able to retrieve that content? No, because it's not a real Web resource.

#13 in reply to: ↑ 12 ; follow-up: @obenland
8 years ago

Replying to afercia:

So my question is: is what's displayed inside the preview modal a real Web resource? Or it's just something that is displayed on the same page? For me, it's the latter.

Right, currently it is the latter. We could copy what the theme directory does though, where that is wrapped in a link to an actual web resource (which wp-admin/themes.php?theme=twentyten is).

#14 in reply to: ↑ 13 @afercia
8 years ago

Replying to obenland:

Right, currently it is the latter. We could copy what the theme directory does though, where that is wrapped in a link to an actual web resource (which wp-admin/themes.php?theme=twentyten is).

The theme directory on wp.org works differently, using links there makes sense. wp-admin/themes.php?theme=twentyten is a resource, where the resource is themes.php. To avoid academic debates about what a resource and a URI are, try this: disable JavaScript in your browser and then go to:

https://wordpress.org/themes/twentyeleven/
https://wordpress.org/themes/twentyfifteen/
https://wordpress.org/themes/twentyfourteen/

it works, they're real web resources and using links to point to them makes sense. Then try to go in the WordPress admin to:

/wp-admin/themes.php?theme=twentyeleven
/wp-admin/themes.php?theme=twentyfifteen
/wp-admin/themes.php?theme=twentyfourteen

nothing happens, it always shows you themes.php so they're not "resources" and links shouldn't be used in this case.

#15 @obenland
8 years ago

Ah, I see what you mean. I wonder if—even though it might not be technically correct—it would make sense to fake it for user convenience.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 years ago

This ticket was mentioned in Slack in #core-editor by afercia. View the logs.


7 years ago

This ticket was mentioned in Slack in #core-editor by afercia. View the logs.


7 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 years ago

#22 @afercia
5 years ago

  • Keywords needs-patch needs-testing 2nd-opinion removed
  • Resolution set to wontfix
  • Status changed from new to closed

Discussed again during today's accessibility bug scrub, agreed to close this ticket for the argumentation in comment 10.

Note: See TracTickets for help on using tickets.