Re: [whatwg] Fullscreen revision I
Sorry for the late reply. Getting to and from TPAC and TPAC itself is basically the reason. I hope you understand. On Wed, 26 Oct 2011 04:06:28 +0200, Robert O'Callahan rob...@ocallahan.org wrote: When you say No longer any attempts at integrating with F11 fullscreen, do you mean to rule out the possibility that UAs do that? E.g., would you allow UAs to have UI that makes the current document fullscreen and sets the fullscreen element to the root element? If UAs want to implement such UI I think that should be fine. However today F11 allows for navigation and such, which this mode does not. About your nested-fullscreen proposal, I do not see how To fix the nested cases, I suggest having a per-document stack of fullscreen elements instead of a single fullscreen element. [...] combines with 2.2 Pop the top element off D's fullscreen element stack until the stack is empty or the element at the top of stack is in D as supposedly everything on D's stack would be in D. Should D.exitFullscreen not just pop one of D's stack and if that stack is empty at that point also clear any descendant document stacks? The only tricky thing there might be order (of events). E.g. if you have a descendant B which has two descendants each with a fullscreen element. I guess you can do them based on the stack order of B. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] video and audio tags need to have volume attribute.
I know that it's possible to manipulate the volume attribute with javascript. Many internet forums allow HTML tags but prohibit javascripts, however. If I was able to set the initial volume with volume attribute of those tags, I would be able to set the volume without javascript.
[whatwg] Fullscreen CSS
I have removed background:black as the way the rendering is defined at the moment is that it cannot be overridden unless !important is used. That's not ideal for backgrounds. Since no color was defined that did not help either. I added margin:0; box-sizing:border-box so the height/width declarations make sense. I also added transition:none to :fullscreen-ancestor per the comment that was present in the draft. Latest draft: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#rendering -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen CSS
On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
Having the rest of the page visible under the fullscreen element is not
expected and I think we should default to avoiding it. background:black
seemed like the right thing for video and a reasonable default for other
kinds of element. Maybe the background:black rule could be at the UA
not-important level?
Glenn Maynard wrote:
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense, but it
doesn't seem right in general.
That's a reasonable point but I'm not sure how to solve it. Making other
page content visible behind divhello/div (which would happen if we just
remove the background rule) is just as unexpected, maybe more so.
Brainstorming:
-- Maybe we could create a new CSS color meaning the document background
color (including the fallback color used when the viewport background is
nominally 'transparent') and use that here?
-- Try a rule :fullscreen-ancestor
:not(:fullscreen-ancestor):not(:fullscreen) { display:none; }? Or
opacity:0?
I really want to avoid solutions that require magical new CSS behaviors.
I think video:fullscreen { background:black; } seems like a good idea in
any case.
Rob
--
If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us. [1 John
1:8-10]
Re: [whatwg] Fullscreen revision I
On Tue, Nov 15, 2011 at 1:27 AM, Anne van Kesteren ann...@opera.com wrote: Sorry for the late reply. Getting to and from TPAC and TPAC itself is basically the reason. I hope you understand. Yeah no worries mate. About your nested-fullscreen proposal, I do not see how To fix the nested cases, I suggest having a per-document stack of fullscreen elements instead of a single fullscreen element. [...] combines with 2.2 Pop the top element off D's fullscreen element stack until the stack is empty or the element at the top of stack is in D as supposedly everything on D's stack would be in D. The element could have been removed from the document while on the stack. (Apart from ensuring that the fullscreen element is always in the document, this clause ensures that adding elements to a fullscreen stack can't cause elements to be leaked. If the fullscreen stack is the only reference to the element, it must not be in the document, in which case an implementation can remove it from the stack early since step 2.2 would skip over it anyway.) Should D.exitFullscreen not just pop one of D's stack and if that stack is empty at that point also clear any descendant document stacks? That's what I suggested, if elements aren't removed from the document while on the stack. (Of course, if the stack is empty you may also need to pop the stack in the containing document as described in step 2.4.) Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Fullscreen CSS
On Mon, Nov 14, 2011 at 12:54 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
Having the rest of the page visible under the fullscreen element is not
expected and I think we should default to avoiding it. background:black
seemed like the right thing for video and a reasonable default for other
kinds of element. Maybe the background:black rule could be at the UA
not-important level?
Glenn Maynard wrote:
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense, but it
doesn't seem right in general.
That's a reasonable point but I'm not sure how to solve it. Making other
page content visible behind divhello/div (which would happen if we just
remove the background rule) is just as unexpected, maybe more so.
Brainstorming:
-- Maybe we could create a new CSS color meaning the document background
color (including the fallback color used when the viewport background is
nominally 'transparent') and use that here?
-- Try a rule :fullscreen-ancestor
:not(:fullscreen-ancestor):not(:fullscreen) { display:none; }? Or
opacity:0?
I really want to avoid solutions that require magical new CSS behaviors.
I think video:fullscreen { background:black; } seems like a good idea in
any case.
I think we should go the route that the dialog element did in Ted's
change proposal and have a pseudo-element that gets created when an
element is fullscreened. Simple and easy, and trivial for the author
to manipulate to get most effects they could want.
~TJ
Re: [whatwg] Fullscreen revision I
One problem with the existing implementation in WebKit of fullscreen is that it is possible to focus with Tab elements that are not contained within the fullscreened element. This is a problem for assistive devices in particular. Perhaps we should specify that elements outside the fullscreened subtree should be unfocusable?
Re: [whatwg] Fullscreen CSS
On Mon, 14 Nov 2011 21:25:38 +0100, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 1:38 AM, Anne van Kesteren ann...@opera.com wrote: I have removed background:black as the way the rendering is defined at the moment is that it cannot be overridden unless !important is used. That's not ideal for backgrounds. Can you elaborate on this? Currently we define a specific place in the cascading order for the style rules that currently does not exist. Just before author important basically. I suppose we could put background:black accompanied by color:white in the normal cascading order for user agent style sheets so people could override it easily (and would not make us remove existing backgrounds). Having the rest of the page visible under the fullscreen element is not expected and I think we should default to avoiding it. That seems fair. background:black seemed like the right thing for video and a reasonable default for other kinds of element. Maybe the background:black rule could be at the UA not-important level? UA does not have an important level. But yes, we could do that. But we should include a rule for the color property too. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen CSS
On 11/15/11 11:25 AM, Anne van Kesteren wrote: UA does not have an important level. In Gecko it actually does: it's a level that overrides the user important level. Such a level is sort of needed in some cases, no matter what you actually choose to call it. -Boris
Re: [whatwg] Fullscreen revision I
On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp jere...@chromium.orgwrote: One problem with the existing implementation in WebKit of fullscreen is that it is possible to focus with Tab elements that are not contained within the fullscreened element. This is a problem for assistive devices in particular. Perhaps we should specify that elements outside the fullscreened subtree should be unfocusable? The display:none rule would achieve that. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Fullscreen revision I
On Tue, Nov 15, 2011 at 9:59 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp jere...@chromium.orgwrote: One problem with the existing implementation in WebKit of fullscreen is that it is possible to focus with Tab elements that are not contained within the fullscreened element. This is a problem for assistive devices in particular. Perhaps we should specify that elements outside the fullscreened subtree should be unfocusable? The display:none rule would achieve that. I can't find any references to display:none on http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html. Is that not the most recent revision of the spec?
Re: [whatwg] Fullscreen CSS
On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes --- specially, at least one new rule for CSS stacking contexts in the infamous appendix E. Also, it doesn't address situations where an ancestor of the dialog or fullscreen element has 'opacity', 'transform', 'filter', 'mask' or 'clip-path' (and maybe other things I've forgotten). I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it we need. And figure out what happens if you make part of a page fullscreen and that uses dialog. Or if you have nested dialogs mixed with fullscreen... Hmm. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Fullscreen CSS
On Mon, Nov 14, 2011 at 3:10 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes --- specially, at least one new rule for CSS stacking contexts in the infamous appendix E. Also, it doesn't address situations where an ancestor of the dialog or fullscreen element has 'opacity', 'transform', 'filter', 'mask' or 'clip-path' (and maybe other things I've forgotten). Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it we need. And figure out what happens if you make part of a page fullscreen and that uses dialog. Or if you have nested dialogs mixed with fullscreen... Hmm. Yes, we should give some thought to how these combine. ~TJ
Re: [whatwg] Fullscreen CSS
On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. The CP says The dialog and its cover, taken together, are siblings within a new stacking context which is placed above all other stacking contexts. This seems like something new in CSS. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
[whatwg] HTML5 video seeking
Hi, I was looking at the seeking algorithmhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#seeking and had a question about step 10. 10. Wait until the user agent has established whether or not the media data for the new playback position is available, and, if it is, until it has decoded enough data to play back that position. Does this mean the user agent must resume playback at the exact location specified? What if the nearest keyframe is several seconds away? Is the UA expected to decode and toss the frames instead of starting playback at the nearest keyframe? On desktop machines I don't think this would be a problem, but on mobile devices it might be since the hardware may not be able to decode significantly faster than realtime. What is the intended behavior for such constrained devices? Aaron
Re: [whatwg] HTML5 video seeking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/11/11 03:49 PM, Aaron Colwell wrote: Does this mean the user agent must resume playback at the exact location specified? Maybe you can muck with the 'media.seekable' TimeRanges object to only show keyframes? Otherwise, it kind of sounds like you're supposed to start playback at the requested position. The final paragraph of that section suggests another out: you can reposition the playback head inside the playback engine as long as you clip to media.seekable and fire the timeupdate and seeked events. -r -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOwasKAAoJEEcAD3uxRB3vOqkH/0QFNAiOir+EOgZaAhZmhoub xr0CThlwEIHUoo6TbDHJmqPRaiKVu9hobkf7DScG2yhjUDaT2vTptF2Wg+lgI2LE pRdjSUi0hArKrNmC8zCV+zG/82yE0l+RlBXOLjLPKXBo0PDqovXKbOknlnv68/P7 0vyhB9t7L8zLhDCL0BEbuF5OoikpW1Zt9iru+ThbY+bU7RTCFSvE0MmnqMAB3MOx 7HOa2liovoeUotoFVEpDMnD5ZbSxbmifax0CRRdcb9u4m/7HG4EaVoK9GOjxmGzA zqCtVZ7Yb+hoAPQIXP4tqsrgM9ma/U0LKgYj1lQMjD4whyp96X+iv/vNuxvVRh8= =tort -END PGP SIGNATURE-
Re: [whatwg] HTML5 video seeking
On Tue, 15 Nov 2011 00:49:32 +0100, Aaron Colwell acolw...@chromium.org wrote: Hi, I was looking at the seeking algorithmhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#seeking and had a question about step 10. 10. Wait until the user agent has established whether or not the media data for the new playback position is available, and, if it is, until it has decoded enough data to play back that position. Does this mean the user agent must resume playback at the exact location specified? What if the nearest keyframe is several seconds away? Is the UA expected to decode and toss the frames instead of starting playback at the nearest keyframe? On desktop machines I don't think this would be a problem, but on mobile devices it might be since the hardware may not be able to decode significantly faster than realtime. What is the intended behavior for such constrained devices? Aaron I believe this is a quality of implementation issue. -- Simon Pieters Opera Software
Re: [whatwg] Fullscreen CSS
On Mon, Nov 14, 2011 at 3:46 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. The CP says The dialog and its cover, taken together, are siblings within a new stacking context which is placed above all other stacking contexts. This seems like something new in CSS. Oh, whoops, indeed. Sorry about that, I forgot the CP worked like that. Yeah, I guess we *would* need some changes to the stacking algorithm. :/ Some thought needs to go into how much of this should be expressed in author-usable CSS and how much should be magic. ~TJ
Re: [whatwg] Fullscreen revision I
On Tue, Nov 15, 2011 at 12:06 PM, Jeremy Apthorp jere...@chromium.orgwrote: On Tue, Nov 15, 2011 at 9:59 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp jere...@chromium.orgwrote: One problem with the existing implementation in WebKit of fullscreen is that it is possible to focus with Tab elements that are not contained within the fullscreened element. This is a problem for assistive devices in particular. Perhaps we should specify that elements outside the fullscreened subtree should be unfocusable? The display:none rule would achieve that. I can't find any references to display:none on http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html. Is that not the most recent revision of the spec? It's something I just made up in the other WHATWG thread :-) Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
