Re: [whatwg] scrdoc and session history don't play along in the spec

On Fri, Jul 12, 2013 at 1:09 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 7/12/13 3:39 PM, Ian Hickson wrote:
>> That wasn't the intent. I've tried to clarify it.
>
> Hmm.  It might help to make it clearer in
> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate
> that "new resource" does not mean "URL".  Maybe have some explicit thing
> that represents the resource being navigated to (which might, for example,
> consist of a (url, srcdoc data) pair or something along those lines)?
>
>
>> You know, it's disheartening to work on something and have you continually
>> insult it like this. Please stick to positive feedback, which you are
>> quite good at providing, and avoid the non-constructive negative
>> commentary.
>
>
> I'm sorry, this certainly wasn't meant to be an insult!  I understand the
> problems involved in trying to specify this, starting with the fact that the
> code that does navigation in browsers is more or less uniformly insane.
>
> That said, I've had feedback from multiple engineers who were trying to
> understand this section of the spec because they wanted to change something
> in Gecko and just gave up because they couldn't figure out where to even
> start start reading it and any time they thought they understood it they
> discovered more "come from" type things that meant their understanding was
> incorrect.
>
> One fundamental problem is that a typical engineer working on something like
> about:srcdoc doesn't read the entire navigation part spec from the top down.
> And if they try to, they get lost partway through.  Engineers consistently
> end up with bugs in their implementations when they try to follow this part
> of the spec.  It doesn't help that navigation as actually implemented in at
> least Gecko looks nothing like the setup in the spec (e.g. the fact that
> history traversal in the spec reenters itself has no analogue in Gecko), and
> mapping between two different navigation models is ... very hard.
>
> I realize this is still non-constructive.  Believe me, if I had constructive
> suggestions for how to make this part of the spec more understandable I
> would be bringing them up!  I keep trying to figure out a better way to
> organize this stuff and failing.  Maybe it's just a lost cause because of
> all the complexity.  :(

The algorithms in the spec are great when it comes to defining things
with high level of exactness. However they only work well when the
implementations of those algorithms actually look like the algorithms
in the spec.

When they don't, the implementor has to read in all relevant
algorithms defined in the spec. Then map those algorithms into the
semantics and behavior they actually result in for the feature that
the implementor is working on implementing. Then map those semantics
and behaviors into an implementation that fits with existing code.

Generally speaking, it would be easier if the spec defined the
semantics and the behaviors instead. Thereby avoiding having to do the
initial algorithms->behavior mapping.

Another fix would of course be to rewrite implementations to match the
algorithms and concepts in the spec more precisely. Though that's a
very risky undertaking for something like navigation since the spec
probably isn't getting all edge cases right. Additionally the spec
doesn't deal with all the situations that at least Gecko has to deal
with (desktop shortcuts being clicked. Bookmarklets being clicked.
Commandlines being executed. Addons. Etc) which means that it might
not be possible to get the two to align very well.

That said, I totally understand that it's very hard to define behavior
to the level of exactness that's currently there, without writing the
spec the way it's currently written. But I believe that this is what's
making the spec hard to read.

/ Jonas

Received on Saturday, 13 July 2013 02:50:49 UTC