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