Re: [whatwg] frame accuracy breaking case for 25fps / status of 29.97fps

[Silvia Pfeiffer]

On Mon, Jul 9, 2012 at 8:17 PM, Odin Hørthe Omdal  wrote:
> On Mon, 09 Jul 2012 18:46:20 +0200, adam k  wrote:
>
>> i have a 25fps video, h264, with a burned in timecode.  it seems to be off
>> by 1 frame when i compare the burned in timecode to the calculated timecode.
>> i'm using rob coenen's test app at
>> http://www.massive-interactive.nl/html5_video/smpte_test_universal.html to
>> load my own video.
>>
>> what's the process here to report issues?  please let me know whatever
>> formal or informal steps are required and i'll gladly follow them.
>
>
> Well, it works beautifully in that web site you reference. What do you think
> is wrong actually? I'm not so sure if the spec is the first and best way to
> go to find the error(?)

Indeed: which browser are you actually using to see the 1 frame offset?

Cheers,
Silvia.

[whatwg] Key handlers Re: seamless iframes and event propagation

[Chaals McCathieNevile]

On Thu, 12 Jul 2012 01:23:07 +0200, Ojan Vafai  wrote:

On Wed, Jul 11, 2012 at 3:38 AM, Chaals McCathieNevile  
wrote:


On Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai   
wrote:



Use-case 1: A global key event handler for keyboard shortcuts. Without
propagating the events, you need to add a key handler to each seamless
iframe's root in order for these keyboard handlers to work when the
iframe has focus.


Using javascript for keyboard shortcuts is not a good idea in the first
place. People will keep doing it instead of something more scalable to  
the web like improving their accesskey implementations, but we should

not be encouraging it, by making it easier to do the wrong thing
instead of something useful.



In practice, this is a very common thing to do. Making seamless iframes  
not work for this thing people are already doing seems backwards to me.

We should address the problems with why doing this in JS is problematic
directly.


I'm not suggesting that we make it not work. Just that we don't make it a  
whole lot easier. Because it is (IMHO, obviously) harmful to the web and  
its ability to evolve.


One way to address it directly is to put our efforts into making better  
alternatives easier, rather than putting them into implementing things  
which reinforce the idea that the anti-pattern is the easiest way to  
achieve a goal.



(The problem is that javascript key handlers generally do not
internationalise well, are awful across a wide range of devices, and are
almost guaranteed to fail future devices).


How does accesskey improve on this?


Very roughly, because it is a passive declaration of intent that can be  
easily rewritten by the user agent in case of conflict. Javascript  
keyhandlers are an active intervention in what is often part of the user's  
expected interaction behaviour (specifically, in the case where they use  
the keyboard for some functionality). Thus it leads to surprises when a  
key does something unexpected.


[...]
cheers

Chaals


On Sat, May 26, 2012 at 5:16 PM, Adam Barth  wrote:

I've added a proposal to the wiki
>
about letting a document
indicate that it is willing to be displayed seamlessly with a
cross-origin parent.  This proposal is a refinement of the approach
previously discussed in this thread:



--
Chaals - standards declaimer