| 08:32 | <annevk> | FWIW, I informed the IETF of our forking of WebSocket: https://mailarchive.ietf.org/arch/msg/hybi/2OIyLSs5JjDfiFB_I_HGoSinsqc |
| 09:58 | <zcorpan> | reflecting as URL seems to have more issues. returns resolved URL when the attribute is absent... <a>.href seems to be better defined. looks like there might be an issue with blob: URLs also. annevk thoughts? should reflect as URL reuse <a>.href machinery? |
| 09:59 | <annevk> | zcorpan: I think technically reflecting a URL requires an internal slot for the URL |
| 09:59 | <annevk> | zcorpan: this is a problem for most of the reflecting stuff though, that they require an internal slot |
| 10:00 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3994 - difference between gecko and chromium |
| 10:00 | <annevk> | zcorpan: I filed a bug on IDL to automatically get internal slots for attributes, unless specified otherwise, but you know how well IDL is maintained |
| 10:03 | <zcorpan> | annevk: ok, i think i'll fix some low-hanging fruit today with resolve as url and revisit to do it "properly" some other day |
| 10:06 | <annevk> | Yeah, I think we should fix IDL for the proper fix |
| 10:07 | <annevk> | It would be nice to standardize [Reflect=URL] or some such too |
| 10:07 | <zcorpan> | yeah |
| 10:08 | <zcorpan> | oh the spec does handle absent attribute actually |
| 10:13 | <zcorpan> | is there any attribute that takes a URL and has a default value? I can't find any |
| 10:20 | <annevk> | Seems unlikely |
| 10:20 | <annevk> | Don't know for sure though |
| 10:48 | <annevk> | jgraham: can the web-platform-tests server be used to transmit a response early? |
| 10:49 | <Ms2ger> | What does that mean? |
| 10:50 | <annevk> | Ms2ger: transmit a response before the entire request is in |
| 10:50 | <Ms2ger> | Hmm |
| 10:50 | <annevk> | See https://github.com/whatwg/fetch/issues/229 for context |
| 10:50 | <Ms2ger> | I don't know, but I wouldn't be surprised if it couldn't |
| 10:51 | <jgraham> | annevk: I doubt it |
| 11:41 | <glazou> | zcorpan: ping |
| 11:41 | <zcorpan> | glazou: pong |
| 11:41 | <glazou> | hi |
| 11:41 | <glazou> | I have a question about DOM spec |
| 11:42 | <glazou> | https://dom.spec.whatwg.org/#dom-range-clonecontents is supposed to clone a Range but returns a DocumentFragment :-) |
| 11:42 | <glazou> | because of https://dom.spec.whatwg.org/#concept-range-clone that itself returns a DocumentFragment |
| 11:44 | <Ms2ger> | [NewObject] DocumentFragment cloneContents(); |
| 11:44 | <Ms2ger> | Why would it return a Range? |
| 11:44 | <zcorpan> | Ms2ger was faster than me |
| 11:44 | <zcorpan> | :-) |
| 11:45 | <glazou> | I really need to stop coffee and go back to beer |
| 11:45 | <zcorpan> | glazou: confused with [NewObject] Range cloneRange(); ? |
| 11:45 | <Ms2ger> | Now zcorpan beat me :) |
| 11:45 | <glazou> | zcorpan: I need vacation, that's all; nm and sorry for annoyance |
| 11:46 | <Ms2ger> | Np |
| 11:46 | <glazou> | yeah probably a confusion because of "clone" ; a "clone" operation that does not return the same object type... hmmm... |
| 11:47 | <zcorpan> | it is confusing, agreed |
| 11:47 | <zcorpan> | the concept should maybe be called "clone the contents" |
| 11:48 | zcorpan | can PR |
| 11:48 | <glazou> | yes that would help |
| 11:50 | <benjamingr__> | caitp, littledan__ : hey, I'd love your opinion on https://github.com/nodejs/node/issues/5691#issuecomment-196275629 |
| 13:04 | <caitp> | benjamingr__: as far as I can tell from api.cc, those api methods just call into the self hosted promise implementation anyways |
| 13:05 | <caitp> | so I'm not sure why there would be any difference between them, at least on ToT |
| 13:10 | <caitp> | so, Promise::Resolver::Resolve() will enqueue a microtask, so long as the promise wasn't already resolved |
| 13:12 | <caitp> | oh I see |
| 13:13 | <annevk> | Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25529 might be of interest (about cloning) |
| 13:27 | <annevk> | smaug____: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19962? |
| 13:34 | <smaug____> | annevk: yeah, I guess we could add those, given that Gecko has now innerText too and insertAdjacentHTML() |
| 13:35 | <smaug____> | hsivonen might have some comment |
| 13:35 | <smaug____> | (is he back?) |
| 13:50 | <smaug____> | we need a bot to file browser engine bugs |
| 13:51 | <annevk> | smaug____: I didn't know he was gone |
| 13:53 | <smaug____> | Looks like still away this week |
| 14:45 | <annevk> | Ms2ger: FYI: https://github.com/w3c/DOM-Parsing/issues/4 |
| 14:45 | <annevk> | smaug____: harder to spec than I thought |
| 14:46 | <annevk> | philipj_: I found a bug in Blink, it says insertAdjacentElement returns "Element" in your IDL, but it's actually "Element?" per impl (and now spec) |
| 14:46 | <Ms2ger> | I didn't fix issues with that spec when I edited it, not going to start now :) |
| 14:47 | <zcorpan> | hmmm... http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3998 the spec says absent.href should return http://example.org/ afaict but webkit/chromium/gecko don't do that |
| 14:47 | <zcorpan> | can someone check Edge? |
| 14:47 | <annevk> | Ms2ger: you didn't write that part? I thought you did |
| 14:47 | <annevk> | Ms2ger: anyway, never mind then |
| 14:47 | <Ms2ger> | I probably did write it |
| 14:48 | <annevk> | I should probably fold that whole spec into DOM at some point |
| 14:48 | <Ms2ger> | No time to maintain, though |
| 14:48 | <Ms2ger> | Of course it's in licensing hell now |
| 14:49 | <annevk> | Ms2ger: hmm yeah, I guess the additions are |
| 14:49 | <annevk> | ugh |
| 14:53 | annevk | was about to add CDATASection back but then figured out he isn't 30 yet |
| 14:56 | tantek | lol annevk |
| 14:59 | <zcorpan> | philipj_: still not excited to remove CDATASection? still have a few months :-) https://www.w3.org/Bugs/Public/show_bug.cgi?id=27386 |
| 15:00 | <zcorpan> | https://www.chromestatus.com/metrics/feature/timeline/popularity/113 0.0048% |
| 15:51 | <annevk> | So low and yet too high |
| 16:04 | <KiChjang> | i'm currently writing a white paper on the evolution of HTTP, and am wondering what i can include in there |
| 16:06 | <annevk> | KiChjang: that's a very generic question, anything specific? |
| 16:08 | <KiChjang> | annevk: i'm currently considering how every subsequent versions is trying to fix or improve upon previous versions |
| 16:08 | <KiChjang> | like how HTTP/0.9 is a really simple protocol designed to transfer HTML documents as-is without any metadata attached to responses and requests |
| 16:09 | <annevk> | KiChjang: I guess you could say that HTTP/1.0 obviated the need for <plaintext> |
| 16:09 | <annevk> | but we still have it because HTTP/0.9 was a real thing |
| 16:09 | <KiChjang> | annevk: obviated? |
| 16:09 | <KiChjang> | as in, it assumes plaintext is used? |
| 16:10 | <annevk> | KiChjang: removed the need for |
| 16:10 | <annevk> | KiChjang: HTTP/0.9 did content sniffing, afaik |
| 16:30 | <annevk> | smaug____: perhaps you know what we should do with https://www.w3.org/Bugs/Public/show_bug.cgi?id=28097? |
| 16:31 | <annevk> | Domenic: I thought your custom element work resulted in an abstract operation for creating all elements |
| 16:31 | <annevk> | Domenic: which could then have some kind of "element created steps" associated with it, if specifications needed a hook |
| 16:43 | <Domenic> | annevk: I guess it could. What does that help with though? |
| 16:43 | <Domenic> | annevk: looking through HTML's existing "when the element is created" it's basically just specifying what the UA-callable-only constructor does |
| 16:45 | <annevk> | Domenic: I think the main problem Hixie_ had was with attributes, where browsers assume that elements created by the parser are created with attributes, so the question I guess is what happens for cloning |
| 16:46 | <Domenic> | annevk: https://w3c.github.io/webcomponents/spec/custom/#clone-modifications-to-dom should hopefully cover it? |
| 16:46 | <annevk> | Domenic: I don't immediately know what the observables would be though |
| 16:46 | <smaug____> | annevk: looking |
| 16:47 | <annevk> | Domenic: yeah, shouldn't typeExtension be an optional argument as well? |
| 16:47 | <Domenic> | annevk: my intention was you always supply null. I guess I messed that up in the cloning section. |
| 16:53 | <annevk> | philipj_: FWIW, I might actually add CDATASection back before August |
| 16:53 | <Domenic> | :( |
| 16:53 | <Domenic> | I wish someone would make the parser change |
| 16:53 | <caitp> | do you think it would make sense for browserland SVG to be specified in a living standard? all vendors seem to differ in at least a few ways from the snapshot editions |
| 16:53 | <Domenic> | It seems plausible that using Text nodes would work |
| 16:54 | <annevk> | philipj_: ooh, maybe not, I was thinking it was required for Shadow DOM, but it's not, whatever Shadow DOM adds to Text ends up automatically on CDATASection |
| 16:54 | <Domenic> | caitp: I think it would make sense for everything to be specified in a living standard. But, it's up to the editors who have the bandwidth to work on those technologies, and I don't think the SVGWG is that excited about doing so. |
| 16:54 | <annevk> | Domenic: I think philipj_ tried and it broke tests at least, e.g., some serialization expectations |
| 16:54 | <Domenic> | caitp: in the meantime we have https://html.spec.whatwg.org/#svg-0 |
| 16:54 | <Domenic> | annevk: yeah, i meant try for real |
| 16:54 | <Ms2ger> | A long time ago (when vendor prefixes were still in fashion), I implemented mozSerializeAsCDATA |
| 16:55 | <Ms2ger> | (Never landed) |
| 16:55 | <annevk> | I have pondered about defining SVG, but it's quite a bit of work |
| 16:55 | <annevk> | As is it's quite a mess though, with nothing really well defined 😟 |
| 16:56 | <caitp> | I just meant some basic ways, was trying to figure out why we add @@iterator to SVGxxList interfaces, blink and geck give it a "length" attribute, but apparently webkit doesn't |
| 16:56 | <caitp> | gecko* |
| 16:56 | <caitp> | there are probably other things |
| 16:56 | <annevk> | caitp: I was thinking basics too, e.g., how <svg:script> works |
| 16:56 | <Domenic> | Ooh caitp you're setting yourself up for a PhiStucK email with that "no feature dashboard" entry. Just wait for it... |
| 16:57 | <caitp> | there are enough chromestatus pieces for real features that people consciously care about :x |
| 16:57 | <annevk> | caitp: at some point the complex stuff is hopefully all abstracted through CSS, and then the remaining complex stuff can be abstracted through HTML |
| 17:09 | <jsbell> | Domenic: only if joe doesn't beat phistuck to it... |
| 17:10 | <annevk> | Domenic: hayato: I think tomorrow I'm going to try to add attachShadow(), ShadowRoot and the ShadowRootOrDocument mixin to DOM, and update the various algorithms that need to account for them |
| 17:11 | <annevk> | Domenic: hayato: and then as exercise I'll try to update Fullscreen, if that's feasible without the flat tree |
| 17:11 | <Domenic> | annevk: sounds ambitious, awesome! |
| 17:12 | <annevk> | Just the basic building blocks, but yeah, might end up being more than anticipated, we'll see |
| 17:13 | <annevk> | The alternative is probably working on outstanding Fullscreen/Storage issues |
| 17:50 | <annevk> | jsbell: https://github.com/whatwg/encoding/issues/18, do it? |
| 17:58 | <jsbell> | annevk: yep. |
| 18:07 | <annevk> | jsbell: so exciting to get rid of that |
| 18:08 | <annevk> | jsbell: makes the constructor argument are a bit useless, but okay |
| 18:08 | <annevk> | s/are// |
| 18:14 | <Domenic> | annevk: can't you just remove the constructor argument? |
| 18:15 | <annevk> | Domenic: I guess we could, though it's probably impossible to introduce a different argument at a later stage |
| 18:16 | <annevk> | Domenic: but I can make sure that doesn't happen by leaving some kind of note in the source |
| 18:16 | <Domenic> | yeah that makes sense |
| 18:16 | <Domenic> | can also remove the encoding internal slot |
| 18:16 | <annevk> | Actually, should probably keep the first argument, so that it keeps throwing for invalid values |
| 18:18 | <annevk> | But yeah, can simplify a couple of things |
| 18:18 | <Domenic> | why though |
| 18:18 | <annevk> | Next big change after this will probably be streams integration |
| 18:18 | <Domenic> | don't throw just ignore it |
| 18:19 | <Domenic> | annevk: I don't think anything else on the platform validates an argument it does nothing with. |
| 18:19 | <annevk> | Domenic: I guess that's true, I'm mostly worried what happens if we want to add that argument back, but maybe that's not going to be a thing |
| 18:19 | <Domenic> | annevk: yeah I don't think it will be. It'll all be fine... |
| 18:25 | <KiChjang> | what's HTTPbis? |
| 18:26 | <gsnedders> | KiChjang: the set of RFCs that obsoleted RFC 2616 |
| 18:26 | <gsnedders> | KiChjang: the revision to HTTP/1.1 specs |
| 18:27 | <KiChjang> | i thought RFC2616 was the latest HTTP/1.1 spec |
| 18:27 | <KiChjang> | so there are others |
| 18:27 | <gsnedders> | KiChjang: RFC 7230–7235 |
| 18:28 | <KiChjang> | gsnedders, ah, so SPDY stuff? |
| 18:28 | <gsnedders> | KiChjang: no |
| 18:28 | <gsnedders> | KiChjang: this is a simple revision of the HTTP/1.1 spec |
| 18:29 | <gsnedders> | KiChjang: SPDY became HTTP/2.0 which is RFC 7540 |
| 18:40 | <KiChjang> | is HTTP/2 stateful? |
| 18:40 | <KiChjang> | it looks like it is, since it has this concept of a stream |
| 18:53 | <smaug____> | annevk: finally looked at https://www.w3.org/Bugs/Public/show_bug.cgi?id=28097 but couldn't immediately understand what it even is about. Why any of this stuff has anything to do with host-inclusiveness ? |
| 18:55 | <smaug____> | oh, hmm, is this about the cycle? |
| 18:56 | <smaug____> | which isn't there... |
| 18:56 | <smaug____> | yeah, don't really understand the bug |
| 18:58 | <smaug____> | pre-insertion validity check shouldn't probably use "host-including inclusive ancestor " |
| 21:19 | <gsnedders> | KiChjang: what sort of statefulness do you mean? |
| 21:20 | <gsnedders> | KiChjang: there's no statefulness exposed at the request/response layer beyond what HTTP/1.1 has as the messaging semantics are unchanged |
| 21:48 | <Domenic> | TabAtkins: where did "Document Object Model" come from for https://storage.spec.whatwg.org/#normative ? |
| 21:48 | <Domenic> | TabAtkins: nevermind, I guess that hasn't been recompiled in a long time |
| 21:51 | <TabAtkins> | Domenic: Yeah, it used to be that SpecRef had the W3C version squatting on "DOM", and Shepherd named their ref (which points to the WHATWG copy) dom-ls, so you reffed that. I've since fixed things - the Shepherd ref is now just "DOM", and Bikeshed has an explicit fixup for the squatted WHATWG specs, so biblio-reffing "DOM" will grab all the right data from |
| 21:51 | <TabAtkins> | SpecRef's WHATWG-DOM reference. |
| 21:51 | <Domenic> | TabAtkins: but it will still show [WHATWG-DOM] as the name, IIRC? Kind of sad. |
| 21:52 | <TabAtkins> | It's the result of me applying a lowest-cost fix, until SpecRef fixes itself properly. |
| 21:52 | <Domenic> | I have little confidence in SpecRef fixes sadly |
| 21:52 | <TabAtkins> | Eh, I believe he'll fix it eventually. |
| 21:53 | <TabAtkins> | In the meantime, it only shows as [WHATWG-DOM] in the biblio index; any explicit `[[DOM]]` tags in your source stay that way. |
| 21:54 | <Domenic> | Which honestly just seems like a bug? A link text [DOM] going to a [WHATWG-DOM] in the index? |
| 21:54 | <Domenic> | It's like, no, I clicked on [DOM], not [WHATWG-DOM]... now I need to scroll up to find where [DOM] is defined... argh it isn't there, where did it go? |
| 22:05 | <TabAtkins> | Like I said, lowest-effort fix. Removing this when SpecRef is fixed will be a 2-line deletion commit. |
| 23:14 | <tobie> | Domenic: Fwiw, I'm happy to accept a PR in Specref that fixes the problem. I just don't have time to look into it myself right now. |
| 23:17 | <tobie> | I agree that this is a problem and want to fix it. |
| 23:18 | <tobie> | But I also want to make sure it doesn't get overwritten with the next update and that we don't loose references to previous specs in the process. |
| 23:45 | <rniwa> | Domenic: is anyone working on new custom elements API in Blink? |
| 23:49 | <Domenic> | rniwa: kochi is |
| 23:49 | <rniwa> | Domenic: cool. is there an issue that I can follow? |
| 23:51 | <Domenic> | rniwa: I will ask him |
| 23:51 | <rniwa> | Domenic: thanks |
| 23:51 | <rniwa> | Domenic: between late March and early April, which one do you prefer for a telecon? |
| 23:52 | <Domenic> | rniwa: probably early April; TC39 is the last week of March. |
| 23:52 | <rniwa> | Domenic: okay |
| 23:55 | <rniwa> | Domenic: alright, I just asked for one on public-webapps |
| 23:55 | <rniwa> | Domenic: btw, we really appreciate your work for the spec :) |
| 23:56 | <rniwa> | Domenic: so are you guys going to be fine with having an explicit method for upgrading custom elements? |
| 23:56 | <rniwa> | Domenic: and not upgrading any elements by default when there is no definition at the time of element construction? |
| 23:56 | <rniwa> | Domenic: or do you still want the HTML parser to set the flag for auto-upgrades? |
| 23:57 | <Domenic> | rniwa: yeah we're having a meeting tomorrow to make sure everyone is on the same page but it looks like maybe a move to in-document-only upgrades is on the table |
| 23:57 | <Domenic> | like you originally proposed |