Re: minutes of 2010-09-08 teleconference

On Fri, Sep 10, 2010 at 5:29 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:

>
> On 9 sep 2010, at 15:27, Silvia Pfeiffer wrote:
>
> > Can Ian provide a pointer to a paragraph in any of the HTML spec
> (including the HTML5 current draft) where it is written that a browser MUST
> jump to the section identified by a (resolvable) frag id for an HTML
> document? This is the standard behavior in all browsers, right? However, I
> cannot find where it has ever been written ... Why would this be different
> for media resources?
> >
> > It's here:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid
> > It had to be included because the specification of what to do with
> fragment identifiers in URLs to text/html resources should have been in
> http://www.ietf.org/rfc/rfc2854.txt, but isn't.
>
> Silvia,
> that last sentence again seems to indicate that the html-folks assume that
> specifying the behaviour of fragments in an HTML context is the
> responsibility of whoever defines the URL format. This strikes me as
> counter-intuitive, as I've already explained in response to the mail about
> MF-semantics.
>
> As you're probably our closest link to the HTML group: could you explain
> the rationale behind this?


I can only point to Ian's email. The idea is that a specification is not
complete until the presentation behavious is also specified, since you can
only call something a "standard" when applications (read: browsers) behave
the same for the same feature.

I would be more than happy to follow up on that thread if we agree that we
don't want to integrate it into our spec. I would suggest though that we put
a recommendation into our spec, in particular for the browser use cases -
then get back to the HTML or WHATWG group and continue the discussion. I am
not sure how much their opinion can be changed and possibly a sentence be
added to that "scroll-to-fragid" section. We could, if we really wanted,
propose some spec text for them to add into that section if that is what we
prefer.

So, probably the best course of action is: a more detailed recommendation in
our spec and a proposed spec text to add to the HTML5 spec. Then a
discussion.

Cheers,
Silvia.