| 00:09 | <MikeSmith> | TabAtkins: https://stackoverflow.com/questions/43215834/what-is-mean-of-participate-in-definition-of-normal-flow-in-w3-spec |
| 03:57 | <annevk> | The above very much depends on the new state, might well be that b is more future proof, but in reality you likely have to vet everything |
| 14:23 | <tobie> | annevk: related to the houdini thread you @-mentioned me in (https://github.com/w3c/css-houdini-drafts/issues/239), would like your thoughts on https://github.com/heycam/webidl/pull/332 |
| 14:24 | <annevk> | tobie: I think I'd prefer just moving it as much as possible to its own section, apart from syntax bits and such of course which should be inlined |
| 14:25 | <annevk> | tobie: I don't really think we need to then hide that section |
| 14:26 | <tobie> | annevk: OK, I'll see if that's doable. iirc the problem is you have legacy stuff both in the language and bindings part |
| 14:26 | <tobie> | annevk: which makes the whole thing hard to move |
| 14:27 | <tobie> | annevk: will give it a go a report back |
| 14:27 | <annevk> | tobie: I see, I guess the other thing I'd note is that this doesn't seem like a huge priority |
| 14:28 | <annevk> | tobie: part of the problem with index/named getters is that they're not marked "legacy" so folks still pick them up; I think if we more clearly marked them in syntax they wouldn't be picked up as much |
| 14:28 | <annevk> | tobie: at least folks don't pick up the other legacy bits |
| 14:29 | <tobie> | Well, it's a frequent point of contention, so heads up in the spec function as social lubricant. |
| 14:30 | <annevk> | I think indexed getter is the main one that is still somewhat contentious and that's because TabAtkins never participated in the long debate we've had on it and nobody else seems to really remember it much or maybe nobody wants to talk about it again |
| 14:31 | <annevk> | But indexed getter is also not marked legacy |
| 14:31 | <botie> | okay, annevk. |
| 14:31 | <annevk> | botie: no |
| 14:31 | <botie> | annevk: i'm not following you... |
| 14:33 | <tobie> | annevk: fwiw, greying out stuff in the spec is faster than renaming everything downstream. As a stopgap measure. |
| 14:33 | <TabAtkins> | Man, I remember those debates, don't even play. |
| 14:33 | <TabAtkins> | But yeah, it's not marked legacy, and new features are defined to depend on it, so what is a person supposed to think? |
| 14:34 | <annevk> | Other than CSSOM no new features that I'm aware of |
| 14:34 | <TabAtkins> | I mean in WebIDL - value iterators |
| 14:35 | <annevk> | I think we mainly added value iterators for legacy interfaces, but we should have more clearly indicated that |
| 14:35 | <annevk> | They were the new ArrayClass for NodeList and such |
| 14:36 | <TabAtkins> | No, kv iterators have non-legacy usecases, v iterators have exactly the same. |
| 14:54 | <TabAtkins> | Seriously, we're in a bind here. We want array-likes, so we try to reach for the best thing available - indexed getters/setters - and get smacked down for them being bad (but not marked as bad, so how was anyone to know?). |
| 14:55 | <TabAtkins> | Then we reach for the second-best thing - value iterator, so people can at least turn the object into an array easily - and whoops that requires us to implement indexed getters again. |
| 14:56 | <TabAtkins> | Then I'm like "welp, what if I hack around this by using a kv iterator instead, that doesn't depend on broken legacy-but-not-marked-as-such features" and get yelled at for hacking around a problem. |
| 14:57 | <TabAtkins> | I really can't win here. :( |
| 14:58 | <annevk> | TabAtkins: I hear you, I wish Domenic could make some time and I really wish arv was still around since he felt pretty strongly about all this |
| 14:59 | <TabAtkins> | Easiest path to something useful is to fix value iterators to just be value iterators, not a sneaky backdoor into full Proxies for no reason. |
| 14:59 | <TabAtkins> | There's literally no reason for value iterators to be built on top of indexed getters right now, it's all downside and makes the feature more complicated. |
| 15:01 | <TabAtkins> | As far as I can tell, the current reason is just "there were some subtle details we couldn't agree on, so instead of answering them, let's just rebase this on top of an existing feature that we presumably are already okay with the details of". |
| 15:01 | <annevk> | TabAtkins: I see |
| 15:01 | <TabAtkins> | But I answered those subtle details, at least the ones the bz brought up, in the thread - feel free to crib my answers. |
| 15:01 | <annevk> | TabAtkins: if value iterators are all we need and Domenic is okay with the overall API shape we should just do that |
| 15:02 | <annevk> | TabAtkins: do we have a bug about separating them from getters? |
| 15:02 | <TabAtkins> | Yeah. It's not *ideal*, but it lets people do `let arr = [...cssomThing];` |
| 15:02 | <TabAtkins> | One of the bugs had me and bz discussing that, let me go track it down. |
| 15:03 | <TabAtkins> | Yeah, end of https://github.com/heycam/webidl/issues/291 |
| 15:04 | <TabAtkins> | The "Remove [LegacyArrayClass]" bug |
| 15:09 | <annevk> | TabAtkins: https://github.com/heycam/webidl/issues/338 |
| 15:36 | <frivoal> | Hi, I'm reviewing a test that seems sensible, but there are 2 non essential parts of it I am not sure which spec justifies. (1) Is there any spec that says that if you make a focused element display:none, it must keep the focus? (2) Is there any spec that says that if you call the .focus() method on a display:none element, it must not get focused? |
| 15:37 | <annevk> | frivoal: HTML would define the latter, the former would be implied |
| 15:38 | <annevk> | (if nothing says you can lose focus, it won't be lost) |
| 15:39 | <frivoal> | annevk: thanks for confirming the former part. For the HTML, do you know it does say that, or do you merely suspect it does? I've tried reading that section, but I got lost trying to follow definitions I did not previously know. |
| 15:40 | <frivoal> | I can get to the bottom of it if needed, but if someone already knows the answer that's easier :) |
| 15:43 | <annevk> | frivoal: I'll have a look |
| 15:44 | <frivoal> | thanks |
| 15:45 | <annevk> | frivoal: per step 1 of https://html.spec.whatwg.org/multipage/interaction.html#focusing-steps the element needs to be rendered (unless it meets some special condition which I guess it doesn't meet in this test) |
| 15:47 | <frivoal> | isn't that sentence only about dialog elements. am I failing to parse the nesting in that sentence? |
| 15:48 | <annevk> | frivoal: I guess you're right, but even then you end up at otherwise since there's no scrollable area |
| 15:49 | <annevk> | frivoal: although I guess you can argue it's a focusable area, so yeah, maybe 2 is not defined |
| 15:50 | <annevk> | frivoal: it does seem like 2 not being defined would be a bug in HTML (if we indeed don't want focusing for those cases) |
| 15:50 | <frivoal> | it seems reasonable and interoperable, but I just had a hard time finding hard backing for it in the spec |
| 15:50 | <frivoal> | oh, no, actually I think we get there |
| 15:51 | <frivoal> | must be "a focusable area" and definition of "focusable area" includes being rendered |
| 15:51 | <frivoal> | so we're good |
| 15:54 | <frivoal> | thanks |
| 15:57 | <annevk> | Oh, the dfn of the element and its actual definition are a bit apart |
| 15:57 | <annevk> | Hmm, don't like that so much |
| 16:19 | <zcorpan> | annevk: how about <dfn><var>features</var> separators</dfn>? |
| 16:20 | <zcorpan> | or maybe just <dfn>feature separators</dfn> |
| 16:35 | <annevk> | zcorpan: I guess that or adding window in front of the others |
| 16:35 | <annevk> | zcorpan: I don't care strongly, seems like something Domenic might care about |
| 18:00 | <annevk> | TabAtkins: you might want to encourage the CSS WG to do some triage now and then, none of https://github.com/w3c/css-houdini-drafts/pulls has some reason listed why they're not applied |
| 18:01 | <annevk> | TabAtkins: and they're all pretty old |
| 18:05 | <tantek> | that would be the Houdini TF |
| 19:10 | <bterlson> | Interested in TC39 & ECMAScript goings-on? /join #tc39 |
| 19:15 | <TabAtkins> | f'ing network spammers |
| 19:15 | <TabAtkins> | :p |
| 19:15 | <bterlson> | They're the worst!! |
| 20:53 | <smaug> | rbyers: do you happen to know if it is a known issue that Chrome 59 on up-to-date Fedora 25 has somehow broken high dpi handling |
| 20:53 | <smaug> | the UI is super tiny |
| 20:53 | <smaug> | it was working fine earlier today, but then I updated Fedora and Chrome |
| 21:15 | <rbyers> | smaug: No that's news to me. I'll look for a bug. I know high-dpi on Linux hasn't been super-well supported (where Linux is different from ChromeOS anyway). |
| 21:16 | <rbyers> | smaug: Don't see one from a quick search. Please file a bug with details (eg. may be WM-specific or something, like so many Linux-specific UI/events issues) |
| 21:18 | <smaug> | ok. will file |
| 21:18 | <smaug> | thanks |
| 22:44 | <nox> | annevk: Isn't the Fetch spec wrong to not skip all body-related steps when request's mode is "websocket"? |