If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Link titles not always accurate

RESOLVED WORKSFORME

Status

Mozilla Developer Network
Wiki pages
P3
normal
RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: openjck, Unassigned)

Tracking

Details

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
This is a follow-up to bug 767526.

The link tooltip is not always accurate. Sometimes it shows the right path, other times it shows the wrong path, and other times it shows nothing at all.

See the screenshots. I use the HTML5 article (https://developer.mozilla.org/en/HTML/HTML5) in the examples.
(Reporter)

Comment 1

5 years ago
Created attachment 639814 [details]
Hover working. Yay!
(Reporter)

Comment 2

5 years ago
Created attachment 639815 [details]
Hover wrong. Aww.
(Reporter)

Comment 3

5 years ago
Created attachment 639816 [details]
Hover empty. Boo!
767526 added titles to new links -- it doesn't change all title attributes when a document is opened.

I'll talk to the rest of the team about what to do about all of the titles that MindTouch messed up.  767526 is working correctly though.
a) For a link added via the editor, Dekiwiki was setting the title attribute to the relative URL (which is pretty useless). 

b) Some title are plain wrong (for whatever reason) like the 'en'.

c) And finally template-generated links don't often have a title set.

For a) we should find a sensible title to be added by the editor, then fix the long backlog of links
For b) we have to fix when we hit them
For c) we have to fix the templates.

A tool to help find a) and b) may help (and eventually) correct them.
For the template, we need to improve them.

This is a part of a whole bunch of fix that we will be able to tackle now that we have left Dekiwiki. 

I have a lot of other details like these: unnecessary <nobr>, &nbsp;, spaces immediately next to a <code> or before a </code>, unnecessary trailing slashed, css/html code without the use of class="brush: css/html", ... 

This is an important work (good typography and consistency greatly improve readibility and navigability) , but it is long term work.

Should we create a meta bug for these and list them? Most of them we'll need to be handle manually or using a simple robot.
It may be possible for me to create a button within the WYSIWYG toolbar which would scour through the document content and assign titles.  The downside of that is someone would need to go to each document and click the the button, which may take time.

I'd love to create that button but with the list of things we need to get done, it seems low on the priority list.
It definitively is a post-Kuma launch thing. It was wrong in DekiWiki, so no hurry. And even in the post-Kuma launch era it won't be at the top of the priorities, I believe.
(Reporter)

Comment 8

5 years ago
Got it. Moving it out.
Blocks: 756266
Yeah, this is crazy low priority really. But we could definitely automate this to some extent eventually.

Updated

5 years ago
Priority: -- → P4
(Reporter)

Updated

5 years ago
Priority: P4 → P3
(Assignee)

Updated

5 years ago
Version: Kuma → unspecified
(Assignee)

Updated

5 years ago
Component: Website → Landing pages
Product: Mozilla Developer Network → Mozilla Developer Network
(Reporter)

Updated

5 years ago
No longer blocks: 756266
(Reporter)

Updated

4 years ago
Whiteboard: u= c= s= p=
(Reporter)

Comment 10

4 years ago
Looks like tooltips were reworked a while back. Cannot reproduce.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.