- From: Marcos Caceres <w3c@marcosc.com>
- Date: Wed, 8 Jun 2016 02:46:57 -0700
- To: Shane McCarron <shane@spec-ops.io>
- Cc: Michiel Bijl <michiel@agosto.nl>, spec-prod <spec-prod@w3.org>
On June 8, 2016 at 5:37:19 AM, Shane McCarron (shane@spec-ops.io) wrote: > Comments in line > > On Tue, Jun 7, 2016 at 2:11 PM, Markus Lanthaler > wrote: > > > > > >> browser is over 2 years old now, and has been superseded by Edge). > > >> Either kindly ask your users to switch to Edge > > > > Well, that might be tricky for lots of users as it also requires an OS > > update. > > > > Agreed. Moreover, this is not an option for many users (see below). But this is an option for everyone who writes specs. I've never met anyone at the w3c who is in this situation (or can't use another browser). > > >> or use a more modern browser ... alternatively, please publish the > > >> ReSpec output instead, which should work on any browser going > > >> back to IE6. > > > > I'm not going to ask to start supporting IE11 again but what browser > > support do you aim for? Only the absolute latest version? IE11 still seems > > to have a considerable market share... > > > > > We have no clear guidelines on this My inclination is to never break faith > with backward compatibility unless maintaining it forces a reduction in > primary function. I suspect we have made a mistake removing whatever > polyfill enabled IE11 support. There was nothing removed. Just stuff got added. IE11 is not maintained, so it breaks because it's been left behind by the Web. > And while I agree with some other > commenters that publishing static versions is a better end user experience > anyway, the reality is that many working groups are developing specs using > ReSpec, and those groups don't want to take the time to generate static > versions - in particular for their "Editor's Draft"s. So to the extent > that we want people to be able to readily review specs as they are in > development, we need to take this into consideration. Agree. This is a long process - but we need to work as a community to get there. > Note that I am not talking about the people writing the specs. I assume > they are working with relatively modern user agents. They are typically > geeks like us. But their constituents are often less tech-savvy. The Web > Payments community, for example, has A LOT of bankers in it. Conservative > organizations tend to lock down software and only upgrade rarely, and then > after acceptance testing. But they are nonetheless members of the W3C, and > should be able to review and comment on our specs. Sure, and again the best way to serve them is to give them generated snapshots (even of EDs). > > > > > As a reader of ReSpec'd specs, I'd highly appreciate it if more people > > > published the generated output instead of the sources. It avoids the > > > flash-of-unprocessed-content and subsequent anchor-jumping, and it > > > works better in the tooling infrastructure. > > > > The thing I like most about ReSpec is that it doesn't need any > > "compilation" step. It's not perfect but for most use cases it works well > > enough. > > > > > Yes. It is what drew many of us to ReSpec. The recent instability has > made it a much less desirable platform. My groups have spent a lot of time > trying to resolve ReSpec introduced problems or learning new requirements > as features change. Worse yet, various changes have broken the tool chain > that enabled the automated generation of "TR" versions of specs or > otherwise made it impossible to publish without hand-editing. This is no different to Bikeshed or Anolis or any other piece of software. Software breaks, things change. We patch stuff quickly and move on. ¯\_(ツ)_/¯ > As a maintainer of ReSpec, I am appalled. As a user, I am frustrated. As > an advocate, I am finding it a hard product to recommend. It's open source, you are free to leave, fork, use BikeShed, whatever ¯\_(ツ)_/¯. I like the improvements I've made - and sure, there was a little pain for a tiny number of people for maybe a couple of hours, but whatever. At least it's actually getting maintained and updated now - and it's vastly better. A year ago, it was "stable" in the sense that it was rotting away because no one was spending any time improving it after Robin left. That's not stability: that's just bit rot. > Perhaps the solution is to make all the (named) versions available so that > document developers can choose the one that works well for them and their > users? Or identify a stable version and call that official, then leave the > "development" bleeding-edge that people can use or not. That's what we do today. We develop in branches, which go to "develop", which then get released into "gh-pages". > Do a migration to > stable periodically after substantial testing. I don't know. But something > needs to change. Right now I see the best case as people forking ReSpec so > they have something they can rely upon. I see the worst case as them > abandoning the platform. Both of these would be a failure. I think you are totally over dramatizing things. Little bugs are no big deal. Most people haven't noticed that we've done like 40+ releases in the last year.
Received on Wednesday, 8 June 2016 09:47:26 UTC