RE: ReSpec and how it gets used

I don't know if this is the right thread for this comment ... if not, feel free to let me know.

I am an editor and I rely on the JAWS screen reader. Because Firefox has to be updating is accessibility tree as respect runs, it takes a really long time to run. It is rare that I am able to start reading a branch in rawgit in under a minute. The ARIA spec takes up to 2 minutes before I can read it. Then, sometimes, like today, things are very broken. Today, none of the roles, states, or property sections have headings or permalinks. I don't know if that is due to a new respec bug or a failure of respect to run completely, or a defect in my spec text. Today, I know it is not a defect in my text because I haven't changed it since it last worked.

I am wondering if there is a better way for respect to work. Is there a way to make all the respec changes without doing it on the live DOM and then replace the entire DOM or something like that. Content hidden with display none is left out of the AX tree, so maybe the whole DOM could be hidden while the processing is occurring ... maybe not great for everyone, but at least you would all have an experience that is more like mine <smile>.

Matt King

-----Original Message-----
From: Marcos Caceres [mailto:w3c@marcosc.com] 
Sent: Wednesday, June 8, 2016 2:47 AM
To: Shane McCarron <shane@spec-ops.io>
Cc: Michiel Bijl <michiel@agosto.nl>; spec-prod <spec-prod@w3.org>
Subject: Re: ReSpec and how it gets used

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 22:48:00 UTC