Re: [whatwg] Scripted querying of video capabilities
On Oct 15, 2008, at 1:44 AM, Ian Hickson wrote: On Tue, 14 Oct 2008, Robert O'Callahan wrote: On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: While the underlying media frameworks can't necessarily answer, if I give you a file with this MIME type, can you play it?, they can at least give a yes/no/maybe answer, which can still be quite helpful, since the UA will know it does not need to check some media streams at all. I agree. If the API lets us answer maybe, there is not much need or temptation to lie, and we can still return information that could be useful to scripts. I have added window.navigator.canPlayType(mimeType). It returns 1, 0, or -1 to represent positive, neutral, and negative responses. This API would be tempting to treat as a boolean but would of course do completely the wrong thing. I think it would be better to either ensure that the positive and neutral responses are both values that JS would treat as true (for instance make the values true, maybe and false), or else make all of the return values something self- descriptive and symbolic (for instance the strings yes, maybe and no). I think 1, 0, -1 are neither clear nor likely to be in any way beneficial for perforamnce. Regards, Maciej
Re: [whatwg] Color attributes
On Thu, 05 Jul 2007 23:43:55 +0200, Simon Pieters [EMAIL PROTECTED] wrote: Color attributes in HTML have special processing. It seems that some pages use three-digit notation and expect it to work as in CSS. I've made the algorithm do that and I've drafted up a spec for this: http://simon.html5.org/specs/html-color-attributes -- Simon Pieters Opera Software
Re: [whatwg] video tag : loop for ever
...not sure if the following has been noted; if so, apologies... Currently, animated GIF and MNG images are used, sometimes, in loop forever form. Assuming that video might be used in an analogous fashion, loop-forever should be supported. I shudder to think about looping audio, however. Animated GIFs are often called dancing baloney ... and looping audio would be...? A-GIF and MNG do not support sub-clips ... and that's for a good reason: even as primitive as they are, GIF and MNG do offer a level of compression and jumping to some arbitrary or near-arbitrary spot in the clip is very difficult. As a counterpoint, jumps are supported by the various embed and video engines ... and can be completely screwed up if the content does not follow best practices, such as frequent full-frame resets. Using Javascript to estimate duration and thereby control the playback of WAV, MP3 or Ogg files has been done, but may not be feasible due to difficulties in determining load completion (onload), inaccuracy in the handling of timer events, and difficulties in skipping over unwanted content. Currently, the best practice is to have discrete content in order to avoid jumps.
Re: [whatwg] video tag : loop for ever
I shudder to think about looping audio, however. Animated GIFs are often called dancing baloney ... and looping audio would be...? One can program a game with svg or canvas with background music and sound effects, which is something proprietary plugins already allow.
Re: [whatwg] video tag : loop for ever
Am Mittwoch, den 15.10.2008, 20:03 -0700 schrieb Eric Carlson: After thinking about this, I'm not sure that limiting playback to a section of a media file will be used very often. Transcript anyone ? If you want to embed a lecture, for example, it makes sense to be able to link to specific points. A developer can easily script the same functionality as long as they don't use the default controller, so it seems to me that attributes for this aren't warranted. How ? Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] video tag : loop for ever
On Oct 15, 2008, at 8:31 PM, Chris Double wrote:
On Thu, Oct 16, 2008 at 4:07 PM, Eric Carlson
[EMAIL PROTECTED] wrote:
However I also think
that playing just a segment of a media file will be a common use-
case, so I
don't think we need start and end either.
How would you emulate end via JavaScript in a reasonably accurate
manner?
With a cue point.
If I have a WAV audio file and I want to start and stop
between specific points? For example a transcript of the audio may
provide the ability to play a particular section of the transcript.
If you use a script-based controller instead of the one provided by
the UA, you can easily limit playback to whatever portion of the file
you want:
SetTime: function(time) { this.elem.currentTime =
(timethis._minTime) ? this._minTime : (timethis._maxTIme?
this._maxTIme:time); }
I agree that it is more work to implement a custom controller, but
it seems a reasonable requirement given that this is likely to be a
relatively infrequent usage pattern.
Or do you think that people will frequently want to limit playback
to a section of a media file?
eric
Re: [whatwg] video tag : loop for ever
On Oct 16, 2008, at 7:32 AM, Nils Dagsson Moskopp wrote: Am Mittwoch, den 15.10.2008, 20:03 -0700 schrieb Eric Carlson: After thinking about this, I'm not sure that limiting playback to a section of a media file will be used very often. Transcript anyone ? If you want to embed a lecture, for example, it makes sense to be able to link to specific points. Certainly. A developer can easily script the same functionality as long as they don't use the default controller, so it seems to me that attributes for this aren't warranted. How ? A script-based controller can easily control the section(s) that are playable as it provides the UI and thus controls the user's access to the media resource. You can have the controller's timeline show just the section you want to play, you can have the controller show the entire duration and limit seeking to just the section, etc. eric
Re: [whatwg] video tag : loop for ever
hey people, you like to make everything as complex as posible don't you? playcount=1 only one time playcount=0 loop forever or playcount=-1 loop forever whats the problem? is it really so hard to program that?
Re: [whatwg] video tag : loop for ever
On Thu, 16 Oct 2008 17:17:49 +0200, SA Alfonso Baqueiro [EMAIL PROTECTED] wrote: hey people, you like to make everything as complex as posible don't you? Yes. playcount=1 only one time playcount=0 loop forever or playcount=-1 loop forever whats the problem? is it really so hard to program that? It's not complex. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video tag : loop for ever
On Oct 16, 2008, at 8:17 AM, SA Alfonso Baqueiro wrote: playcount=1 only one time playcount=0 loop forever or playcount=-1 loop forever Or how about loop = loop forever, else play one time though? eric
Re: [whatwg] video tag javascript library for contemporary browsers
On 10/16/08, Robert O'Callahan [EMAIL PROTECTED] wrote: On Thu, Oct 16, 2008 at 5:03 PM, Michael A. Puls II [EMAIL PROTECTED]wrote: Maybe video needs something (currently. maybe not in a few years) like a wmode param where the author can suggest (and the user can ultimately override if necessary) whether it's accelerated or not. Then, a site might provide video wmode=something all by itself on a separate page as an alternative to the normal all-cpu-driven-can-be-overlayed version. No, that is definitely not the right way to go. We could actually detect situations where an overlay could be used, and use it automatically, if that makes sense. I'm not sure it does. Thanks That would be cool to do it automatically. But, does using an overlay guarantee that other elements can't be placed on top of it? If so, then only the author of the page would know (by testing) that nothing needs to go over the top of it. Or, is it trivial to code the browser to look at the css applied on the page (and any behavior that might later apply css) to determine that an overlay won't interfere with any thing? If not, it seems like doing it automatically might break things. But, like you said if that makes sense. Just, fwiw, when a video playing in flash doesn't play at full speed and smoothly, there are 4 main steps to fix that. 1. Make sure that wmode=window (the default) is set. 'transparent' and 'opaque' hurt performance. I think there's a new value for it though that's supposed to help performance. 2. Make sure the video is shown at its original size. Scaling it hurts performance. Some flash players allow the user to adjust this so the video isn't scaled. 3. Pause the video and let it download all the way before watching. This seems to work because the network code and the video renderer are not fighting over the cpu and causing the video to download really slow or not at all. (Maybe that's some type of npapi threading issue or something) 4. Lower the quality. video is not flash though, but those are some things to think about (if you haven't already of course). Let us work on general video performance first and if we can't get close to VLC that way, Cool. then we'll see if overlay tricks are needed. Understood. We know we can improve performance quite a bit already without fundamental changes (e.g. we don't use MMX on Windows yet, and we're making some big improvements to the organization of our Ogg decoder). Sounds promising. -- Michael
Re: [whatwg] video tag : loop for ever
Eric Carlson wrote:
On Oct 15, 2008, at 8:31 PM, Chris Double wrote:
On Thu, Oct 16, 2008 at 4:07 PM, Eric Carlson [EMAIL PROTECTED]
wrote:
However I also think
that playing just a segment of a media file will be a common
use-case, so I
don't think we need start and end either.
How would you emulate end via JavaScript in a reasonably accurate
manner?
With a cue point.
If I have a WAV audio file and I want to start and stop
between specific points? For example a transcript of the audio may
provide the ability to play a particular section of the transcript.
If you use a script-based controller instead of the one provided by
the UA, you can easily limit playback to whatever portion of the file
you want:
SetTime: function(time) { this.elem.currentTime =
(timethis._minTime) ? this._minTime :
(timethis._maxTIme?this._maxTIme:time); }
IMHO, using 'currentTime' and cue ranges is - while technically possible
- a more cumbersome and roundabout way to delimitate a single audio
interval than just using 'start' and 'end' attributes.
I advocate keeping the simple way to do it, with 'start' and 'end', in
the spec.
Also, since you just showed how it can be implemented using cue ranges
and currentTime, having a second, simpler interface (for the case of a
single interval) should be cheap in terms of implementation cost, if you
plan to implement the other one anyway.
I agree that it is more work to implement a custom controller, but it
seems a reasonable requirement given that this is likely to be a
relatively infrequent usage pattern.
How do you know this will be infrequent?
Or do you think that people will frequently want to limit playback to
a section of a media file?
Yes, I think so - if people include those folks working with
professional audio/speech/music production. More specifically the
innovative ones among those, who would like to see audio-related web
apps to appear.
Imagine e.g. an audio editor in a browser and the task play this
selection of the oscillogram...
Why should such use cases be left to the Flash 10 crowd
(http://www.adobe.com/devnet/flash/articles/dynamic_sound_generation.html)?
I for one want to see them become possible with open web standards!
In addition, cutting down on number of HTTP transfers is generally
advocated as a performance booster, so the ability to play sections of a
larger media file using only client-side means might be of independent
interest.
-- Markus
Re: [whatwg] Some media element details
Ian Hickson wrote: On Mon, 6 Oct 2008, Bonner, Matt wrote: the original proposal said: var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY you appear to be proposing: var playing = !video.paused video.readyState = HTMLMediaElement.CAN_PLAY which only leaves the video.ended state in question. It's redundant -- the readyState can never be HAVE_FUTURE if there is no future (as is the case if the playback has ended). Okay, makes sense. thanks, Matt -- Matt Bonner Hewlett-Packard Company smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video tag : loop for ever
Allowing client-side fragments reduces the number of connections but
allowing server-side partial content is likely to reduce the volume of data.
Those features are antagonists, both are needed and it is hard to tell when
each one should be.
The case of hyperlinked transcript would be better served with an analogue
of IMAGEMAP AREA for cue ranges. It has been brought forward previously.
The case of instant cue ranges on demand is an edge case.
IMHO,
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dr. Markus Walther
Sent: Thursday, October 16, 2008 6:25 PM
To: Eric Carlson
Cc: whatwg group; Chris Double
Subject: Re: [whatwg] video tag : loop for ever
Eric Carlson wrote:
On Oct 15, 2008, at 8:31 PM, Chris Double wrote:
On Thu, Oct 16, 2008 at 4:07 PM, Eric Carlson [EMAIL PROTECTED]
wrote:
However I also think
that playing just a segment of a media file will be a common
use-case, so I
don't think we need start and end either.
How would you emulate end via JavaScript in a reasonably accurate
manner?
With a cue point.
If I have a WAV audio file and I want to start and stop
between specific points? For example a transcript of the audio may
provide the ability to play a particular section of the transcript.
If you use a script-based controller instead of the one provided by
the UA, you can easily limit playback to whatever portion of the file
you want:
SetTime: function(time) { this.elem.currentTime =
(timethis._minTime) ? this._minTime :
(timethis._maxTIme?this._maxTIme:time); }
IMHO, using 'currentTime' and cue ranges is - while technically possible
- a more cumbersome and roundabout way to delimitate a single audio
interval than just using 'start' and 'end' attributes.
I advocate keeping the simple way to do it, with 'start' and 'end', in
the spec.
Also, since you just showed how it can be implemented using cue ranges
and currentTime, having a second, simpler interface (for the case of a
single interval) should be cheap in terms of implementation cost, if you
plan to implement the other one anyway.
I agree that it is more work to implement a custom controller, but it
seems a reasonable requirement given that this is likely to be a
relatively infrequent usage pattern.
How do you know this will be infrequent?
Or do you think that people will frequently want to limit playback to
a section of a media file?
Yes, I think so - if people include those folks working with
professional audio/speech/music production. More specifically the
innovative ones among those, who would like to see audio-related web
apps to appear.
Imagine e.g. an audio editor in a browser and the task play this
selection of the oscillogram...
Why should such use cases be left to the Flash 10 crowd
(http://www.adobe.com/devnet/flash/articles/dynamic_sound_generation.html)?
I for one want to see them become possible with open web standards!
In addition, cutting down on number of HTTP transfers is generally
advocated as a performance booster, so the ability to play sections of a
larger media file using only client-side means might be of independent
interest.
-- Markus
Re: [whatwg] video tag : loop for ever
On Oct 16, 2008, at 9:24 AM, Dr. Markus Walther wrote: Eric Carlson wrote: I agree that it is more work to implement a custom controller, but it seems a reasonable requirement given that this is likely to be a relatively infrequent usage pattern. How do you know this will be infrequent? Of course I don't *know* that 'start' and 'end' attributes will be used infrequently, but I suspect it based on my experience helping developers with the QuickTime plug-in. It has had 'startTime' and 'endTime' attributes for almost ten years, but they are not commonly used. Or do you think that people will frequently want to limit playback to a section of a media file? Yes, I think so - if people include those folks working with professional audio/speech/music production. More specifically the innovative ones among those, who would like to see audio-related web apps to appear. Imagine e.g. an audio editor in a browser and the task play this selection of the oscillogram... Why should such use cases be left to the Flash 10 crowd (http://www.adobe.com/devnet/flash/articles/dynamic_sound_generation.html)? I for one want to see them become possible with open web standards! I am anxious to see audio-related web apps appear too, I just don't think that including 'start' and 'end' attributes won't make them significantly easier to write. In addition, cutting down on number of HTTP transfers is generally advocated as a performance booster, so the ability to play sections of a larger media file using only client-side means might be of independent interest. The 'start' and 'end' attributes, as currently defined in the spec, only limit the portion of a file that is played - not the portion of a file that is downloaded. If you are interested in clients requesting and playing media fragments, you might want to look at the W3C Media Fragments Working Group [1] which is investigating this issue. eric [1] http://www.w3.org/2008/WebVideo/Fragments
Re: [whatwg] video tag : loop for ever
Michael A. Puls II wrote: On 10/14/08, Ian Hickson [EMAIL PROTECTED] wrote: To be honest I'm not really convinced we need the looping feature at all. It seems like we should drop this from the current version. What benefit does it bring? Is looping really that common? If we got rid of it we could find better ways of picking the start time. Whenever I come across an awesome video with an awesome song, I'll loop it for hours. I'll even loop it while I sleep. When it comes to playlists, I loop them too. That would be a use case to consider for a browser providing looping functionality for the user, possibly activated through the context menu or something. But it is not a use case for providing authors with the ability to loop automatically using attributes. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] video tag : loop for ever
Eric Carlson wrote: As we discussed on IRC today, I think a valid use case for looping is background audio. It is possible to implement looping from script, but as someone else in this thread commented, it will be very difficult to do cleanly (eg. without artifacts). If this was done as some sort of background music for a game, then that's reasonable. There are many games that play annoyingly repetitive music. Having said that, I don't think that loopstart and loopend will be used frequently enough justify inclusion in the (first version of the) spec. Agreed. I think it's worth nothing that, according to Mozilla's documentation, the bgsound element uses a loop attribute uses a loop attribute that takes a number or the keyword infinite. The documentation for IE on MSDN is, however, quite vague about what values the attribute accepts. http://developer.mozilla.org/En/HTML/Element/Bgsound http://msdn.microsoft.com/en-us/library/aa454504.aspx -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] video tag : loop for ever
Chris Double wrote: On Thu, Oct 16, 2008 at 4:07 PM, Eric Carlson [EMAIL PROTECTED] wrote: However I also think that playing just a segment of a media file will be a common use-case, so I don't think we need start and end either. How would you emulate end via JavaScript in a reasonably accurate manner? If I have a WAV audio file and I want to start and stop between specific points? For example a transcript of the audio may provide the ability to play a particular section of the transcript. So if we keep the 'start' and 'end' attributes and have a simple boolean 'loop' attribute that indicates if looping should happen or not that would still be possible. The problem with relying on cues is that audio plays a lot faster than we can gurentee that cue-callbacks will happen. So if you for example create a audio file with a lot of sound effects back to back it is possible that a fraction of a second of the next sound will play before the cue-callback is able to stop it. / Jonas
Re: [whatwg] input type=hidden outside phrasing content
Kristof Zelechovski wrote: Why is FORM INPUT[type=hidden] not enough? Hi Chris, I'm sorry I don't follow your comment. My suggestion is about input type=hidden currently not being allowed in all locations in a document. Could you elaborate? (Maybe the followups below will make things clearer anyway.) Anne van Kesteren wrote: Where is it currently not allowed that you would like to allow it? It's pretty much allowed anywhere already as far as I can tell. Yes, maybe it is? Reading the spec again, I realize I had missed the sentence All phrasing content is also flow content. (I was mainly on the lookout for DTD-like info.) I have included a couple of the cases I'm thinking of below (that are invalid in HTML4). But some of them may already be ok in HTML5? form ... input type=hidden ... /form blockquote input type=hidden ... /blockquote table input type=hidden ... /table table tr input type=hidden ... td/td /tr /table ul/ol/dl input type=hidden ... /ul/ol/dl Tab Atkins Jr. wrote: For arbitrary state accessible to in-page scripting (like javascript), html5 defines the data-* family of attributes on all elements. These can have any name (as long as it starts with data-) and can hold arbitrary data. Yes, I'm aware of them and they actually have an interesting property in that they introduce page state in a way orthogonal to the element structure, as they allow data binding without introducing a new element or enforcing a certain element structure. (My focus this time is on POSTable state so the data- props won't do, but it would be interesting if hidden POSTable data could be added orthogonally to the element structure in a fashion similar to data-.) For POSTable state, the state needs to be within the form that's being submitted in any case, so being able to place the hidden state outside of the form wouldn't get you much. Can you elaborate on what you're proposing? Certainly, and no it is not outside the form I'm seeking but rather the odd cases above (imagine an outer form on all examples but the first). Best regards Mike Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wilson Sent: Wednesday, October 15, 2008 9:40 PM To: whatwg@lists.whatwg.org Subject: [whatwg] input type=hidden outside phrasing content Would it be possible to have HTML5 allow the insertion of input type=hidden ... (or something with the same effect) anywhere in the document? This would f ex relieve cases like server-side templating wanting to attach hidden state to its generated markup, and not having to use complex algorithms to find a suitable spot. As this type of element is non-visual this suggestion shouldn't cause any layout problems, but I guess having different placement rules for different settings on the same element type is, so maybe using input is not possible. Could HTML5 support adding hidden POSTable state in another way, that wouldn't be subject to placement rules for visual content? Best regards Mike Wilson
Re: [whatwg] video tag javascript library for contemporary browsers
On Fri, Oct 17, 2008 at 5:15 AM, Michael A. Puls II [EMAIL PROTECTED]wrote: That would be cool to do it automatically. But, does using an overlay guarantee that other elements can't be placed on top of it? If so, then only the author of the page would know (by testing) that nothing needs to go over the top of it. Or, is it trivial to code the browser to look at the css applied on the page (and any behavior that might later apply css) to determine that an overlay won't interfere with any thing? If not, it seems like doing it automatically might break things. But, like you said if that makes sense. What I mean by automatically is that we can detect when using an overlay won't break things, and use it when it won't break things. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] video tag : loop for ever
On Fri, Oct 17, 2008 at 5:24 AM, Dr. Markus Walther [EMAIL PROTECTED]wrote: Imagine e.g. an audio editor in a browser and the task play this selection of the oscillogram... Why should such use cases be left to the Flash 10 crowd (http://www.adobe.com/devnet/flash/articles/dynamic_sound_generation.html )? If people go in that direction they won't be using cue ranges etc, they'll be using dynamic audio generation, which deserves its own API. OK, in principle you could use audio with data:audio/wav, but that would be crazy. Then again, this is the Web so of course people will do that. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] input type=hidden outside phrasing content
Your question made me think you want HEAD INPUT[type=hidden]. INPUT[type=hidden] must be within a paragraph (explicitly or implicitly) for consistency with other INPUT controls that are displayed. So, where a paragraph is not allowed, neither is the INPUT control; inserted where it does not belong, it migrates; the document is invalid but it can be rescued. I do not see much value in allowing it to stay wherever it is found. If you want to create another hidden control, go ahead and tell us how do you imagine it should look like. Chris -Original Message- From: Mike Wilson [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2008 11:09 PM To: 'WHATWG List'; 'Kristof Zelechovski'; 'Anne van Kesteren'; 'Tab Atkins Jr.' Subject: RE: [whatwg] input type=hidden outside phrasing content Kristof Zelechovski wrote: Why is FORM INPUT[type=hidden] not enough? Hi Chris, I'm sorry I don't follow your comment. My suggestion is about input type=hidden currently not being allowed in all locations in a document. Could you elaborate? (Maybe the followups below will make things clearer anyway.) Anne van Kesteren wrote: Where is it currently not allowed that you would like to allow it? It's pretty much allowed anywhere already as far as I can tell. Yes, maybe it is? Reading the spec again, I realize I had missed the sentence All phrasing content is also flow content. (I was mainly on the lookout for DTD-like info.) I have included a couple of the cases I'm thinking of below (that are invalid in HTML4). But some of them may already be ok in HTML5? form ... input type=hidden ... /form blockquote input type=hidden ... /blockquote table input type=hidden ... /table table tr input type=hidden ... td/td /tr /table ul/ol/dl input type=hidden ... /ul/ol/dl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wilson Sent: Wednesday, October 15, 2008 9:40 PM To: whatwg@lists.whatwg.org Subject: [whatwg] input type=hidden outside phrasing content Would it be possible to have HTML5 allow the insertion of input type=hidden ... (or something with the same effect) anywhere in the document? This would f ex relieve cases like server-side templating wanting to attach hidden state to its generated markup, and not having to use complex algorithms to find a suitable spot. As this type of element is non-visual this suggestion shouldn't cause any layout problems, but I guess having different placement rules for different settings on the same element type is, so maybe using input is not possible. Could HTML5 support adding hidden POSTable state in another way, that wouldn't be subject to placement rules for visual content? Best regards Mike Wilson
Re: [whatwg] video tag : loop for ever
The documentation page Lachlan visited describes embedded technology, truncated to fit; you should understand that it may be incomplete. The mainstream documentation for the BGSOUND element is at http://msdn.microsoft.com/en-us/library/ms534134(VS.85).aspx. HTH, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Thursday, October 16, 2008 10:32 PM To: Eric Carlson Cc: whatwg Subject: Re: [whatwg] video tag : loop for ever I think it's worth nothing that, according to Mozilla's documentation, the bgsound element uses a loop attribute uses a loop attribute that takes a number or the keyword infinite. The documentation for IE on MSDN is, however, quite vague about what values the attribute accepts. http://developer.mozilla.org/En/HTML/Element/Bgsound http://msdn.microsoft.com/en-us/library/aa454504.aspx
Re: [whatwg] input type=hidden outside phrasing content
table tr input type=hidden ... td/td /tr /table This is something I wanted to do recently. I was building HTML in a Perl script, adding table rows in a loop, and I wanted some rows to contain text field with user-editable value, while for other rows I wanted the value to be displayed but not editable (and I didn't want to use a disabled text input, I wanted the value displayed as plain text and use a hidden input with the value preset). I believe I wound up putting the input inside the td, which worked well enough but if putting it directly inside the tr were valid I probably would have done that. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Color attributes
While the first item's length in segments is greater than 2 and the first character in each item in segments is a U+0030 DIGIT ZERO character, remove the first character from each item in segments. Does this mean, if the length of the first item in segments is greater than 2 then loop through each item in segments, and if the first character is 0 then remove it? Or does it mean, if the length of the first item in segments is greater than 2 and the first character of every item in segments is 0, then loop through each item and delete the first character, but if the first character of any item is not 0 then leave the whole thing alone? I'm assuming you meant #1, but your wording isn't perfectly clear. Has it occurred to you that while your algorithm makes the string foo return an error, the string l33tsp34k is converted to a dark purple? -- Andy Lyttle [EMAIL PROTECTED] On Oct 16, 2008, at 4:46 AM, Simon Pieters wrote: On Thu, 05 Jul 2007 23:43:55 +0200, Simon Pieters [EMAIL PROTECTED] wrote: Color attributes in HTML have special processing. It seems that some pages use three-digit notation and expect it to work as in CSS. I've made the algorithm do that and I've drafted up a spec for this: http://simon.html5.org/specs/html-color-attributes -- Simon Pieters Opera Software
Re: [whatwg] input type=hidden outside phrasing content
On Thu, 16 Oct 2008 23:08:32 +0200, Mike Wilson [EMAIL PROTECTED] wrote: Yes, maybe it is? Reading the spec again, I realize I had missed the sentence All phrasing content is also flow content. (I was mainly on the lookout for DTD-like info.) I have included a couple of the cases I'm thinking of below (that are invalid in HTML4). But some of them may already be ok in HTML5? I'd suggest playing with validator.nu. Out the top of my head: form ... input type=hidden ... /form Fine. blockquote input type=hidden ... /blockquote Fine. table input type=hidden ... /table Not fine. table tr input type=hidden ... td/td /tr /table Not fine. ul/ol/dl input type=hidden ... /ul/ol/dl Not fine. For the table and lists cases, is there a good use case for complicating their content model or could you just as well put the input either before or after the table or list? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] input type=hidden outside phrasing content
On Thu, Oct 16, 2008 at 4:59 PM, Andy Lyttle [EMAIL PROTECTED] wrote: table tr input type=hidden ... td/td /tr /table This is something I wanted to do recently. I was building HTML in a Perl script, adding table rows in a loop, and I wanted some rows to contain text field with user-editable value, while for other rows I wanted the value to be displayed but not editable (and I didn't want to use a disabled text input, I wanted the value displayed as plain text and use a hidden input with the value preset). I believe I wound up putting the input inside the td, which worked well enough but if putting it directly inside the tr were valid I probably would have done that. That seems sort of weird though. You're fine with putting the input type=text within the td, but you'd prefer *not* to do the same with the input type=hidden? It seems much more reasonable to just put it in the exact same place. At any rate, it certainly doesn't seem like a compelling reason to change the content model of tr. ~TJ
Re: [whatwg] input type=hidden outside phrasing content
That seems sort of weird though. You're fine with putting the input type=text within the td, but you'd prefer *not* to do the same with the input type=hidden? It seems much more reasonable to just put it in the exact same place. At any rate, it certainly doesn't seem like a compelling reason to change the content model of tr. Only because within the td I already had the value expressed as plain text. I ended up with something like tdinput type=hidden value=FooFoo/td (except it was uglier). I can't think of a specific example, but I know there's been something similar I wanted to do in the past that was similar that turned out uglier than this. I'm not saying it's a compelling reason, just that wanting to do it isn't completely insane. :-) -- Andy Lyttle [EMAIL PROTECTED] On Oct 16, 2008, at 3:07 PM, Tab Atkins Jr. wrote: On Thu, Oct 16, 2008 at 4:59 PM, Andy Lyttle [EMAIL PROTECTED] wrote: table tr input type=hidden ... td/td /tr /table This is something I wanted to do recently. I was building HTML in a Perl script, adding table rows in a loop, and I wanted some rows to contain text field with user-editable value, while for other rows I wanted the value to be displayed but not editable (and I didn't want to use a disabled text input, I wanted the value displayed as plain text and use a hidden input with the value preset). I believe I wound up putting the input inside the td, which worked well enough but if putting it directly inside the tr were valid I probably would have done that. That seems sort of weird though. You're fine with putting the input type=text within the td, but you'd prefer *not* to do the same with the input type=hidden? It seems much more reasonable to just put it in the exact same place. At any rate, it certainly doesn't seem like a compelling reason to change the content model of tr. ~TJ
Re: [whatwg] video tag : loop for ever
On Fri, Oct 17, 2008 at 1:32 AM, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: Am Mittwoch, den 15.10.2008, 20:03 -0700 schrieb Eric Carlson: After thinking about this, I'm not sure that limiting playback to a section of a media file will be used very often. Transcript anyone ? If you want to embed a lecture, for example, it makes sense to be able to link to specific points. Linking to a specific time point or section in a media file is not something that needs to be solved by HTML. It is in fact a URI issue and is being developed by the W3C Media Fragments working group. If you use a URI such as http://example.com/mediafile.ogv#time=12-30 in the src attribute of the video element, you will not even have to worry about start and end attributes for the video element. Take the analogy of html pages - HTML does not specify how to get a paragraph out of a html page either. It is done by a URI reference to the name (id) of that paragraph. This should be done in the same way for video and other Web resources. Then, a loop over that segment only requires a boolean loop attribute. Regards, Silvia.
Re: [whatwg] video tag : loop for ever
On 10/16/08, Lachlan Hunt [EMAIL PROTECTED] wrote: Michael A. Puls II wrote: On 10/14/08, Ian Hickson [EMAIL PROTECTED] wrote: To be honest I'm not really convinced we need the looping feature at all. It seems like we should drop this from the current version. What benefit does it bring? Is looping really that common? If we got rid of it we could find better ways of picking the start time. Whenever I come across an awesome video with an awesome song, I'll loop it for hours. I'll even loop it while I sleep. When it comes to playlists, I loop them too. That would be a use case to consider for a browser providing looping functionality for the user, possibly activated through the context menu or something. But it is not a use case for providing authors with the ability to loop automatically using attributes. True. As long as the browser provided a way to change (and save the loop preference) on a per-webapp basis, that would solve my use case. -- Michael
Re: [whatwg] Whatwg Social Meeting This Month
Hello, I've received a number of responses, and it looks like Thursday, 10/28, is the best date. I think that 7pm is the best time, but if someone has any pressing arguments for an earlier time (like, most whatwg contributors don't have have real jobs anyway =) then feel free to send them my way. In a couple of days after I've finalized the details, I'll put this information up somewhere. -Michael Carter On Tue, Oct 14, 2008 at 8:28 AM, Michael Carter [EMAIL PROTECTED]wrote: Hello, Who is interested in a whatwg social meeting this month? While I know many of you are located all around the world, if there is a locus of participants in whatwg, I would say its in the Bay Area (San Francisco and perimeter, CA, USA). With that in mind, let me propose that we schedule an informal meetup in Mountain View, CA at Red Rock cafe, on castro street: http://maps.google.com/maps?hl=enclient=firefox-arls=com.ubuntu:en-US:unofficialhs=Eulum=1ie=UTF-8q=red+rock,+94040fb=1cid=0,0,4140843673288073926sa=Xoi=local_resultresnum=1ct=image. If you live halfway across the world and aren't planning travel out here this month, don't worry -- I'm sure there will be other opportunities. We should probably set up a wiki for this sort of thing, but for this meeting I'm happy to keep track of logistics via emails to this thread. For now, I'd just like to know everyone's availability between the dates of 10/23 and 10/31 at 7pm. Cheers, Michael Carter
Re: [whatwg] video tag : loop for ever
On Wed, Oct 15, 2008 at 10:39 AM, Eduard Pascual [EMAIL PROTECTED] wrote: I quite agree with this idea. For a number, I think -1 would be ideal: it is already used by lots of desktop software to convey similar meanings, and could have an interesting benefit implementation-wise: if the 2's complement representation of the number is interpreted as an unsigned integer, then it will represent the highest respresentable value (ie: hex for 16-bit, or for 64-bit), just due to the way 2's complement works. If we ever add a feature to loop for ever I like the idea of -1 * representation of it in binary is same a the biggest number * other implementations already use it eg: http://msdn.microsoft.com/en-us/library/ms534134(VS.85).aspx Use case:- It make easy for the Average Joe web-developer to write a infinite-loop player. Other wise he is going to make web page with lot of javascript event handler, which may work in IE but not in Firefox. Thanks. Biju
[whatwg] Can AUDIO/VIDEO element have a balance attribute
Can AUDIO/VIDEO tag have a balance attribute like? http://developer.mozilla.org/En/HTML/Element/Bgsound BTW: Thanks to http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016699.html for dmo link. spec: http://www.whatwg.org/specs/web-apps/current-work/#dom-media-volume
