No, but the solution has to work when everyone is playing by the rules,
even if most things are optional. Take for an example the idea that the
client can offer a different session ID from the one the server offered.
In this case, you can't encode anything in the session ID even if 99% of
the world doesn't implement it, because someone will come along and make
the world's most popular browser for reasons unrelated to this and all of
a sudden your solution doesn't work for half the population.
> If every possible interaction of conforming implementations of a spec
> produces reliable behaviour, then that's about the best you can ask of
> a spec.
Yep.
> The problem with web reliability is that we've got incomplete specs,
> (i.e. there are interactions between implementations that comply with
> everything that's in the spec, and things go haywire anyway.) Plus,
> we've got implementations with no specs at all.
Yep yep.
> Lord knows we've got a lot of catching up to do in order to get
> to the point where there's a good spec for all the web technology.
That's basically my point. Until then, I'll continue to use what works,
because it works. I think one thing that should go in the FAP about this
is exactly why the current solutions are suboptimal, other than "they're
a lot of work for the servers," because nobody knows how much work it's
going to be for the servers dealing with the future technology.
Things like "URLs like this can't be cached" is a good point, but then
you have to consider whether they *should* be cached.
> But catering to every existing implementation in the mean time will
> make this process take _even longer_.
When you're academic, that's not a problem. When you're trying to put
product out the door, that's a problem. I can sympathise, but I'm not
going to wait. :-)
> I like to draw the line at the point where an
> implementation goes against a spec that was available at the time of
> implementation. There are exceptions, of course, but that's the
> general rule, if you ask me.
That's a good general rule, but it doesn't fly when Netscape (for
example) or Microsoft's bundled Win95 browser breaks the rules.
> is incredibly expensive -- it's what's creating many of the
> existing support nightmares, if you ask me.
Actually, it's customer support creating the nightmares. If you're
willing to say "Go spend $150 to get a new browser if you want to
subscribe to our $25/year web journal" then you don't have many support
problems.
> So the HTML spec is littered with "notes" that are essentially
> documentation on the Mosaic parser. But the HTML language hasn't
> changed as a result. There's an up-hill battle ahead, but I actually
> expect HTML on the web to become conformant over the next year or
> so, because in the end, it's worth it for everybody involved.
And there are market pressures driving it the other way. Publishers want
better control over the display. I have to keep telling our tech writers
"and think how someone blind having this read to them would hear it"
whenever they ask if it's possible to set the exact point size or change
the color of text or stuff like that.
--Darren