W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2013

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 10 Sep 2013 21:28:32 +0000 (UTC)
To: Jonas Sicking <jonas@sicking.cc>
Message-ID: <alpine.DEB.2.00.1309102122410.12199@ps20323.dreamhostps.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Adam Barth <w3c@adambarth.com>
On Fri, 12 Jul 2013, Jonas Sicking wrote:
> 
> 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.

Yeah. This is further complicated by the way all the implementations are 
implemented in ways that differ from each other, so that there's no way to 
write a single description that would be easy to understand for all 
vendors. I do sometimes actually try to follow one or the other browser's 
implementation, if I understand it well enough and it's clear enough.


> 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.

I agree. Unfortunately, it's really hard (for me) to describe behaviours 
like navigation in a declarative way while still covering all the edge 
cases.

I'd be very happy to consider alternatives ways to describe the behaviours 
in the spec that are currently algorithmic in declarative ways, if anyone 
has any suggestions for how to do this. I do actually do it where possible.


> 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.

Yup.


> 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.

Yup.


> 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.

What's making the spec hard to read is the same thing that makes the 
implementations hard to read. The topic in question is complicated.

At the end of the day, there's a limit to how simply one can describe 
something that is fundamentally complicated.

But as I said above, I'm very open to any suggestions.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 10 September 2013 21:29:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:09 UTC