| 00:00 | <TabAtkins> | Your "confusing to the reader" argument is based on the simplistic styling conventions I'm currently using to provide permalinks to <dfn>s. |
| 00:00 | <Hixie> | seriously, i find that presentation really confusing. |
| 00:00 | <TabAtkins> | A different styling would negate your argument; it's not generally valid. |
| 00:00 | <Hixie> | the whole thing is bold italics, and as i hover over it i get permalinks that and i can't work out what they're for |
| 00:01 | <Hixie> | it's not helpful to define the term but not show what the term is |
| 00:01 | <TabAtkins> | That's cool, *but it's an argument against my current simplistic styling, not the markup*. |
| 00:01 | <Hixie> | no, whether it's confusing or not has to be determined in the absence of any styling. |
| 00:01 | <Hixie> | it'd be much clearer if they were sibling elements |
| 00:01 | <TabAtkins> | The "definition" of the family argument is "family is an argument to the FontFace function", which is implicit in the text it's embedded in. |
| 00:02 | <Hixie> | with punctuation between them |
| 00:02 | <TabAtkins> | ??? |
| 00:02 | <Hixie> | as in, <code><dfn>FontFace</dfn>(DOMString <dfn>family</dfn>, ...)</code> like i suggested earlier |
| 00:03 | <TabAtkins> | You're trying to argue that <dfn>FontFace</dfn>() is, in general, better than <dfn>FontFace()</dfn>? |
| 00:03 | <Hixie> | no, i'm arguing it's better if you also want to <dfn> the arguments. |
| 00:03 | <Hixie> | in the no-argument case i think it's a wash |
| 00:04 | <TabAtkins> | So you're arguing that I should change the markup of a function definition based on whether or not I'm defining other things vaguely related to it? |
| 00:04 | <Hixie> | (you could argue it either way, i mean, it's common to think of the method as "foo()", but really it's called "foo") |
| 00:04 | <TabAtkins> | And that it's important enough that it should be considered invalid to not do that? |
| 00:04 | <Hixie> | i'd recommend being consistent throughout, personally |
| 00:05 | <Hixie> | i do think the confusion resulting from nesting <dfn>s like this is important enough that it should be considered invalid, yes, based on this example at least |
| 00:06 | <Hixie> | (gotta go, mtg) |
| 00:06 | <TabAtkins> | Ignoring the permalinks, you wouldn't be confused in the slightest. |
| 00:06 | <TabAtkins> | The permalinks are something I added myself - they are completely unconnected to the example. |
| 00:06 | <Hixie> | (ignoring the permalinks, i'd be completely unaware of the inner <dfn>s, meaning they'd be pointless) |
| 00:06 | <Hixie> | (afk) |
| 00:06 | <TabAtkins> | They're link targets! |
| 00:06 | <zewt_> | hixie plays magic the gathering |
| 00:07 | <TabAtkins> | ...and? |
| 00:07 | <TabAtkins> | Ah, mtg |
| 00:07 | <TabAtkins> | Okay. |
| 00:18 | <jamesr__> | TabAtkins: you're setting a bad example for all the kids reading public-webapps. tsk tsk |
| 00:19 | <TabAtkins> | Urgh, now I have to either add more explicit metadata to the nested argument definitions and type links, or add a dummy <span> around the whole thing solely to move the metadata args to. |
| 00:21 | <zewt> | the shitty attempts at moderation are the most common thing that make me consider unsubscribing from that list; they're always much more unpleasant than anything they're in response to |
| 10:19 | <mathiasbynens> | what is the expected behavior here? data:text/html,<img%20name=anchors><img%20name=anchors><script>document.write(document.anchors.length)</script> |
| 10:19 | <mathiasbynens> | i’d expect 1 based on http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-tree-accessors |
| 10:24 | <mathiasbynens> | which spec says <img name=foo> → `document.foo`? and does that spec explicitly override DOM tree accessors or not? |
| 10:39 | <mathiasbynens> | via https://twitter.com/RobbertAtWork/status/434273199648284672 and http://robbertbroersma.nl/demo/kill-document/ |
| 11:31 | <annevk> | mathiasbynens: seems you missed "getter object (DOMString name)" on Document |
| 11:31 | <annevk> | mathiasbynens: http://www.whatwg.org/specs/web-apps/current-work/#dom-document-nameditem |
| 11:32 | <annevk> | mathiasbynens: also exists on Window but works a bit differently |
| 11:40 | <mathiasbynens> | ah, so DOM tree accessors don’t magically take precedence |
| 11:40 | <mathiasbynens> | thanks |
| 11:45 | <annevk> | mathiasbynens: because of the [OverrideBuiltins] annotation |
| 11:53 | MikeSmith | wonders if tyoshino__ made it home before the blizzard arrived |
| 11:54 | <annevk> | TabAtkins: I don't get why you'd <dfn> an argument either, fwiw |
| 11:55 | <annevk> | TabAtkins: the definition is for the method, including its parameters |
| 11:55 | <annevk> | TabAtkins: you're not defining the parameters independently from the method |
| 11:55 | <annevk> | TabAtkins: (and if you are, that's old-style DOM stuff and wrong) |
| 11:59 | <yoav> | TabAtkins & SimonSapin: I'm having some trouble implementing http://dev.w3.org/csswg/css-syntax/#consume-a-number |
| 12:06 | <MikeSmith> | annevk: dunno if you're following the recent Streams discussions but do you know is it correct that the plan is to eventually have the ecmascript spec define a Streams abstraction |
| 12:07 | <annevk> | MikeSmith: Domenic_ certainly envisions it that way |
| 12:07 | <MikeSmith> | ok |
| 12:07 | <annevk> | MikeSmith: I get the impression ECMAScript wants to define all the things that make sense across embedding environments, which would also include URLs, encodings, etc. |
| 12:08 | <MikeSmith> | oh |
| 12:08 | <MikeSmith> | that would be ideal |
| 12:08 | <MikeSmith> | as long as they don't mess it all up at least |
| 12:09 | <MikeSmith> | I mean to have it define all in once place for all JS environments, including no-browser onces |
| 12:10 | <MikeSmith> | a problem I see with |
| 12:10 | <MikeSmith> | one problem I see with this plan is that TC39 is not famous for getting things done quickly |
| 12:11 | <Ms2ger> | I certainly don't think the JS spec is the right place to define URLs |
| 12:12 | <MikeSmith> | has Promises already been folded into the ecmascript draft yet? |
| 12:12 | <annevk> | MikeSmith: yes |
| 12:12 | <annevk> | Ms2ger: it seems like a good place for the API, certainly |
| 12:13 | <MikeSmith> | Ms2ger: maybe not the URL abstract definition |
| 12:13 | <MikeSmith> | what annevk said |
| 12:13 | <Ms2ger> | Oh, URL api, I guess |
| 12:15 | <Ms2ger> | What do people think about moving the editing spec to github/whatwg, btw? |
| 12:15 | <SimonSapin> | yoav: How so? |
| 12:15 | <annevk> | SimonSapin: oreolunch in 30min, better get to the office |
| 12:15 | <SimonSapin> | oreolunch? |
| 12:16 | <annevk> | Ms2ger: well we can move things around, but is someone going to maintain it? |
| 12:16 | <Ms2ger> | Not it :) |
| 12:16 | <MikeSmith> | annevk: I wish Jason would generate a multipage version of the ES6 draft. I wonder if he's using python to generate it |
| 12:16 | <MikeSmith> | (to generate the single-age one I mean) |
| 12:16 | <Ms2ger> | MikeSmith, the code is on github, I think |
| 12:17 | <MikeSmith> | k |
| 12:17 | <MikeSmith> | Ms2ger: I say yeah I don7t see any good reason not to move the editing spec to github/whatwg |
| 12:17 | <annevk> | Ms2ger: also, you suggesting moving something to GitHub is funny |
| 12:18 | <Ms2ger> | It is |
| 12:18 | <annevk> | MikeSmith: it loads quite quickly for me |
| 12:18 | <MikeSmith> | where would Ms2ger normally prefer to move things? |
| 12:18 | <annevk> | MikeSmith: are you on your phone again? :p |
| 12:18 | <MikeSmith> | hehah |
| 12:18 | <Ms2ger> | hg.whatwg.org ;) |
| 12:18 | <MikeSmith> | ah |
| 12:19 | <yoav> | SimonSapin: I think that a "reconsume" is missing in http://dev.w3.org/csswg/css-syntax/#consume-a-token in the digit section |
| 12:19 | <yoav> | before the "consume a numeric token" |
| 12:19 | <MikeSmith> | annevk: yeah I was loading it on my phone. which is a valid use case |
| 12:20 | <yoav> | The way it is specced, the first digit is consumed, and then not added to the number |
| 12:20 | <yoav> | Unless I'm missing something, which is highly possible |
| 12:20 | <annevk> | MikeSmith: yeah fair |
| 12:20 | <MikeSmith> | annevk: but yeah it's hardly a normal case |
| 12:22 | <MikeSmith> | hmm I see python in Jason's repo so I bet Philip` spec splitter could be modified to split it. I guess I should try it |
| 12:29 | <mathiasbynens> | MikeSmith, Ms2ger: https://github.com/jorendorff/es-spec-html/issues/5 |
| 12:33 | <annevk> | MikeSmith: make http://es.github.io/ as ES living standard :-) |
| 12:38 | <SimonSapin> | yoav: there may be a spec bug. Could you write to www-style with the details? |
| 12:39 | <yoav> | SimonSapin: Sure |
| 12:39 | <yoav> | Is the spec on GitHub by any chance? |
| 12:39 | <yoav> | if so, I can open an issue there |
| 12:39 | <SimonSapin> | there is a github mirror of the repo |
| 12:39 | <SimonSapin> | but we don’t use github for issue tracking |
| 12:40 | <yoav> | OK |
| 12:40 | <SimonSapin> | https://github.com/w3c/csswg-drafts |
| 12:41 | <SimonSapin> | The "main" repo is https://dvcs.w3.org/hg/csswg |
| 12:41 | <SimonSapin> | yoav: or if you’d rather not subscribe on www-style, email me |
| 12:42 | <yoav> | I'm subscribed to www-style, just have a hard time spamming everyone with this bug :) |
| 12:42 | <yoav> | But I'll get over it |
| 12:42 | <SimonSapin> | don’t worry about that |
| 12:42 | <SimonSapin> | it’s what the list is for |
| 12:43 | <Domenic_> | Hah! Worries about mail volume on www-style! Now I've heard everything. |
| 12:44 | <yoav> | Domenic_: That's exactly why I'd rather avoid mailing it to the list :) |
| 12:45 | <annevk> | CSS has Bugzilla as well... |
| 12:45 | <annevk> | I usually use that as email tends to get lost and forgotten |
| 12:46 | <yoav> | annevk: Is it open for non members? |
| 12:46 | <annevk> | yoav: yeah is |
| 12:47 | <yoav> | OK, will try that |
| 12:47 | <yoav> | Thanks! |
| 12:47 | <annevk> | yoav: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=CSS |
| 12:56 | <yoav> | SimonSapin: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24661 |
| 12:57 | <SimonSapin> | yoav: why did you go there? |
| 12:58 | <SimonSapin> | CSSWG has too many fucking ways to track issues |
| 12:58 | <yoav> | annevk suggested to open a bug there |
| 12:58 | <SimonSapin> | I need an issue tracker tracker |
| 12:58 | <yoav> | Sorry |
| 12:58 | <yoav> | I can send it to the list if you prefer |
| 13:00 | <SimonSapin> | annevk: Buzilla bugs can get lost and forgotten just as easily. I recently discovered that the specs *I’m* editing had bugs on Bugzilla |
| 13:01 | <SimonSapin> | Everything is broken and nobody cares |
| 13:23 | <MikeSmith> | mathiasbynens: ah thanks I remember that now. I should get around to trying it and just implement a PR |
| 13:24 | <MikeSmith> | annevk: yeah I could just make http://es.github.io/ redirect to Jason's HTML |
| 13:25 | <MikeSmith> | oh if I owned "es" |
| 13:27 | <MikeSmith> | hey I do own http://ecmascript.github.io/ though |
| 13:44 | <MikeSmith> | http://ecmascript.github.io/ now redirects to the latest, and will http://es-spec.github.io/ soon hopefully too |
| 13:49 | <MikeSmith> | and http://es6.github.io/ for now |
| 15:36 | <JakeA> | annevk: Looking at serviceWorker.ready()… any idea what the use-cases are for it? |
| 15:38 | <annevk> | JakeA: no |
| 15:39 | <JakeA> | annevk: Ok, not just me then |
| 15:40 | <annevk> | JakeA: yeah, I asked in the bug; it seems like you need to use register() anyway |
| 15:40 | <JakeA> | annevk: I'm not even sure what "ready" means |
| 15:40 | <gsnedders> | Ms2ger: Can we try removing the lxml dependency from Anolis? It should be way quicker in PyPy, because basically all the cost is overhead. |
| 15:40 | <JakeA> | annevk: Does it mean when it becomes the active worker? |
| 15:40 | <Ms2ger> | We can :) |
| 15:41 | <gsnedders> | Ms2ger: Either that or rewrite it in Haskell ;P |
| 15:41 | <annevk> | JakeA: yeah I thought maybe that's it |
| 15:42 | <annevk> | JakeA: that would be somewhat different from register() anyway |
| 15:42 | <annevk> | JakeA: but we also have an event for that |
| 15:42 | <Ms2ger> | Not that :) |
| 15:42 | <JakeA> | annevk: But register() is the only place you can a non-active worker |
| 15:43 | <JakeA> | annevk: Yeah, and we decided that a promise wasn't the right fit, because .active can change without a call to registration |
| 15:43 | <JakeA> | annevk: and it can change multiple times over the life of a page |
| 15:43 | <annevk> | JakeA: I thought the idea was that if you did getAll() you would get all workers, regardless of whether they are active |
| 15:43 | <Domenic_> | NOT USING PROMISES FOR SOMETHING!? IMPOSSIBRU |
| 15:43 | <JakeA> | :D |
| 15:44 | <Domenic_> | I am pretty sure Alex had a use case for serviceWorker.ready() |
| 15:44 | <JakeA> | annevk: ahh ok, yeah, that's possible, I can't remember |
| 15:44 | <Domenic_> | https://gist.github.com/slightlyoff/8927885 |
| 15:44 | <Domenic_> | hmm you guys already seem to be talking about relevant things like .active so you are probably way ahead of me on this |
| 15:46 | <annevk> | JakeA: hmm, looking at it now ready() makes sense for code that doesn't want to deal with registration and still needs to get a handle on things |
| 15:46 | <annevk> | JakeA: e.g. a library that does push as per Domenic_'s link |
| 15:46 | <JakeA> | annevk: Isn't .active already the handle you need? |
| 15:47 | <jgraham> | gsnedders: Rewrite in in rust :p Of course you would need to start by writing a HTML parser and tree library… |
| 15:48 | <gsnedders> | jgraham: :P |
| 15:48 | <annevk> | JakeA: so yeah |
| 15:48 | <gsnedders> | jgraham: Yeah, Haskell's still sounding better. |
| 15:48 | <annevk> | JakeA: except if you want to wait for a possible register() call, but I'm not really sure how that could work so indeed |
| 15:49 | <gsnedders> | I mean, at the end of the day Anolis is just a transformation from one tree to another! |
| 15:49 | <JakeA> | annevk: and the registration call may have come from another tab, so the 'activate' event is better in this case |
| 15:49 | <annevk> | right, given the event this makes little sense |
| 15:50 | <JakeA> | annevk: will add this to the ticket |
| 16:04 | <JakeA> | annevk: Tried to make it clearer https://github.com/slightlyoff/ServiceWorker/issues/174#issuecomment-35096632 |
| 16:05 | <annevk> | JakeA: ta |
| 16:13 | <JakeA> | Domenic_: annevk: In https://gist.github.com/slightlyoff/8927885, is the serviceworker the only place you could receive push messages? |
| 16:23 | <annevk> | Domenic_: seems like you commented on the wrong thread in blink-dev |
| 16:23 | <Domenic_> | annevk: I was trying to be funny... or did the threading go off? |
| 16:24 | <annevk> | Domenic_: I see, slow day here |
| 16:24 | <Domenic_> | yeah, I guess that could have been clearer, "stop torturing them by messing with the Promise API." |
| 16:24 | <JakeA> | Oh, I didn't realise the promises api wsa changing |
| 16:24 | <JakeA> | was* |
| 16:25 | <annevk> | JakeA: yeah that's the plan |
| 16:25 | <annevk> | JakeA: push notifications only really make sense if the app isn't open |
| 16:25 | <JakeA> | I guess .race is still in there to confuse people |
| 16:27 | <JakeA> | Domenic_: "Keep then, reject chain (NOT DEFER, reject!)" what does that mean? |
| 16:27 | <Domenic_> | lol |
| 16:27 | <Domenic_> | *that* sentence was almost certainly designed to confuse people |
| 16:27 | <Domenic_> | it means don't add monadic chain method to promises, neither now, nor in ES7 |
| 16:27 | <JakeA> | It is a fruitless collection of words |
| 16:28 | <JakeA> | Ahh, the whole flatMap thing? |
| 16:29 | <JakeA> | I was playing around with the design of a AsyncMap, it gets quite confusing if the AsyncMap stores promises |
| 16:29 | <JakeA> | Domenic_: See https://github.com/slightlyoff/ServiceWorker/issues/156 |
| 16:30 | <JakeA> | It's one of those weird cases where you want to resolve a promise with a promise without unwrapping |
| 16:30 | <Domenic_> | I don't understand why you want to store promises in AsyncMap. |
| 16:31 | <Domenic_> | The most natural semantics (for promises, not monads) is option B |
| 16:31 | <Domenic_> | in terms of what you can implement in JS |
| 16:32 | <Domenic_> | wait no not optionB |
| 16:32 | <Domenic_> | I will write it up |
| 16:33 | <annevk> | JakeA: btw, I'll be in SF April 1-8 for service workers and summit thingy |
| 16:33 | <JakeA> | annevk: What days are you available for serviceworkering? |
| 16:34 | <annevk> | JakeA: 7/8 is still best |
| 16:34 | <annevk> | JakeA: the tentative dates from the email |
| 16:35 | <JakeA> | annevk: Oh yeah, I do have that in my calendar |
| 16:35 | <JakeA> | Cool |
| 16:35 | <annevk> | great |
| 17:08 | <dglazkov> | good morning, Whatwg! |
| 17:31 | <annevk> | morning dglazkov |
| 18:30 | <TabAtkins> | Domenic_: I gave examples in the es-discuss thread of why you'd want to store a promise. |
| 18:30 | <TabAtkins> | And not have it auto-chain. |
| 18:33 | <TabAtkins> | Domenic_: I suppose that my example is exactly the example in the OP of SW issue 156 |
| 19:22 | <Hixie> | so...... |
| 19:22 | <Hixie> | if you have an <area> that is used by two image maps |
| 19:22 | <Hixie> | one in a <dialog> and one in the page |
| 19:23 | <Hixie> | and you call .focus() on the <area> |
| 19:23 | <Hixie> | should it focus: |
| 19:23 | <Hixie> | a) the first one in tree order |
| 19:23 | <Hixie> | b) the first one in tree order in whatever (dialog/page) is currently focused, if possible, else the first one in tree order |
| 19:25 | <Hixie> | c) the last one that was focused, if any has been focused, or otherwise b) |
| 19:25 | <Hixie> | c) the last one that was focused, if any has been focused, or otherwise a) |
| 19:25 | <Hixie> | e) something else |
| 19:25 | <Hixie> | i'm leading to a. |
| 19:30 | <Hixie> | oh... wait... |
| 19:30 | <Hixie> | i'm silly |
| 19:30 | <Hixie> | well, no, i'm not silly |
| 19:30 | <Hixie> | the above is fine, but i was thinking it was more general than that in my head |
| 19:30 | <Hixie> | but it really is very specific to <area> |
| 19:44 | <annevk> | how does <dialog> makes this different from just two image maps? |
| 20:11 | <Hixie> | annevk-cloud: only difference would be that now there's more than one group of controls, since each dialog has its own group |
| 20:19 | <jamesr__> | TC39 seems confusing |
| 20:20 | <Hixie> | how so? |
| 20:21 | <jamesr__> | i'm trying to follow the threads describing what the status of Promises is |
| 20:23 | <Hixie> | ah, yeah |
| 20:23 | <Hixie> | i assume they just didn't know it had shipped |
| 20:23 | <Hixie> | (they presumably wouldn't have changed it if they knew that) |
| 20:26 | <jamesr__> | the part in parens is the part i'm not sure about, which is what i find confusing |
| 20:27 | <Hixie> | why would they change it if it had shipped? once it's shipped it almost certainly can't change unless it's really really early on, and even then there's a huge cost |
| 20:31 | <Hixie> | TabAtkins or any other CSS mavens around: does CSS have some equivalent to "tree order"? |
| 20:32 | <Hixie> | if an element generates multiple boxes that are scrollable, then it might have multiple scrollable regions, and i'd like to be able to pick the "first one" by some useful definition |
| 20:32 | <Hixie> | but i don't know how to say that |
| 20:36 | <jamesr__> | i can't speak strongly, though. these promises threads are very long |
| 20:36 | <jamesr__> | Hixie: CSS doesn't define a box tree properly anywhere, sadly |
| 20:37 | <jamesr__> | there may be an approximation somewhere though |
| 20:39 | Hixie | figures out these regions have to be in the tab order too, and so defers to that for now |
| 20:39 | <Hixie> | (that'll come and bite me in the ass later...) |
| 20:42 | <Hixie> | i wish someone could explain to me the value of all the chatter on some of the w3c lists about whether something is "at risk" or not and whether it should be in or out for CR and when to ship the CR and all the crap |
| 20:42 | <Hixie> | just publish it all. why would you want to _not_ get the patent protection. |
| 20:43 | <Hixie> | and publish it asap. why would you want to wait. |
| 20:43 | <Hixie> | sigh |
| 20:43 | <Hixie> | (hm, actually i guess they might not theoretically all be in the tab order.) |
| 20:58 | <TabAtkins> | Hixie: Yeah, you can do tree order on the box tree. |
| 20:59 | <Hixie> | oh, cool. what should i reference when doing that? |
| 20:59 | <TabAtkins> | http://www.w3.org/TR/CSS21/intro.html#formatting-structure |
| 21:00 | <TabAtkins> | It's not really "defined", per se, but that's the right ref for people to know what you're talkinga bout. |
| 21:15 | <Hixie> | TabAtkins: is there any plan for a real definition that i can reference? |
| 21:15 | <TabAtkins> | Plan, yes. Timetable, no. |
| 21:15 | <Hixie> | i mean, people will "know what i mean" even without a ref... :-) |
| 21:15 | <Hixie> | k |
| 22:21 | <Hixie> | seriously. running. out. of. words. in. the. english. language. |
| 23:04 | <jamesr__> | mint some new words for en-hixie |
| 23:04 | <Hixie> | people complain when i do that :-( |
| 23:11 | <Hixie> | the fact that my training in the scientific method has so much bearing on my job is freaking ludicrous |
| 23:12 | Hixie | continuous trying to reverse engineer blur() |
| 23:12 | <Hixie> | continues, even |
| 23:49 | <SimonSapin> | https://pbs.twimg.com/media/A6cKmvQCcAAApzT.png:large is my attempt at CSS box tree |
| 23:52 | <Hixie> | dear kittens |
| 23:52 | <Hixie> | what is that |
| 23:52 | <Hixie> | what do the arrows represent? containership? |
| 23:52 | <TabAtkins> | All the various categories of "box" that CSS uses. |
| 23:53 | <TabAtkins> | I don't think the arrows represent any strict relationship. |
| 23:53 | <TabAtkins> | It's definitley *sometimes* containership |
| 23:53 | <Hixie> | i could tell that some of the things on there were types of "box", yes :-P |
| 23:53 | <cabanier> | is there an XOR box in there? |
| 23:54 | <cabanier> | no, there |
| 23:54 | <Hixie> | i was confused by the xor thing too |
| 23:54 | <cabanier> | are 2 |
