I suppose what I’m hoping for (perhaps unrealistically) is an opinionated norm that establishes a convention.
The standard refers to…
from the query or fragment component of a URI
…but the average web user just wants to know “that thing I learned I can do on YouTube I can also do on Facebook, and the BBC”, etc.
It doesn’t serve the average user to have to know the specific way each publisher does things, which publishers are often not very good at communicating anyway.
AFAICT, the Media Fragments URI spec applies to URLs pointing directly to media file itself, not to a webpage that contains an embedded media player for the media file where hash notation could conflict with identifiers of HTML elements on the page. Webpage case is left up to web developer.
Sorry for my brevity earlier. It is indeed only for media itself. It is however existing work .Last time I checked some of the video providers supported the same syntax of #t=1m20s
Also interesting prior work: The Web Share API receiving target which is defined as an API which could perhaps could be expanded for other meta data such as time perhaps.
@MT highlights some issues with embedding media which can’t easily be resolved with URLs:
IDs will collide with on page anchor behaviour
Query params impact with JS and serverside interactions
Paths impact with server and JS also
Pages could have multiple embedded videos so the deep linking would require a way of specifying a primary media element
The other problem is as I see it would there would need to be some added benefit as to why developers would use this new standard way of linking. What would they get from being unifom?
Could the browser make them sharable as part of Web Share?
Could users bookmark with increased context
Could browsers start behaving smarter with this extra context data?
Can browsers help the page developers too?
Once the primary element is set could the browser increment the seeking #playt=?
Thank you both for your input, and for thinking about the implications that I haven’t.
As more and more content becomes embedded within audio and video, and frequently without a transcript, I feel it would be in our collective interests to agree a convention that gathers momentum, but perhaps that isn’t a ‘standard’ per se…
Perhaps the answer lies in UI design such as Marco Arment’s wonderfully simple Share at current time option within his Overcast app, with the URL mechanics up to him and made irrelevant to the user.
Aside: Wasn’t there a specfic SMPTE standard about timecoding on broadcast media? (Granted that on web media you’d possibly be only able to timecode down to the key-frame level, not inter-frame interpolations.).