Re: [whatwg] video tag : loop for ever

[John Foliot - WATS.ca]

Maciej Stachowiak wrote:
> 
> 
> (Probably the best way to do something like this (short of a realtime
> sound API) would be the ability to queue up an audio file (or range
> thereof) to play next when the current one finishes, because then the
> media framework can take care of ensuring a smooth transition.)

"Playlists" such as this can be done with SMIL / SAMI already - smooth
transitioning is up to the UA
[http://www.w3.org/TR/2006/WD-SMIL3-20061220/smil-serverplaylist-profile.htm
l] 
[http://msdn.microsoft.com/en-us/library/ms752554(VS.85).aspx]
[http://service.real.com/help/library/guides/production/htmfiles/smil.htm]


(one more reason why you don't want to burn everything into a monolith file)

JF

Re: [whatwg] [WF2]

[Weston Ruter]

Kristof, you are right. This is not implemented in IE 7. However, Microsoft
has implemented it in IE 8 Beta 2; that's what I tested in.


On Fri, Oct 24, 2008 at 12:52 PM, Kristof Zelechovski <[EMAIL PROTECTED]
> wrote:

>  The official documentation for the disabled Property (BUTTON, INPUT
> type=button, INPUT type=checkbox, 
> ...):
> contains the following:
>
> *Note*  For 
> OPTGROUPand
> OPTION ,
> the functionality specified by the HTML 4.0
>  [image: World Wide Web link] standard is not currently implemented. You
> can define your own functionality.
>
>
>  --
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Weston Ruter
> *Sent:* Friday, October 24, 2008 9:40 PM
> *To:* [EMAIL PROTECTED]
> *Cc:* Ian Hickson; Tab Atkins Jr.; Joao Eiras; Simon Pieters; Robert
> *Subject:* Re: [whatwg] [WF2] 
>
>
>
> I just realized that there is existing support for using a first OPTION as
> a non-selectable hint value. Instead of this:
>
> 
>   Select one
>   None of these
>   Love It
>   Hate It
> 
>
>
> One may set two attributes, @disabled and @selected, on the first OPTION:
>
> 
>   Select one
>   None of these
>   Love It
>   Hate It
> 
>
>
> The behavior in browsers is that "Select one" is displayed as the value in
> the drop-down, and in MSIE it's even grayed out. In Firefox and MSIE, since
> the default selected option is disabled, it will not submit a value. In this
> case, the option's @value makes no difference and can be an empty string or
> any value at all. (Note that Firefox is a little buggy in that when clicking
> on the select list, the shown selected option won't change but the value
> submitted will change to the first non-disabled value.) Unfortunately,
> Safari and Opera submit the disabled option, even though it cannot be
> selected by hand. In IE and Firefox, once the one of the options is selected
> by the user, they are unable to re-select the disabled option, as with
> Safari and Opera.
>
> Here's a demo:
> http://weston.ruter.net/projects/test-cases/html-select-element/
>
>
>
>
<>

Re: [whatwg] [WF2]

[Kristof Zelechovski]

The official documentation for the
 disabled
Property (BUTTON, INPUT type=button, INPUT type=checkbox, ...): contains the
following:

Note  For  
OPTGROUP and  
OPTION, the functionality specified by the
 HTML 4.0 World Wide Web link standard is
not currently implemented. You can define your own functionality.

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Weston Ruter
Sent: Friday, October 24, 2008 9:40 PM
To: [EMAIL PROTECTED]
Cc: Ian Hickson; Tab Atkins Jr.; Joao Eiras; Simon Pieters; Robert
Subject: Re: [whatwg] [WF2] 

 

I just realized that there is existing support for using a first OPTION as a
non-selectable hint value. Instead of this:


  Select one
  None of these
  Love It
  Hate It



One may set two attributes, @disabled and @selected, on the first OPTION:


  Select one
  None of these
  Love It
  Hate It



The behavior in browsers is that "Select one" is displayed as the value in
the drop-down, and in MSIE it's even grayed out. In Firefox and MSIE, since
the default selected option is disabled, it will not submit a value. In this
case, the option's @value makes no difference and can be an empty string or
any value at all. (Note that Firefox is a little buggy in that when clicking
on the select list, the shown selected option won't change but the value
submitted will change to the first non-disabled value.) Unfortunately,
Safari and Opera submit the disabled option, even though it cannot be
selected by hand. In IE and Firefox, once the one of the options is selected
by the user, they are unable to re-select the disabled option, as with
Safari and Opera. 

Here's a demo:
http://weston.ruter.net/projects/test-cases/html-select-element/




 

<>

Re: [whatwg] [WF2]

[Weston Ruter]

I just realized that there is existing support for using a first OPTION as a
non-selectable hint value. Instead of this:


>   Select one
>   None of these
>   Love It
>   Hate It
> 
>

One may set two attributes, @disabled and @selected, on the first OPTION:


>   Select one
>   None of these
>   Love It
>   Hate It
> 
>

The behavior in browsers is that "Select one" is displayed as the value in
the drop-down, and in MSIE it's even grayed out. In Firefox and MSIE, since
the default selected option is disabled, it will not submit a value. In this
case, the option's @value makes no difference and can be an empty string or
any value at all. (Note that Firefox is a little buggy in that when clicking
on the select list, the shown selected option won't change but the value
submitted will change to the first non-disabled value.) Unfortunately,
Safari and Opera submit the disabled option, even though it cannot be
selected by hand. In IE and Firefox, once the one of the options is selected
by the user, they are unable to re-select the disabled option, as with
Safari and Opera.

Here's a demo:
http://weston.ruter.net/projects/test-cases/html-select-element/

I also include on that page a proposed "unselected" attribute for the SELECT
element. By default, a first option in a SELECT is selected; the only way to
select no OPTION is to set select.selectedIndex = -1. It would seem quite
useful if some non-scripting means of doing this; perhaps an "unselected"
boolean attribute would make sense. Unfortunately, WebKit still submits the
first OPTION as the value even if the selectedIndex == -1.

Regarding the original topic of this thread, the [EMAIL PROTECTED] attribute,
when select.selectedIndex == -1 (whether set programmatically or via some
"unselected" boolean attribute), a @required attribute absolutely makes
sense. It also absolutely makes sense with [EMAIL PROTECTED]


On Fri, Oct 24, 2008 at 11:14 AM, Tab Atkins Jr. <[EMAIL PROTECTED]>wrote:

>
>
> On Fri, Oct 24, 2008 at 11:57 AM, Andy Lyttle <[EMAIL PROTECTED]> wrote:
>
>> On Oct 24, 2008, at 8:23 AM, Tab Atkins Jr. wrote:
>>
>>  So, pulling it all together, my proposal for a hinting ability on
>>>  is thus:
>>>
>>>  can have a @hint attribute, which takes a text value.  If there
>>> is no , then this hint is initially displayed in the
>>> 's collapsed state.  As soon as an option is selected, though (or if
>>> an  had @selected initially), the hint disappears and the selected
>>> 's text is instead displayed in the 's collapsed state.
>>>  When @hint is supplied, a conforming UA will not allow the form to be
>>> submitted until an option is selected (again, an  with @selected
>>> specified counts here), indicating in some way that a value in the 
>>> must be chosen (the exact method UAs use to indicate this to users is left
>>> undefined, but should be similar to how the UA alerts a user that an 
>>> with @required is empty and must be filled).
>>>
>>> For fallback, authors should provide an empty  (or one containing
>>> only whitespace) with an appropriate default @value as the 's first
>>> child.  If s are used, this  should come before them.
>>>  Conforming UAs will not display this .  In legacy UAs, this will
>>> cause the  to initially display as blank in the collapsed state, and
>>> will submit the author-supplied default value as the value of the control if
>>> the user does not make a proper selection.
>>>
>>> This sound good?
>>>
>>
>> Almost!  The only problem is, I might want the text of my "blank" option
>> to be something other than whitespace, for example "(none)", "None of the
>> above" (it could be the last option instead of the first), etc.  Remember
>> that in a case where the initial state is some other  selected, we
>> want the user to be able to choose the "blank" option, and "(none)" is much
>> clearer in the expanded menu than whitespace, which may not be recognized as
>> being a selectable choice.
>
>
> Well, remember what the fallback  is for.  It's *only* meant to
> indicate that the  has *not* been selected yet.  If "None of the
> Above" or whatever is a valid choice, then it is ipso facto *not* a fallback
> option.  It may be the default option, but that's no different than a
> country selector setting United States as the default.  This doesn't clash
> with my proposal at all, as it doesn't run afoul of the "first child of the
>  with whitespace for content" rule.  The "none of the above" option
> can be first, last, or anything in between.
>
> You can even specify both a fallback and a "none of the above" option with
> the same value if you so chose, though how that would be different from just
> setting the "none of the above" option as @selected, I don't know.
>
> So, frex, this code would be perfectly fine, and would display the same in
> both legacy and hypothetical conforming UAs:
> 
>   None of these
>   Love It
>   Hate It
> 
> Because there's no @hint attribute, both legacy and conformant UAs would
> show the "None of these

Re: [whatwg] [WF2]

[Tab Atkins Jr.]

On Fri, Oct 24, 2008 at 11:57 AM, Andy Lyttle <[EMAIL PROTECTED]> wrote:

> On Oct 24, 2008, at 8:23 AM, Tab Atkins Jr. wrote:
>
>  So, pulling it all together, my proposal for a hinting ability on 
>> is thus:
>>
>>  can have a @hint attribute, which takes a text value.  If there
>> is no , then this hint is initially displayed in the
>> 's collapsed state.  As soon as an option is selected, though (or if
>> an  had @selected initially), the hint disappears and the selected
>> 's text is instead displayed in the 's collapsed state.
>>  When @hint is supplied, a conforming UA will not allow the form to be
>> submitted until an option is selected (again, an  with @selected
>> specified counts here), indicating in some way that a value in the 
>> must be chosen (the exact method UAs use to indicate this to users is left
>> undefined, but should be similar to how the UA alerts a user that an 
>> with @required is empty and must be filled).
>>
>> For fallback, authors should provide an empty  (or one containing
>> only whitespace) with an appropriate default @value as the 's first
>> child.  If s are used, this  should come before them.
>>  Conforming UAs will not display this .  In legacy UAs, this will
>> cause the  to initially display as blank in the collapsed state, and
>> will submit the author-supplied default value as the value of the control if
>> the user does not make a proper selection.
>>
>> This sound good?
>>
>
> Almost!  The only problem is, I might want the text of my "blank" option to
> be something other than whitespace, for example "(none)", "None of the
> above" (it could be the last option instead of the first), etc.  Remember
> that in a case where the initial state is some other  selected, we
> want the user to be able to choose the "blank" option, and "(none)" is much
> clearer in the expanded menu than whitespace, which may not be recognized as
> being a selectable choice.


Well, remember what the fallback  is for.  It's *only* meant to
indicate that the  has *not* been selected yet.  If "None of the
Above" or whatever is a valid choice, then it is ipso facto *not* a fallback
option.  It may be the default option, but that's no different than a
country selector setting United States as the default.  This doesn't clash
with my proposal at all, as it doesn't run afoul of the "first child of the
 with whitespace for content" rule.  The "none of the above" option
can be first, last, or anything in between.

You can even specify both a fallback and a "none of the above" option with
the same value if you so chose, though how that would be different from just
setting the "none of the above" option as @selected, I don't know.

So, frex, this code would be perfectly fine, and would display the same in
both legacy and hypothetical conforming UAs:

  None of these
  Love It
  Hate It

Because there's no @hint attribute, both legacy and conformant UAs would
show the "None of these" option by default, and submit its value (the empty
string) if the user doesn't actively select anything.

If you provide a @hint attribute, the *only* change will be that conformant
UAs will display the hint in the collapsed  until the user actively
selects something.  Both legacy and conformant UAs will submit the empty
string as the value of the control if the user doesn't actively select
anything, because that is the value of the first .  The defining
point of this piece of code is that "None of these" is an acceptable default
option to the author.  (Note that the author should probably give the first
option @selected, but that would prevent the hint from displaying; there are
some tradeoffs here.  Without the @selected it works the same, though.)

On the other hand, this markup works differently:

  
  None of these
  Love It
  Hate It

In a conformant UA, the  will initially display "Select one" while
it is collapsed.  When it is expanded, the first (blank) option will *not*
display.  If the user attempts to submit the form without actively selecting
a value, the UA will prevent it and inform them that they must select a
value in the control.

In a legacy UA, on the other hand, the  will initially display empty
when collapsed, and will have a blank line as the first option when
expanded.  If the user submits the form without actively selecting a value,
the server will receive the value "[[invalid]]", which lets the author know
that the user didn't actively select an option (or chose to select the blank
, which is just as invalid), and that the user should be returned to
the form with an error message.

And, of course, contrast that with this markup, which is how you would do
this currently:

  Select one
  None of these
  Love It
  Hate It

The UA will display "Select one" initially in the , and will send
"[[invalid]]" if the user doesn't select anything.  The difference is that
there's no way for a UA to detect that the form shouldn't be submitted with
the first  selected, and so any client-side validation has t

Re: [whatwg] [WF2]

[Andy Lyttle]

On Oct 24, 2008, at 8:23 AM, Tab Atkins Jr. wrote:

So, pulling it all together, my proposal for a hinting ability on  
 is thus:


 can have a @hint attribute, which takes a text value.  If  
there is no , then this hint is initially  
displayed in the 's collapsed state.  As soon as an option  
is selected, though (or if an  had @selected initially),  
the hint disappears and the selected 's text is instead  
displayed in the 's collapsed state.  When @hint is  
supplied, a conforming UA will not allow the form to be submitted  
until an option is selected (again, an  with @selected  
specified counts here), indicating in some way that a value in the  
 must be chosen (the exact method UAs use to indicate this  
to users is left undefined, but should be similar to how the UA  
alerts a user that an  with @required is empty and must be  
filled).


For fallback, authors should provide an empty  (or one  
containing only whitespace) with an appropriate default @value as  
the 's first child.  If s are used, this   
should come before them.  Conforming UAs will not display this  
.  In legacy UAs, this will cause the  to initially  
display as blank in the collapsed state, and will submit the author- 
supplied default value as the value of the control if the user does  
not make a proper selection.


This sound good?


Almost!  The only problem is, I might want the text of my "blank"  
option to be something other than whitespace, for example "(none)",  
"None of the above" (it could be the last option instead of the  
first), etc.  Remember that in a case where the initial state is some  
other  selected, we want the user to be able to choose the  
"blank" option, and "(none)" is much clearer in the expanded menu  
than whitespace, which may not be recognized as being a selectable  
choice.


Reserving value="" to indicate which option is the "blank" one would  
solve this problem (while presenting more). :-)


--
Andy Lyttle
[EMAIL PROTECTED]

Re: [whatwg] video tag : loop for ever

[Maciej Stachowiak]

On Oct 24, 2008, at 6:44 AM, timeless wrote:


Sounds like what you really want is an audio/video stiching api so
that you could concatenate a second sound track and achieve a smooth
transition.


That might be useful in its own right but seems irrelevant to the use  
case of looping a single sound.


(Probably the best way to do something like this (short of a realtime  
sound API) would be the ability to queue up an audio file (or range  
thereof) to play next when the current one finishes, because then the  
media framework can take care of ensuring a smooth transition.)


 - Maciej




On 10/23/08, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:


On Oct 14, 2008, at 5:40 PM, Ian Hickson wrote:



There is no way to say "loop forever" right now primarily because
doing so
would mean complicating the syntax of the playcount attribute to be
not
just a number. You can work around it with script (just add
onended="currentTime=0" to the  element).


This would lead to perceptible glitches in looped audio, compared to
being able to represent the looping to the media framework.


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.


For example: I think looped audio would be a common thing for games  
to

want to do, and they wouldn't want it to glitch when it loops.

Regards,
Maciej




--
Sent from Gmail for mobile | mobile.google.com

Re: [whatwg] [WF2]

[Tab Atkins Jr.]

On Fri, Oct 24, 2008 at 12:37 AM, Andy Lyttle <[EMAIL PROTECTED]> wrote:

> On Oct 23, 2008, at 12:19 PM, Tab Atkins Jr. wrote:
>
> Ultimately the display of the hint is, and should be, up to the UA, so that
> non-full-featured devices can display things in a maximally helpful way to
> the user.  Within the context of a standard browser on an ordinary computer,
> though, the correct display seems relatively clear.  When the select is
> collapsed, the hint should show until the user selects something.  After the
> user selects something, the hint will never again display in the collapsed
> state.  I'm not sure if it's necessary for the hint to display in the
> expanded state.  If it is, though, then it should always be the first item
> in the list, and it should be nonselectable, similar to how column groups
> display currently.
>
> My responses to the following questions (from Andy Lyttle, in case the
quoting throws anyone) should be considered only my own opinions.

1) If the user clicks to open the menu, then clicks away or presses Esc
> without making a selection, does that count as a selection for purposes of
> making the placeholder not appear again?
>

No.  They have not yet selected anything.  The situation is similar to the
preferred display of the hint in a text input - if the user focusses the
field (making the hint disappear) then changes the focus without ever
entering anything, the hint should display again.

2) If the user never selects something, they'll never see anything but the
> placeholder.  That means they won't see the text associated with whatever
> option is selected by default.  In many cases, the default option will be
> some sort of blank* value to indicate that the user has not made a
> selection; the current practice serves both purposes at the same time
> (having a blank value to indicate no selection, and setting the text of that
> option to a placeholder/hint).  A placeholder option would replace one of
> these purposes, but not both; authors would still need to have a default
> option that indicates non-selection.
>
> * By blank, I mean something unique that the script that will process the
> form knows means a non-selection.  I normally use  for this
> purpose, but it could be any value the author devises.
>
> In other cases, there must always be something selected; a non-selection
> shouldn't be possible.  An example might be the "country" field on an
> address form, which defaults to the most likely choice (e.g. United States
> for sites that expect most of their audience to be American).  The user
> shouldn't be permitted to select a non-value.  How should the placeholder
> text be displayed?  It seems clear to me that it should NOT appear on the
> collapsed menu at all, but should appear at the top of the expanded menu.
>
> There are other cases where having a blank option is appropriate, but the
> default may be something else.  The user can explicitly change the selection
> to a blank option.
>
> How should the placeholder behave in each of these cases?
>

Very, very good questions.  Okay, so let's go back to the beginning.
 already has a widely-used hinting method.  If there is an
appropriate default , then an author puts @selected on it, and
everything's golden.  If not, the author makes the very first  have
an appropriately hint-y text, and an appropriate default value, so that they
can distinguish on the server side that the  wasn't successfully
submitted.  These two methods are already widely used, so is there actually
a problem needing to be solved here?  Both methods will also need to be
supported into the future as fallback material.

I think yes.  If there is an appropriate default value, we don't need a
hint.  This is similar to a text input with @value - a good value is already
provided, and the  and context provides the rest of what you need.
However, if there is *not* an appropriate default value, the current
practice makes this known *only* to the server-side script.  The UA has no
way of knowing that the  is officially in an invalid position at the
moment, and so can't provide automatic validation help (like it can with
).

So that's the only problem we really have to solve - how to tell the UA that
the first  in the  is invalid.  We Two things present
themselves to me.

(1) Allow @hint as a boolean attribute on the first .  This is
nothing more than what I said above - a hint to the UA that the first
 in the list isn't a valid choice, so it should display as normal
but not be submittable with this value.

(2) Put @hint as a text attribute on .  This would then display
initially on the collapsed .  Upon selecting a value, the hint
disappears and  acts like normal.

Option (1) is easy.  However, it breaks symmetry with the proposed
/ @hint attribute.  As well, it still provides an
officially selectable attribute, even if the UA prevents the form from
actually being submitted with it.  The best user experience would be if the
user simply couldn't select 

Re: [whatwg] video tag : loop for ever

[timeless]

Sounds like what you really want is an audio/video stiching api so
that you could concatenate a second sound track and achieve a smooth
transition.

On 10/23/08, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Oct 14, 2008, at 5:40 PM, Ian Hickson wrote:
>
>>
>> There is no way to say "loop forever" right now primarily because
>> doing so
>> would mean complicating the syntax of the playcount attribute to be
>> not
>> just a number. You can work around it with script (just add
>> onended="currentTime=0" to the  element).
>
> This would lead to perceptible glitches in looped audio, compared to
> being able to represent the looping to the media framework.
>
>> 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.
>
> For example: I think looped audio would be a common thing for games to
> want to do, and they wouldn't want it to glitch when it loops.
>
> Regards,
> Maciej
>
>

-- 
Sent from Gmail for mobile | mobile.google.com