W3C home > Mailing lists > Public > public-media-fragment@w3.org > September 2010

Re: minutes of 2010-09-08 teleconference

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 10 Sep 2010 21:01:12 +1000
Message-ID: <AANLkTikjQp+_XWd0ZTT7E3XgP+YEj8W3bbr1amp_7nMA@mail.gmail.com>
To: Jack Jansen <Jack.Jansen@cwi.nl>
Cc: RaphaŽl Troncy <raphael.troncy@eurecom.fr>, Erik Mannens <erik.mannens@ugent.be>, public-media-fragment@w3.org
On Fri, Sep 10, 2010 at 6:49 PM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:

> On 10 sep 2010, at 00:33, Silvia Pfeiffer wrote:
> > 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.
> Let's do that. At least the first (more detailed recommendations) and
> whether we want to go all the way of suggesting text to the HTML5 group:
> let's see if anyone has the energy for that:-)
It may actually be a good thing to propose spec text for the HTML spec,
because it will then make it a necessity for the browser vendors to
implement support and they understand what is actually asked of them.

I'd be happy to have that discussion!

Received on Friday, 10 September 2010 11:02:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:45 UTC