Minecraft Wiki talk:Projects/Refactoring edition specific information

Suggestion for a guiding principle
I propose that as we discuss how to organize and present edition specific information, we be guided by the following principle: "Strive to maintain a distinction between the structure and the form of edition-specific information. Structure refers to how the information fits into the article as a whole and how it relates to similar information for other editions. Form refers to how it's presented on the page."

This is adapted from the principle that the World Wide Web Consortium (W3C) used to separate the CSS language from HTML, and it enormously simplifies both the encoding of the information itself and the customization of its layout for different devices and reader preferences. Every modern web site, including this wiki, depends on this distinction to enable it to generate responsive pages that automatically reformat themselves for the device presenting them.

A special advantage for our purpose is that when information is appropriately marked, our registered readers can customize their Appearances preferences with custom CSS and JavaScript to change how edition-specific information is shown. For instance, they might choose to display their preferred edition's information in a box or a special color, or they might decide to hide information for editions they aren't using. It's simply a matter of changing their preferences at view time, provided our wikitext is properly tagged with structure information. We will still have to decide on a default layout, but at a future time we can design alternate layouts for readers to adopt if they like, or they can create their own, and there won't be any need to change our markup in articles to accomplish the reformatting.

For this project, what this principle means is that we need to identify the different kinds of structure for our edition-specific information, but we can postpone details about how it should appear on the page until later. We can think about its layout to help us visualize, but everybody can visualize it however they like; we don't need to agree on it until much later, possibly even after we've done all the markup changes. I think adhering to this principle will make this project—or any project, because it can apply to lots of them—a lot less likely to get bogged down in its early stages by trying to decide too much too soon. – Auldrick (talk &middot; contribs) 15:10, 9 June 2018 (UTC)