| 07:07 | <annevk> | Domenic: now I wonder what happens when you assign to a long and it's out-of-range |
| 07:09 | <Domenic> | annevk: The setter will never receive it, but yeah if you have contentattribute="1111111111111111111111111"... I suspect that does fall back to the default, but I wonder. |
| 07:09 | <annevk> | Domenic: oh right, it's because all the magic is in the getters that we can't rely on Clamp and such, meh |
| 07:11 | <annevk> | Although, maybe if ConvertToInt took EnforceRange and Clamp as arguments of sorts we could actually be using that |
| 07:16 | <annevk> | It would be nice to investigate if we could have fewer number parsers, but that would be a hell of a yak shave for this project, probably worth at least a follow-up issue though |
| 07:19 | <annevk> | Domenic: I was also thinking that we could express enumerated attribute tables as two arrays/sets in Web IDL, but it might get rather unwieldy and we'd have two sources of information; arguably that's the case with something like [ReflectURL] as well, but that would make it pretty glaring |
| 07:20 | <Domenic> | Yes, I have had similar thoughts. However I believe most engines have some sort of IDL for enumerated attributes. It doesn't match the spec's model that well, but somehow gives the same observable results. |
| 07:21 | <Domenic> | I think maybe it only takes care of the getter/setter behavior and doesn't take care of producing a "state" which the rest of the spec/implementation can consult? |
| 07:21 | <annevk> | Hmm, perhaps with some custom logic for the bad cases? I guess we need to look into that first then. |
| 07:21 | <Domenic> | So like you don't need to identify that "rect" and "rectangle" both go to the same state, in the IDL. |
| 07:22 | <annevk> | Hmm, but if you set to one you get the other back, right? You'd have to encode that somehow. |
| 07:23 | <Domenic> | Ah, only if "limited to only known values", and area's shape="" is not one of those... |
| 07:23 | <Domenic> | Let's see... |
| 07:24 | <annevk> | I gotta go for a bit, prolly back when you're away, but happy to see a thought dump 😀 |
| 07:26 | <Domenic> | In Chromium at least it appears to be all hacks that are just enough to work with the spec's current model. There's a special ReflectEmpty which you can use for cases where the empty string maps to another keyword and is not the canonical keyword. If we ever created something that was both (a) limited to only known values; and (b) had two non-empty-string values mapping to a single state, Chromium would be unable to cope. |
| 07:45 | <Ms2ger> | Or would need to hack around it some more :) |
| 07:47 | <Domenic> | Right, or just write custom bindings. It's just sad that there's no ready-made answer waiting for us that fits with the spec's model. |
| 08:29 | <annevk> | Domenic: on the other hand, maybe we shouldn't add such stuff? |
| 09:40 | <annevk> | So clamping doesn't affect the setter steps apparently. How is that even useful? The getter will give you 1000, but the content attribute (which carries the semantics, supposedly) will indicate 5000 or whatever it was set to... |
| 09:41 | <annevk> | Some of this stuff we should probably prefix with legacy to discourage further usage of. |
| 11:24 | <Domenic> | Did you test the setter in implementations? I don't really trust the spec very much... |
| 12:58 | <annevk> | Domenic: yeah I did |
| 12:58 | <annevk> | Domenic: and I guess it makes some sense because you cannot constrain setAttribute() anyway, but still, it all seems rather awkward |
| 13:00 | <annevk> | Domenic: there is definitely some redundancy in the specification around clamping, the default value concept, positive numbers; I think we could simplify that somewhat and at the very least remove some redundancy here and there, but would prefer to sort that out as a follow-up to ease review and make it clearer to future people where we made mistakes |
| 14:57 | <littledan> | Andreu Botella: are you familiar with HttpOnly cookies? |
| 15:00 | <Ms2ger> | I thought the issue was that response.headers.get("Set-Cookie") would expose cookies to scripts that shouldn't be |
| 15:00 | <zcorpan> | Domenic: are we changing how html numbers in attributes are parsed? |
| 15:01 | <Andreu Botella> | I guess you could filter Set-Cookie headers depending on whether they are HttpOnly, but that would mean parsing the header at filter time, which could cause parsing differences to result in XSS I guess |
| 15:03 | <Ms2ger> | Does response.headers do any normalization right now? |
| 15:06 | <annevk> | littledan: are you talking about an API for the cookie store or an API for cookie "suggestions" on a Set-Cookie header of a response, minus those marked HttpOnly? |
| 15:07 | <annevk> | littledan: the former has some difficulties as per the review feedback from Mozilla (and WebKit?) on the Cookie Store API, not sure anyone seriously proposed the latter |
| 15:08 | <annevk> | Ms2ger: no, it either happens in the HTTP parser or is passed along as-is, but we do filter on top... |
| 15:09 | <annevk> | zcorpan: no, we're fixing some aspects of reflection in https://github.com/whatwg/html/pull/8496 |
| 15:30 | <annevk> | https://twitter.com/jaffathecake/status/1628001142037745664 is pretty interesting Jake Archibald |
| 15:31 | <annevk> | I wonder what happens when you present folks with Response.json() and response.json() |
| 15:34 | <Jake Archibald> | annevk: ohh, I brought up Response.redirect() vs response.json() in one of the replies, but I'd forgotten that Response.json() was a thing. |
| 15:34 | <annevk> | Oh lol, Mastodon is worse https://hachyderm.io/@jaffathecake@mastodon.social/109902664880383769 |
| 15:34 | <Jake Archibald> | annevk: the difference in the results for EventTarget on Mastodon is blowing my mind a bit |
| 15:36 | <annevk> | Stuart Langridge's reply actually makes me think that forcing the prototype notation through will be better for everyone in the long term |
| 15:37 | <Jake Archibald> | I just feel that fewer and fewer people know what the prototype is. Since we got Class in JS |
| 15:37 | <Jake Archibald> | But I'd take it over what MDN currently does |
| 15:38 | <Jake Archibald> | But I think array.map() is fiiiine. Doesn't need to be Array.prototype.map() |
| 15:38 | <annevk> | I guess it's still going to be difficult with mixins |
| 15:38 | <Jake Archibald> | I'd be fine with the URL being Array/prototype/map |
| 15:39 | <Jake Archibald> | Yeah, I realised my document.querySelector example should technically be parentNode.querySelector |
| 15:39 | <annevk> | Perhaps the real answer is "both" or some such, you're prolly right that presenting instance methods on instances is more useful |
| 15:40 | <Jake Archibald> | There's no perfect answer |
| 15:40 | <annevk> | array.map(arg, arg2, ...) <small>(Array.prototype.map)</small> |
| 15:41 | <Jake Archibald> | Or array.map() as the page title, but Array > prototype > map breadcrumbs? |
| 15:41 | <annevk> | In standards we do present them as instance methods in domintro boxes |
| 15:44 | <annevk> | Jake Archibald: right, as long as there's a way to find instance methods and static methods and as long as they can have the same name (as with json()) I think it'll work and people have the opportunity to learn |
| 15:45 | <Jake Archibald> | +1. I guess currently, there's no way for MDN to document Response.json() |
| 15:45 | <annevk> | Yeah, we did file an issue on that |
| 17:50 | <annevk> | Domenic: I haven't merged https://github.com/whatwg/html/pull/8496 because I think it would benefit from one final look by you |
| 17:50 | <annevk> | Domenic: I have been doing some of the ARIA work that I also see as a necessary next step and plan to tackle: https://gist.github.com/annevk/2ffb664fd4c9b5070556866ae9a5a416 |
| 17:51 | <annevk> | Domenic: probably need to schedule a call with the current editors as ARIA is very weird about how it describes attributes |
| 17:52 | <annevk> | Domenic: and am also still interested in fixing the non-ARIA-related follow-ups, including those you asked for; I would like to do them separately for blame purposes and reviewer fatigue (I think I already mentioned that somewhere, but summarizing here just in case) |
| 18:17 | <TabAtkins> | Sigh, I still need to figure out the Bikeshed story for "instance and static methods with the same name". |
| 18:21 | <annevk> | TabAtkins: oh yeah, we avoided that I guess due to the mixin |
| 18:22 | <TabAtkins> | The problem is I'm gonna need to make a backwards-incompatible change to IDs. It's probably fine if I change static member IDs as they're pretty rare, but still, ugh. |
| 18:26 | <annevk> | TabAtkins: when you do please don't land the PR immediately and instead give everyone a couple weeks to create fixed IDs that match the current IDs |
| 18:27 | <annevk> | TabAtkins: using the breaking changes thread |
| 18:27 | <TabAtkins> | Yup def |
| 21:15 | <zcorpan> | [].map() :) |
| 21:26 | <TabAtkins> | Hm, is the requirement that literal %s in a URL be percent-encoded an HTML requirement or a more general URL requirement? |
| 21:27 | <TabAtkins> | Wondering whether I should fix this in Bikeshed or in WebRef. |
| 21:54 | <TabAtkins> | Answering my own question - looks like it's a URL requirement, and WebRef is just wrong in reporting URLs without non-encoded %s in them (generated from IDs having %s). |