Re: [whatwg] Feature Request: Media Elements as Targets for Links

Glenn Maynard <glenn@zewt.org> schrieb am Wed, 19 Dec 2012 08:09:59
-0600:

> On Wed, Dec 19, 2012 at 4:19 AM, Philip Jägenstedt
> <philipj@opera.com>wrote:
> 
> > What should a browser do with a URL ending with #foo&t=10 if there
> > is an element on the page with id="foo&t=10"? What about #foo&bar
> > if there is an element with id="foo"? I would be surprised if
> > treating #foo& the same as #foo were Web compatible...
> >
> 
> What if the page already uses this format for the hash, and is using
> the key "t" for something else?  I shouldn't need to worry that my
> hash keys are suddenly going to gain second meanings.

Do you have examples for this? I am not aware of any specification
except Media Fragments that uses the key “t”. I reason that if there is
no such specification, then that key has no other meaning defined for
HTML and URLs.

> What if the page uses a different format for the hash?  I use
> "#foo/bar?a=b&c=d" (giving me a path segment within the hash, which is
> extremely useful).

The hash is still there. You can still use it for whatever you like,
though I suggest you don't – please use history.pushState().
<https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history>

As I see it, the proposed feature could pose a problem for existing web
content if all of the following were true:

a) author uses a hash of the format “#foo/bar?a=b&c=d”
b) author has an element on the page with the id “foo/bar?a=b”
c) author does not “mean” the fragment to refer to the element
d) that element is a media element
e) “c=d” (or whatever comes then) is a valid media fragment

(With the exception of case c, this can be checked programmatically.)

Those who are overloading the meaning of fragments to refer to their
private namespaces right now already have to deal with the problem
when it occurs (a, b, c). The problem space associated with the proposed
feature (a, b, c, d, e) is a strict subset of an already existing
problem space (a, b, c) when authors invent private semantics.

I think a collision like that is very unlikely. Do you have evidence of
content that could break?

> What if the video element doesn't exist on page load, because it's
> created by dynamically by a script?

We already have the problem of imperative programming where declarative
solutions would suffice. AFAIK, if an element does not exist on page
load, it is not possible to refer to it in a URL.

Can you explain how the proposed feature would make things worse?

>  You can't simply apply the time
> to every video, since the page might be going through a playlist and
> you surely don't want "t=30" to cause every song or video in the
> playlist to start at 30s.

This is why my feature proposal includes the element id – so one can
refer to a specific element. Have you experimented with the polyfill
and found breakage in playlists?

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

Received on Wednesday, 19 December 2012 16:06:21 UTC