Re: ReSpec and how it gets used

I was aware that you were having issues Matt.  I was not aware they were
quite this dire.  Can you send us / me the URI to your rawgit tree so I can
figure out what the respec issue is?  As far as I know the ARIA trees were
fixed to work with the current ReSpec a couple of weeks ago.

As to your suggestions....  the approach I had wanted to take was to set
aria-busy to true on the body element until respec and any extensions were
complete.  ReSpec added a Promise that should facilitate this.  Do you
think this approach would work?

On Wed, Jun 8, 2016 at 5:47 PM, Matt King <a11ythinker@gmail.com> wrote:

> 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.
>
>
>


-- 
Shane McCarron
Projects Manager, Spec-Ops