Re: [whatwg] Media elements statistics
I've also just added a section with the stats that the Adobe Flash player exposes. Apart from the statistics that are not currently available from the HTML5 player, there are stats that are already available, such as currentSrc, currentTime, and all the events which can be turned into hooks for measurement. I think the page now has a lot of analysis of currently used stats - probably a sufficient amount. All the video publishing sites likely just use a subpart of the ones that Adobe Flash exposes in their analytics. Cheers, Silvia. On Thu, Apr 7, 2011 at 4:52 AM, Mark Watson wats...@netflix.com wrote: All, I added some material to the wiki page based on our experience here at Netflix and based on the metrics defined in MPEG DASH for adaptive streaming. I'd love to here what people think. Statistics about presentation/rendering seem to be covered, but what should also be considered are network performance statistics, which become increasingly difficult to collect from the server when sessions are making use of multiple servers, possibly across multiple CDNs. Another aspect important for performance management is error reporting. Some thoughts on that on the page. ...Mark On Mar 31, 2011, at 7:07 PM, Robert O'Callahan wrote: On Fri, Apr 1, 2011 at 1:33 PM, Chris Pearce ch...@pearce.org.nz wrote: On 1/04/2011 12:22 p.m., Steve Lacey wrote: Chris - in the mozilla stats, I agree on the need for a frame count of frames that actually make it the the screen, but am interested in why we need both presented and painted? Wouldn't just a simple 'presented' (i.e. presented to the user) suffice? We distinguish between painted and presented so we have a measure of the latency in our rendering pipeline. It's more for our benefit as browser developers than for web developers. Yeah, just to be clear, we don't necessarily think that everything in our stats API should be standardized. We should wait and see what authors actually use. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Can we make checkboxes readonly?
What are the use cases for readonly oninput type=text? The primary one I've seen is to have a non-editable text input that the user can still select-and-copy from. Well... span could be enough for this use case ;-) Alexandre Morgaut Product Manager 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email :alexandre.morg...@4d.com Web : www.4D.com
Re: [whatwg] Can we make checkboxes readonly?
On Thu, Apr 7, 2011 at 3:25 AM, Alexandre Morgaut alexandre.morg...@4d.com wrote: What are the use cases for readonly oninput type=text? The primary one I've seen is to have a non-editable text input that the user can still select-and-copy from. Well... span could be enough for this use case ;-) Well... you wont get effect of cursor movement, which are something wanted by our end user.
Re: [whatwg] Can we make checkboxes readonly?
Den 2011-04-06 22:45:36 skrev Tab Atkins Jr. jackalm...@gmail.com: Currently, the spec disallows checkboxes from being made readonly. Is there some good reason for this? If not, can we change it? Checkboxes being readonly would be useful for the same reasons that text inputs being readonly is. Radio buttons can't be readonly either, but they have the obvious complication of being multiple elements. We could define behavior for them, of course. One option is to take the @required route, and say that if one radio button in a group is readonly, they all are. We could alternately say that a radio button being readonly means that that specific input can't have its checkedness changed - if it's currently unchecked, clicking on it won't check it; if it's currently checked, clicking on a mutable radio button from the same group wouldn't change the checkedness of either input. ~TJ These are very good points, which many web developers that has been handling forms probably have torn their hairs about for a long time. Time to do something about it ;) Thank you for bringing it up :) -- Jesper Gustin QA, Linux Devices SDK Opera Software
Re: [whatwg] Can we make checkboxes readonly?
Simple use case with existing car configurators: When a car feature / accessory is selected that requires another feat. / access., I don't want customers to uncheck that feature, but still need the submission of the required features. Or the Mootools library builder: Depending modules need to be selected and submitted in order to generate the correct javascript file. Yes, you can re-add that logic server-side, but why would you want to add that kind of logic twice. My 2 cents Randy -Original Message- From: Lachlan Hunt lachlan.h...@lachy.id.au Sender: whatwg-bounces@lists.whatwg.orgDate: Thu, 07 Apr 2011 00:39:04 To: Tab Atkins Jr.jackalm...@gmail.com Cc: WHATWG Listwha...@whatwg.org Subject: Re: [whatwg] Can we make checkboxes readonly? On 2011-04-07 00:28, Tab Atkins Jr. wrote: On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Huntlachlan.h...@lachy.id.au wrote: What's wrong with using disabled? input type=checkbox disabled input type=checkbox disabled checked Disabled elements don't participate in form submission. That's true, but if the controls are readonly, then the user can't change the value and so why does that matter? Could you clarify the use case for having a readonly checkbox value submitted? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Can we make checkboxes readonly?
On 6 April 2011 23:39, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2011-04-07 00:28, Tab Atkins Jr. wrote: On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Huntlachlan.h...@lachy.id.au wrote: What's wrong with using disabled? input type=checkbox disabled input type=checkbox disabled checked Disabled elements don't participate in form submission. That's true, but if the controls are readonly, then the user can't change the value and so why does that matter? Could you clarify the use case for having a readonly checkbox value submitted? A lot of my work involves tables of data which can be navigated via a highlighted cell much like a spreadsheet. Where some cells may be readonly within the table itself, but perhaps editable through a popup value picker opened by double clicking on the cell for example. In this case the text input or checkbox would need to be readonly but still provide a value through the form on submission. This may not sound appropriate for a checkbox because there are only two options, but consider if you had a Y/N field but if the Y option is chosen you wanted to record some other data in a hidden field because you didn't want it to appear in the table. For example you might have a field indicating whether a client wishes to be contacted via telephone, you might then have a popup value picker appear when clicking on the checkbox with 3 options 'No', 'Yes, contact anytime' or 'Yes, only during office hours'. The popup would cause the checkbox to be cleared if the first option is selected, and checked for the other two and a hidden field may be used to store the contact time preference. I would like to add that it would also be advantageous if checkboxes could be made readonly and in doing so follow readonly text inputs with regards to responding to and firing events like focus, blur, click etc. This has been a source of much frustration when trying to implement a spreadsheet-like table where onfocus, onblur and onclick events are used to highlight or unhighlight a cell, because disabled checkboxes do not respond to nor fire these events. Some consistency here with other input types like textbox would be very much appreciated. David McMurray
Re: [whatwg] Styling details
On 2011-04-06 02:56, Lachlan Hunt wrote:
To render this, the following CSS should be applied by the UA stylesheet.
detailssummary:first-of-type {
display: list-item;
margin-left: 1em; /* LTR-specific: use 'margin-right' for rtl elements */
list-style-type: -o-disclosure-closed;
}
details[open]summary:first-of-type {
list-style-type: -o-disclosure-open;
}
There are a few other issues that we have identified.
1. The rendering of details will, unfortunately, inherit the quirks mode
rendering of list-items, where the bullet is a fixed size in quirks
mode, and based on the font-size in standards mode. This is a quirk
implemented by Firefox, IE and Opera for display: list-item; though
WebKit doesn't seem to. We are not sure if this quirk is still required
for web compatibility.
2. If the author attempts to shoot their own foot off by using:
summary { display: none; }
This leaves an empty details box of zero height in the closed state
with no way to open it, and the renders the content without a summary or
disclosure widget in the details open state.
We think this is acceptable, and that we should not introduce the magic
that exists in Chrome's experimental implementation, where they render
the default summary that says Details.
3. We'd like to get some feedback from web developers, and agreement
from other browser vendors, about exactly which glyphs are most
appropriate to use for these disclosure states. We considered two
alternatives, but we think these three glyphs are the most appropriate.
U+25B8 (▸) BLACK RIGHT-POINTING SMALL TRIANGLE
U+25C2 (◂) BLACK LEFT-POINTING SMALL TRIANGLE
U+25BE (▾) BLACK DOWN-POINTING SMALL TRIANGLE
The other alternative we considered was a larger set of triangle glyphs
that were too big for this purpose.
We created a custom SVG font with these glyphs, and I've put up a page
illustrating how each of these look.
http://lachy.id.au/dev/2011/triangle.html
(Use Opera to see the SVG font)
Copies of these glyphs (rendered with list-style-image instead) are now
being used in the simulation I created before.
http://lachy.id.au/dev/2011/details.html
(Check the directory listing there to get all the image files if you
want them.)
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Styling details
On Thu, Apr 7, 2011 at 6:09 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
1. The rendering of details will, unfortunately, inherit the quirks mode
rendering of list-items, where the bullet is a fixed size in quirks mode,
and based on the font-size in standards mode. This is a quirk implemented
by Firefox, IE and Opera for display: list-item; though WebKit doesn't seem
to. We are not sure if this quirk is still required for web compatibility.
You mean that it will inherit that behavior *in quirks mode*, right?
That's not a big deal - old pages won't use details, and new pages
shouldn't use quirks mode.
(Interesting that we don't have that quirk - that probably constitutes
decent evidence at this point that the quirk is unnecessary. I'll try
to remember to file a bug on Gecko about it.)
2. If the author attempts to shoot their own foot off by using:
summary { display: none; }
This leaves an empty details box of zero height in the closed state with
no way to open it, and the renders the content without a summary or
disclosure widget in the details open state.
We think this is acceptable, and that we should not introduce the magic that
exists in Chrome's experimental implementation, where they render the
default summary that says Details.
Yes, I think that's acceptable. The default summary should only show
up if there is no summary element - just hiding the summary element
shouldn't have any special effect. The author's doing it on purpose,
after all. Our implementation is just really buggy.
3. We'd like to get some feedback from web developers, and agreement from
other browser vendors, about exactly which glyphs are most appropriate to
use for these disclosure states. We considered two alternatives, but we
think these three glyphs are the most appropriate.
U+25B8 (▸) BLACK RIGHT-POINTING SMALL TRIANGLE
U+25C2 (◂) BLACK LEFT-POINTING SMALL TRIANGLE
U+25BE (▾) BLACK DOWN-POINTING SMALL TRIANGLE
Yup, looks good.
~TJ
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
On Wed, Apr 6, 2011 at 7:40 PM, Tim Down timd...@gmail.com wrote: Is there an overwhelming reason why execCommand() should be restricted to contentEditable/designMode elements, as the spec seems to suggest? IIRC from testing, that's how all browsers but IE9 behave. I guess the reason is that if you have a typical WYSIWYG editor, which has non-editable stuff surrounding it, and the user has selected some non-editable stuff on the page and clicks the bold button, you don't want the non-editable stuff to be bolded -- the button should only affect the editable area. Also, in a typical case, you're letting the user edit so that the markup will be saved or submitted to a server, and the markup that you'll save or submit is probably only the editable stuff. So if you do something like push down styles from outside the editable area, that change will not only unexpectedly affect the appearance of the non-editable part of the page, the change might not get saved. Of course, this makes it less convenient to use the commands for non-editing purposes, but they're mostly not very useful for that anyway. Do you have particular use-cases for using execCommand() outside of contentEditable/designMode? I'll probably put off tackling details like this until a much later date, once I've specified the algorithms themselves to a satisfactory extent.
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
On 7 April 2011 18:36, Aryeh Gregor simetrical+...@gmail.com wrote: On Wed, Apr 6, 2011 at 7:40 PM, Tim Down timd...@gmail.com wrote: Is there an overwhelming reason why execCommand() should be restricted to contentEditable/designMode elements, as the spec seems to suggest? IIRC from testing, that's how all browsers but IE9 behave. I guess the reason is that if you have a typical WYSIWYG editor, which has non-editable stuff surrounding it, and the user has selected some non-editable stuff on the page and clicks the bold button, you don't want the non-editable stuff to be bolded -- the button should only affect the editable area. Also, in a typical case, you're letting the user edit so that the markup will be saved or submitted to a server, and the markup that you'll save or submit is probably only the editable stuff. So if you do something like push down styles from outside the editable area, that change will not only unexpectedly affect the appearance of the non-editable part of the page, the change might not get saved. Of course, this makes it less convenient to use the commands for non-editing purposes, but they're mostly not very useful for that anyway. Do you have particular use-cases for using execCommand() outside of contentEditable/designMode? I'll probably put off tackling details like this until a much later date, once I've specified the algorithms themselves to a satisfactory extent. I don't recall ever wanting to use execCommand() in non-editable content myself (although I wouldn't rule it out), but I've answered a few questions on Stack Overflow where the asker has wanted to highlight (i.e. change the background colour of) the current selection. I've suggested temporarily putting the document into designMode, calling execCommand() with HiliteColor / BackColor and turning designMode off again. Here's an example of someone wanting to do this for a bookmarklet: http://stackoverflow.com/questions/3223682/change-css-of-selected-text-using-javascript I found about five others that were not so specific about why they wanted it, but all wanted to highlight the selected text using a background colour. One more example: http://stackoverflow.com/questions/1622629/javascript-highlight-selected-range-button Tim
Re: [whatwg] DOM Range: redefining behavior under DOM mutation
On 3/30/11 10:50 AM, Aryeh Gregor wrote: That would result in pbFoo/bbbar/b/p but actually, the result in Gecko is pbFoobar/b/p So I looked into this. It looks like Gecko does move the text node containing bar to be a child of the b and tracks which selection ranges are in the node it's removing so it can reset them when the node is inserted. For those who care, the relevant class is nsRangeUpdater, in editor/libeditor/base/nsSelectionState.h in the Gecko tree, and the relevant comment is: // editor selection gravity routines. Note that we can't always // depend on DOM Range gravity to do what we want to the real // selection. For instance, if you move a node, that corresponds to // deleting it and reinserting it. DOM Range gravity will promote // the selection out of the node on deletion, which is not what you // want if you know you are reinserting it. The editor notifies nsRangeUpdater about things like I'm about to move a node and I'm done moving a node so that nsRangeUpdater can track the fact that that the remove and insert it's seeing are part of a move and not unrelated operations. So browsers must be special-casing how execCommand() affects selections somehow That's certainly what Gecko is doing, yes. -Boris
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
On Thu, Apr 7, 2011 at 5:57 PM, Tim Down timd...@gmail.com wrote: I don't recall ever wanting to use execCommand() in non-editable content myself (although I wouldn't rule it out), but I've answered a few questions on Stack Overflow where the asker has wanted to highlight (i.e. change the background colour of) the current selection. I've suggested temporarily putting the document into designMode, calling execCommand() with HiliteColor / BackColor and turning designMode off again. That's an interesting use-case. On the other hand, the execCommand() works everywhere behavior is less flexible, in that it's impossible to work around it if you don't want it, unless I'm missing something. The behavior of non-IE browsers works well for the common case, and when you do want to style something that's not editable, you can always briefly make it editable. So I'm inclined to spec the non-IE behavior.
Re: [whatwg] DOM Range: redefining behavior under DOM mutation
On Thu, Apr 7, 2011 at 6:03 PM, Boris Zbarsky bzbar...@mit.edu wrote: So browsers must be special-casing how execCommand() affects selections somehow That's certainly what Gecko is doing, yes. Thanks for the info. In the end, I managed to define a reasonably clean way of getting good enough results: http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=d2481d02#preserving-ranges There are some cases where its behavior is slightly unexpected, in terms of putting the ends of the selection inside vs. outside elements, but it's good enough for now.
