Operator: Izno ( talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)
Time filed: 01:21, Tuesday, February 23, 2021 ( UTC)
Automatic, Supervised, or Manual: supervised
Programming language(s): AutoWikiBrowser
Source code available: AWB
Function overview: Make NavFrame uses accessible in user-space
Links to relevant discussions (where appropriate): Wikipedia:NavFrame, MediaWiki talk:Common.css/to do#NavFrame
Edit period(s): one time run
Estimated number of pages affected: 2400 or less
Exclusion compliant (Yes/No): Yes
Already has a bot flag (Yes/No): Yes
Function details: Two changes will be made:
NavFrame
, replace with NavFrame collapsed
display *: *none *;?
, replace with the empty stringBackground:
WP:NavFrame has been deprecated for a long time. I've recently taken up the cause (again, I spent some time on templates a year or two ago) of removing its uses, either via replacement with a collapsible template or raw mw-collapsible
and friends. Outside the project spaces externally visible (e.g. portal, template, module), a perfect solution probably isn't called for.
What I'd like to do is update user pages particularly to be marginally more accessible by applying the above changes.
At some point, after all article space uses are fixed (I'm not going to fix talk spaces and I've covered the other spaces where necessary pending about 120 individual pages), NavFrame would be removed from Common.css and Common.js. This would cause remaining pages everywhere (user space, article space, talk spaces, etc.) to display uncollapsed and users could elect to update their pages on their own time if they were interested in continuing to have collapsed content, either by using an existing template or migrating to mw-collapsible.
Possible alternatives to this task:
mw-collapsible
alternatives (and remove the NavHead class). This would change some colors and borders, and the interaction with the toggle element would be slightly "jumpy" for the end user. I have no problem implementing this solution if it is preferable to the later possible disruption when NavFrame is removed entirely.-- Izno ( talk) 01:24, 23 February 2021 (UTC) reply
display:none
, which is why I got confused. Personally I think it'd be better to do this in one go, just swapping all the old-and-busted CSS for the new-hotness of mw-collapsible
. I can have a look at finding a solution for the 'jumpy interaction' problem if you wish? Even without that fix, I would support just swapping out the old for the new in userspace and being done with it.
ƒirefly (
t ·
c ) 17:28, 23 February 2021 (UTC)
reply
display *: *none *;?
bit is the same element as the one using NavFrame
, though. I also suggest adding a note about the deprecation in the edit summary, that way users who spot your edits can get a head start on fixing their userpage if they so desire. —
MusikAnimal
talk 21:37, 4 March 2021 (UTC)
reply
Operator: Izno ( talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)
Time filed: 01:21, Tuesday, February 23, 2021 ( UTC)
Automatic, Supervised, or Manual: supervised
Programming language(s): AutoWikiBrowser
Source code available: AWB
Function overview: Make NavFrame uses accessible in user-space
Links to relevant discussions (where appropriate): Wikipedia:NavFrame, MediaWiki talk:Common.css/to do#NavFrame
Edit period(s): one time run
Estimated number of pages affected: 2400 or less
Exclusion compliant (Yes/No): Yes
Already has a bot flag (Yes/No): Yes
Function details: Two changes will be made:
NavFrame
, replace with NavFrame collapsed
display *: *none *;?
, replace with the empty stringBackground:
WP:NavFrame has been deprecated for a long time. I've recently taken up the cause (again, I spent some time on templates a year or two ago) of removing its uses, either via replacement with a collapsible template or raw mw-collapsible
and friends. Outside the project spaces externally visible (e.g. portal, template, module), a perfect solution probably isn't called for.
What I'd like to do is update user pages particularly to be marginally more accessible by applying the above changes.
At some point, after all article space uses are fixed (I'm not going to fix talk spaces and I've covered the other spaces where necessary pending about 120 individual pages), NavFrame would be removed from Common.css and Common.js. This would cause remaining pages everywhere (user space, article space, talk spaces, etc.) to display uncollapsed and users could elect to update their pages on their own time if they were interested in continuing to have collapsed content, either by using an existing template or migrating to mw-collapsible.
Possible alternatives to this task:
mw-collapsible
alternatives (and remove the NavHead class). This would change some colors and borders, and the interaction with the toggle element would be slightly "jumpy" for the end user. I have no problem implementing this solution if it is preferable to the later possible disruption when NavFrame is removed entirely.-- Izno ( talk) 01:24, 23 February 2021 (UTC) reply
display:none
, which is why I got confused. Personally I think it'd be better to do this in one go, just swapping all the old-and-busted CSS for the new-hotness of mw-collapsible
. I can have a look at finding a solution for the 'jumpy interaction' problem if you wish? Even without that fix, I would support just swapping out the old for the new in userspace and being done with it.
ƒirefly (
t ·
c ) 17:28, 23 February 2021 (UTC)
reply
display *: *none *;?
bit is the same element as the one using NavFrame
, though. I also suggest adding a note about the deprecation in the edit summary, that way users who spot your edits can get a head start on fixing their userpage if they so desire. —
MusikAnimal
talk 21:37, 4 March 2021 (UTC)
reply