| 00:01 | <annevk> | btw |
| 00:01 | <annevk> | fullscreendeny, would that fire async too? |
| 00:02 | <cpearce> | I think it should match fullscreenchange, so yes. |
| 00:03 | <annevk> | do we use "deny" elsewhere in the platform? |
| 00:03 | <annevk> | could make it fullscreenerror I suppose... meh |
| 00:05 | <cpearce> | fullscreendenied matches tense with fullscreenchanged, and matches tense with the events fired in the video spec, many of which are past tense. I don't really know the other HTML specs. |
| 00:06 | <annevk> | well "changed" is going to become "change" |
| 00:07 | <annevk> | we have hashchange for instance |
| 00:08 | <cpearce> | I think it makes sense for it to be past tense if it's dispatched async. |
| 00:10 | <AryehGregor> | hashchange is surely dispatched async. |
| 00:11 | <annevk> | generally events do not use past tense |
| 00:11 | <annevk> | there's a couple for which it was a mistake |
| 00:12 | <annevk> | but we have volumechange, durationchange, ratechange |
| 00:12 | <Hixie> | hashchange is fired synchronously from within a task that is itself async |
| 00:14 | <cpearce> | argh, what am I saying, our implementation already dispatches mozfullscreenchange, not *changed. :P |
| 00:14 | <annevk> | Hixie, can you dispatch events on documents that are not the active document? |
| 00:14 | <cpearce> | I do think it sounds funny having a fullscreendeny event though. |
| 00:15 | <Hixie> | annevk: well |
| 00:15 | <annevk> | fullscreenerror might be somewhat better |
| 00:15 | <cpearce> | well, it's not really an error though. |
| 00:15 | <Hixie> | annevk: you mean using that document as the context? you can, but the task would just sit in the queue until it became active |
| 00:15 | <annevk> | okay |
| 00:15 | <Hixie> | i would avoid it where possible though |
| 00:16 | <Hixie> | since the doc could get discarded any minute anyway |
| 00:16 | <annevk> | Hixie, if you remove an <iframe> from a document does that <iframe>'s document become inactive? |
| 00:17 | <Hixie> | this part of the spec is a little controversial, but: |
| 00:17 | <annevk> | cpearce, if you navigate a child browsing context that has a fullscreen element in it, and then navigate back, is it still the fullscreen element? |
| 00:17 | <Hixie> | annevk: it is "active" but not "fully active" |
| 00:18 | <annevk> | okay |
| 00:18 | <Hixie> | annevk: it stops getting events and stuff though, iirc |
| 00:18 | <cpearce> | annevk: We should exit full-screen mode when a full-screen document navigates. |
| 00:19 | <Hixie> | annevk: (because the event loop only takes tasks for docs that are fully active) |
| 00:20 | <annevk> | cpearce, the top-level browsing context? |
| 00:20 | <annevk> | Hixie, thanks |
| 00:21 | <cpearce> | annevk: If we navigate a non-full-screen child iframe and the parent is full-screen, there's no need to break out of full-screen. |
| 00:21 | <annevk> | cpearce, right |
| 00:22 | <annevk> | cpearce, but what if you navigate a child frame that contains a fullscreen element? |
| 00:22 | <annevk> | I mean the top-level browsing context will still have a fullscreen element in that case too |
| 00:23 | <cpearce> | annevk: It seems that if a document has a full-screen element, it must be full-screen? So since it's full-screen we should exit full-screen mode? |
| 00:24 | <smaug____> | annevk: how does "fullscreendeny"/"...error" solve the problem that it may take arbitrary amount time for user to decide whether to allow the fullscreen mode |
| 00:24 | <annevk> | your use of fullscreen confuses me, do you mean exit it for that document only or the whole top-level-browsing context? |
| 00:25 | <cpearce> | smaug: we use a ask forgiveness model now, so the decision to deny can be made synchronously. |
| 00:25 | <smaug____> | ? |
| 00:25 | <cpearce> | annevk: If we exit for one, we exit for all. |
| 00:25 | <smaug____> | user many not allow or deny |
| 00:25 | <smaug____> | user may just be slow to say anything |
| 00:26 | <zewt> | i notify in advance that i will not forgive any browser vendor that lets pages show fullscreen ads at me |
| 00:26 | <annevk> | cpearce, okay |
| 00:26 | <cpearce> | smaug: I mean, *we* don't have UI which requires the user to approve requests for full-screen, we just go full-screen and give them the option to exit. I guess though you're concerned about vendors which do want to implement an approval UI... |
| 00:27 | <smaug____> | that is no-go |
| 00:27 | <smaug____> | I'm pretty sure vendors don't want to implement such thing |
| 00:27 | <zewt> | (pretty disconcerting that it seems nobody but me seems to care if pages are allowed to show fullscreen ads) |
| 00:28 | <smaug____> | going to fullscreen *must* ask permission |
| 00:28 | <smaug____> | (or the permission can be given beforehand) |
| 00:28 | <cpearce> | if you put ads in an iframe they won't be able to go full-screen unless there's a fullscreenallowed attribute on the iframe. |
| 00:28 | <zewt> | smaug____: but from what i've heard, both FF and Chrome intend to go fullscreen without asking (and then asking after it's too late) ... |
| 00:28 | <smaug____> | uh |
| 00:29 | <smaug____> | that sure hasn't been security reviewed |
| 00:29 | <zewt> | which i find horrifying |
| 00:29 | <smaug____> | it sounds absolute horrifying |
| 00:29 | <cpearce> | That has. We show a bug warning to make it obvious you've gone fullscreen. |
| 00:29 | <zewt> | i don't want a big, obnoxious warning every time i go fullscreen (like Flash does), that's also bad |
| 00:29 | <gsnedders> | IMO Flash's behaviour is fine. |
| 00:30 | <zewt> | and ... again, that doesn't solve the problem that it's letting pages go fullscreen to show ads (asking after is *too late* then) |
| 00:30 | <zewt> | (it's already shoved a gigantic ad in my face) |
| 00:30 | <gsnedders> | To go full-screen, the change must either happen as a result of a user initiated action, or must be confirmed by the user, IMO. |
| 00:30 | <smaug____> | cpearce: what is the reason to allow web page to do such a major change to the UI without asking user's permission? |
| 00:31 | <gsnedders> | Which addresses all the major uses of Flash full-screen I can think of. |
| 00:31 | <cpearce> | right, the fullscreen request is only granted in user initiated action. |
| 00:31 | <zewt> | gsnedders: both of those are still intending to require it to be within a click/keypress, but that doesn't solve these problems |
| 00:31 | <cpearce> | So permission is implicit. |
| 00:31 | <zewt> | uh |
| 00:31 | gsnedders | is rather out-of-touch of all of this stuff, though |
| 00:31 | <zewt> | sorry, "implicit permission" doesn't make sense, heh |
| 00:32 | <gsnedders> | zewt: If it's harder to do than in Flash, people will keep using Flash for stuff like full-screen video. |
| 00:32 | <smaug____> | clicking something on the page is not the same as giving permission |
| 00:32 | <gsnedders> | So we can't make it considerably harder than with Flash, IMO. |
| 00:32 | <gsnedders> | Like, a site moving to HTML for video shouldn't regress the UX. |
| 00:32 | <gsnedders> | By asking permission extra times. |
| 00:33 | <zewt> | gsnedders: importing major problems of Flash into HTML because people will continue to use Flash is a very poor rationale--there's a *reason* i use flashblock! |
| 00:33 | <zewt> | (of course, any sane UI would have the major response be "allow this, and don't ask in the future", so you usually only have to agree to it the first time) |
| 00:34 | <gsnedders> | If I press a button on YouTube to go full screen, I damn well want it to go full screen. I don't want to then have to confirm it. Even the first time. |
| 00:34 | <smaug____> | (there is a reason why I don't have Flash installed in this browser profile) |
| 00:34 | <zewt> | gsnedders: that implies pages being able to smear gigantic ads in my face without permission; so I say, too bad, live with it |
| 00:34 | <zewt> | no way that I can see of allowing one without the other |
| 00:36 | <zewt> | it's bad enough that I'm afraid to click anywhere in the window on things like image hosts, for fear that a page will use it to open a popup; this would be so much worse |
| 00:36 | <annevk> | not "too bad", if we're not competitive with the usability of Flash people will just use that |
| 00:36 | <gsnedders> | Yeah. If it's too restrictive people simply won't use it. |
| 00:37 | <smaug____> | zewt: with Chrome you can fear also that clicking anywhere in the window starts recording and sending your audio to google ;) |
| 00:37 | <zewt> | if flash lets people format the user's hard drive, we'd have to let them do that too, or they'll just keep using flash? heh |
| 00:38 | <gsnedders> | zewt: There's a rather large difference. |
| 00:38 | <zewt> | smaug____: sounds like a massive security hole |
| 00:38 | <annevk> | non-rational arguments ftw |
| 00:38 | <zewt> | gsnedders: difference of magnitude only |
| 00:38 | <annevk> | o_O |
| 00:38 | <zewt> | the idea that html has to let people do everything flash does, regardless of if that causes serious, obnoxious problems on the web, is a bad one |
| 00:38 | <smaug____> | zewt: that is Google's "clicking gives permission" -permission model |
| 00:38 | <annevk> | but that's not the idea |
| 00:39 | <zewt> | sure seems like it |
| 00:40 | <annevk> | then you haven't really been paying attention |
| 00:40 | <zewt> | non-rational arguments ftw |
| 00:41 | <zewt> | disagreeing with me doesn't mean i havn't been paying attention |
| 00:41 | <annevk> | e.g. we didn't copy the crossdomain.xml disaster |
| 00:41 | <zewt> | no, you designed something better for its use cases; you're not doing that here |
| 00:42 | <annevk> | I don't really see a better way here to be honest |
| 00:42 | <annevk> | I also hardly see the popup abuse you talk about |
| 00:43 | <annevk> | making the popular use case impossibly annoying is just not going to work |
| 00:43 | <zewt> | plenty of random sites open popups during the first click event they see, to work around the user-interaction restriction |
| 00:43 | <zewt> | (don't have one off-hand) |
| 00:44 | <zewt> | how is it "impossibly annoying"? it's the model used by geolocation |
| 00:47 | <annevk> | geolocation is infrequent, fullscreen is frequent |
| 00:47 | <zewt> | hardly infrequent if you're searching on mobile |
| 00:47 | <smaug____> | how often do you use fullscreen, I mean from different domains? |
| 00:48 | <gsnedders> | I find it annoying in the geolocation case, but I think that's partly a UI issue. |
| 00:49 | <annevk> | smaug____, pretty often I think, mostly for video, sometimes slideshows |
| 00:49 | <smaug____> | and they are really from different domains? |
| 00:50 | <zewt> | smaug____: FF6's geoloc confirmation box is sort of annoying, because you have to open a dropdown to get to the most common answer for most people (always) |
| 00:50 | gsnedders | is more than happy to try full-screen with explicit user confirmation first, but will need to watch for user feedback |
| 00:50 | <smaug____> | I would have guessed most of the fullscreen usage comes from youtube |
| 00:50 | <zewt> | three "yes"/"no"/"just this once" buttons would be nicer |
| 00:50 | <annevk> | smaug____, there's quite a bit of self-hosted video out there as well |
| 00:52 | <zewt> | i suppose also because the confirmation is "out-of-line"; at least for mouse-initiated events, it'd be nicer (at least for fullscreen buttons) if the box appeared over the button you clicked |
| 00:52 | <smaug____> | zewt: I don't recall what FF6 did. Nightly has IMO quite good UI for geolocation permission |
| 00:52 | <annevk> | cpearce, can you reply to Darin Fisher on the mailing list with Mozilla's use cases for not ignoring calls to requestFullscreen while fullscreen? |
| 00:53 | <cpearce> | sure. |
| 00:53 | <zewt> | smaug____: http://zewt.org/~glenn/ff6%20doorhanger.png |
| 00:53 | <smaug____> | zewt: seems like Nightly has that |
| 00:53 | <smaug____> | and it is IMO ok API |
| 00:54 | <smaug____> | s/API/UI/ |
| 00:54 | <zewt> | it's not bad, but could be streamlined as I said ^ |
| 00:54 | <smaug____> | you can click share, or just ignore the whole thing |
| 00:54 | <zewt> | better than a modal dialog, obviously |
| 00:55 | <smaug____> | the point is that if you don't want to share, you don't need to do anything |
| 00:55 | <smaug____> | and if you explicitly want to share always, you need to click once more |
| 00:56 | <zewt> | yeah, but again, my most common answer (always) is a clumsier two-step UI, and if that was used for confirming fullscreen, it's inconveniently way in the corner instead of near whatever fullscreen button I clicked (putting aside keyboard events) |
| 00:57 | <smaug____> | is always the most common answer? |
| 00:57 | <zewt> | i can't speak for everyone :) |
| 00:57 | <smaug____> | to me the most common answer is "I don't care", so I don't click anything |
| 00:57 | <smaug____> | and next most common answer is, "ok, allow this time" |
| 00:58 | <zewt> | for me in the fullscreen case, i'm pretty sure the only two i'd use are "always" and "no" |
| 00:59 | <zewt> | ("always" if it's a fullscreen I actually requested; "never" if it's a mysterious attempt to go fullscreen that I didn't ask for) |
| 01:07 | <Hixie> | why does opera not work on http://www.hixie.ch/tests/adhoc/dom/css/StyleSheet/002.html ? |
| 01:08 | <Hixie> | wait, IE doesn't either now |
| 01:08 | <Hixie> | aw man, what have i done now |
| 01:08 | <zewt> | Hixie: the tried and true "paste on irc" debugging technique |
| 01:10 | <Hixie> | ok IE's problem is it misteriously only finds 2 links |
| 01:10 | <Hixie> | but what's opera doing |
| 01:10 | <Hixie> | o_O |
| 01:10 | <Hixie> | opera's not running the timeout? o_O |
| 01:10 | <gsnedders> | Hixie: I wonder if the setTimeout is running not when you think it is |
| 01:11 | <Hixie> | maybe |
| 01:11 | <gsnedders> | Hixie: It's running it. After it has run the second script. |
| 01:11 | <Hixie> | how can that be |
| 01:11 | <Hixie> | it's a 100ms timeout and the third link takes 2 seconds to load |
| 01:12 | <gsnedders> | Hixie: DSE enabled? |
| 01:12 | <Hixie> | DSE? |
| 01:12 | <gsnedders> | Delayed Script Execution |
| 01:12 | <Hixie> | what is that? |
| 01:12 | <gsnedders> | opera:config#Extensions|DelayedScriptExecution |
| 01:13 | <gsnedders> | Hmm, has no effect. |
| 01:13 | <gsnedders> | Hixie: speculative parsing + some more complexity |
| 01:16 | <gsnedders> | Hixie: Are you sure Opera blocks on link elements? |
| 01:17 | <gsnedders> | Hixie: Note that behaviour is likely different between Op12 and Op11.50 |
| 01:18 | <Hixie> | yes, opera is blocking (for more than 150ms) on the link elements. |
| 01:18 | <Hixie> | but it's blocking less than 1000ms |
| 01:18 | <Hixie> | or something |
| 01:18 | <Hixie> | i can't say i understand what opera is doing |
| 01:19 | <Hixie> | oh no |
| 01:19 | <_bga> | http://www.youtube.com/watch?v=Ws6AAhTw7RA |
| 01:19 | <Hixie> | i was timing it wrong |
| 01:19 | <Hixie> | ok, opera isn't blocking at all |
| 01:19 | <Hixie> | ok that's another bug then :-) |
| 01:20 | <Hixie> | it acts like it's blocking |
| 01:20 | <Hixie> | i mean, the page takes 2 seconds to load and all |
| 01:20 | <annevk> | that you can detect it is prolly a bug |
| 01:20 | <Hixie> | i don't understand what opera's doing at all. it has all the disadvantages of blocking and none of the advantages. |
| 01:20 | <annevk> | oh |
| 01:20 | <annevk> | that does sound wrong |
| 01:22 | <gsnedders> | AFAIK it only blocks on a CSSOM call while there is a stylesheet yet to load |
| 01:23 | <gsnedders> | Or at least that's the theory |
| 01:23 | <gsnedders> | So, on the whole, I think the .sheet accesses block |
| 01:33 | <Hixie> | gsnedders: so why doesn't the script run until after parsing has finished? |
| 01:33 | <Hixie> | gsnedders: note how parsed gets set to true |
| 01:33 | <Hixie> | oh wait, i see what you're saying |
| 01:34 | <Hixie> | interesting |
| 01:34 | <Hixie> | so opera blocks the script itself |
| 01:34 | <Hixie> | huh |
| 01:35 | <annevk> | yeah, we just stop script executing until loading and parsing is done |
| 01:35 | <annevk> | execution* |
| 02:04 | <annevk> | when is Chrome going to return "" for canPlayType("video/mp4")? |
| 02:05 | <annevk> | "next couple months" in http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html for a reasonable definition of "next couple" has not really happened it seems |
| 02:05 | <annevk> | or am I missing something? |
| 02:16 | <annevk> | cpearce, so given what Hixie said earlier about inactive documents it seems not dispatching fullscreenchange on removed documents or documents navigated away from is the way to go |
| 02:18 | <cpearce> | no. we should still dispatch, so that if the document is re-added or navigated back to, it gets a notification. otherwise if we navigate back, it will still think it's in fullscreen mode. we'd need to rely on the event not being dispatched until the doc is reactivated though (if I understood that correctly that should happen?) |
| 02:19 | <cpearce> | does that make sense? |
| 02:19 | <annevk> | I guess we could do that too, but Hixie said he rather avoids it |
| 02:20 | <annevk> | cpearce, btw, for requestFullscreen if you are already fullscreen, exitFullscreen is going to do the wrong thing |
| 02:20 | <cpearce> | how so? |
| 02:21 | <annevk> | I'm on site A that embeds site B |
| 02:21 | <annevk> | site A does requestFullscreen |
| 02:21 | <annevk> | then site B does requestFullscreen |
| 02:21 | <annevk> | then site B does exitFullscreen |
| 02:21 | <annevk> | A is no longer fullscreen |
| 02:22 | <cpearce> | hmmm. true. |
| 02:23 | <annevk> | so either the entire design needs a revamp to allow for a single browsing context go in and out of fullscreen rather than a whole set or we should give up on this use case |
| 02:24 | <annevk> | I think |
| 02:31 | <cpearce> | how annoying. |
| 02:31 | <annevk> | is it easy to display a single browsing context (including descendants of course) fullscreen? |
| 02:32 | <annevk> | basically displaying fullscreen on a per-Document basis |
| 02:32 | <annevk> | that way you can have a nested stack if so desired |
| 02:33 | <annevk> | and it would definitely make the whole dispatch "fullscreenchange" everywhere stuff easier |
| 02:33 | <annevk> | since that will only affect a single document |
| 02:34 | <annevk> | also solves the potential cross-process issue |
| 02:34 | <cpearce> | Not really. then you need to pop the rendering of documents out of their rendering targets, which greatly complicates things. With the nested full-screen approach, all you need is to apply css rules, and you're there. |
| 02:37 | <annevk> | sigh |
| 02:38 | <annevk> | the other way is pretty silly too though |
| 02:38 | <annevk> | not being able to fullscreen a video while fullscreen |
| 02:45 | <cpearce> | annevk: I think we should just have exitFullScreen() exit fullscreen state on the document and all descendent documents. Then in my powerpoint/video use case, users can use the video controls to exit fullscreen on the video element but remain in fullscreen in the slide deck. The UA can and should break out of all fullscreen on ESC keypress though, where they'll call exitFullScreen() on the... |
| 02:45 | <cpearce> | ...root doc. |
| 02:46 | <cpearce> | where the UA will call exitFullScreen() on the root doc that is. Users should be absolutely sure that when they press ESC, they've exited fullscreen. |
| 02:47 | <annevk> | it should probably also set the frame element of the parent document to null or some such |
| 02:48 | <annevk> | otherwise B is still fullscreen |
| 02:48 | <annevk> | just not its embedded video (maybe) |
| 02:50 | <cpearce> | right, exitFullScreen() on the root document should reset fullscreen state (Document.fullscreenElement, Document.fullscreen) on the root document and all its descendents. So it would exit fullscreen in all documents completely. |
| 02:50 | <cpearce> | I wonder if that's going to confuse people... |
| 02:51 | <annevk> | I'm not talking about the root document |
| 02:51 | <annevk> | A embeds B |
| 02:51 | <annevk> | through <iframe> A1 |
| 02:51 | <annevk> | if B goes fullscreen A1 will become the fullscreen element of A |
| 02:52 | <annevk> | if B then invokes exitFullscreen that should be reset somehow |
| 02:54 | <cpearce> | right, I get you. I guess that should become null as you suggest, which is equivalent to making A's document fullscreen without a specific fullscreen element. |
| 02:56 | <annevk> | I think it would also make sense that requestFullscreen can only be invoked for a descendant of the current fullscreen document |
| 02:57 | <annevk> | so you only traverse in one direction |
| 02:57 | <annevk> | cpearce, should we add document.requestFullscreen? |
| 03:00 | <cpearce> | annevk: I don't think we really need document.requestFullscreen, you can just use document.body.requestFullscreen(). When I said "making A's document fullscreen..." the result is its body is displayed fullscreen, though it's not reported as the fullscreen element in Document.fullscreenElement. |
| 03:02 | <annevk> | given the current styling rules the result is most definitely not the same |
| 03:03 | <annevk> | we could of course have exitFullscreen on a descendant of the top-level browsing context make it set the fullscreen element of its parent to its parent root element |
| 03:05 | <cpearce> | how is document.body.requestFullScreen() not the same as document.requestFullScreen()? |
| 03:05 | <cpearce> | I guess document.body != root? |
| 03:05 | <annevk> | depends on how you define things |
| 03:06 | <annevk> | I'm just saying that setting A's fullscreen element to null is probably not the correct way here |
| 03:08 | <cpearce> | If we dispatch a fullscreenchange event when we change A's fullscreen element (to whatever) then A will have the opportunity to request the fullscreen element to what it meant it to be. |
| 03:09 | <cpearce> | And yeah, only granting requests for fullscreen in a descendant of the fullscreen document (if there is one) simplifies implementation. I can't really think of a case were it would be useful to grant requests from sibling/cousin documents. |
| 03:09 | <annevk> | that'll give you flickering, but I guess that's somewhat acceptable |
| 03:09 | <annevk> | for this use case you want the root element to be the fullscreen element anyway I think |
| 03:10 | <annevk> | cpearce, about the styling rules, should we have transform:none for :fullscreen-ancestor and probably disable transitions/animations? |
| 03:10 | <annevk> | cpearce, also seems like background:black needs to be complemented by color:#fff or some such |
| 03:12 | <cpearce> | annevk: not sure about transfoms etc. That's outside of my expertise. Probably worth suggesting. |
| 03:14 | <annevk> | they create stacking contexts afaik, so... |
| 03:14 | <annevk> | will discuss with roc at some point I guess |
| 03:14 | <annevk> | better sort the API side out first |
| 03:17 | <roc> | yeah we should have transform:none |
| 03:19 | <roc> | whether cancelling fullscreen on a subdocument also cancels fullscreen on the parent document is a tricky one |
| 03:20 | <roc> | we may need some per-document flag to indicate whether the document requested fullscreen |
| 03:21 | <annevk> | yeah |
| 03:21 | <annevk> | because now in the A B case above |
| 03:21 | <annevk> | if B calls requestFullscreen and then exitFullscreen |
| 03:21 | <annevk> | A would still be fullscreen |
| 03:21 | <annevk> | which is obviously wrong |
| 03:21 | <roc> | there are use-cases where it should cancel fullscreen on the parent, and use-cases where it shouldn't |
| 03:21 | <annevk> | cpearce, ^^ |
| 03:21 | <roc> | maybe if we have a per-doc flag to indicate whether it wants to be fullscreen |
| 03:21 | <annevk> | I guess we need to track which documents went fullscreen |
| 03:22 | <roc> | which is set on requestFullScreen, and cleared on exitFullScreen |
| 03:22 | <roc> | and then exitFullscreen would remove fullscreen status from all the ancestors up to and excluding the first one that has the want-fullscreen flag set |
| 03:23 | <annevk> | exitFullscreen also needs to clear all descendants |
| 03:23 | <roc> | yes ok |
| 03:23 | <annevk> | yeah that additional state is needed otherwise you get sad behavior |
| 03:23 | <Hixie> | annevk: re earlier, i'd rather avoid sending events to inactive documents if we can by arranging the api so it's not needed, but if it's needed, sobeit |
| 03:24 | <annevk> | Hixie, is it better to state "do animation async" or "spin the event loop until the animation is finished" |
| 03:24 | <annevk> | and what is the difference? |
| 03:24 | <cpearce> | roc: what element would become fullscreen when then want-fullscreen doc returns to being fullscreen? its root element? what was formerly its fullscreen eleent? |
| 03:25 | <annevk> | former fullscreen element is prolly best |
| 03:25 | <jamesr> | so you have a stack of fullscreen elements to pop out of? |
| 03:26 | <annevk> | yeah |
| 03:26 | <Hixie> | annevk: not much different. "spin the event loop" is defined as just queuing a task to continue running the algorithm :-) |
| 03:27 | <Hixie> | annevk: so it depends on whether you want stuff happening in the background or whether you want it in a task |
| 03:27 | <Hixie> | annevk: ("stuff" being anything in your algorithm other than the animation) |
| 03:28 | <annevk> | method -> state change -> non blocking animation -> events |
| 03:28 | <annevk> | is prolly the order we should have |
| 03:29 | <annevk> | not sure what should happen if requestFullscreen or exitFullscreen is invoked during the non-blocking animation |
| 03:29 | <annevk> | i guess you would get some additional events |
| 03:36 | <roc> | ugh, the idea of a stack kinda sucks |
| 03:37 | jamesr_ | dislikes stack |
| 03:38 | <roc> | what if we let each document have it's own fullscreen element, and define the concept of an effective fullscreen element, which is either the document's own fullscreen element, or the element for a fullscreen subdocument |
| 03:38 | <annevk> | alternatives: 1) not make this work 2) make it possible for a single document to go fullscreen |
| 03:39 | <roc> | jamesr_: it would be helpful if we had more feedback from Webkit people; I met two different Chrome people working on fullscreen last week yet it's Mozilla and Opera working on the spec |
| 03:39 | <annevk> | roc, darin fisher asked questions on list |
| 03:39 | <roc> | good, I'm behind |
| 03:40 | <roc> | ah, only three hours ago, I don't feel bad about that :-) |
| 03:40 | <annevk> | :) |
| 03:40 | <annevk> | how does the effective fullscreen element concept help? |
| 03:41 | <roc> | define styling in terms of it |
| 03:42 | <annevk> | oh I read it wrong |
| 03:42 | <annevk> | they could be the same right? |
| 03:42 | <roc> | they could be |
| 03:43 | <roc> | it means that if a subdocument exits fullscreen then the fullscreen element reverts to whatever the document requested |
| 03:43 | <roc> | without needing a stack |
| 03:43 | <annevk> | if a subdocument goes fullscreen does the document get a notification change? |
| 03:43 | <roc> | yes |
| 03:45 | <annevk> | it's sort of the same as a stack I guess, it's just an implementation detail |
| 03:45 | <jamesr_> | roc, the apple guys rambo'd an implementation into 5.1 as i understand it |
| 03:45 | <jamesr_> | roc, including such wonderful things like overriding offsetWidth/offsetHeight for some crazy compat hack in some scenario |
| 03:46 | <annevk> | should prolly go with "fullscreen element" and "original fullscreen element" so it's clear what fullscreenElement and :fullscreen refer to |
| 03:46 | <roc> | jamesr_: sweet |
| 03:46 | <jamesr_> | so now we're mostly trying to play catch-up. i'll try to prod the googlers involved with the chromium implementation to participate more as the opportunity arises |
| 03:50 | <annevk> | "fullscreen element", "original fullscreen element", "requestfullscreen invoked", and "fullscreen allowed" |
| 03:50 | <annevk> | is the state required I guess |
| 03:51 | <roc> | thanks |
| 03:58 | <annevk> | lunch and stuff, I'll redo my sketches from yesterday to work out this new model |
| 03:58 | <annevk> | I haven't committed anything thus far |
| 03:58 | <annevk> | on the plus side this does seem easier than the call requestFullscreen method anywhere model |
| 04:01 | <jarek-> | Hi |
| 04:01 | <jarek-> | CSS2 spec defines {nonascii} as [\240-\377] |
| 04:01 | <jarek-> | but I'm not sure what actually 240-377 range refer too |
| 04:02 | <jarek-> | this is obviously not range from ASCII table |
| 04:02 | <jarek-> | it also doesn't look like UTF |
| 04:02 | <jarek-> | s/refer/refers |
| 04:10 | <annevk> | jarek, isn't there some note explaining it? |
| 04:10 | <annevk> | jarek, so there is, which says the octal codes are Unicode |
| 04:12 | <jarek> | annevk: I see, thanks |
| 04:20 | <jarek> | so it is allowed to have signs such as ® or µ inside css ID names? |
| 04:20 | <jarek> | that's interesting |
| 04:21 | <Hixie> | what's a "css ID name"? |
| 04:21 | <Hixie> | do you mean the #foo syntax or id="foo"? |
| 04:21 | <jarek> | Hixie: e.g. #headyer® > h1 |
| 04:21 | <Hixie> | ah. well you can have anything in that, even spaces, if you escape it |
| 04:21 | <Hixie> | e.g. #\ { ... } |
| 04:22 | <Hixie> | matches elements whose id is a space |
| 04:22 | <jarek> | but id="foo®" is not allowed, right? |
| 04:22 | <Hixie> | not that that's a legal ID in HTML |
| 04:22 | <jarek> | so what's the point in allowing it in CSS idents? |
| 04:22 | <Hixie> | in HTML, id="" can take any value except one containing spaces, and except the empty string |
| 04:23 | <Hixie> | well, nothing stops someone from applying CSS to a language that uses spaces in IDs |
| 04:23 | <annevk> | once we tie CSS closer to the DOM there will be |
| 04:24 | <annevk> | but then it will still have to work |
| 04:24 | <annevk> | really going now |
| 04:24 | <Hixie> | even then someone could define a mapping |
| 07:53 | <annevk> | lunch breaks these days take a while |
| 07:53 | <annevk> | I do know a whole lot more about the component model so that's nice |
| 07:54 | <Hixie> | every time i end up in a discussion with semantic web people, i end up questioning why we even do microdata at all |
| 07:55 | <Hixie> | (then i remember there's some interesting use cases with drag and drop) |
| 07:55 | <Hixie> | (but those are never the ones they mention, and the ones they mention almost always seem to be either unrealistic or theoretical) |
| 07:58 | <annevk> | it's such a time sink |
| 07:59 | <annevk> | and HTML is really somewhat unique in that |
| 08:30 | <annevk> | hmm |
| 08:30 | <annevk> | so I think the fullscreen model still does not work cpearce :( |
| 08:31 | <annevk> | cpearce, Document is fullscreen, same document hosts a couple of videos by means of <video> elements |
| 08:31 | <annevk> | cpearce, document.exitFullscreen is going to do the wrong thing |
| 08:44 | <MikeSmith> | hsivonen: small patch review when you have time |
| 08:44 | <MikeSmith> | https://gist.github.com/1294834 |
| 08:44 | <MikeSmith> | for http://bugzilla.validator.nu/show_bug.cgi?id=865 |
| 09:00 | <annevk> | cpearce, I wrote an email |
| 09:00 | <annevk> | guess I'll write the WHATWG Weekly if there's anything to report on |
| 09:00 | <jgraham> | annevk: This concept of nested fullscreen seems like it will make for a confusing user experience |
| 09:00 | <jgraham> | I could be wrong |
| 09:01 | <annevk> | your site is displayed fullscreen, you have a video in it |
| 09:01 | <annevk> | the user hits the fullscreen button on the video, then exits |
| 09:02 | <annevk> | what is the expected user experience? |
| 09:02 | <annevk> | to me it seems pretty obvious you want the site to remain fullscreen |
| 09:02 | <annevk> | but I could be wrong |
| 09:02 | <jgraham> | I'm not sure |
| 09:03 | <jgraham> | It seems like you could get into a situation where you think "exit fullscreen" will actually cause you to exit fullscreen when it won't |
| 09:04 | <annevk> | the alternative is to not support nesting and if you want nesting you need to implement your own concept of fullscreen |
| 09:04 | <annevk> | which is kind of sucky given all the benefits of using fullscreen |
| 09:05 | <jgraham> | I wonder if it is a problem if a site takes you two levels of fullscreen deep, gives you an "exit fullscreen" button and meanwhile draws something that looks like maximised browser chrome on the inner fullscreen |
| 09:05 | <foolip> | won't calling requestFullscreen when already in fullscreen cause the fullscreen'd element to change? |
| 09:05 | <foolip> | if so, they could just have the "exit fullscreen" button call fullscreen on another element in this situation |
| 09:05 | <foolip> | although the native UI won't do the same thing |
| 09:05 | <jgraham> | Maybe it's not, since you could do that even without the concept of nested fullscreen |
| 09:06 | <jgraham> | (but if there is a browser escape hatch that only works one level deep, it could be more confusing) |
| 09:06 | <foolip> | still, if I ever actually wanted to really exit fullscreen, I'd be pretty annoyed if I found myself in n levels of fullscren |
| 09:06 | <annevk> | foolip, yeah, then you get a disparity between <video controls> and <video> with site-supplied controls |
| 09:06 | <annevk> | to exit fullscreen you press "Esc" |
| 09:07 | <annevk> | we'll clearly advertise that in the UI and it will go through everything |
| 09:08 | <jgraham> | I guess as long as browsers implement a method that blows away all fullscreen there's no problem |
| 09:08 | <foolip> | anyway, the user putting a page into fullscreen with F11 isn't the same as requestFullscreen right? |
| 09:08 | <jgraham> | Is it possible for sites to bind to the esc key? Or is that forbidden? |
| 09:08 | <foolip> | so the case where a site just happens to be in fullscreen without knowing it can be handled |
| 09:09 | <annevk> | foolip, I would sort of like it to be the same |
| 09:09 | <annevk> | jgraham, the site would never get hold of this key basically |
| 09:09 | <annevk> | jgraham, while in fullscreen |
| 09:09 | <annevk> | foolip, i.e. have the API and UI work together |
| 09:10 | <foolip> | hmm, that does sound nice I agree |
| 09:11 | <jgraham> | So that is equivalent to requestFullscreen on the root element? |
| 09:11 | <annevk> | or on a video element |
| 09:11 | <annevk> | kind of depends |
| 09:11 | <jgraham> | What? Why would video be special? |
| 09:17 | <foolip> | A fullscreen button in native controls and option in the context menu of <video> would make sense, but not so much for <input> |
| 09:18 | <annevk> | we should definitely have it on the native controls |
| 09:18 | <jgraham> | But also for <canvas> or <svg> or <div> with a video and some other stuff in |
| 09:19 | <annevk> | dunno about those |
| 09:19 | <jgraham> | Well I don't necessarily think we should |
| 09:19 | <jgraham> | But video isn't really that special |
| 09:19 | <annevk> | yes it is |
| 09:19 | <foolip> | the spec could allow it, but I doubt anyone will implement it |
| 09:19 | <annevk> | for <video>? |
| 09:19 | <foolip> | for <input> :) |
| 09:19 | <annevk> | oh |
| 09:19 | <jgraham> | Only in the case it has native controls. Even then it could be using other stuff synced to the video |
| 09:20 | <jgraham> | That would mean that taking it fullscreen alone didn't make sense |
| 09:20 | <annevk> | sounds like an edge case |
| 09:20 | <foolip> | jgraham, then the page author will have to provide fullscreen controls |
| 09:20 | <foolip> | UI for picking a random element to fullscreen would have to look something like dragonfly's focus rectangles, i.e. intolerable |
| 09:21 | <jgraham> | Right, I'm not saying that will work |
| 09:21 | <jgraham> | I'm saying that the converse will break sometimes |
| 09:21 | <foolip> | absolutely |
| 09:21 | <jgraham> | I don't know how often that will be |
| 09:21 | <foolip> | all of my <track> demos so far will break |
| 09:21 | <foolip> | but that's fine I think |
| 09:22 | <jgraham> | An end user that doesn't understand the implementation may disagree ofc |
| 09:22 | <jgraham> | Anyway, I don't know |
| 09:22 | <foolip> | uh, yeah, users... |
| 09:23 | <foolip> | I do look forward for bug reports that the captions don't show in fullscreen because the page author did it using scripts |
| 09:23 | <jgraham> | Possibly people only use video with native controls in testcases so this is irrelevant |
| 09:23 | <foolip> | s/for/to/ |
| 09:24 | <foolip> | yeah, you don't see them a lot |
| 09:25 | <zcorpan> | annevk: video with custom controls isn't an edge case |
| 09:26 | <zcorpan> | custom controls for video and fullscreen is kind of a problem. you might want to allow the user to enter fullscreen from the context menu of the video, but you still want to show the custom controls in fullscreen |
| 09:28 | <jgraham> | There could be some mechanism for changing the element that will go fullscreen. That could be evil though |
| 09:28 | <foolip> | zcorpan, presumably not without some involvement from the script managing the controls? |
| 09:28 | <annevk> | zcorpan, we were not talking about custom controls |
| 09:35 | <zcorpan> | what were you talking about? custom captions? |
| 09:35 | <zcorpan> | seems like you'd want those in fullscreen too |
| 09:35 | <zcorpan> | foolip: what can the script do if the user fullscreened from the video's context menu? |
| 09:36 | <foolip> | zcorpan, if there is an event when fullscreen happens and some kind of container element then presumably it can make the controls visible in fullscreen as well |
| 09:37 | <annevk> | yeah, the site could check fullscreenchange events and retarget accordingly |
| 09:37 | <foolip> | but I doubt anyone would, scripts will mostly assume that the context menu and native controls do not exist |
| 09:37 | <foolip> | and break if they do |
| 09:38 | <annevk> | it seems reasonable for browsers to provide native controls if the fullscreen element is the video element itself |
| 09:38 | <roc> | what problem are you guys talking about? |
| 09:38 | <annevk> | UI and API-based fullscreen interaction |
| 09:39 | <roc> | ah |
| 09:39 | <annevk> | roc, could you look at my most recent email to the WHATWG list? |
| 09:40 | <roc> | ok |
| 09:41 | <roc> | I would not allow cancelFullScreen to leave full-screen state if the user initiated it |
| 09:42 | <annevk> | is that in reply to my email? |
| 09:46 | <zcorpan> | foolip: you mean you would change the 'fullscreen element' after the user fullscreened the video? |
| 09:47 | <annevk> | fwiw, if there are custom controls I very much doubt the user will right-click |
| 09:48 | <roc> | annevk: yes |
| 09:49 | <annevk> | because it doesn't address my email |
| 09:50 | <annevk> | site goes fullscreen (either API or UI-wise, I don't really care) then you want to view some video in it that's in the same document |
| 09:50 | <annevk> | and you want to continue using the site |
| 09:50 | <annevk> | after viewing the video, or maybe halfway |
| 10:04 | <foolip> | zcorpan, either that or if there is always a container into which more elements can be stuffed |
| 10:04 | <foolip> | but that seems a bit magical |
| 10:14 | <annevk> | roc, did you see http://krijnhoetmer.nl/irc-logs/whatwg/20111018#l-783 ? |
| 10:19 | <roc> | yeah |
| 10:19 | <roc> | well, I just read your link |
| 10:20 | <annevk> | I haven't really figured out a simple way to make the single document case work yet :( |
| 10:21 | <annevk> | I guess authors can hack around it using <iframe srcdoc=""> but that seems like a really ugly workaround |
| 10:24 | <roc> | one option is that the video fullscreen controls could explicitly save the previous fullscreen element, if any, and then when un-full-screening the element you either requestFullScreen on the old element or else cancelFullScreen if there wasn't one |
| 10:25 | <annevk> | does that assume custom controls? |
| 10:26 | <annevk> | it doesn't seem nice if the API and UI have wildly different implementations |
| 10:27 | <annevk> | I suppose you could also make this work UI-wise somehow, but it's not pretty |
| 13:11 | <annevk> | http://www.identityblog.com/?p=1201 |
| 14:05 | <smaug____> | annevk: ttp://www.identityblog.com/?p=1201 is interesting |
| 14:05 | <smaug____> | annevk: http://www.identityblog.com/?p=1201 is interesting |
| 14:06 | <smaug____> | thanks for the link |
| 16:41 | <dglazkov> | good morning, Whatwg! |
| 17:00 | <jarek> | Hi |
| 17:00 | <jarek> | which specification introduces the "@supports" atrule? |
| 17:01 | <jarek> | I have stumbled upon it in one example in http://www.w3.org/TR/css3-fonts |
| 17:02 | <hasather> | jarek: http://www.w3.org/TR/css3-conditional/#at-supports |
| 17:03 | <jarek> | hasather: thanks |
| 17:04 | <jarek> | btw, do you know if any browser supports @supports? |
| 17:09 | <zewt> | @supports (@supports) |
| 17:18 | <jarek> | http://www.w3.org/TR/css3-fonts/ uses following code in one example: |
| 17:18 | <jarek> | font-family: Mercury Serif, serif; |
| 17:18 | <jarek> | is this really valid? Shouldn't Mercury Serif be put between quotes? |
| 17:21 | <jarek> | "Font family names must either be given quoted as strings, or unquoted as a sequence of one or more identifiers. This means most punctuation characters and digits at the start of each token must be escaped in unquoted font family names." |
| 17:22 | <miketaylr> | i would quote mercury serif, yes |
| 17:25 | <jarek> | so Mercury Serif is a valid name, but 9Mercury Serif would fail :/ |
| 17:49 | <Ms2ger> | jarek, yes |
| 17:49 | <Ms2ger> | Fun, isn't it? |
| 21:01 | <jgraham> | So is David Flanagan writing a html parser in js? |
| 21:06 | <Ms2ger> | Along with his dom implementation, yes |
| 21:06 | <Ms2ger> | https://github.com/andreasgal/dom.js |
| 21:06 | <Ms2ger> | "all HTML parser tests pass!" |
| 21:10 | <jgraham> | So is that actually a necessary part of dom.js? |
| 21:11 | <jgraham> | And what's next, the network layer? |
| 21:17 | <Ms2ger> | That'll be in rust, more likely |
| 21:18 | <jgraham> | So what I don't understand is where script scheduling fits is |
| 21:18 | <jgraham> | *in |
| 21:18 | <jgraham> | That is tightly coupled to the parser |
| 21:19 | <jgraham> | So it seems weird to have those in different languages |
| 21:19 | <jgraham> | But writing the scheduler in javascript seems... unlikely |
| 21:19 | <jgraham> | But maybe I am wrong about one of those things |
| 21:20 | <Ms2ger> | Dunno, haven't been following closely |
| 21:20 | <Ms2ger> | What I know is from http://dl.dropbox.com/u/4186469/rust-all-hands-w2011/assets/fallback/index.html around slide 38 |
| 21:21 | <Ms2ger> | Though that claims the HTML parser would be in rust |
| 21:32 | <zcorpan> | TabAtkins: now this is some flippin https://twitter.com/#!/wilto/status/126342267337318400 |
