| 00:18 | <jarek> | Hi |
| 00:18 | <jarek> | what's the difference between '::before' and ':before", and '::after' and ':after'? |
| 00:19 | <jarek> | the CSS3 spec defines only '::before' and '::after' |
| 00:19 | <jarek> | but I can see the other format all over the web |
| 00:21 | <jarek> | nvm |
| 00:21 | <jarek> | just found this http://www.impressivewebs.com/before-after-css3/ |
| 02:38 | <annevk> | Hixie, hey, I'll file bugs once we sorted out the fullscreen model |
| 02:38 | <annevk> | still seems a bit unclear (to me anyway) |
| 02:42 | <annevk> | jarek, note how that article is missing the point; the single-colon syntax does not work for new pseudo-elements, only those introduced prior to the double-colon syntax |
| 02:42 | <annevk> | oh you are not her |
| 02:42 | <annevk> | e |
| 03:33 | <annevk> | on the other hand API-based and UI-based fullscreen necessarily have to be different already of course as navigation should not cause UI-based fullscreen to exit |
| 03:34 | <zewt> | annevk: "UI-based" is ambiguous--F11 fullscreen and native-video-controls-fullscreen are very different |
| 03:35 | <erlehmann> | it is funny: in the evince PDF reader there exist „presentation“ and „fullscreen“ side-by-side with different semantics. quite some time, they behaved funny (yet predictable) when interleaving them. |
| 03:37 | <annevk> | zewt, I guess they are |
| 03:39 | <annevk> | maybe we should just not bother with nesting of requestFullscreen |
| 03:39 | <zewt> | i do like the possibility of native and scripted fullscreen being identical, though |
| 03:40 | <erlehmann> | in during category error. |
| 03:40 | <zewt> | what? heh |
| 03:40 | <erlehmann> | not true? |
| 03:40 | <zewt> | ("native" referring to video controls, not F11) |
| 03:40 | <erlehmann> | oh. |
| 03:40 | <zewt> | don't know what you said |
| 03:41 | <zewt> | parse error :) |
| 03:41 | <erlehmann> | a category error is, basically, treating things from different categories the same. in software, this is almost guaranteed to lead to problems later on. but i thought of “F11”. |
| 03:42 | <zewt> | ... it's also conceivable that native video fullscreen could use the fullscreen API, while still not allowing nesting |
| 03:42 | <zewt> | at least then the interactions would be clear, and the other useful side-effects |
| 03:43 | <erlehmann> | nested fullscreen … fullception. or screenception? |
| 03:43 | <erlehmann> | WE NEED TO SCREEN FULLER. |
| 03:43 | <zewt> | erlehmann: enterFullscreen followed by the user clicking a native video fullscreen box |
| 03:44 | <erlehmann> | my angler sense tingles. fishing possibilities ahead? |
| 03:45 | <erlehmann> | (users may or may not be confused. it is unclear to me what they would expect.) |
| 03:45 | <annevk> | maybe we should have document.requestFullscreen and it would be quite a bit different |
| 03:45 | <annevk> | and element.requestFullscreen would be for the <video> case and such |
| 03:45 | <zewt> | annevk: why have them be different? |
| 03:46 | <annevk> | if you press F11 you don't want a black background and such |
| 03:46 | <annevk> | you just want your document to be fullscreen |
| 03:46 | <zewt> | confused--F11 is browser fullscreen, pages don't have control over that |
| 03:46 | <annevk> | the idea would be to give them control |
| 03:47 | <zewt> | but it's a separate mode entirely (affects all tabs in the window; doesn't go away on navigation) |
| 03:53 | <erlehmann> | ha! |
| 03:53 | <erlehmann> | see? confusion everywhere. |
| 03:58 | <annevk> | zewt, i guess the navigation would be different |
| 04:07 | <zewt> | annevk: if you want to fullscreen the tab without getting the black background (etc), you can just document.documentElement.enterFullscreen(), right? due to :not(:root) |
| 04:07 | <annevk> | oh right, I forgot about that hack |
| 04:08 | <zewt> | better than having two entry points, IMO |
| 04:08 | <annevk> | given that they're fundamentally different I'm not so sure |
| 04:09 | <zewt> | well, i'm just talking about the black background, etc--the fullscreen API shouldn't have any control over whole-window fullscreen |
| 04:09 | <zewt> | (if it should--why?) |
| 04:10 | <annevk> | I don't really see the difference |
| 04:10 | <zewt> | ("window fullscreen" being F11 "affects the whole window", vs. tab-specific fullscreen that this API deals with) |
| 04:11 | <zewt> | i don't see the similarity :) |
| 04:11 | <zewt> | if I hit F11, I want the browser to stay fullscreen permanently until I hit F11 again; individual pages shouldn't affect (or care) about that |
| 04:11 | <zewt> | (or necessarily even be able to tell) |
| 04:12 | <annevk> | they can tell pretty easily |
| 04:12 | <zewt> | that is, F11 fullscreen shouldn't affect eg. fullscreenElement |
| 04:14 | <zewt> | why would a page want to activate window fullscreen (instead of just fullscreening the document)? |
| 04:14 | <annevk> | I don't think they'd want that, but the visual effect is pretty much identical |
| 04:15 | <annevk> | I mean sure one allows you to navigate and probably switch tabs, but things within the current document should probably work identical |
| 04:16 | <zewt> | i just think--well, what Darin said, that it's a separate UA feature that the UA can deal with, fullscreen api doesn't need to talk about it |
| 04:23 | <Hixie> | annevk: roger |
| 04:52 | <annevk> | zewt, yeah I guess |
| 04:52 | <annevk> | so how about this |
| 04:53 | <annevk> | since each Document has the fse (fullscreen element) and original fse, you can allow one-level of nesting per-Document |
| 04:53 | <annevk> | first time you do requestFullscreen fse gets set |
| 04:53 | <erlehmann> | oh well. i quite like the way i have to press F11. |
| 04:53 | <erlehmann> | to get fullscreen. it is the only way now. |
| 04:53 | <erlehmann> | goodbye, F11. |
| 04:54 | <annevk> | second time you do reqeustFullscreen original fse becomes fse, and fse becomes whatever requestFullscreen was invoked upon |
| 04:54 | <annevk> | erlehmann, huh? |
| 04:54 | <erlehmann> | annevk, i will probably not need it for the stuff i need it now. mainly web-based presentations and games. |
| 04:54 | <annevk> | if you then exitFullscreen fse becomes original fse again |
| 04:55 | <erlehmann> | because they will use the scripted fullscreen facilities, right? |
| 04:55 | <erlehmann> | so, goodbye F11. :3 |
| 04:55 | <zewt> | annevk: what's the "original fse"? that's just ... null, isn't it? |
| 04:55 | <annevk> | well, I sort of think F11 should still give you fullscreenchange events |
| 04:55 | <annevk> | zewt, initially fse and original fse are null |
| 04:56 | <zewt> | annevk: are you basically suggesting a stack with a max size of 2? (implemented as two values rather than an array) |
| 04:56 | <erlehmann> | annevk, anythink you could use fullscreenchange events in that case for that is not layout? |
| 04:56 | <annevk> | zewt, you need original fse also if you are doing fullscreen in a descendant document, but yeah, that's the suggestion |
| 04:57 | <annevk> | erlehmann, not sure what you are suggesting |
| 04:57 | <zewt> | i'm not sure either way if it's really important to be able to do the "api fullscreen -> second fullscreen -> exit to the first fullscreen" thing |
| 04:57 | <erlehmann> | annevk, i am not suggesting. just musing and asking. |
| 04:57 | <zewt> | (not necessarily saying it's not, just not sure) |
| 04:58 | <annevk> | zewt, yeah, I sort of think we should maybe disallow that for now (requestFullscreen would just fail) and we'll see what happens |
| 04:58 | <zewt> | annevk: i think maybe it should succeed, and switch the element |
| 04:59 | <zewt> | eg. so video fullscreen buttons still work (they just don't stack) |
| 04:59 | <annevk> | so you have your powerpoint, go fullscreen in your video, and then you exit and it all falls apart? |
| 04:59 | <zewt> | maybe if there's a way to implement the stack behavior manually, for people who really want to ... not sure if that would work |
| 05:00 | <zewt> | doesn't fall apart, it behaves predictably--just not necessarily the way the page wanted |
| 05:00 | <zewt> | hmm |
| 05:01 | <zewt> | i'm biased by wanting to see video native controls just be defined as "transition to fullscreen" (with some trusted flag to ignore fullscreenEnabled, perhaps) |
| 05:01 | <zewt> | because it seems like that would make it all fit together a lot better |
| 05:03 | <zewt> | (if there's any possibility of that happening, it probably needs to happen early, or pages might start depending on it *not* happening) |
| 05:38 | <annevk> | I emailed the list with an update on UI/API and nesting |
| 05:39 | <annevk> | hopefully it is somewhat coherent and hopefully it helps moving this discussion forward |
| 06:39 | <TabAtkins_> | annevk5: Good email. |
| 07:24 | <annevk> | hg diff -c REV --reverse is kind of cool |
| 07:24 | <annevk> | need to remember that one |
| 07:34 | <annevk> | where did https://developer.mozilla.org/presentations/xtech2005/e4x/ go? |
| 07:34 | <annevk> | broken links on mozilla.org, when did that start happening? |
| 07:34 | <erlehmann> | dead links are the cancer that is killing the web. |
| 07:35 | <erlehmann> | i recently made a script to check for them in link lists. and found sites not answering to HEAD. |
| 07:35 | <annevk> | lets not get overly dramatic |
| 07:35 | <erlehmann> | that site is not even properly 410 |
| 07:35 | <annevk> | dude that's impossible, HTTP has no problems |
| 07:35 | <erlehmann> | but sadly, as mpilgrim has killed off his stuff, no one will read his article on 410. |
| 07:42 | <annevk> | oh man |
| 07:43 | <annevk> | that made me look up http://intertwingly.net/blog/2004/06/13/Gone-Really-I-mean-it and read about Dave Winer tried to reinvent HTTP in some XML and several others did too, and aah |
| 07:48 | <erlehmann> | my simple trick on HTTP 410 is to have it delivered on files with zero length |
| 07:49 | <erlehmann> | so when a file goes poof, i just nul it. |
| 08:11 | <annevk> | Hixie, I emailed public-script-coord to see if there's interest in reviving E4X as H4E (does not mean "Husband for ever") |
| 08:12 | <Hixie> | yeah we should just trim down E4X to just the literal stuff, and make it a short hand for DOM nodes |
| 08:12 | <Hixie> | drop all the query stuff |
| 08:12 | <annevk> | Hixie, if there's no interest I guess we're back to H4J (HTML for JSON) |
| 08:12 | <Hixie> | and drop comment support |
| 08:12 | Hixie | shudders at the idea of H4J |
| 08:13 | <annevk> | I suggested something to that effect, yes |
| 08:13 | <annevk> | drop cdata, comment, pi, drop namespaces, drop xpath |
| 08:13 | <annevk> | simplify the API, was my suggestion more or less |
| 08:13 | <Hixie> | yeah |
| 08:13 | <Hixie> | cool |
| 08:14 | <Hixie> | btw iirc mozilla only does e4x in certain modes |
| 08:14 | <Hixie> | so there's not really a compat risk |
| 08:15 | <annevk> | Brendan did make it work outside the es4=true flag |
| 08:15 | <Hixie> | oh ok |
| 09:36 | <smaug____> | ok, if Websocket protocol forces the API to be as bizarre as it is, we should not use the protocol |
| 09:39 | <zcorpan> | smaug____: ? |
| 09:40 | <smaug____> | "If reason is longer than 123 bytes, then throw a SyntaxError exception and abort these steps." |
| 09:41 | <smaug____> | There is also "is not an integer equal to 1000 or in the range 3000 to 4999, throw an InvalidAccessError exception", but I'm not sure where that insanity comes from |
| 09:42 | <annevk> | maybe you should read the protocol |
| 09:44 | <zcorpan> | smaug____: they wanted close frames (and controls frames in general) to be short. seems reasonable? |
| 09:45 | <annevk> | I wonder if http://wiki.ecmascript.org/doku.php?id=harmony:quasis will get the same lovely definition as new Date(...) i.e. undefined |
| 09:45 | <smaug____> | annevk: yes, I should read the latest version of the protocol |
| 09:45 | <smaug____> | zcorpan: no, as far as I see, there is no readon to limit the reason |
| 09:45 | <annevk> | Or ECMAScript would need some kind of normative dependency on CSS, HTML, etc. to define how strings are contextually escaped |
| 09:45 | <smaug____> | limit it more than limiting normal message length |
| 09:47 | <annevk> | seems like the reason is API-defined |
| 09:50 | <zcorpan> | smaug____: send feedback to hybi |
| 09:51 | <zcorpan> | i guess it could be useful to dump a stack trace or something in the reason |
| 09:55 | <jgraham> | annevk: It isn't clear to me from that page whether the intention is to have any built-in handlers at all |
| 09:55 | <jgraham> | I didn't read it all though |
| 10:01 | <annevk> | jgraham, the use cases and examples seem to imply so |
| 10:01 | <annevk> | not sure what you mean with handlers |
| 10:02 | <jgraham> | The function at the start is called a handler, isn't it? |
| 10:06 | <annevk> | oh |
| 13:09 | <annevk> | iPhone 4S (32GiB) in the US: 550 EUR thereabouts, in NL via T-Mobile: 750 EUR |
| 13:10 | <annevk> | I guess the US one does not include tax, but still |
| 13:24 | <Lachy> | annevk, is VAT 25% in NL? |
| 13:27 | <Timz> | 19% |
| 13:27 | <Lachy> | 550 * 1.19 = 654.5. Still 100 EUR difference. |
| 13:28 | <Timz> | yes and also a dollar !== euro so more.. |
| 13:28 | <annevk> | I already took that into account |
| 13:28 | <Timz> | ok |
| 13:32 | <Lachy> | woah, the EUR prices are even more than the AUD prices. 64GB model is 849 EUR in France, $999 AUD in Aus (~= 745.75 EUR) |
| 13:33 | <micheil> | Lachy: the US is probably not allowing you to buy out right |
| 13:34 | <micheil> | the 999$AU is for buying it completely unlocked from an apple store with no sim attached |
| 13:34 | <micheil> | (that's how I bought mine) |
| 13:34 | <Lachy> | micheil, yeah, I know. So is the France price |
| 13:36 | <annevk> | micheil, actually you can buy an unlocked iPhone in the US |
| 13:36 | <Lachy> | micheil, http://store.apple.com/us/browse/home/shop_iphone/family/iphone/iphone4s |
| 13:36 | <micheil> | annevk: last I recall it was pretty damn hard to |
| 13:36 | <Lachy> | select a phone, then click "Or get iPhone unlocked and contract-free. Coming in November." |
| 13:36 | <Lachy> | the prices are tehre |
| 13:36 | <Lachy> | *there |
| 13:36 | <annevk> | I believe there is some delay, but come November the iPhone 4S should be available |
| 13:37 | <micheil> | hmm.. anyone happen to know where to go for developer support with firefox? |
| 13:37 | <Lachy> | "The unlocked iPhone will not work with CDMA carriers such as Verizon Wireless or Sprint." :-( |
| 13:39 | <annevk> | why does that matter Lachy? |
| 13:44 | <Lachy> | annevk, it means that people who want to buy an unlocked phone are still effectively locked to using GSM networks in the US, and that they can't switch between Verizon and Sprint easily in the future if they get a locked phone. |
| 13:46 | <Lachy> | that's not really a problem in countries where CDMA isn't used any more though, so at least it won't affect me. |
| 13:50 | <annevk> | just means CDMA is crappy |
| 16:39 | <zcorpan> | annevk5: so jgraham and i wondered earlier why the dom has no way to dispatch an event async |
| 16:39 | <zcorpan> | annevk5: currently if you want that you have to abuse postMessage or xhr or something |
| 16:46 | <zewt> | setTimeout(0) seems like the general way of doing anything "async" in JS |
| 17:02 | <dglazkov> | good morning, Whatwg! |
| 17:19 | <jarek> | Hi |
| 17:19 | <jarek> | CSS3 selectors specification defines {simple_selector_sequence} as follows: |
| 17:19 | <jarek> | [ type_selector | universal ] |
| 17:19 | <jarek> | [ HASH | class | attrib | pseudo | negation ]* |
| 17:19 | <jarek> | | [ HASH | class | attrib | pseudo | negation ]+ |
| 17:20 | <jarek> | why there is no '*' or '+' or '?' sign after [ type_selector | universal ] ? |
| 17:20 | <jarek> | does it mean that there should be exactly one {type_selector} or {universal} at the start of {simple_selector_sequence}? |
| 17:21 | <jarek> | this would mean that something like '#header' is not a simple selector |
| 17:28 | <jarek> | no, wait... it makes sense... |
| 17:28 | <Philip`> | jarek: "#header" matches HASH so it matches "[HASH | ...]+" so it matches "... | [HASH | ...]+", I think |
| 17:34 | <jarek> | s/one of both/one from the two |
| 17:38 | <jarek> | "A sequence of simple selectors is a chain of simple selectors that are not separated by a combinator. It always begins with a type selector or a universal selector. No other type selector or universal selector is allowed in the sequence." |
| 17:39 | <jarek> | now I'm confused, selectors starting with '.blah' or '#blah' are not a sequence of simple selectors? |
| 17:42 | <jarek> | "If a universal selector represented by * (i.e. without a namespace prefix) is not the only component of a sequence of simple selectors selectors or is immediately followed by a pseudo-element, then the * may be omitted and the universal selector's presence implied." |
| 17:42 | <Philip`> | jarek: [ A | B ] means either A, or B |
| 17:43 | <Philip`> | (not both, and not neither) |
| 17:43 | <jarek> | so the grammar definition is wrong? It assumes that universal selector or type selector are always there |
| 17:43 | <jarek> | it doesn't take into account the fact that universal selector's presence might be implied |
| 17:44 | <Philip`> | I think the grouping is equivalent to "[ [type_selector|universal] [stuff]* ] | [stuff]+", not like "[type_selector|universal] [ [stuff]* | [stuff]+ ]" |
| 17:44 | <Philip`> | so if you don't have type_selector or universal, you need at least one of the stuff |
| 17:45 | <Philip`> | (i.e. you can't just have the empty string) |
| 17:51 | <zewt> | Philip`: (clearer to say "means A xor B") |
| 21:21 | <rniwa> | Hixie: yt? |
| 21:25 | <Hixie> | rniwa: about to go to lunch |
| 21:25 | <rniwa> | Hixie: k. |
| 21:25 | <rniwa> | Hixie: will ping you back later then :) |
| 21:25 | <Hixie> | k |
| 22:52 | <Hixie> | annevk5: is a concept-event different than an Event? they seem to be treated as equivalent in DOM Core |
| 23:05 | <Hixie> | anyone know if i'm just mistesting this again or whether it's possible for opera to return non-null for input.selectedOption? |
| 23:09 | <Hixie> | ok i'll just drop it |