RfC Proposal re modify default layout of universal skin template[edit]
This proposal is a precursor to a formal bugzilla request. Basically, the change being presented for consideration is ...
... to utilize and supplement the recently added universal skin-template generated primary div container for all User typed in content-text by adding two additional universal skin-template generated place-holder div containers immediately before and after the primary container to eventually accommodate the handling of typical header and footer content-text and/or templates normally being applied at various points in the ProofReading process depending upon the namespace involved.
In basic terms, the proposed additions are simply proactive rather than reactive for a change, will not affect the way pages currently function or appear in any namespace in question nor require Users to learn or change the ways & means they currently use to contribute to Wikisource. It involves a rather unextraordinary modification to the underlying code that automatically generates the core layout of any given page regardless of User-selected skin in use or the namespace in question.
Background: In earlier days of the on-going development of Wiki-based coding and for Wikisource's side-by-side proof reading & transclusions in particular, there was little present in the way user-typed content was separated or organized in the default universally generated layout(s) for coders to work with. Every optional 'skin' Users could apply (as well as the default skin) contained the same basic underlying structure and elements as the next skin did even though the styling and format seemed to differ from one skin to the next. This limitation sometimes meant that in order to incorporate new functions or features to the basic layout, developers had to first create additional containers or place-holders in their coding to help facilitate the execution of the coding that came afterwards; coding which actually related to running that new function or adding that mew feature upon a User's view or action. When such newly developed "gadgets" were found to be universally useful and reliable enough across the board, they were incorporated into the default coding with the needed place-holder(s) or container(s) becoming standardized within the default skin generation. In short, the new function or feature was no longer a collection of local-based scripts & files but a formally established extension to the base coding on our servers that can be easily enabled or disabled as needed depending on the Wiki-domain in question. The proposed additional place-holders are akin to that standardization logic but without a specific feature or function currently driving the utilization of them. The hope is that their existance will lead to further enhancements of and simplifications to the extensions that were created long before the current defaults were being automatically generated in the weeks and months to come.
Concern: You're going to break everything from dynamic layouts to side-by-side by proof-reading!
How the proposal addresses this concern: Unfounded. Several similar div containers that function as place-holders as these new div containers would already exist in the universal skin-template and are generated by default even if they are not being used or called upon for every instance on every page. Some examples...
When viewing a sub-page of a base-page, the container holding the link to go up one or more levels in relation to the top-level base-page is generated by default and is in use. When you reach the top-level base-page, the container is still generated but is not utilized (since it doesn't apply) and therefor appears non-existant. In addition, the same universally generated container winds up holding the relevant User and log links along the top of every User's 'Contributions' list-page as well.
When a page is viewed under "Printable view" when selected from the 'Print/export' side-menu, the container holding the tag-line comment, From Wikisource, near the top is automatically generated and utilized. In normal view, the same container with is message is automatically generated as well - only further coding (i.e. CSS style="display:none;" ) prevents the display of the tag-line for every instance of a normally viewed page.
When a page has no categories automatically or manually assigned to it, the category-bar's container is still generated but not used. As soon as a category is associated with a page, the place-holder is utilized and becomes populated with that category in a standardized layout.
So the idea that these additions would somehow break normal display or operation of things is an unfounded one.
