- Open Source dev since 2001
- Wikipedian since 2005
- Wikipedia admin 2008-2019
- Commons admin 2010-2015
- MediaWiki dev (+2) since 2009
Uses Safari most of the time (because someone has to)
Uses Safari most of the time (because someone has to)
I can't confirm this. I don't have any performance issues caused by this feature and I never heard of anyone who had some. Are there any bug reports or discussions in which someone mentions problems caused by this feature?
This ticket is about keyboard accessibility primarily. I do note however that both controls the Personal Tools dropdown and the Language dropdown don't work properly in screenreaders either (the latter works a bit better than the first). The More dropdown works reasonably well in a screenreader.
- Thumbor at WMF has no owner, an issue we constantly keep running into.
Since the entire maps cluster is?/was? rebuilt, can this ticket be closed ?
These two patches should provide a decent amount of screenreader accessibility. It wasn't easy. Lessons learned:
This might be a reason to consider a css-grid layout over a table. From reading some web posts ( 1 and 2 ), it seems that grids are better for interactive content like this. Rather than each cell being it sown focus, the whole grid is a focus that can be navigated using keys and such.
Note. One concern that I identified which I didn’t see addressed in the spike, is with side by side and that it just doesnt work on narrow screens. I worked around this in ALP by disabling the functionality below a certain width. But it turns out this sometimes surprises ppl. I have received “complaints” in the past, both because ALP didn’t work (use enabled, but his screen was too small so it seemed the preference didn’t do anything) and “what the hell is this all of a sudden” (user had had the option enabled for ages but all of a sudden started using a bigger screen and the functionality “magically” appeared.
Note, it’s September !
Sounds like this can be closed ?
Wasnt there already a ticket for this ???
@nray i was thinking that maybe its acceptable to auto hide the header upon navigating to an anchor after a couple ms. Then whenever you scroll it would unhide ? might be worth an experiment.
For Animated PNG, we render to a still frame png when we thumbnail. Note that this is primarily a side effect of the pipeline if i'm not mistaken. It was never much of an active decision.
I can confirm that i updated Vector first, MIGHT have loaded a page, and then updated core.
Based on the Hebrew Wikipedia's implementation, I think the moves should be RTL in those locales. The game details are currently set up as a table, and since that's text it should probably be RTL though he Wiki has the metadata in English it seems.
I did some work on keyboard accessibility for the button/actions. TODO:
I've not been able to get it to draw a tile that looks like a current tile.. I'm not sure why. I don't have the experience to deal with problems like these unfortunately. Maybe we need to ask wikitech-l ?
I'm wondering if accessibility takes a hit if we do this. Consider a user landing on a page, scrolling down to trigger the sticky header and then hitting tab.
This happens when a page has a Score and also a TMH element. The TMH player script tries to load it's JS on top of the Score player, but we probably never tested that in the last couple of years (because everything was broken).
Apparently there are also situations where the cursor is misaligned an entire line up/down. This might be related to extremely long articles, or specific skins.
Was not able to confirm this yet, will have to look tomorrow.
I'm going to be deploying an update to my gadget on en.wp soon. This includes the fix for the collapsed borders + sticky. Unfortunately it seems that in Safari 14 there are now several problems with sticky table elements. The most noticeable is that the space that a table caption takes up is added above the sticky element. All these problems should be fixed in Safari 15 pretty soon however (according to the upstream tickets)
Just a thank you to Tim and Lego for working on this for all that time. I know its been quite a bit of work.
Yes likely we will need to set a state file from before we got out of sync... Determining when that was exactly is probably going to be the hard part however... I think it was at least about a year or so....
I've also made some significant changes in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ChessBrowser/+/715603/
That still requires a bit more work, which I hope to do later this week.
hmmmm. now it disappeared.. i'm guessing some sort of RL caching ???
Small guess.. it doesn't like symlinks very well ?
ls -la ./skins lrwxr-xr-x 1 hartman staff 28 Dec 6 2016 Vector -> ../../mediawiki-skins/Vector
Is this with the core patch applied? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/712998/
I'll take a look.
I update Vector, and this seems to have broken my installation...
And what about the game details, the steps and the table ? what should their directionality be ?
sounds like a missing event.preventDefault() or something. I'll check this later tonight.
this can be easily fixed by using the .client-js class to hide the element, instead of JS. I'll do that tonight.
Ah, another reason I didn't see this problem in the same way, was because I was using
https://he.wikipedia.beta.wmflabs.org/wiki/משתמש:קיפודנחש1/ChessBrowser_test_cases?uselang=en instead of
Hmm. does anyone know about the class pgn-pgn-display ? This sets a direction, but apparently it is never used in the source code of the player... Was it renamed perhaps at some point ?
Well I can easily hardcode the direction to ltr for the checkerboard, that fixes the legend…. But apparently not the piece position. That can be for various reasons, I’ll have to check if it’s because they are calculated only once…..
can you make screenshots of what it looks like and how it should like ? That makes interpretation a lot easier...
And is this a new issue, or was it already like that for a while but no one noticed ?
This specific bug was fixed, and the more general 'problem' is already tracked at T116318: Images in tables are too small
ok.. the original issue with text overlaying the other text, was actually because someone added a heigh limit which was insufficient for the contents... this has been fixed.
calling this fixed
I rewrote this template. Not yet deployed, but https://en.wikipedia.org/wiki/Template_talk:Subject_bar#Better_responsiveness
I don't see the problem. If you break the html, other things are going to break. Don't break the html.
i don't see this problem any longer
Related ticket: T116318: Images in tables are too small
@Molgreen Its fixed in PHP, but not in the version of PHP that the WMF currently runs.
@fgiunchedi you know if that patch makes sense ?
I'm calling this fixed.... we'd likely seen more reports by now if it wasn't
Found the ticket on this problem: T226311: Full size videos displayed as small videos in gallery
I suspect some of the performance-related concerns raised here are from users who experienced this before January 2021. That issue is fixed.
I guess this is a FileBackend detail..
So I took a quick look at specifically: https://commons.wikimedia.org/wiki/File:Klaviersonate_Nr._31_As-Dur_op._110_-_I._Moderato_cantabile,_molto_espressivo.ogg from T288896: Some Ogg files show "Invalid Ogg file: Stream Undecodable"
I also see all the VE JS being loaded (with debug=true).. that's not normal....
i mean. it's infra that no one wants to be responsible for, i get it, but we gotta put some sort of tag on it...
not thats just the rendering. This is about the postgres DB with the database..
ok... now thumbframes on mediawiki.org are loading late.. seems like the parsoid CSS module is not added with addModuleStyles() to ensure its loaded before the page rendering starts ?
they are for implementing the results of those discussions.
@Majavah I didn't know we kept separate tags for the DB replicas of Toolforge. Do you know what the project tag for that is ?
of note.. if you add a sticky header, your anchor (section links) will anchor to behind ur header... which can be rather confusing.. might want to think about that as well when implementing this..
@Iniquity can we add a white outline to that play button ? When you have a dark background in the thumb, it blends in a LOT now...
forgot to close
this seems interesting though...
known issue, see linked task