Closed Bug 1018707 Opened 11 years ago Closed 10 years ago

Empty CustomCSS

Categories

(developer.mozilla.org Graveyard :: Performance, enhancement)

Product:
developer.mozilla.org Graveyard
Component:
Performance
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: fs, Unassigned)

References

(
URL
)

Details

(Keywords: perf)

A couple of weeks ago, I created an etherpad [1] with comments and proposals for migrating the CSS rules from CustomCSS to stylus and with that to a real reviewed and structured CSS in the hand of our Front-end engineers. I haven't heard much feedback yet, so opening this bug to discuss the goal of *empyting* the CustomCSS template. Note: This bug is not about finding a solution for a fast wiki-editable CSS (use bug 770195 for that discussion). I am opening this bug for emptying and refactoring the current contents of https://developer.mozilla.org/en-US/docs/Template:CustomCSS [1] https://etherpad.mozilla.org/CustomCSS-migration
Before I can really respond, the writers need to figure out what they *need*. You guys know your docs better than I do, so this is a process I'd like for you all to work out, then tell me what to do :)
I think we have loads of things in there that we need (myself and others marked those as in need of migration in the etherpad). These things need to persist and could be refactored into real CSS/stylus which is reviewed by the devs step by step. No need to do it all at once. If you look at the etherpad, you might find several things that belong together. A first PR could start with e.g. all banner rules or another with all compat table rules and so forth. Needinfo'ing sheppy and teoli for more thoughts.
Flags: needinfo?(jypenator)
Flags: needinfo?(eshepherd)
I do agree with Florian here. We need to do it step by step: a do it all in once will never happen. We have four kinds of things there: 1. Things that we need, that need review (change) and be moved away in the official CSS. 2. Things that we don't want, but are a stop gap: we need to have the real problem fix (We have an !important added last week-end to work-around a problem — this has to go away when the original bug is closed) 3. Things that are no more needed: they are still in use, but we are them phasing out. For each of them, we need to perform the phasing out (changes in macros/in pages) then delete them from CustomCSS. 4. Things that are no more in use (and we don't want to keep) that needs to be deleted. 3. and 4. can be done by the writers alone. But 1. and 2. needs time from the developers. I also believe that if we want this to go forward we need the managers to set this as a goal for both of our teams (E.g. a goal for the second half of 2014), else we will never put time on this.
Flags: needinfo?(jypenator)
Severity: normal → enhancement
OK. I propose we divide this work into stages: 1. Find and remove anything we are not actually using. 2. Find the things we shouldn't be using and stop using it, then remove them from CustomCSS. 3. Everything that's left should be cleaned up, standardized, and migrated to stylus. 4. Remove the now empty CustomCSS. 5. Celebrate.
fscholz, are you game to drive this by scheduling the meetings and nagging people to do stuff? :)
Flags: needinfo?(eshepherd)
fscholz: On second thought, that's probably something I should handle, unless you really want to. If you really want to deal with it, let me know.
Note that we don't want to remove CustomCSS until we have another way to change CSS while the devs are not there. Pre-review of all CSS is a no go.
(In reply to Eric Shepherd [:sheppy] from comment #6) > fscholz, are you game to drive this by scheduling the meetings and nagging > people to do stuff? :) No, I'd like to write content instead :) (In reply to Eric Shepherd [:sheppy] from comment #7) > fscholz: On second thought, that's probably something I should handle, > unless you really want to. If you really want to deal with it, let me know. Thanks, go for it! (In reply to Jean-Yves Perrier [:teoli] from comment #8) > Note that we don't want to remove CustomCSS until we have another way to > change CSS while the devs are not there. > > Pre-review of all CSS is a no go. As I said in the description, please let's not start this discussion here again. This bug is only about emptying the template (and refactoring its CSS) and not about removing it. Sheppy's step 4 in comment 4 therefore depends on the solution we find in bug 770195.
Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/d474c27828ead17dc878306ac7a3147320a92fdf Bug 1018707 - Empty CustomCSS Moved the default link styles to be first in the declaration. Moved the .ignore-external class out of customCSS and into wiki.styl. I will remove it from customCSS when this change is live. https://github.com/mozilla/kuma/commit/98e85ecd50e57c260775699ac33a90274644dbd2 Merge pull request #2733 from stephaniehobson/BUG-1018707-empty-customcss Bug 1018707 - Empty CustomCSS
Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/7711b44a199b80f24df66c8d7e855892a2762126 Bug 1018707 - Empty CustomCSS Copied CustomCSS into this file so it is minified. Myself and @groovecoder have "subscribed" to changes to CustomCSS and when changes to the file occur they can be moved into a proper place in the code base. We can work through this file slowly integrating its contents into our code base but in the mean time at least it's minified. When this goes into staging the contents of CustomCSS need to be emptied for testing. When this goes into production they contents of CustomCSS will need to be removed there as well. https://github.com/mozilla/kuma/commit/f799c863e4b11da441c3cd15761e30e90b6aee48 Merge pull request #2746 from stephaniehobson/BUG-1018707-empty-customcss Bug 1018707 - Empty CustomCSS
Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/db02afd1f32d620d9a870abab59657d6312f575a bug 1018707 - Waffle CustomCSS so that we can remove it from production https://github.com/mozilla/kuma/commit/6fb69d6cb234d1752087ec31744b6ce5900b7e0f bug 1018707 - add test for enable_customcss waffle https://github.com/mozilla/kuma/commit/99edace8e5866ffde982583f61a9fc5ecae7261a Merge pull request #2752 from groovecoder/waffle-customcss-1018707 bug 1018707 - Waffle CustomCSS so that we can remove it from production
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
I moved the great review of the CSS classes that Florian created and linked to in comment 0 to: https://docs.google.com/document/d/1pi2qrKmYmcV28gsEr7dCpYhW5cli1dOHoxUkVVC6M5Y/edit?usp=sharing which should be visible to anyone with the link. Ping me if you would like edit access.
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.