Re: [whatwg] focus change inside keypress event handler

[Michael A. Puls II]

On Mon, 08 Mar 2010 20:17:45 -0500, Ian Hickson  wrote:


On Tue, 27 Oct 2009, Michael A. Puls II wrote:


With:



, if you type a character in the first field, should the character be  
entered

in the second field or the first?


The thread that started with the above question seemed to conclude that
the DOM3 Events spec requires that the focus change not affect which
element receives the event, which is also my understanding of the
situation. The thread did not seem to suggest any further changes were
needed, so I haven't changed anything in HTML5. Please let me know if
there is something in HTML5 that needs changing for this.

Cheers,


Still waiting for Doug and others to comment on my findings in this  
thread. But, yes, nothing to change in the spec so far.


--
Michael

Re: [whatwg] Fullscreen for HTML5 Video element

[Remco]

On Tue, Mar 9, 2010 at 02:46, David Singer  wrote:
> Kiosks and the like fall into the category where the user agent, hardware 
> platform, and so on, are known in advance, so proprietary extensions or other 
> special methods work just fine.

Until you find out that you can't change the infrastructure because
you would need to rewrite the application. You don't want to end up
with another IE6: an ancient application that you can't get rid of
because all intranet applications would break.

-- 
Remco

Re: [whatwg] Fullscreen for HTML5 Video element

[David Singer]

Kiosks and the like fall into the category where the user agent, hardware 
platform, and so on, are known in advance, so proprietary extensions or other 
special methods work just fine.

On Mar 9, 2010, at 6:04 , Silvia Pfeiffer wrote:

> On Tue, Mar 9, 2010 at 2:42 AM, Nils Dagsson Moskopp
>  wrote:
>> Dawid Czyzewski  schrieb am Mon, 8 Mar 2010
>> 16:05:00 +0100:
>> 
>>> Full screen custom UI is very needed feature and it's need to be
>>> solved somehow. Specially in times here HD video show up on Internet.
>> 
>> This seems to be a presentational issue. Maybe that is a use case better
>> solved with CSS media types or media queries.
> 
> In what situations would we want automatic full-screen video? I can
> think of Kiosks, or where a Web browser is used for watching TV. Is
> this really something we can express through media queries?
> 
> Cheers,
> Silvia.

David Singer
Multimedia and Software Standards, Apple Inc.

Re: [whatwg] rp is a styling tag and has no semantic function

[Ian Hickson]

On Wed, 28 Oct 2009, Nikita Popov wrote:
>
> In the spec the use of the rp-tag is shown like this:
> 
> 
> 漢 (かん)
> 字 (じ)
> 
> 
> What semantic function has the rp-tag? No. It is only styling for browsers not
> supporting ruby-text.
> So I think this element musn't be in the HTML5 spec. You can add the brackets
> before and after the ruby text using CSS pseudoclasses (:after, :before).

What about when the legacy browser doesn't support CSS?


On Fri, 30 Oct 2009, Nikita Popov wrote:
>
> How should a screen-reader actually handle ruby annotations? In this 
> case
>
> 
> ��   
> ��   
> 
>
> it would be quite strange if a screen-reader read the annotations, 
> because they have the same content as the ruby base text. (I hope this 
> is correct. I don't know the Japanese language, but I understood it as 
> �� beeing same as  only in a different "way" of writing.) So the 
> reader must not read the annotation.

Exactly how ruby annotations are rendered is UA-defined.


> In an example i got from an older W3C spec, it's different:
> 
> 
>   
> 10
> 31
> 2002
>   
>   
> Month
> Day
> Year
>   
>   
> Expiration Date
>   
> 
> 
> As this markup isn't used anymore with HTML5, here's how it would be
> (dropping the "expiration date"):
>
> 
> 10 Month
> 31 Day
> 2002 Year
> 
>
> This one now should be read out by the screen-reader. Otherwise the
> meaning of the numbers may be not as clear.
> 
> (Or is the date-example out-of-date and ruby shouldn't be used there?)

In both cases, I would personally expect a speech UA to indicate to the 
user that annotations are available, without immediately rendering them. 
However, I'm no expert on the matter!


On Fri, 30 Oct 2009, Futomi Hatano wrote:
> 
> More correctly, screen-readers should read only the contents of  rather 
> than the base text.
> That is, screen-readers are expected to read it as "ka-n-ji" from s.
>
> [quoting the date example above]
> 
> I think that  of HTML5 is not appropriate for the case.
> According to the HTML5 spec,  is "primarily used in East Asian 
> typography as a guide for pronunciation or to include other annotations".
> I think that this element was not designed for the case you mentioned.
> "Ruby Annotation module for XHTML 1.1" can be used for a broad range of 
> objectives.
> But  of HTML5 is limited, I think.

As far as I can tell the problem for speech browsers exists the same in 
both variants of Ruby markup.


On Fri, 30 Oct 2009, Nikita Popov wrote:
>
> I am not sure whether it is as easy. Please consider this one:
> 
> char pron 1
> another char pron 2 pron 3
> and some other text without a ruby annotation.
> 
> If a screen-reader now only would read the ruby-annotations, it would
> sound like this: "pron 1 pron 2 pron 3" and the rest of the text
> wouldn't be read.

On Sat, 31 Oct 2009, Futomi Hatano wrote:
> 
> The text without a ruby annotation should not be in .
> It should be marked up like this:
> 
> 
> char pron 1
> another char pron 2 pron 3
> 
> and some other text without a ruby annotation.

On Sat, 31 Oct 2009, Nikita Popov wrote:
>
> Yes, that's right. But there are always people not as strict. I think
> some ninety-nine percent of websites aren't valid an even less semantic.
> HTML5 mustn't be planed only for the exemplary developers but for the
> standard-user, too.

On Sun, 1 Nov 2009, Futomi Hatano wrote:
> 
> Do you think that HTML5 should support bad markups? I don't think so.

Supporting "bad markups" seems to be a losing proposition, since we'd 
never be able to rely on any of the markup to determine how to render it.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] focus change inside keypress event handler

[Ian Hickson]

On Tue, 27 Oct 2009, Michael A. Puls II wrote:
> 
> With:
> 
> 
> 
> , if you type a character in the first field, should the character be entered
> in the second field or the first?

The thread that started with the above question seemed to conclude that 
the DOM3 Events spec requires that the focus change not affect which 
element receives the event, which is also my understanding of the 
situation. The thread did not seem to suggest any further changes were 
needed, so I haven't changed anything in HTML5. Please let me know if 
there is something in HTML5 that needs changing for this.

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] HTML Cookie API

[Ian Hickson]

On Tue, 23 Feb 2010, Adam Barth wrote:
>
> The document.cookie API is kind of terrible.  Web developers shouldn't 
> have to parse a cookie-string or prepare a properly formated 
> set-cookie-string.  Here's a proposal for an HTML cookie API that isn't 
> as terrible:
> 
> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
> 
> I'd like to propose we include this API in a future version of HTML. As 
> always, feedback welcome.

The incremental benefit of this seems pretty minimal, considering that 
there are widely available libraries that provide better APIs for cookies 
already, especially since as I understand it we want to move people off 
cookies where possible. This is quite a lot of surface area (meaning 
implementation cost, testing cost, potential bugs, tutorial costs, etc), 
and introduces quite a lot of authoring complexity (e.g. having to do 
everything asynchronously), for such a minimal incremental benefit 
(responsiveness and not having to use a library once this is widely 
deployed in the browsers you care about).

All things considered, I think we should probably wait until we have 
addressed more fundamental problems with the platform before adding 
something like this.

Having said that, if browser vendors think this is something worth 
implementing today, then the above is a pretty good stand-alone spec. It 
would be reasonable IMHO for this API to be specified separately, e.g. 
through the Web Apps WG.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Ian Hickson]

On Mon, 7 Dec 2009, Nicholas Zakas wrote:
> 
> [...] I found that there are several instances where the browser will 
> make a second [request] to the page based on resolving empty-string URLs 
> in the several tags.

On Mon, 7 Dec 2009, Aryeh Gregor wrote:
> 
> This is clearly not a good idea for , since otherwise  src=""> is an instant infinite loop on a typical page.

On Tue, 15 Dec 2009, Nicholas Zakas wrote:
>
> Here's what I would propose:
> 
> Empty string attributes for HTML elements specifying resources to 
> automatically download are considered invalid and don't cause a request 
> to be sent.

On Tue, 15 Dec 2009, Jonas Sicking wrote:
> 
> I'd prefer to explicitly enumerate the elements we're talking about,
> rather than giving rules which risk being interpreted differently by
> different people. [...]
> 
> So the specific list would then be:
> 
> 
> 
> 

Re: [whatwg] Fullscreen for HTML5 Video element

[Silvia Pfeiffer]

On Tue, Mar 9, 2010 at 2:42 AM, Nils Dagsson Moskopp
 wrote:
> Dawid Czyzewski  schrieb am Mon, 8 Mar 2010
> 16:05:00 +0100:
>
>> Full screen custom UI is very needed feature and it's need to be
>> solved somehow. Specially in times here HD video show up on Internet.
>
> This seems to be a presentational issue. Maybe that is a use case better
> solved with CSS media types or media queries.

In what situations would we want automatic full-screen video? I can
think of Kiosks, or where a Web browser is used for watching TV. Is
this really something we can express through media queries?

Cheers,
Silvia.

Re: [whatwg] Fullscreen for HTML5 Video element

[Nils Dagsson Moskopp]

Dawid Czyzewski  schrieb am Mon, 8 Mar 2010
16:05:00 +0100:

> Full screen custom UI is very needed feature and it's need to be
> solved somehow. Specially in times here HD video show up on Internet.

This seems to be a presentational issue. Maybe that is a use case better
solved with CSS media types or media queries.

-- 
Nils Dagsson Moskopp // erlehmann



signature.asc
Description: PGP signature

Re: [whatwg] Fullscreen for HTML5 Video element

[Dawid Czyzewski]

Hmmm, why not tell script that user toggle full screen (via browser internal
UI) and it need to setup UI for it? This is only solution i see, but i
suppose this would require to create tools to make custom UI on full
screen

Full screen custom UI is very needed feature and it's need to be solved
somehow. Specially in times here HD video show up on Internet.

Re: [whatwg] Fullscreen for HTML5 Video element

[Ashley Sheridan]

On Mon, 2010-03-08 at 13:31 +, Tim Hutt wrote:

> On 8 March 2010 13:16, Nils Dagsson Moskopp
>  wrote:
> > Tim Hutt  schrieb am Mon, 8 Mar 2010 12:48:30 +:
> >
> >> 2010/3/8 Ashley Sheridan 
> >> > Also, I've never seen anything built in Flash that started up in
> >> > full-screen mode automatically. I had to trigger it explicitly
> >> > every time by an action from me.
> >>
> >> That was his point - despite the fact that it *can* be done in flash,
> >> it isn't. Hence the argument in the spec is invalid.
> >
> > I doubt anyone thought about annoying advertisments immediately when
> > popup technology came around. Still, popup blocking is widespread today.
> 
> Yes that's exactly the point Gallantmon was trying to make. The popup
> API was created, people abused it, hence pop-up blockers. However, we
> have already seen that since the creation of flash's full-screen API,
> people haven't abused it. So there's no real argument for not
> including it in HTML5 video.
> 
> You might say "But people might abuse it in the future and then we'd
> be stuck with it!!", but this isn't correct. Whereas we are somewhat
> stuck with popups, with HTML5 video you could always disable the API
> via a preference, and still access full-screen manually via the
> context menu.
> 
> >> I don't really see what's wrong with having an API for fullscreen. If
> >> they want, user agents could have a preference to disable the
> >> full-screen API if people ever start doing annoying things.
> >
> > I don't really see what is wrong with not having an API. Users could
> > still use UA facilities, like they do now to have a web page display in
> > full screen mode.
> 
> Yeah I don't think it is critical. I assume it is wanted so web sites
> (e.g. youtube) can display custom full-screen buttons.


Perhaps having the action of fullscreen triggered only by something the
user does, rather than allowing it to be done automatically. This
shouldn't be too hard to achieve, as browsers have been doing this for
ages with popup windows (hence why now you see popups triggered from
every single damn click on any part of a page!)

By doing this, you could essentially have the custom controls that you
want, and the user is under less threat of being abused by automatic
full-screen video that they don't want.

Don't forget that as soon as something becomes too annoying the user
agents will make efforts to make the users lives better. Popups are not
inherently evil and I've seen them used well and effectively before, but
the abuse they suffered has led to them being a feature that cannot be
relied upon. If full-screen video in HTML 5 is to avoid being misused,
then similar safeguards need to be in place. Just saying "well, it
hasn't happened to Flash yet" isn't a good enough reason to ignore the
potential for a problem to surface.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] Fullscreen for HTML5 Video element

[Tim Hutt]

On 8 March 2010 13:16, Nils Dagsson Moskopp
 wrote:
> Tim Hutt  schrieb am Mon, 8 Mar 2010 12:48:30 +:
>
>> 2010/3/8 Ashley Sheridan 
>> > Also, I've never seen anything built in Flash that started up in
>> > full-screen mode automatically. I had to trigger it explicitly
>> > every time by an action from me.
>>
>> That was his point - despite the fact that it *can* be done in flash,
>> it isn't. Hence the argument in the spec is invalid.
>
> I doubt anyone thought about annoying advertisments immediately when
> popup technology came around. Still, popup blocking is widespread today.

Yes that's exactly the point Gallantmon was trying to make. The popup
API was created, people abused it, hence pop-up blockers. However, we
have already seen that since the creation of flash's full-screen API,
people haven't abused it. So there's no real argument for not
including it in HTML5 video.

You might say "But people might abuse it in the future and then we'd
be stuck with it!!", but this isn't correct. Whereas we are somewhat
stuck with popups, with HTML5 video you could always disable the API
via a preference, and still access full-screen manually via the
context menu.

>> I don't really see what's wrong with having an API for fullscreen. If
>> they want, user agents could have a preference to disable the
>> full-screen API if people ever start doing annoying things.
>
> I don't really see what is wrong with not having an API. Users could
> still use UA facilities, like they do now to have a web page display in
> full screen mode.

Yeah I don't think it is critical. I assume it is wanted so web sites
(e.g. youtube) can display custom full-screen buttons.

Re: [whatwg] Fullscreen for HTML5 Video element

[Nils Dagsson Moskopp]

Tim Hutt  schrieb am Mon, 8 Mar 2010 12:48:30 +:

> 2010/3/8 Ashley Sheridan 
> > Also, I've never seen anything built in Flash that started up in
> > full-screen mode automatically. I had to trigger it explicitly
> > every time by an action from me.
> 
> That was his point - despite the fact that it *can* be done in flash,
> it isn't. Hence the argument in the spec is invalid.

I doubt anyone thought about annoying advertisments immediately when
popup technology came around. Still, popup blocking is widespread today.

IMO, it is better to err on the side of caution. Such an API can always
be added later, if insurmountable obstacles to doing things the UA way
appear (I see no such hindrances today, could you elaborate).

> I don't really see what's wrong with having an API for fullscreen. If
> they want, user agents could have a preference to disable the
> full-screen API if people ever start doing annoying things.

I don't really see what is wrong with not having an API. Users could
still use UA facilities, like they do now to have a web page display in
full screen mode.

> As for the security issue, the 'Press Escape to exit fullscreen mode'
> banner works for flash.

Still, annoying. See Geolocation for an example that is handled in an
unobstrusive way by browsers.


Cheers,
-- 
Nils Dagsson Moskopp // erlehmann



signature.asc
Description: PGP signature

Re: [whatwg] Fullscreen for HTML5 Video element

[Ashley Sheridan]

On Mon, 2010-03-08 at 12:48 +, Tim Hutt wrote:

> 2010/3/8 Ashley Sheridan 
> > Also, I've never seen anything built in Flash that started up in 
> > full-screen mode automatically. I had to trigger it explicitly every time 
> > by an action from me.
> 
> That was his point - despite the fact that it *can* be done in flash,
> it isn't. Hence the argument in the spec is invalid.
> 
> I don't really see what's wrong with having an API for fullscreen. If
> they want, user agents could have a preference to disable the
> full-screen API if people ever start doing annoying things.
> 
> As for the security issue, the 'Press Escape to exit fullscreen mode'
> banner works for flash.


The banner would be a good idea, but it would depend or not if Adobe had
the copyright on that sort of thing. It sounds stupid, but I've seen a
lot worse being copyrighted before.

I think fullscreen within a simple browser window would do the trick. It
would behave in the same way that it does now if you point your browser
at a media file directly rather than at a web page that contains the
clip as a page element.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] Fullscreen for HTML5 Video element

[ニール・ゴンパ]

On Mon, Mar 8, 2010 at 6:48 AM, Tim Hutt  wrote:

> 2010/3/8 Ashley Sheridan 
> > Also, I've never seen anything built in Flash that started up in
> full-screen mode automatically. I had to trigger it explicitly every time by
> an action from me.
>
> That was his point - despite the fact that it *can* be done in flash,
> it isn't. Hence the argument in the spec is invalid.
>
> I don't really see what's wrong with having an API for fullscreen. If
> they want, user agents could have a preference to disable the
> full-screen API if people ever start doing annoying things.
>
> As for the security issue, the 'Press Escape to exit fullscreen mode'
> banner works for flash.
>

And if you're really paranoid, an option could be available in the browser
to disable having videos start up in fullscreen mode automatically, even if
there is an API to do it. Flash certainly doesn't offer that. By not
offering a standard way to handle full screen videos, it gives a reason to
NOT use HTML 5 video over Flash or Silverlight. That's not what we want.

Re: [whatwg] Fullscreen for HTML5 Video element

[Tim Hutt]

2010/3/8 Ashley Sheridan 
> Also, I've never seen anything built in Flash that started up in full-screen 
> mode automatically. I had to trigger it explicitly every time by an action 
> from me.

That was his point - despite the fact that it *can* be done in flash,
it isn't. Hence the argument in the spec is invalid.

I don't really see what's wrong with having an API for fullscreen. If
they want, user agents could have a preference to disable the
full-screen API if people ever start doing annoying things.

As for the security issue, the 'Press Escape to exit fullscreen mode'
banner works for flash.

Re: [whatwg] Fullscreen for HTML5 Video element

[Ashley Sheridan]

On Mon, 2010-03-08 at 06:24 -0600, Sir Gallantmon (ニール・ゴンパ)
wrote:
> On Mon, Mar 8, 2010 at 4:40 AM, Ashley Sheridan
>  wrote:
> 
> 
> On Mon, 2010-03-08 at 14:35 +0530, balachandar muruganantham
> wrote:
> 
> > Hi,
> > 
> > I have heard from people that there have been a discussion
> > on supporting the fullscreen mode for HTML5 video element.
> > can anyone share the information on the conclusion we
> > arrived at? i searched in the archive but i could not come
> > to any conclusion. 
> > 
> > -bala
> > 
> 
> 
> 
> 
> Not according to the spec:
> 
> "User agents should not provide a public API to cause videos
> to be shown full-screen. A script, combined with a carefully
> crafted video file, could trick the user into thinking a
> system-modal dialog had been shown, and prompt the user for a
> password. There is also the danger of "mere" annoyance, with
> pages launching full-screen videos when links are clicked or
> pages navigated. Instead, user-agent-specific interface
> features may be provided to easily allow the user to obtain a
> full-screen playback mode"
> 
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
> 
> 
> 
> 
> I don't know if I completely agree with that. If that were the case,
> people would have done it with Flash years ago. Flash can be started
> in full screen mode, and yet nobody's done it


Flash is a plugin whose display is outside of the browser, which is why
there's been countless problems over the years with it stealing browser
focus, appearing over the top of page elements, etc.

Also, I've never seen anything built in Flash that started up in
full-screen mode automatically. I had to trigger it explicitly every
time by an action from me.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] Fullscreen for HTML5 Video element

[ニール・ゴンパ]

On Mon, Mar 8, 2010 at 4:40 AM, Ashley Sheridan 
wrote:

>  On Mon, 2010-03-08 at 14:35 +0530, balachandar muruganantham wrote:
>
> Hi,
>
> I have heard from people that there have been a discussion on supporting
> the fullscreen mode for HTML5 video element. can anyone share the
> information on the conclusion we arrived at? i searched in the archive but i
> could not come to any conclusion.
>
> -bala
>
>
> Not according to the spec:
>
> "User agents should not provide a public API to cause videos to be shown
> full-screen. A script, combined with a carefully crafted video file, could
> trick the user into thinking a system-modal dialog had been shown, and
> prompt the user for a password. There is also the danger of "mere"
> annoyance, with pages launching full-screen videos when links are clicked or
> pages navigated. Instead, user-agent-specific interface features may be
> provided to easily allow the user to obtain a full-screen playback mode"
>
>   Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>   I don't know if I completely agree with that. If that were the case,
people would have done it with Flash years ago. Flash can be started in full
screen mode, and yet nobody's done it

Re: [whatwg] Fullscreen for HTML5 Video element

[Ashley Sheridan]

On Mon, 2010-03-08 at 14:35 +0530, balachandar muruganantham wrote:

> Hi,
> 
> I have heard from people that there have been a discussion on
> supporting the fullscreen mode for HTML5 video element. can anyone
> share the information on the conclusion we arrived at? i searched in
> the archive but i could not come to any conclusion. 
> 
> -bala
> 


Not according to the spec:

"User agents should not provide a public API to cause videos to be shown
full-screen. A script, combined with a carefully crafted video file,
could trick the user into thinking a system-modal dialog had been shown,
and prompt the user for a password. There is also the danger of "mere"
annoyance, with pages launching full-screen videos when links are
clicked or pages navigated. Instead, user-agent-specific interface
features may be provided to easily allow the user to obtain a
full-screen playback mode"

Thanks,
Ash
http://www.ashleysheridan.co.uk

[whatwg] Fullscreen for HTML5 Video element

[balachandar muruganantham]

Hi,

I have heard from people that there have been a discussion on supporting the
fullscreen mode for HTML5 video element. can anyone share the information on
the conclusion we arrived at? i searched in the archive but i could not come
to any conclusion.

-bala