Skin talk timeless – mediawiki

Hover menus like that require skilled mouse pointing/usage, which can prove difficult for people with hand mobility issues or who don’t fully master mouse usage yet (eg. young children, people who are new to computers, etc.). Since the hover areas aren’t links themselves, you could mitigate that problem by making hover menus stick open if one clicks on the area that triggers the hover menu at the moment. Subsequently trying to click on the links the menu contains, with the menu stuck open, becomes less difficult because accidentally hovering outside no longer closes the menu.

There are probably other solutions, but as it stands, this kind of hover menu can create frustration for people who already have a frustrating web browsing experience where clicking on a link that doesn’t move is already a challenge, let alone one that is conditionally visible.

• Looking at a page like this, one sees too many colors. The colors of the links and images are inevitable. Nor do I mind the colored horizontal line under the search box (although one color might be better than three, I don’t know), but the red and the blue under the headings are definitely superfluous.

• I think that "site functions" and "page functions" should be appropriately differentiated. They are not differentiated in the current Vector skin, but this could be a major area of improvement. It would not be bad, for example, to have all "site functions" in the left sidebar and all "page functions" on the right. You could try moving "Print/export", as well as all the "Wiki tools" except "Upload file" and "Special pages", to the right; the result may be interesting.

I see on your userpage that you are also creating less "serious" skins, which better suit certain kinds of non-Wikimedia projects. The suggestions I give above, especially the one about the colors, are specifically intended for the kind of work we do here at Wikimedia projects. So they may or may not interest you, depending on the scope you want your skin to have.– Erasmo Barresi ( talk) 23:26, 16 May 2017 (UTC)

I’m using it in 1.29 and it works well, as far as I can tell Txantimedia ( talk) 22:29, 17 October 2017 (UTC) Timeless seems to work fine on 1.30, as far as I can tell Noloader ( talk) 04:08, 24 December 2017 (UTC) Font needs improvement [ edit ]

Somehow the font used by this skin is bad. After a couple of minutes I get a headache probably since it is pretty blurry and small. I think it will be better to use the same font as for the Vector skin. I am using the skin an a regular PC with 1920 x 1080. Cheers — [[kgh]] ( talk) 22:35, 4 September 2017 (UTC)

@kgh – At the risk of sounding argumentative, I think the font selection is fine. I have older eyes, and I configure the browser with 110% Zoom for all pages. Maybe that speaks to the need for a $wgTimelessFontScale setting. Noloader ( talk) 04:35, 24 December 2017 (UTC) Well, I think it’s bad too, but whether or not it’s apt to be an issue is a bit of a platform-specific thing. I just haven’t gotten around to killing it. -— Isarra ༆ 22:28, 1 May 2018 (UTC) Grant proposal: Post-deployment support for Timeless and stuff [ edit ]

Good luck with the proposal and grant. It would be nice to see you compensated for your time. Its one thing when a small number of users need support and you can do it in your spare time. It’s a different situation when the skin is adopted system-wide and support demands increase 5 fold. Noloader ( talk) 04:11, 24 December 2017 (UTC) To be fair, wide adoption does mean it can be much more quickly debugged and such, so there is that. Generally speaking the issues would be there whether there’s ten users or several hundred. -— Isarra ༆ 22:27, 1 May 2018 (UTC) Can I help? [ edit ]

One thing I’m having trouble with is a custom button in WikiEditor appears randomly. Sometimes it’s there when you open edit. Sometimes I have to reload the page repeatedly before it shows up. I don’t think this is a problem related to the Timeless skin, but perhaps it is. Txantimedia ( talk) 22:29, 17 October 2017 (UTC)

It’s the page self-link (the page tab in others) often used to reload the page/whatever. That’s probably not the best place for it on mobile special pages, though… if it even makes sense to keep it at all at that point. -— Isarra ༆ 22:25, 1 May 2018 (UTC) Nice [ edit ]

It looks nice, but after a while I start to notice a kind of error. There are simply to many layers at the top in the half-compact view. You have site (with search and personal), site navigation, page, and page navigation. Four levels? Add that some pages at Wikipedia has their own levels. This is simply way to much!

My gut feeling is that this skin needs further cleansing of unneeded stuff, it tries to keep to many elements visible. What we sell is content, not navigation. Now it has become way to much navigation. Jeblad ( talk) 07:43, 28 November 2017 (UTC)

I use the 2017 wikitext editor, and I noticed that after clicking "Show preview" the "Resume editing" button in the top left corner is missing. So I have to return to the save form first and resume editing from there. Woodcutterty ( talk) 10:28, 29 November 2017 (UTC)

Now that’s pretty odd, but I have a highlighting problem in Chrome (also Opera and Maxthon, but not IE!). When I try to select some symbols to copy with my mouse, it just selects three or four symbols and then stops doing that. I move the cursor, but nothing happens – four symbols selected, that’s all. Then if I move mouse far away – to the other line, for example, plenty of symbols suddenly get selected, but then it freezes again. I’ve figured this happens only with this skin applied. Also I’ve noticed, that this happens only to those pages which are short and don’t have a scrollbar. This is extremeley wierd, but that’s how it works. Also I’ve noticed, that if I narrow my browser window so that scrollbar appears, highlighting starts to work.

Sounds like phabricator:T183215 and related – chrome is a piece of crap and just does not like certain overflow rules, it seems… it’s a high priority, though. -— Isarra ༆ 20:15, 8 May 2018 (UTC) How to display the title of the link called from the summary? [ edit ]

After a few tests, I notice that it is the banner in fixed position which covers the title called since the anchor of the summary, but, I can not modify the CSS so that the call of a link since the summary can display the title, below the fixed search banner.