Re: Web standards, Openness and Transparency

On Tue, Aug 12, 2014 at 7:43 AM, Marcos Caceres <marcos@marcosc.com> wrote:

> For example:
>
> * srcset in HTML and the huge fight we (the RICG) had to have for 2 years
> to get that removed from HTML in favor of <picture> (and updated srcset).
> Editors adding features into a spec without consensus is clearly bad and
> leads to a lot of confusion/frustration.
>

Yeah, I'd actually written out that example and then deleted it.


> > that makes it quite hard (particularly in a large specification) to tell
> > what's implemented everywhere, what's pretty solidly agreed upon, and
> what
> > is just a roughed-out idea.
>
> Agree. Though specs like WHATWG HTML have per-section stability markers -
> though they can be deceiving.
>

s/can be/usually are.  :)


> > > > It *IS*
> > > > a good idea to make sure /TR documents always POINT to the current
> > > > spec or effort (yes, including pointing to editor's drafts).
> >...
>
> Ok, making this mandatory in the templates would be great.
>

That's what I've had in mind as part of that "graveyard of /TR" item.


>
> > > I think redefining history of specs is bad.
> > >
> > > Not sure what this means. Can you provide an example?
> > >
> >
> > Any time you simply rev in-place without significant versioning, you're
> > effectively changing history.
>
> But all specs are worked using a version control system - so you always
> have history? Are you saying that specs should provide a link to their
> commit history? (if yes, many specs do - but yes, it would be nice if this
> was a mandatory thing).
>

There's a big difference between digging through thousands of commits in a
repo and having a clear "oh, that's how these things worked together in v6."