On Monday, 26 March 2012 at 23:55, Tab Atkins Jr. wrote:
> On Mon, Mar 26, 2012 at 3:52 PM, Glenn Adams <[email protected]
> (mailto:[email protected])> wrote:
> > On Mon, Mar 26, 2012 at 4:43 PM, Tab Atkins Jr. <[email protected]
> > (mailto:[email protected])>
> > wrote:
> > > On Mon, Mar 26, 2012 at 1:40 PM, Glenn Adams <[email protected]
> > > (mailto:[email protected])> wrote:
> > > > "if it isn't written in the spec, it isn't allowed by the spec"
> > >
> > >
> > >
> > > The statement you quoted is more or less accurate. Behavior that
> > > isn't specced is almost certain to not be interoperable. If the spec
> > > is incomplete or unclear in some aspect, that's a spec bug, not an
> > > opportunity for implementations to make up their own behavior based on
> > > what the engineer thinks is reasonable at the time they're writing the
> > > code.
> >
> >
> >
> > however, that is exactly what implementers do every day... especially those
> > not closely connected with the spec process
>
>
>
> Of course they do. Reality isn't perfect. That doesn't mean it's a good thing.
>
> That said, I agree with your point that documenting important points,
> even if it's technically not required, is a good thing if there is a
> reasonable possibility of confusion.
>
I guess it would be best if people just comment directly on the following (to
cut to the chase):
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16299#c3
