store interface data better, do not require developers to interact directly with giant array
(get, html, etc functions too much)
figure out what all the actually used functions should be - what do we need to place? What do we not?
Nagivation
Need way to make second sidebar/other navigation with different ids
use case - limited navigation duplicated in footer (greystuff)
use case - literally a second sidebar for mobile with extra handling (monobook)
use case - sticky cactions
wtf is with makeLink, makeListItem, etc, extremely poor UX and extensibility (don't even know what it's entirely for currently; vague option soup)
STOP USING RAW STRINGS FOR EVERYTHING
per id-fixing php-side: "if you're using htmlelements or whatever the modern thing is, should be easy enough. if it's a raw string, then you're mostly screwed"
(note that currently a lot of stuff isn't even that good - much still assumes you're printing directly, so strings skin developers work with can often come from catching this - see MonoBookTemplate::deprecatedHookHack)
more granular common styles rl modules/resources
good: more specific things like external links module
bad: content.css, with borders and pading and everything for toc, categories, everything, specific thumbnail syles in general (vector/monobook style); also has definitions that make the thumbnail magnify icon appear (much more likely to be globally applicable)
categories
need way to just get category data (to deal with however) (issues with current approaches and caching - timeless)
also need standard way to get category data (as currently)
need singular ToC
instead of scattering across three other classes, specific ToC class that extensions can interact with directly
allow skins to place/use it however they want, along with the default
still needs to abide by NOTOC, TOC, etc?
Tools - core tools such as cactions, toolbox, etc, plus extension-added tools - need sorting
Define types of tools, let extensions say what type of tool what they're adding is, and let the skin decide where to put all tools of that type
add priorities - high priority tools shown first, lower priority ones might be moved to a dropdown or such if insufficient space (a la more cactions menu in Vector)
set of colours/values for reuse by core interface objects/extensions
borders, backgrounds for tables, boxes
highlight colours?
sort of padding to use
thickness, rounding, whatever
standardise set of classes for ''types'' of things so skins can further customise if desired
boxes, types of links
¿¿??
Also use this to define ooui themes? (perhaps this IS the ooui 'theme' definition as well?)
ooui across all forms for consistency
problem: skin:example is insufficient and poorly updated
no idea how to fix this - actually pay someone to maintain skins in general?
need better way to start making skins in general, perhaps?
wiki-side site admin configuration for skins - set themes, upload all possible logos, manage available skins
determine consistent logo formats for all skins to be able to use - square image, tall image, long image, wordmark only, different sizes?
common or skin-specific site colours
probably a special page?
themes - need consistent approach, be able to just set in skin some available ones, set some canned colour combos
probably something like current theme approach using less variables (was in bluesky, currently broken), but without requiring skin developers to put in all the setup skin-side (define canned themes in skin.json, set the variables in files)
use these in onwiki config, allow users (site admins) to set their own as well
what even is mobilefrontend, get useful stuff in core, that should not need an extension
stop hiding crap, seriously
" with echo, etc, clean this mess up (need notifications handler/display standardised unambiguously so skins etc can work with it) - https://www.mediawiki.org/wiki/Requests_for_comment/Notifications_in_core
issues with one vs two icons
" with ULS, get some options for different layouts built in, apis for putting it in core
people really like language switchers being more accessible (top of page)
canned things
thing to collapse tabs into side menu at lower resolution (vector actions -> more)
basic mobile layout with the sort of js/dropdown menus people apparently expect (per reaction to not having that initially in monobook mobile)
search boxes - full buttons (monobook), search icon for button (vector), full-width (timeless)
mobile
editing - through extensions or core
special pages
content tables
navboxes
extension content in general
ooui
rabdom skin-specific stuff that really isn't skin-specific that needs to be moved into core
everything from:
tabindex on search T201424
62% of skinstyles stuff currently in core
all the per-skin helper functions that are all slightly different but really shouldn't be (getfooter, getportlet, getsidebar, etc)
JUST ADD SOME FECKIN' HOOKS AND CRAP FOR BETTER MODIFICATION FROM SKINS OR EXTENSIONS
core should provide default page status indicator CSS T199035rabdom skin-specific stuff that really isn't skin-specific that needs to be moved into core
everything from:
tabindex on search T201424
62% of skinstyles stuff currently in core
all the per-skin helper functions that are all slightly different but really shouldn't be (getfooter, getportlet, getsidebar, etc)
JUST ADD SOME FECKIN' HOOKS AND CRAP FOR BETTER MODIFICATION FROM SKINS OR EXTENSIONS
core should provide default page status indicator CSS T199035
----
wmf not really supporting skins (team specific)
wmf makes changes across all skins to update a thing
get things learned from timeless into other skins
tickets for the issues
(instead of dumb notes)
like minerva disabling all the things that don't work
echo not working in mobile, ooui needing to handle desktop/mobile vs skins/extensions
create hierarchy of skin support
not put stuff into core just shoving it in wherever, but divide it into classes
timeless working around issues from other skins, but starting from scratch
get common things in core, especially where new skin is still doing the same things
useful to talk to other folks to make case for changing how things are done
timeless/minerva lacking the baggage of monobook/vector - good for experimentation
switch to monobook - pretty smooth
switch to vector - fiiiiight
did not consult community (adequately) - problem?
small things caused problems
- now want small changes, small chages put vector into a state very similar to monobook again
- typography refresh issues, changes always have issues, even in bigger companies
do put specific ways to set things like max width, how many columns to force, etc (normally preferences)
no such thing as a private api - better to actually have api, because css, dom etc can change (though normally we try to avoid this)
TODO: do add note that timeless structure/dom can/will change at a whim
https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Notifications_in_core/Archive_1
