User:Isarra/Skinning

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

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 " 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

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)