Re: Temporal Functions in HTML5?

Could you actually describe the exact use case that you're trying to
implement? It"s somewhat difficult to understand what you are trying
to achieve when you are just describing technology rather than what
the app would do.

More comments inline.

On Fri, May 25, 2012 at 11:36 PM, GAUSMAN, PAUL <pg2483@att.com> wrote:
>
> -----Original Message-----
> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
> Sent: Thursday, May 24, 2012 11:26 PM
> To: GAUSMAN, PAUL
> Cc: public-web-and-tv@w3.org
> Subject: Re: Temporal Functions in HTML5?
>
> On Fri, May 25, 2012 at 3:25 AM, GAUSMAN, PAUL <pg2483@att.com> wrote:
>>
>> *       Independent clock functions (e.g. a clock instance just for an app or HTML5 based experience, with start/stop/reset/set capabilities,) timing parameters within tags, time driven push functions, bidirectional event timing functions (logging time between inbound and outbound events,)
>
> There is also setTimeout and setInterval for timing events and the
> execution of functions. There is no feature that I know of that times
> the tags - and I don't quite understand the use case for it.
>
> +++I was thinking that a web app could use this as one indicator of user intent or the like, e.g. quick responses may mean focus, slow may mean casual use and prolonged responses (minutes, hours, days) could mean low interest. This could enable an app to change "gears" to make an experience more meaningful to the user.

This is not a matter of having clocks, but of measuring user
interaction. It's not difficult to capture the frequency of
interaction in JavaScript and do your "gear change" in that way.


>
>> *       Etc.,
>> *       Anything that addressing timing in a multi-device, multi-app, multi-user experience framework.
>
> These are all forms of distributed applications for which
> synchronization is indeed hard. You will likely need protocols to
> solve such synchornization issues - markup alone will not help.
>
> +++Good thought. I believe that there should also be tags, parameters and core functionality to enable temporal aspects of any appropriate functionality.

The Web has a perfectly good programming language for dynamic stuff:
JavaScript. You will find that almost everything that you're trying to
do can already be achieved with JavaScript and HTML. A concrete
example app would be better to discuss than generically pointing out
the need for multi-device handling - we should drill down to exactly
what extensions would be required. Do you have a concrete example that
you think is not possible to implement with existing technology?


>> Supporting functions might include inter-object/inter-event/inter-device messaging and WebRTC interactive functions.
>
> The WebRTC spec allows to exchange data as well as media streams
> directly between peer browsers. You might want to check out the
> PeerData API, see
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#peer-to-peer-data-api
> .
>
> +++I haven't read this yet but I'll comment that inter-browser/inter-app/inter-window/inter-object/inter-whatever capabilities are certainly part of this. While it's important to be able send triggers and other data between any entities, the intent of my comments are not only to make entities interact, but to seamlessly converge multiples of any/all entities into a natural (or unnatural if desired) user experience in real-time and real-space.

That's indeed what the Web is good at. You can develop such
applications using all of HTML, CSS, JavaScript, HTTP and the modern
HTML5 APIS. JavaScript gives you the possibilities to integrate it all
seamlessly.


>> Existing functionality which could use this includes Closed Captioning and playlist execution but these are just the tip of the tip of the iceberg compared to the potential emerging applications, like multi-device, multi-user, multi-location user experiences, VR, AR, etc.
>
> Closed captions are a solved issue in HTML5. We have the <track>
> element for it with @kind=captions, see
> http://www.w3.org/TR/html5/the-track-element.html#the-track-element .
>
> +++Maybe other "@kind" values could be: clock, timecode, cue, playlist, HTML, etc. (Please excuse me if any of these already exist.)

The clock and timecode are provided by the media element - what other
clock are you thinking about?

Cues are provided by the track API with contains the TextTrackCue object.

Time-synchronized HTML tracks can already be provided through @kind=metadata.

Playlists don't fit the track paradigm, but are a superset of video
elements. They are indeed something we've been considering at one
stage. However, in reality a playlist is a set of URLs to videos and
it is fairly easy to implement in JavaScript the load of a new video
URL open ending a previous video's playback. So, we are waiting for
the market to experiment with playlists and come up with reasons why
we need a native implementation in HTML.

HTH.

Cheers,
Silvia.

Received on Saturday, 26 May 2012 03:34:52 UTC