Jump to content

User:Isarra/Skinning

From mediawiki.org

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