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

unflow:

nested threads content model blah blah blah what did lqt do well? what did flow do well? What do we need from discourse help desk?

https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Notifications_in_core/Archive_1