For the record, that is dated information about the EPUB spec. The last version of EPUB that pointed to CSS 2.1 was published in 2011. See https://www.w3.org/Submission/2017/SUBM-epub-contentdocs-20170125/Overview.html#sec-overview-relations-css.
Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>
From: Florian Rivoal <florian@rivoal.net>
Sent: Monday, November 11, 2019 11:24 PM
To: Mike Champion <Michael.Champion@microsoft.com>
Cc: fantasai <fantasai.lists@inkedblade.net>; Jeff Jaffe <jeff@w3.org>; W3C Process Community Group <public-w3process@w3.org>
Subject: Re: [EXTERNAL] EverTeal
On Nov 12, 2019, at 6:59, Michael Champion <Michael.Champion@microsoft.com<mailto:Michael.Champion@microsoft.com>> wrote:
If there’s a use case for the charter / AC insisting that a WG restrict itself from using the new EverTeal process improvements, I’m not seeing it
We have things like the EPUB spec, which made CSS2.1 minus some specific features a normative dependency. They didn't make CSS overall a dependency, they made a specific feature set (defined by CSS2.1 minus some things) a dependency. There's been other cases of this, for example HBBTV's normative dependency on CSS. I don't remember others off the top of my head, but I am sure there are more. These things aren't interested in a normative dependency on something with an open scope. They explicitly want to lock the scope down. If we have a kind of REC that can take bugfixes but not new features, they'll depend on that. If we cannot, they'll take normative dependencies on dated versions, miss out on bug fixes. In the worst case, this could end up causing a fork in the technology if people are particularly diligent about implementing the details of the dated version referenced.
WCAG is another example of something where fixing the scope (while allowing bug fixes) seems desirable.
—Florian