Thread:Hackey5/@comment-957747-20190302213052/@comment-5645428-20190308080500

I imagine that you would understand that the nature of working with code is not a straightforward and one-size-fits-all process. To achieve certain outcomes, there are multiple methods to do so, and this is acknowledged to an extent where the policy states “It’s impossible to create an exhaustive list of “do’s” and “don’ts” for CSS, there are so many variations!”, as indeed there is. Comprehensive styling is complex and deeply integrated and addressing particular aspects is not as simple as a plain addition or removal of a line of code.

As I understand it, the primary objectives of the customisation policy is to ensure the consistency and clear presence of branding elements, essential functional elements, advertising elements, as well as the general page layout and its associated breakpoints, while also discouraging radical departures.

Moreover, some examples of radical departures that the customisation policy is designed to prevent would be to:
 * Lock the global header to the top of the page or change its colour scheme.
 * Increase the content-space to span the entire browser window like Wikipedia.
 * Shrink the sidebar/rail to two thirds of its width to increase the article body width.
 * Allow content to overflow from the article body beneath the sidebar/rail.
 * Completely hide advertising elements.
 * Add, rearrange or remove items from the global footer.

My code has been wholly respectful here, but as mentioned, it is not straightforward to achieve certain outcomes to improve the aesthetic if the policy is interpreted as a blunt ‘hands-off’, which is not at all stated (outside of global branding elements). My code in multiple instances involves adjusting margins, padding and font size to unify and balance what is by default distorted spacing across the site, while the breakpoints have not been changed and the widths of container elements are retained (possibly respecified at the default value), assisted by consistency tweaks. Interpreting these as severe policy violations is excessive, when these only serve to improve the site appearance by making it neater and more consistent than the default state, especially when compared to the bulleted items above which are proper violations that are understandably what the customisation policy is actually designed to prevent. The precedent which the Geometry Dash Wiki sets is not by any means extreme. Rather, it’s a simple, balanced and appealing look that only builds upon Fandom’s established design.

My code contains no apparent violations that can be interpreted as veering into radical territory that is outright questionable. The only exception is code associated with the staple header, which understandably can be considered a branding element as a whole, but this code was suppressed, and should not have been removed, not being active and existing for reference.

The Fan Feed footer, if this was in fact observed, in particular is improved extensively with my code, and I would argue that I have done Fandom a favour since by making it look so much nicer, it is far more likely to attract people to click on its items. It is not mentioned in the customisation policy either and the enhancing code had no logical reason to be removed, especially on the basis of its own merit in being a superior rendition. I have included images so that you may see it for its obvious improvements and compare it to the lacklustre default state. This is one of many examples where my code serves to optimise and improve in a faithful manner.

Further instances of removing code that did not violate any policies include that which optimised older features which even to this day are not properly compatible and do not fully display on smaller browser windows. This is counterproductive at best and contrary to the design principles so frequently expressed as part of the modernisation project.

It cannot be ignored either that Fandom has been heavily promoting its community focus. Overreach into a community’s site customisation – and by extension its unique visual identity – where that customisation is not obscuring Fandom branding or advertisements or radically negatively altering the general layout, serves neither Fandom's interests in attracting users or the community and viewers' interests.

The customisation policy states "...visitors should be able to rely on the interface and features being in expected places as they move around FANDOM.", and to that my code remains faithful. Its implementation is complex, but it does not extend beyond what could be considered conducive and reasonable improvements. It does not warrant code being removed in a black and white context, and once again, does not veer into radical questionable territory. ​