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

Re: media fragment URI use on web pages

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 5 Nov 2010 23:21:30 +1100
Message-ID: <AANLkTimMYYS98VF8zPsfNwy9PDKV0kAuqpjCrUp9Td0r@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: public-media-fragment@w3.org
On Fri, Nov 5, 2010 at 8:06 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Thu, 04 Nov 2010 23:01:42 +0100, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Thu, Nov 4, 2010 at 9:21 PM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>> On Thu, 28 Oct 2010 02:13:07 +0200, Silvia Pfeiffer
>>> <silviapfeiffer1@gmail.com> wrote:
>>>> Hi guys,
>>>> I've been wondering about how we can use media fragment URIs on Web
>>>> page URLs such that the fragment is handed through to the correct
>>>> media element. Existing schemes - such as YouTube's scheme of e.g.
>>>> http://www.youtube.com/watch?v=ZhMoxXilwro#t=186 only work with a
>>>> single video on a page.
>>>> It might be an idea to suggest something like:
>>>> http://example.com/page.html#video[0]&t=10,20
>>>> Then it's possible to provide a URL with media fragments for multiple
>>>> videos on a page:
>>>> http://example.com/page.html#video[0]&t=10,20&video[1]&t=30,40 etc.
>>>> or for all videos on the page:
>>>> http://example.com/page.html#videos&t=10,20
>>>> It would be nice if something like this (or nicer - improved
>>>> suggestions welcome) becomes a scheme that everyone uses and that
>>>> therefore the browsers can support.
>>>> It's a scheme on a Web page (.html) rather than on a media resource
>>>> (.ogv / .webm / .mp4) and as such not really something that this group
>>>> was chartered for. But I believe we could add a note that recommends
>>>> such use and would be a Web author recommendation, and that the HTML
>>>> WG could eventually pick up as a browser recommendation.
>>> While this would be very useful, it's not something that can be
>>> standardized
>>> in browsers. The URL page.html#t=1 already causes browsers to scroll to
>>> the
>>> element with id="t=1". Overloading this behavior would most likely break
>>> some pages. See
>>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid>
>>> This is quite unfortunate, as far as I can see the best we can hope for
>>> is
>>> page.html?t=1 with per-site server-side solutions or page.html#t=1 with
>>> per-site JavaScript solutions (those sites would have to make sure to not
>>> have id="t=1" on their pages, and live with not being able to use the
>>> fragment for its usual purpose). Perhaps there's room for standardization
>>> here, as long as it's clear that User Agents aren't involved.
>> You misunderstand. I didn't want to suggest it for browsers, but for
>> site developers. Over time, as people change their Websites to use
>> such structured fragment URIs, we may be able to bring it into the
>> browser, but I don't expect it to be before another 5-10 years. Some
>> sites already use this kind of markup (see YouTube for example). It
>> would be nice to recommend a common naming scheme for all sites. They
>> don't have to follow, but more is done today by convention than by
>> standardisation.
>> Seems we missed that discussion at the F2F. :-)
> OK, I'm glad that this isn't intended for browsers, then. I should stress
> that even in 5-10 years we can't really put this in browsers, it would cause
> the same breakage then as it would today.

Unless everyone has moved to the new meaning of media fragments on
HTML. But indeed, I am not worried about that.

Received on Friday, 5 November 2010 12:22:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:47 UTC