Re: [whatwg] Timing API proposal for measuring intervals

[James Robinson]

The discussion of audio concerns seems to have died down.  I think anything
specific to audio will be additive to this API, and there are still several
non-audio use cases, so here's an updated proposal:

double window.performance.now();

The idea of putting it on window.performance is that this seems closely
related to the UserTiming spec currently under development by the Web Perf
working group (
http://w3c-test.org/webperf/specs/UserTiming/#the-usertiming-interface).
 When window.performance.now() is called, the browser returns a double
representing the number of milliseconds that have elapsed since the most
recent top-level navigation in that context.  That's the same time value
that is used by the navigation and user timing specs.  Defining this as a
function instead of an attribute makes it clearer that the returned value
can change on every access and is not fixed while script is running.  This
is important for the script profiling use case.  When a fixed time value is
needed, as for example in requestAnimationFrame, it should be provided by
that API.  By putting this on window.performance, we can pick a nice short
function name without having to worry so much about potential collisions
with existing content.

- James

Re: [whatwg] [editing] Additional miscellaneous commands

[Alfonso Martínez de Lizarrondo]

2011/8/16 Aryeh Gregor 

> 2011/8/16 Alfonso Martínez de Lizarrondo :
> > Hi
> >
> > The drafted specs defines most of the common features of contentEditable,
> > but there are other commands that have been left out
> >
> > enableInlineTableEditing
> > enableObjectResizing
> > AutoUrlDetect
> > RespectVisibilityInDesign
> > ...
>
> I have some of these noted in the "Comments" drop-down at the bottom here:
>
> http://aryeh.name/spec/editing/editing.html#issues
>

Ups, sorry, I thought that the Comments buttons would open a feedback form
but anyway I haven't read all the spec and I just used Ctrl+F to check for
some of those commands and I didn't find anything.


> I've looked at MSDN documentation and compiled a list of supported
> commands, but I seem to be missing some.  Do you know of a more
> comprehensive list?  Also, it would help a lot if you (or anyone else)
> could point out which specific commands sound especially useful.
>
>
As I said, there are a bunch of commands for IE, but many of them aren't
really related to editing (like SaveAs), few people knows how to use them,
or just don't work (some lists of commands refer to the MSHTML component
that seemed more focused on developing FrontPage).

>From the list that I've mentioned previously:
Inline table editing is available only in Mozilla, it's nice in order to add
or remove rows.

Autodetection of URLs is a feature of IE and since IE9 it's possible to
disable it. Many people expect that when they type an URL it gets converted
automatically into a link. Of course there are other people that don't want
it. I've written previously in other sites that the best way to handle it
would be to get an event with the new created link, that way the editor
could alter some properties (like setting a @rel or @target) if needed.

The Respect visibility features is aimed at being able to have something
with display:none and the user can edit it, if it's hidden then the editor
has to provide some other way so that the user can edit that content that
might be displayed later with javascript.

At the very least, providing a list of all the known commands of all the
browsers can help to use those little hidden secrets. And of course a big
warning on those that shouldn't be used anymore like it's done with the
useCss. In those cases it might be enough to provide a list of commands that
aren't really useful and so the implementors can move to try to remove them
as you suggested.


> IE used to had a bunch of poorly documented commands, but the important
> part
> > for me is that those extra commands might enable some behaviors that are
> too
> > hard to emulate by javascript, and if they can be added to the spec, then
> > hopefully they will be available in the future for all the users.
>
> I agree with this general point, but it's really best to have specific
> examples to work with.  It's almost surely not worth it to
> reverse-engineer all the IE commands here.  For instance,
> RespectVisibilityInDesign is something we can do without -- visibility
> should always be respected, so that what the user sees is what they
> get when they save.  If authors want to let users edit particular
> invisible things, they can make them visible using a stylesheet rule.
>

There are many things that are possible with javascript and stylesheets, but
I think that the goal was to make things simpler.
For example your algorithm is implemented in Javascript and AFAIK, both
CKEditor and TinyMCE don't use .execCommand to apply styling while editing,
they also use their own javascript routines. So applying the same statement
there's no need that the browsers change their implementation because it can
be done with javascript.


>
> > One basic example is resizing. Currently Webkit browsers doesn't allow
> the
> > user to resize a picture, table,.. that it's placed in the contents. Some
> > people might not want that behavior at all, others might prefer to enable
> it
> > only for tables but not images, and I think that instead of putting that
> > burden on the javascript editor, it should be the browser the one that
> takes
> > care of that with a basic command to turn it on/off and then firing the
> > needed events when something like a resize starts or ends like IE does.
>
> Might the CSS resize property be the best way to do this?
>
> http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resize
>
> Then authors could do img { resize: both } or similar.  This is much
> more flexible than a global on-off switch, because you could allow the
> user to resize some things but not others.  For instance, a forum that
> allows users to insert custom images and also smilies might want them
> to be able to resize the custom images but not the smilies, and it
> could do that with an appropriate CSS selector.  I'd have to update
> the spec to say that if the user resizes editable things, the browser
> needs to actually change the DOM to add height/width attributes or
> properties.
>
> I filed a bug on this:

Re: [whatwg] [editing] Additional miscellaneous commands

[Aryeh Gregor]

2011/8/16 Alfonso Martínez de Lizarrondo :
> Hi
>
> The drafted specs defines most of the common features of contentEditable,
> but there are other commands that have been left out
>
> enableInlineTableEditing
> enableObjectResizing
> AutoUrlDetect
> RespectVisibilityInDesign
> ...

I have some of these noted in the "Comments" drop-down at the bottom here:

http://aryeh.name/spec/editing/editing.html#issues

I've looked at MSDN documentation and compiled a list of supported
commands, but I seem to be missing some.  Do you know of a more
comprehensive list?  Also, it would help a lot if you (or anyone else)
could point out which specific commands sound especially useful.

> IE used to had a bunch of poorly documented commands, but the important part
> for me is that those extra commands might enable some behaviors that are too
> hard to emulate by javascript, and if they can be added to the spec, then
> hopefully they will be available in the future for all the users.

I agree with this general point, but it's really best to have specific
examples to work with.  It's almost surely not worth it to
reverse-engineer all the IE commands here.  For instance,
RespectVisibilityInDesign is something we can do without -- visibility
should always be respected, so that what the user sees is what they
get when they save.  If authors want to let users edit particular
invisible things, they can make them visible using a stylesheet rule.

> One basic example is resizing. Currently Webkit browsers doesn't allow the
> user to resize a picture, table,.. that it's placed in the contents. Some
> people might not want that behavior at all, others might prefer to enable it
> only for tables but not images, and I think that instead of putting that
> burden on the javascript editor, it should be the browser the one that takes
> care of that with a basic command to turn it on/off and then firing the
> needed events when something like a resize starts or ends like IE does.

Might the CSS resize property be the best way to do this?

http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resize

Then authors could do img { resize: both } or similar.  This is much
more flexible than a global on-off switch, because you could allow the
user to resize some things but not others.  For instance, a forum that
allows users to insert custom images and also smilies might want them
to be able to resize the custom images but not the smilies, and it
could do that with an appropriate CSS selector.  I'd have to update
the spec to say that if the user resizes editable things, the browser
needs to actually change the DOM to add height/width attributes or
properties.

I filed a bug on this:
.  Please feel
free to file bugs for any other specific features you'd like me to
look into.  Note that right now I'm mostly focused on fixing up and
stabilizing core functionality, so I might not get around to adding
new features for a while.

Re: [whatwg] Proposal for a MediaSource API that allows sending media data to a HTMLMediaElement

[Mark Watson]

On Aug 12, 2011, at 10:01 AM, Aaron Colwell wrote:

Hi Mark,

comments inline...

On Thu, Aug 11, 2011 at 9:46 AM, Mark Watson 
mailto:wats...@netflix.com>> wrote:
I think it would be good if the API recognized the fact that the media data may 
becoming from several different original files/streams (e.g. different 
bitrates) as the player adapts to network or other conditions.

I agree. I intend to document this when I spec out the format of the byte 
stream that is passed into this API. Initially I'm focusing on WebM which 
requires this type of functionality if the Vorbis initialization data ever 
needs to change during playback. My intuition says that Ogg & MP4 will require 
similar solutions.


The different files may have different initialization information (Info and 
Tracks in WebM, Movie Box in mp4 etc.), which could be provided either in the 
first append call for each stream or with a separate API call. But subsequently 
you need to know which initialization information is relevant for each appended 
block. An integer streamId in the append call would be sufficient - the 
absolute value has no meaning - it would just associate data from the same 
stream across calls.

Since I'm using WebM for the byte stream I don't need to add explicit streamIds 
to the API or data. StreamIDs are already in the byte stream. Ogg bitstream 
serial numbers, and MP4 track numbers should serve the same purpose.

I may have inadvertently overloaded "stream id". And I'm assuming that the 
different bitrates essentially come from different media files. If you use the 
track id in mp4 (or it's equivalent in WebM) then you require that there is a 
level of coordination in the creation of the different bitrate files: they must 
all use distinct track ids. To add a new bitrate you need you need to know what 
track ids were used in the old ones and pick a distinct one. When people get it 
wrong you have a difficult-to-detect failure mode.



The alternatives are:
(a) to require that all streams have the same or compatible initialization 
information or
(b) to pass the initialization information every time you change streams

(a) has the disadvantage of constraining encoding, and making adding new 
streams more dependent on the details of how the existing streams were 
encoded/packaged
(b) is ok, except that it is nice for the player to know "this data is from the 
same stream you were playing a while ago" - it can re-use some previously 
established state - rather than every stream change being 'out of the blue'.

I'm leaning toward (b) right now. Any time a change in stream parameters is 
needed new INFO & TRACKS elements will be appended before the media data from 
the new source. This is similar to how Ogg chaining works. I don't think we 
need unique IDs for marking this state. The media engine can look at the new 
codec config data and see if it matches anything it has seen before. If so then 
it can simply reuse whatever resources it see fit. Another thing to note is 
that just because we append this data every time a stream switch occurs, it 
doesn't mean we have to transfer that data across the network each time. 
JavaScript can cache this data and simply append it when necessary.

That's fine for me. It needs to be clear in the API that this is the expected 
mode of operation. We can word this in a way that is independent of media 
format.



A separate comment is that practically we have found it very useful for the 
media player to know the maximum resolution, frame rate and codec level/profile 
that will be used, which may be different from the resolution and 
codec/level/profile of the first stream.


I agree that this info is useful, but it isn't clear to me that this API needs 
to support that. Existing APIs like 
canPlayType() 
could be used to determine whether specific codec parameters are supported. 
Other DOM APIs could be used to determine max screen size. This could all be 
used to prune the candidate streams sent to the MediaSource API.

True, but I wasn't thinking so much of determining whether playback is 
supported, but of warning the media pipeline of what might be coming so that it 
can dimension various resources appropriately.

This may just be a matter of feeding the header for the highest 
resolution/profile stream first, even if you don't feed any media data for that 
stream. It's possible some players will not support switching resolution to a 
resolution higher than that established at the start of playback (at least we 
have found that to be the case with some embedded media pipelines today).

...Mark



Aaron

[whatwg] [editing] Additional miscellaneous commands

[Alfonso Martínez de Lizarrondo]

Hi

The drafted specs defines most of the common features of contentEditable,
but there are other commands that have been left out

enableInlineTableEditing
enableObjectResizing
AutoUrlDetect
RespectVisibilityInDesign
...

IE used to had a bunch of poorly documented commands, but the important part
for me is that those extra commands might enable some behaviors that are too
hard to emulate by javascript, and if they can be added to the spec, then
hopefully they will be available in the future for all the users.

One basic example is resizing. Currently Webkit browsers doesn't allow the
user to resize a picture, table,.. that it's placed in the contents. Some
people might not want that behavior at all, others might prefer to enable it
only for tables but not images, and I think that instead of putting that
burden on the javascript editor, it should be the browser the one that takes
care of that with a basic command to turn it on/off and then firing the
needed events when something like a resize starts or ends like IE does.

Regards