(probably) based on Vector
Version: unspecified
Severity: normal
Whiteboard: u=dev c=frontend p=0
(probably) based on Vector
Version: unspecified
Severity: normal
Whiteboard: u=dev c=frontend p=0
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Jdlrobson | T78430 [Epic] Getting Wikidata to render nicely on mobile web | |||
Open | None | T158181 Aim for workflow equivalence for MediaWiki on desktop and mobile web | |||
Open | None | T95878 [Story] Make Wikidata editable on mobile web | |||
Open | None | T95649 Create and document a stable framework for extending the Wikibase UI | |||
Stalled | None | T40968 Keyboard-navigability of the repo UI | |||
Open | None | T54136 [Epic] Redesign Item UI for Wikidata repo | |||
Declined | Lydia_Pintscher | T75653 Implement new Wikibase Skin | |||
Invalid | • adrianheine | T75652 Research how we can maximize compatibility of a new Wikibase skin with Vector (and Monobook) | |||
Resolved | Tobi_WMDE_SW | T75651 Research usage of different skins in Wikidata community |
After some tossing and turning, I opt for not implementing a dedicated skin as long as there are no specific requirements. A dedicated skin (although it would just be an adaption of an existing skin without applying any complex patterns) increases complexity in several ways with the benefit not outweighing that trade-off.
The lack of being able to customize the DOM structure while rendering is more like an issue with the core software that would just be worked around.
What is being done in Wikibase at the moment: Native DOM elements (basically just #firstHeading) are hidden while the whole Wikibase DOM structure is assembled in #mw-content-text. The native CSS class .firstHeading is mirrored with .wb-firstHeading.
The procedure of putting the whole entity DOM into #mw-content-text is basically fine as it circumvents having to mess with core DOM structure. (The Wikibase entity DOM structure should be independent from the core DOM structure in any way.) Cloning the .firstHeading class should be removed which can be done along implementing the new UI header because that requries changing the DOM structure anyway.
The final question is how to properly handle the DOM produced by core? Most nodes are configurable and probably may (should) remain untouched. However, the effect of those elements on the layout needs to be evaluated. For example, showing #siteSub looks quite awkward at the moment. Still a bugging issue is hiding #firstHeading as #firstHeading is a core concept of the native core DOM structure and, probably, should just not be hidden but styled in an unobtrusive way. In fact, #firstHeading covers information that is not necessarily reflected elsewhere (as it contains not just the Q number but the namespace as well). Although this is not a blocking issue, since, as mentioned above, the Wikibase DOM structure should be independent from core DOM structure, all these core elements need to be considered at some point when (re-)designing.
I would strongly urge you that if you are building a new skin it shouldn't be tied to Wikibase in any way so that it can be used by 3rd parties and help guide the work that @TrevorParscal and @matmarex are doing.