On 04/07/2013 07:10 AM, Bartosz Dziewoński wrote: > tl;dr: Let's add class="skintimestamp-YYYYMMDD" to <body> in all skins, > so we can make HTML+CSS changes without breaking the sites. > > [Resending as it doesn't seem to have gotten through the first time.] > > We need HTML versioning information needed in skins to be able to > cleanly make incompatible CSS changes. > > In the Wikimedia setup generated page HTML is cached for ~30 days > regardless of skin HTML changes, while CSS&JS is purged at most a few > minutes after a change is deployed. > > This is a highly suboptimal situation, as this means that in every > change that modifies both the HTML and the CSS, the CSS must be > backwards-compatible with old HTML. This requires a lot of care and > additional awkward testing and causes major issues when not done > carefully enough (e.g. bug 42452), and sometimes just isn't possible > at all unless some transitional hacks are inserted (e.g. bug 46947). > > Luckily this isn't an issue for most third-party wikis, as > `php update.php` after upgrade purges the cache entirely. > > ---- > > I'm proposing adding another class to <body>, > "skintimestamp-YYYYMMDD", where YYYYMMDD is the year, month and day of > the time that given skin's HTML was last modified in an incompatible > way. Day should be enough granularity to avoid conflicts while keeping > the class name short enough. > > This can be easily done using the addToBodyAttributes() method of the > Skin class. The timestamp would be updated manually by whoever is > making those changes, and the class could be used in the CSS to only > apply new styles to newly generated HTML. Older styles could be simply > left intact, and then removed after enough time has passed. > > If multiple incompatible changes are ever done in overlapping time > periods, the successive ones would include updates to the "old new" > styles to use both the new and old class. > > Thoughts? > > [Bug for this is https://bugzilla.wikimedia.org/show_bug.cgi?id=46956 , > but let's keep the discussion here, please.]
Thanks, Bartosz, for clearly and collegially stating this problem and your proposed solution! The problem sounds like a real problem. I don't see any particular blockers in your proposed solution, but I do want to watch out for one implementation detail. "The timestamp would be updated manually by whoever is making those changes" -- could we introduce some clever automation to propose an update every time a relevant file is touched or a particular automated test breaks? Otherwise we have to thoroughly educate authors and reviewers to always update this, which sounds tedious. Thanks again. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
