| 00:00 | <Domenic> | Yeah, pretty much |
| 00:01 | <Domenic> | The plan is to use `mixin` instead of `[NoInterfaceObject] interface` and then say you can only `implements` such `mixin`s |
| 00:01 | <Domenic> | Or maybe we'll have `mixes` as `implements` v2 |
| 03:05 | <MikeSmith> | I wonder how https://bugs.chromium.org/p/chromium/issues/detail?id=682521 fits with the Console spec |
| 03:07 | <MikeSmith> | that is, does the spec or other current implementation specify a way to control console verbosityーfor the console to show messages that are not shown by default |
| 03:08 | <MikeSmith> | or maybe this is out of scope for the console spec and instead just an implementation-specific thing |
| 04:02 | <Domenic> | Yeah I mean it depends on how they plan to expose that |
| 04:02 | <Domenic> | E.g. is this only for deprecation warnings |
| 04:02 | <Domenic> | Or is this supposed to be web developer exposed |
| 04:20 | <karlcow> | MikeSmith: does it relate to the levels of errors? In firefox devtools there are categories: Errors and Warnings |
| 04:21 | <karlcow> | … for JS. Error, Warning, Reflow for CSS. Logging has a lot more stuff. |
| 04:22 | <karlcow> | all of these you can activate and deactivate them. |
| 07:20 | <MikeSmith> | karlcow: I guess that is what the comment at https://bugs.chromium.org/p/chromium/issues/detail?id=568218#c20 refers to |
| 07:21 | <MikeSmith> | Domenic: yeah, web-developer exposed |
| 08:02 | <annevk> | Oh my, DreamHost's SSH instructions are basically "trust the network" |
| 08:02 | <annevk> | They move the server and there's no place to find the new public key securely |
| 08:02 | <annevk> | Why is the SSH culture so broken? Does nobody care? |
| 08:28 | <MikeSmith> | annevk: biting my tongue here |
| 08:28 | <MikeSmith> | don’t want to sound like a broken record but that and other problems would be solved if we fully controlled the environment we’re running things on |
| 08:29 | <annevk> | MikeSmith: oh yeah, I'm okay with exploring moving away from DreamHost for whatwg.org et al |
| 08:30 | <annevk> | MikeSmith: maybe open a whatwg/meta issue? |
| 08:30 | <annevk> | MikeSmith: but this is not specific to DreamHost I think |
| 08:30 | <MikeSmith> | true |
| 08:30 | <MikeSmith> | I fully agree about the general problem |
| 08:30 | <MikeSmith> | accidents waiting to happen |
| 08:31 | <MikeSmith> | well not accidents, but people waiting to get pwned and other people inadvertently training them to be ready to get pwned |
| 08:53 | <MikeSmith> | annevk: OK https://github.com/whatwg/meta/issues/8 raised |
| 12:16 | <rbyers> | MikeSmith: I think Pavel is considering breaking the 1:1 connection between the API and UI. Eg. "Info" in the UI may become disabled by default, but console.info may still be on by default under the "Log" level in the UI. |
| 12:18 | <rbyers> | I'm not sure he wants to add but-yet-another level in the UI below info. Seems like this is impl defined in the console spec, but feel free to raise an issue against it to discuss and/or comment on the bug with your thoughts. |
| 14:29 | <annevk> | yoav: assuming all is okay now I'll be able to squash and merge in a bit |
| 14:30 | <annevk> | yoav: kid got sick again so I'm a bit on and off |
| 14:32 | <tobie> | jyasskin: fyi landing the syntax for mixins is on my high-priority list. |
| 14:32 | <annevk> | tobie: ooh great |
| 14:33 | <tobie> | annevk: now that Domenic explained that it's basically sugar around [NoInterfaceObject], I'm much more confortable addressing it. :) |
| 14:35 | <annevk> | tobie: yeah, it's basically about removing [NoInterfaceObject] |
| 14:35 | <tobie> | annevk: I thought it implied bikesheding the semantics of mixins |
| 14:35 | <tobie> | annevk: so wasn't very keen on getting *that* started. |
| 14:36 | <annevk> | I see, I was wondering why it was being postponed, since at TPAC we decided it was important I think |
| 14:41 | <tobie> | annevk: well, the learning curve for WebIDL is quite something, tbh. |
| 14:45 | <yoav> | annevk: OK, thanks! (absolutely no rush, take good care of the kid :D) |
| 15:50 | <No_se> | For html (5) tags, is it recommended (or at least valid) to place a dir="ltr" everywhere? (Except where the language is rtl) |
| 15:51 | <No_se> | Well, to be more precise: In the opening html tag itself |
| 15:59 | <annevk> | No_se: you can define it there, yes |
| 16:00 | <annevk> | No_se: if not specified at all it defaults to ltr, so not really recommended |
| 16:02 | <No_se> | My usecase: I want to avoid setting i.e. float: right and overwrite it (via dir=rtl selector) with float: left |
| 16:09 | <Domenic> | Dunno if anyone else has opinions on polyfills not deferring to native implementations given all the pain we've seen caused by that in the past (e.g. custom elements, shadow DOM) but if so feel free to chime in at https://github.com/w3ctag/polyfills/issues/2 . Maybe annevk or mathiasbynens. |
| 16:51 | <annevk> | Domenic: I left a reply |
| 16:52 | <annevk> | Domenic: I looked into the URL issue and I think it basically requires a redesign of many states |
| 16:52 | <annevk> | Domenic: we basically lost the information of "/" by the time we are in the "path state" and we need to preserve it if we are to distinguish between "" and "/" for non-special URL paths |
| 16:53 | <annevk> | Domenic: I'm starting to think my earlier suggestion of separating empty paths and non-special hosts makes a lot of sense |
| 16:56 | <annevk> | Domenic: https://github.com/whatwg/html/issues/2271 you should probably state you do support the API concept and the naming convention that would go with that |
| 16:57 | <annevk> | Domenic: might have been too subtle when you pointed that out the first time |
| 17:24 | <Domenic> | annevk: thanks |
| 17:24 | <Domenic> | Good luck with the URL stuff... |
| 17:24 | <Domenic> | I do think splitting the hostname and path changes might work out well |
| 17:49 | <annevk> | Domenic: that polyfill thread is kinda baffling |
| 17:49 | <annevk> | oh well |
| 18:02 | <annevk> | Domenic: I also noticed that new URL("///y", "foo://x/") doesn't quite do what I think it should do |
| 18:02 | <annevk> | Domenic: you end up with foo://y rather than foo:///y (empty host) |
| 18:02 | <annevk> | Domenic: which seems like a plain bug |
| 18:03 | <Domenic> | Hmm I see |
| 18:03 | <annevk> | Domenic: so yeah, I'm going to split them up |
| 18:03 | <annevk> | 1) fix host handling for non-special URLs |
| 18:03 | <annevk> | 2) fix path handling for non-special URLs |
| 18:03 | <annevk> | And 2 requires a revamp of path handling in general I suspect |
| 18:04 | <annevk> | Hopefully all tomorrow |
| 18:51 | <JonathanNeal> | Domenic: re: polyfills, you said “ Defering to native implementations does not provide the desired interop” - polyfills defer to native implementations for performance, no? |
| 18:52 | <Domenic> | JonathanNeal: I sure hope not, since native implementations are usually slower |
| 18:54 | <JonathanNeal> | Is there a qualifier for “usually”? Is that blanket JS, or specific to some browser or even some field (like DOM)? Like, would using the ES5/6 polyfill for Array methods be faster than native? Or DOM4? |
| 18:55 | <JonathanNeal> | s/Or DOM4 … polyfills being faster than native implementations |
| 19:10 | <Domenic> | It's especially try that polyfills are usually faster for ES |
| 19:10 | <Domenic> | It's also true in many smaller cases in DOM |
| 19:10 | <Domenic> | Wide-ranging stuff like custom elements or shadow DOM are where polyfills are slower, but also way less likely to follow the spec. |
| 19:28 | <innovati> | eyyy JonathanNeal |
| 19:29 | <JonathanNeal> | hiii innovati |
| 19:29 | <innovati> | fancy meeting you here ^^ |
| 19:31 | <JonathanNeal> | CSS, JS, HTML; they’re all part of the web. |
| 22:48 | <tobie> | Domenic: had you settled the question around [SameObject] and promise types with Boris? |
| 22:48 | <tobie> | Domenic: i.e. can I merge this thing? |
| 22:49 | <tobie> | Domenic: for ref, it's this thread I'm talking about: https://github.com/heycam/webidl/pull/217#discussion_r87079498 |