On Thu, 13 Jan 2011 01:03:03 +0100, Aryeh Gregor
wrote:
On Wed, Jan 12, 2011 at 3:42 AM, Philip Jägenstedt
wrote:
* add HTMLMediaElement.seek(t, [exact]), where exact defaults to false
if
missing
Boolean parameters are evil, since it's impossible to guess what they
do from reading the
On Thu, 13 Jan 2011 01:23:57 +0100, Eric Carlson
wrote:
On Jan 12, 2011, at 4:04 PM, Robert O'Callahan wrote:
On Wed, Jan 12, 2011 at 9:42 PM, Philip Jägenstedt
wrote:
For the record, this is the solution I've been imagining:
* add HTMLMediaElement.seek(t, [exact]), where exact defaul
Does the "same underlying data" of a structured clone of a File refer
to a reference to the file (eg. the path and filename, which is the
real underlying data of a File object), or the contents of the file?
As it's used by web worker messaging, it's obviously the pathname.
However, HTML Storage (i
On Jan 12, 2011, at 4:04 PM, Robert O'Callahan wrote:
> On Wed, Jan 12, 2011 at 9:42 PM, Philip Jägenstedt wrote:
>
>> For the record, this is the solution I've been imagining:
>>
>> * add HTMLMediaElement.seek(t, [exact]), where exact defaults to false if
>> missing
>>
>> * make setting HTMLM
On Wed, Jan 12, 2011 at 2:35 PM, Marijn Haverbeke wrote:
> So I propose a selectionAnchor property, which holds either "top" or
> "bottom", and can be set to one of these strings to modify the
> direction. "top" would mean the anchor lies after the base of the
> selection, so further shift-movemen
On Wed, Jan 12, 2011 at 9:42 PM, Philip Jägenstedt wrote:
> For the record, this is the solution I've been imagining:
>
> * add HTMLMediaElement.seek(t, [exact]), where exact defaults to false if
> missing
>
> * make setting HTMLMediaElement.currentTime be a non-exact seek, as that
> seems to be t
On Wed, Jan 12, 2011 at 3:42 AM, Philip Jägenstedt wrote:
> * add HTMLMediaElement.seek(t, [exact]), where exact defaults to false if
> missing
Boolean parameters are evil, since it's impossible to guess what they
do from reading the code. Make it a two-value enum instead. The
second argument c
I completely agree, and have been lobbying for similar functionality
for the main document selection object, resulting in the current
ongoing discussion in this bug:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10624.
Rather than a single string property, how about integer
selectionAnchor and sel
I agree that something like this is a valuable addition. I'm not sure
selectionAnchor is ideal. I was thinking
selectionDirection="forward"/"backward". It's equivalent really, but that
just seems more intuitive to me.
On Wed, Jan 12, 2011 at 11:35 AM, Marijn Haverbeke wrote:
> Hi,
>
> I'd like to
Hi,
I'd like to propose a minor addition to 4.10.20 APIs for the text
field selections. When programmatically setting the selection of a
text input, it is currently impossible to create a range with the
'anchor' at the bottom and the 'base' at the top. Concretely, this
means that, after a selectio
I implemented frame-accurate seeking in Chrome (mostly as an experiment) and
it does have the drawback of potentially being very slow. Depending on the
type of video there can be a noticeable difference in seek time if you seek
to just-before-a-keyframe versus just-after-a-keyframe.
I do like the
On Jan 12, 2011, at 12:42 AM, Philip Jägenstedt wrote:
> On Wed, 12 Jan 2011 09:16:59 +0100, Glenn Maynard wrote:
>
>> On Wed, Jan 12, 2011 at 2:49 AM, Philip Jägenstedt wrote:
>>> (Also, it might be useful to be able to chose whether seeking should be fast
>>> or exact, as frame-accurate seek
On Jan 12, 2011, at 2:05 PM, Rob Coenen wrote:
> The need for SMPTE still remains as I want to be able to do things such as
> video.seekTo(smpte_timecode_converted_to_seconds, seek_exact=true); so that
> my video goes to exactly the exact frame as indicated by
> smpte_timecode_converted_to_sec
On Wed, Jan 12, 2011 at 10:15 AM, Jeroen Wijering
wrote:
>
> Alternatively, one could look at a step() function instead of a
> seek(pos,exact) function. The step function can be used for frame-accurate
> controls. e.g. step(2) or step(-1). The advantage over a seek(pos,exact)
> function (and the p
On Jan 12, 2011, at 11:04 AM, whatwg-requ...@lists.whatwg.org wrote:
> Date: Wed, 12 Jan 2011 11:54:47 +0200
> From: Mikko Rantalainen
> To: whatwg@lists.whatwg.org
> Subject: Re: [whatwg] HTML5 video: frame accuracy / SMPTE
> Message-ID: <4d2d7a67.7090...@peda.net>
> Content-Type: text/plain; c
2011-01-08 00:06 EEST: Ian Hickson:
> The basic idea behind this design is that type=radio seems to have been
> designed to keep each control as independent as possible -- before we
> started fiddling with it in WF2, the only way type=radio controls had any
> relationship to other type=radio con
2011-01-12 00:40 EEST: Rob Coenen:
> Hi David- that is b/c in an ideal world I'd want to seek to a time expressed
> as a SMPTE timecode (think web apps that let users step x frames back, seek
> y frames forward etc.). In order to convert SMPTE to the floating point
> value for video.seekTime I need
On Wed, 12 Jan 2011 09:16:59 +0100, Glenn Maynard wrote:
On Wed, Jan 12, 2011 at 2:49 AM, Philip Jägenstedt
wrote:
(Also, it might be useful to be able to chose whether seeking should be
fast
or exact, as frame-accurate seeking is hardly necessary in most normal
playback situations.)
In
On Wed, Jan 12, 2011 at 2:49 AM, Philip Jägenstedt wrote:
> (Also, it might be useful to be able to chose whether seeking should be fast
> or exact, as frame-accurate seeking is hardly necessary in most normal
> playback situations.)
In an audio engine I worked on I had a seek hint like that, to
19 matches
Mail list logo
