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:[email protected]]=20
Sent: Wednesday, June 8, 2016 2:47 AM
To: Shane McCarron <[email protected]>
Cc: Michiel Bijl <[email protected]>; spec-prod <[email protected]>
Subject: Re: ReSpec and how it gets used

On June 8, 2016 at 5:37:19 AM, Shane McCarron ([email protected]) 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=20
> > 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=20
> > >> 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=20
> faith with backward compatibility unless maintaining it forces a=20
> reduction in primary function. I suspect we have made a mistake=20
> 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=20
> experience anyway, the reality is that many working groups are=20
> developing specs using ReSpec, and those groups don't want to take the =

> time to generate static versions - in particular for their "Editor's=20
> Draft"s. So to the extent that we want people to be able to readily=20
> 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=20
> assume they are working with relatively modern user agents. They are=20
> typically geeks like us. But their constituents are often less=20
> tech-savvy. The Web Payments community, for example, has A LOT of=20
> bankers in it. Conservative organizations tend to lock down software=20
> and only upgrade rarely, and then after acceptance testing. But they=20
> 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=20
> > > people published the generated output instead of the sources. It=20
> > > avoids the flash-of-unprocessed-content and subsequent=20
> > > anchor-jumping, and it works better in the tooling infrastructure.
> >
> > The thing I like most about ReSpec is that it doesn't need any=20
> > "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=20
> made it a much less desirable platform. My groups have spent a lot of=20
> time trying to resolve ReSpec introduced problems or learning new=20
> requirements as features change. Worse yet, various changes have=20
> broken the tool chain that enabled the automated generation of "TR"=20
> 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.
=C2=AF\_(=E3=83=84)_/=C2=AF

> As a maintainer of ReSpec, I am appalled. As a user, I am frustrated.=20
> 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
=C2=AF\_(=E3=83=84)_/=C2=AF.

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=20
> that document developers can choose the one that works well for them=20
> and their users? Or identify a stable version and call that official,=20
> 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=20
> something needs to change. Right now I see the best case as people=20
> forking ReSpec so they have something they can rely upon. I see the=20
> 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.