2019-10-01
[17:01:04.0000] <Domenic>
wanderview: https://github.com/whatwg/whatwg.org/issues/253

[17:52:08.0000] <MikeSmith>
TimothyGu: about any of those redirects, you can talk to me. But as far as the HTML51 AND HTML52 TRs, it's intentional that they don't redirect. It's not an oversight. That's how I was specifically asked by W3C to handle those.

[17:53:39.0000] <MikeSmith>
TimothyGu: If you feel strongly that those should be redirected too, lemme know why and I can can try to make a few case to plh

[17:58:10.0000] <TimothyGu>
MikeSmith: ah, didn't know that was intentional. it's fine in that case

[18:03:22.0000] <MikeSmith>
TimothyGu: OK (FWIW, the rationale is those are the published Rec/historical versions)

[18:04:06.0000] <MikeSmith>
there are still a bunch of other redirects I need to set up (e.g., for the WebSocket spec fork)

[18:04:40.0000] <TimothyGu>
MikeSmith: if you're not already aware, there's https://wiki.whatwg.org/wiki/Fork_tracking

[18:05:01.0000] <TimothyGu>
for instance, https://w3c.github.io/dom/ still doesn't redirect yet

[18:05:05.0000] <TimothyGu>
though the TR does

[18:15:19.0000] <MikeSmith>
TimothyGu: oh, OK, yeah, will fix that

[22:52:14.0000] <hsivonen>
TabAtkins: does that mean that Chrome ships a block list of faux friend sets?

[01:21:02.0000] <annevk>
Domenic: I'm reporting these 404 spammers as well btw

[02:17:20.0000] <annevk>
TIL https://en.wikipedia.org/wiki/HTTPRange-14 has its own Wikipedia page

[04:42:39.0000] <MikeSmith>
hsivonen: annevk: https://github.com/validator/validator/issues/874 Can you look and comment about whether the handling of the encoding names (with extra characters) is conforming per spec, or if instead it's.a checker bug

[04:43:41.0000] <annevk>
MikeSmith: that's a valid bug

[04:44:10.0000] <annevk>
MikeSmith: the original HTML spec used the wrong kind of matching for labels and I suspect the validator^Wchecker code hasn't been updated when I changed all that

[04:44:52.0000] <annevk>
MikeSmith: new matching is basically strip whitespace from start and end and then do an ASCII case-insensitive match against all possible enums

[04:45:49.0000] <MikeSmith>
annevk: OK, thanks much

[04:48:35.0000] <MikeSmith>
hmm,  I guess this may actually be a bug in the HTML parser. And if so, that means Gecko has the same bug

[04:52:57.0000] <annevk>
MikeSmith: Firefox decodes data:text/html,<meta charset=utf%208>%c2%80 and data:text/html,<meta charset=utf8>%c2%80 quite differently here

[05:52:08.0000] <MikeSmith>
annevk: Ok

[06:44:15.0000] <cybai>
/me wonders those update 404.html are sent by spam bots 🤔

[06:46:18.0000] <annevk>
I report them as such

[06:46:33.0000] <cybai>
annevk: ah! I should do that too :D


2019-10-02
[18:30:41.0000] <Krinkle>
/me spent way too much time reading the DOM spec only to realise jQuery was at fault all along – https://bugs.chromium.org/p/chromium/issues/detail?id=1010363

[22:12:28.0000] <TimothyGu>
Krinkle: does that mean the bug should be closed?

[22:24:35.0000] <Krinkle>
TimothyGu: yep, can't do that myself it seems, though

[22:28:27.0000] <TimothyGu>
Krinkle: done

[23:59:39.0000] <hsivonen>
MikeSmith, annevk: Actually updating the Java side of the HTML parser to the Encoding Standard is still a TODO item. :-(

[00:00:46.0000] <hsivonen>
Using encoding_rs via JNI would probably be the easiest solutions but not the acceptable Java culture solution that would keep the parser reusable by others

[00:09:57.0000] <MikeSmith>
hsivonen: Ah, so the Gecko parser doesn't use that encoding code at all?

[02:43:39.0000] <hsivonen>
MikeSmith: it doesn't

[07:51:07.0000] <JakeA>
https://wicg.github.io/contact-api/spec/#contactsmanager - this API takes a sequence of an enum type. Due to WebIDL, this means it'll throw if an unrecognised type is provided. This feels inconsistent with dictionary types which ignore additional keys. Is there any prior art here? Should the API take a sequence of DOM strings instead and filter manually?

[08:07:21.0000] <Ms2ger>
JakeA, you means ContactsManager.select()? Note that it rejects anyway if you pass anything but a subset of ContactsManager.getAvailableContactProperties()

[08:09:29.0000] <JakeA>
Ms2ger: yeah, that's the behaviour I'm questioning. It does it in the prose, but IDL will be doing it anyway. It feels unlike how we usually design APIs, but I'm looking for a second opinion (or some prior art)

[08:10:28.0000] <Ms2ger>
I'm not aware of any prior art

[09:48:44.0000] <lgrahl>
o/ Hey folks, I'm currently testing the StorageManager API and I'm confused... navigator.storage.persist does not ask for a permission in Chrome (it does in Firefox) and just rejects it. I can't find anything in the interwebz about that problem. Any hints?

[09:55:49.0000] <Mek>
lgrahl: https://developers.google.com/web/updates/2016/06/persistent-storage explains some of chromes behavior (assuming it hasn't changed since then). I.e. it auto-grants in some conditions, and auto-denies in other conditions, but we'll never show a prompt.

[09:57:30.0000] <lgrahl>
Tried bookmarking it and it didn't work :/

[09:57:35.0000] <lgrahl>
I'll try the home screen thing

[10:03:19.0000] <lgrahl>
Guess I'll call it a day and fiddle with it tomorrow. Thanks, Mek!


2019-10-03
[06:20:41.0000] <AndresInSpace>
Hello everyone, if I have a proposal to make for HTML changes, I would submit to the https://github.com/whatwg/html/issues right?

[07:33:19.0000] <annevk>
AndresInSpace: yup, though I’d encourage you to read the FAQ and Working Mode documents first

[07:44:20.0000] <lgrahl>
Why does (persistent) storage have to be such a nightmare? :(

[07:47:02.0000] <lgrahl>
annevk: So, since you specced the StorageManager API (which I like)... do you know of an API to increase the quota? And the quota returned from Firefox is... weird.

[07:51:15.0000] <AndresInSpace>
annevk: so if I wanted to post this up https://github.com/WICG/intrinsicsize-attribute/issues/16#issuecomment-537692814  - should I just reference it in https://github.com/whatwg/html/issues/4961 or create a new issue?..

[08:33:05.0000] <annevk>
AndresInSpace: that’s a new issue as picture requires a diff design

[08:46:21.0000] <AndresInSpace>
annevk: it's more around <source> than <picture> ? i guess

[08:46:31.0000] <AndresInSpace>
but would still be a new issue right

[08:46:56.0000] <AndresInSpace>
asking just cause I see https://github.com/whatwg/html/issues/4961 references <video> which utilizes <source>

[09:26:18.0000] <annevk>
AndresInSpace: <video> uses <source> in a very different way than <picture> does

[09:26:44.0000] <annevk>
AndresInSpace: I suppose we should still consider if they ought to behave in equivalent ways

[09:28:29.0000] <AndresInSpace>
annevk: well considering that everyone is asking for <video>, <picture>, <object>, etc for ratios.. and they all utilize <source> i think it would be ideal to implement consistency

[09:28:43.0000] <AndresInSpace>
not sure on the technicals though

[09:33:24.0000] <annevk>
AndresInSpace: <object> does not, but yeah, maybe

[09:34:26.0000] <AndresInSpace>
ah my bad

[11:57:28.0000] <AndresInSpace>
annevk: I posted, is my first time so if I did anything wrong please let me know

[11:57:33.0000] <AndresInSpace>
appreciate your time


2019-10-04
[12:41:05.0000] <weijunli>
do you know any tricky way, perhaps with jquery or any framework that allow me to

[12:41:05.0000] <weijunli>
 get all images on a directory using the input tag but everything done dynamicall


2019-10-08
[05:46:43.0000] <zcorpan>
https://wpt.fyi/results/webvtt?label=experimental&label=master&aligned has incredibly bad results for rendering/ still :-/

[05:51:56.0000] <jgraham>
zcorpan: Any idea if they're failures to implement the features or the tests not being flexible enough to allow for a (permissible) range of rendering?

[05:56:50.0000] <zcorpan>
jgraham: I think many of the failures are in principle the latter, but really the spec doesn't allow much variation of rendering

[06:04:11.0000] <jgraham>
Bleh

[06:08:55.0000] <zcorpan_>
jgraham: looking at webvtt/rendering/cues-with-video/processing-model/basic.html in chrome, it looks like chrome makes the rendering area smaller than the video. The spec used to allow this, but can't find it in the spec now

[06:09:47.0000] <zcorpan_>
https://github.com/w3c/webvtt/commit/6f73c35e7c70c90592cbb6468e75afe4248dfca2

[06:14:30.0000] <jgraham>
zcorpan_: Maybe that spec change is defacto wrong?

[06:16:16.0000] <zcorpan_>
jgraham: well maybe, but i don't think so. the spec previously allowed multiple different renderings, which was bad. but maybe instead of requiring 0% edge margin it should require the exact margin chromium uses, i dunno

[06:16:34.0000] <zcorpan_>
filing a crbug

[06:21:14.0000] <zcorpan_>
https://bugs.chromium.org/p/chromium/issues/detail?id=1012242

[07:18:57.0000] <annevk>
JakeA: happy to elaborate on that short tweet btw, only so many characters to go around there

[07:29:58.0000] <JakeA>
annevk: only if you've got time! It's just a curiosity, but I've seen it trip up lots of things like media players

[07:33:24.0000] <annevk>
JakeA: with bfcache-style semantics it might not be too bad, but there's probably still a lot I'm missing as I'm not super comfortable with all aspects of bfcache

[07:33:47.0000] <annevk>
JakeA: and it's not clear how stable all bfcache bits are given that COOP makes it more involved

[07:34:26.0000] <JakeA>
same tbh. I should read up on COOP. Recording some HTTP 203 stuff tomorrow… maybe if I learn it enough on the train home…

[07:39:51.0000] <zcorpan_>
annevk: now I'm curious how COOP affects bfcache

[07:40:21.0000] <annevk>
zcorpan_: currently it blows it away

[07:42:06.0000] <annevk>
zcorpan_: the main problem is that COOP replaces the top-level browsing context

[07:42:26.0000] <zcorpan_>
annevk: ok. is this specced in https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e ?

[07:43:08.0000] <annevk>
JakeA: I guess the other main difference between bfcache and a disconnected frame is that with bfcache the Window is still connected

[07:43:34.0000] <annevk>
zcorpan_: no, session history in general is a mess

[07:44:13.0000] <JakeA>
I'm not sure what difference that makes in practice, but I guess I need to read COOP first

[07:45:36.0000] <zcorpan_>
annevk: ok. yeah. un-messing session history & navigation would be nice certainly :)

[07:46:45.0000] <annevk>
JakeA: that's not really related to COOP, but it means that if you have a Window object reference, .top and such still make sense

[08:44:34.0000] <JakeA>
annevk: zcorpan_ posted this on Twitter https://readable-email.org/list/whatwg/topic/the-so-called-magic-iframe-feature. "It turns out that there's a lot of code in browsers that can't cope with a disconnected iframe being alive."

[08:47:01.0000] <annevk>
JakeA: yeah, unclear how much of that is true with bfcache though

[08:47:23.0000] <JakeA>
true

[08:47:24.0000] <annevk>
JakeA: though maybe a lot of it is and it's the same issue as with COOP

[08:48:00.0000] <annevk>
I dunno, maybe not, it's hard

[09:24:24.0000] <ondras>
mkwst: a quick question: as an authorization provider, i would like my cookies to be sent cross-site. what is the recommended transition now?

[09:24:35.0000] <ondras>
send them with samesite=none for non-safari browsers?


2019-10-09
[01:55:33.0000] <annevk>
/me wonders what decade microformats.org will be on HTTPS

[01:58:26.0000] <zcorpan>
annevk: jgraham: https://twitter.com/zcorpan/status/1181855911570280448

[01:59:36.0000] <annevk>
zcorpan: good luck

[02:17:51.0000] <jgraham>
zcorpan: If someone provides a script to run curl against a checkout of wpt I expect we can add that to the ci configuration somehow

[02:18:02.0000] <jgraham>
Do weekly runs or somesuch

[02:18:14.0000] <jgraham>
(just for those tests ofc)

[02:51:57.0000] <zcorpan>
jgraham: cool! Can you follow up with Daniel? I gave some pointers in the twitter thread

[03:01:47.0000] <jgraham>
I don't think I have any way to follow up with Daniel. Well apart from email I suppose

[03:02:41.0000] <jgraham>
And per twitter he's still doing the boring "their url spec" thing rather than engaging productively

[03:12:20.0000] <annevk>
TabAtkins: in Encoding I get "FATAL ERROR: Multiple local 'attribute' &lt;dfn>s for 'TextDecoderCommon' have the same linking text 'encoding'."

[03:13:17.0000] <annevk>
TabAtkins: now TextDecoderCommon does have an internal slot called encoding and an attribute with the same name, but the attribute is annotated with attribute in its <dfn>

[03:15:28.0000] <annevk>
TabAtkins: and it was building yesterday which makes the recent changes to Bikeshed suspect

[03:19:10.0000] <annevk>
TabAtkins: filed https://github.com/tabatkins/bikeshed/issues/1537

[05:31:48.0000] <annevk>
littledan: why would an Agent flag be passed down to JS?

[05:31:57.0000] <annevk>
littledan: doesn't JS have access to its Agent?

[05:32:10.0000] <littledan>
annevk: It would be; it would just *also* be passed down to JS in the dynamic import case

[05:32:19.0000] <littledan>
and JS and Wasm would need to duplicate the checks

[05:32:34.0000] <littledan>
so I think the check logically makes more sense in the SW/HTML specs

[05:36:12.0000] <annevk>
littledan: ah yeah, I keep forgetting the dynamic import case and I suspect Shu might have too

[05:36:36.0000] <littledan>
are there any problems with the [[Async]] approach?

[05:37:24.0000] <annevk>
littledan: is that in the current PR? I found the current PR weird because it directly peeks at [[PromiseState]]

[05:37:49.0000] <littledan>
annevk: That's a separate issue. That's due to an editorial decision Domenic strongly encouraged me to take. I could revert it if you'd like

[05:39:26.0000] <littledan>
but I guess we took that decision when we were assuming that ServiceWorker would just wait for the TLA to happen

[05:42:33.0000] <annevk>
littledan: I guess I lost the plot a bit, but if what ljharb is objecting to is the status quo of the proposal I think I'm okay

[05:42:49.0000] <annevk>
littledan: that is, it seems best for developers if the error surfaces as early as possible

[05:43:13.0000] <Domenic>
I agree a parsing error is better

[05:44:23.0000] <littledan>
(I'm also skeptical of this kind of lazy error)

[05:45:27.0000] <littledan>
annevk: Yeah, many people in TC39 encouraged the ServiceWorker group to reconsider the restriction on async modules, but understood that it was also a decision that W3C/WHATWG can make. In the HTML PR, I included a note encouraging caution in making the restriction.

[05:46:31.0000] <littledan>
I think we should've been a little more active in the presentation in encouraging people to have some more appreciation for the good technical work going on in other venues, but it's a little tricky rhetorically

[05:50:22.0000] <annevk>
I find it interesting how folks in TC39 can both appreciate JavaScript not having much API surface and therefore being useful in many contexts and then not appreciating that when they add more surface it might be less generic

[05:50:50.0000] <annevk>
It's probably not the same people

[06:00:50.0000] <annevk>
littledan: I added a comment that hopefully helps Shu

[06:08:37.0000] <annevk>
Domenic: also have a theory for the logo failures now; Firefox doesn't support crossorigin for rel=icon I'm pretty sure, might not even be part of the standard

[06:33:03.0000] <Domenic>
Ah that makes sense why the logo might be consistently borked, interesting

[06:34:25.0000] <Domenic>
And I guess the image cache is causing it to break the <img> (although I doubt the spec uses the image cache for <link>)

[06:34:51.0000] <Domenic>
I still think HTML being inconsistent with other specs is a good hypothesis for styles. Styles are the really bad problem IMO.

[06:35:20.0000] <annevk>
Happy to patch that in a bit

[06:35:51.0000] <annevk>
That rel=icon doesn't use the image cache is more a result of image loading not being fully defined than anything else I suspect

[06:43:04.0000] <annevk>
Domenic: https://github.com/whatwg/html/pull/4994

[10:35:37.0000] <ondras>
hm, does mkwst visit here from time to time?

[14:14:38.0000] <TabAtkins>
ondras: Yes, tho pinging him on Twitter might be more reliable.


2019-10-10
[21:56:30.0000] <annevk>
TabAtkins: for Bikeshed regression tests you can turn on fatal behavior for warnings et al on WHATWG documents

[21:56:48.0000] <annevk>
TabAtkins: maybe that would have caught this

[22:00:25.0000] <TabAtkins>
I'd prefer the tests to not stop. 😀 But I do need to start collecting the console output as part of the test artifacts.

[00:07:54.0000] <annevk>
TabAtkins: yeah, I meant that if you see output for WHATWG, it’s a regression

[00:08:27.0000] <annevk>
Might be intentional and something we should address, but then we find out ahead of time and can plan for it

[04:29:36.0000] <ondras>
TabAtkins: thanks! :)

[15:05:37.0000] <zcorpan>
annevk: https://simon.html5.org doesn't have a directory index anymore, I noticed just now (but /htmlpubquiz works)

[15:16:39.0000] <zcorpan>
annevk: maybe I should move the stuff in there somewhere else


2019-10-11
[20:54:01.0000] <MikeSmith>
annevk: hsivonen: https://github.com/validator/validator/issues/877 seems to be another issue about the parser in the HTML checker not conforming to the current spec requirements for <meta charset> parsing — I guess because it’s following the old requirements, right?

[20:56:31.0000] <MikeSmith>
the specific case cited in the issue is <meta http-equiv="Content-Type" content="text/html; xxxxxcharset=iso-8859-2">, which it parses as a iso-8859-2 despite the junk xxxxx characters

[20:56:40.0000] <MikeSmith>
the other cases are:

[20:56:50.0000] <MikeSmith>
<meta http-equiv="Content-Type" content="text/html; charset charset=iso-8859-2">

[20:56:50.0000] <MikeSmith>
<meta http-equiv="Content-Type" content="text/html; charsetxxxxxcharset=iso-8859-2">

[20:56:53.0000] <MikeSmith>
<meta http-equiv="Content-Type" content="text/html; charsetcharset=iso-8859-2">

[20:57:25.0000] <MikeSmith>
... for all of which it reports an "The legacy encoding declarationdid not contain charset= after the semicolon..

[20:57:35.0000] <MikeSmith>
..error

[20:57:56.0000] <MikeSmith>
I’m not sure what the OP is saying that expected behavior should be

[21:48:42.0000] <annevk>
MikeSmith: I don’t really recall the details of that algorithm, but bugs seem likely


2019-10-14
[06:14:31.0000] <annevk>
I wish GitHub organization owners could delegate some of their powers, but not all. It makes no sense for the WHATWG that only owners get to invite people to it, but it makes a lot of sense that only a few people get to create and delete repositories.

[09:36:49.0000] <annevk>
foolip: thanks for pushing https://github.com/w3c/gamepad/issues/8

[09:37:09.0000] <annevk>
foolip: somehow nobody involved understands it's actually important to get lifetimes right

[09:37:51.0000] <annevk>
(excepting Ted here, I suppose, but he's no longer doing browsers anyway)

[09:38:36.0000] <foolip>
annevk: np, I just followed links until I found what seems like the root problem.

[09:38:59.0000] <foolip>
annevk: sorting it out doesn't seem all that hard, but we'll see

[09:39:14.0000] <annevk>
foolip: that's what I thought, but it's also 4yo

[09:49:47.0000] <foolip>
annevk: by now probably live objects are required for web compat, and TBH that seems sensible for the API shape. To return a new "Gamepad" each time something has changed, even if there's a stable ID, seems kinda bizarre. API shape should have been different for that to make sense.

[09:53:58.0000] <annevk>
foolip: I don't really care, as long as it's defined and it actually ends up working that way

[09:54:15.0000] <annevk>
foolip: I recall there being some issues with true liveness as well, but dunno

[14:34:54.0000] <TabAtkins>
Yeah, live makes the most sense there also for intended use-case of polling in a loop.


2019-10-15
[00:59:16.0000] <annevk>
mkwst: I like those referrer policy changes, will check with others to make sure we'd follow Chrome shipping those, but I don't really see why not

[06:40:12.0000] <annevk>
Domenic: what's the story for <label> pointing to a FACE?

[06:43:25.0000] <Ms2ger>
To a what now?

[06:45:40.0000] <annevk>
Ms2ger: form-associated custom element

[06:46:15.0000] <Ms2ger>
Ugh

[06:46:36.0000] <annevk>
Ms2ger: why the sad FACE?

[06:47:04.0000] <Ms2ger>
/me eyes annevk beadily

[06:50:43.0000] <annevk>
Domenic: ooh I see

[07:00:40.0000] <annevk>
/me files https://github.com/whatwg/html/issues/5009 since although it's somewhat addressed, it's not great

[12:24:37.0000] <ondras>
so... trying to extend HTMLTableElement; `get tBodies' does not seem to work (Firefox: called on object that does not implement interface HTMLTableElement)

[12:24:50.0000] <ondras>
is this *supposed* to work? :)

[12:26:00.0000] <ondras>
https://jsfiddle.net/xa7z5grq/

[12:30:26.0000] <annevk>
ondras: no, https://github.com/heycam/webidl/issues/484#issuecomment-349373116

[12:32:29.0000] <ondras>
annevk: okay, thanks. I basically have no idea what the linked issue/comment means, but I take that as a confirmation that it is not supposed to work :)

[12:33:38.0000] <annevk>
ondras: a subclass has a different brand, basically

[12:34:03.0000] <ondras>
okay

[12:34:31.0000] <ondras>
my initial idea was "get tBodies() { return super.tBodies; }" but this failed as well :/

[12:35:52.0000] <annevk>
You can maybe bind a call with an instance of an actual table

[12:36:30.0000] <annevk>
It might be worth raising this use case somewhere to see if we should reprioritize

[12:37:39.0000] <ondras>
this is the most-useless-hobby-experimental-timewaste ever; probably not a reason to reprioritize

[12:38:09.0000] <annevk>
Fair

[12:38:19.0000] <ondras>
it all started well with simple sublcasses to learn customelements v1. but unfortunately the project's nature then required to sublass <table>

[12:38:33.0000] <ondras>
also, I still have no idea why {extends:"table"} is necessary for the construction

[12:38:43.0000] <ondras>
but the spec is probably going to explain that to me

[12:40:33.0000] <annevk>
It should explain brand checks too

[12:41:03.0000] <annevk>
IDL does anyway, though might not use the term brand


2019-10-16
[02:03:15.0000] <bkardell>
I was chatting with some folks at igalia's hackfest and the q came up why is <a href> not in the allowed list for ability to have a shadow dom added to it -- no one could recall.  I reached out to some others and beyond some general "I think maybe it had something to do with ... activiation behavior?" we couldn't really seem to recall... Does anyone recall?

[04:31:10.0000] <annevk>
bkardell: I think in retrospect it's unfortunate that we didn't have ElementInternals before as that is the right place to attach shadow trees

[04:40:51.0000] <Domenic>
https://hacktoberfest.digitalocean.com/details#spam says if we tag the spam pull requests as "invalid" then they might not get credit for making them

[04:43:44.0000] <annevk>
Domenic: I saw that, but I don't like this scheme as it puts the onus on us for a problem of their creation

[04:44:00.0000] <Domenic>
I agree, just not sure what else to do

[04:44:10.0000] <annevk>
Domenic: it'd be better if they created a GitHub-wide label "hacktoberfest" we'd apply to successful contributions

[04:44:45.0000] <annevk>
I guess I've been reporting spammy-looking PRs and getting explanations of hacktoberfest...

[04:45:16.0000] <hsivonen>
Is WPT coverage for focus/blur good?

[04:46:02.0000] <annevk>
I'd expect it to be improved given recent focus efforts

[04:48:48.0000] <Domenic>
the actual events themselves are probably the biggest missing piece

[04:49:13.0000] <hsivonen>
Domenic: as in it doesn't test the focus/blur events?

[04:54:27.0000] <annevk>
hsivonen: pretty sure there are some tests for those, but there are 6 focus events or so and that's not well covered (or defined)

[05:12:30.0000] <Domenic>
In particular I think nobody's tried writing tests since webdriver appeared and made a lot of these things actually testable.

[06:06:16.0000] <hsivonen>
annevk, Domenic: OK. Thanks. I guess mochitest-plain is then the best indication of whether I'm breaking the Web

[06:21:10.0000] <bkardell>
annevk:  but do we remember the reason, or is there a thing we can do to correct this now?

[06:21:57.0000] <annevk>
bkardell: we don't want to create more edge cases, basically, there's an issue covering <a> somewhere

[06:22:06.0000] <annevk>
I guess I can quickly find it...

[06:24:31.0000] <annevk>
bkardell: https://github.com/w3c/webcomponents/issues/511 you were involved in an issue that was duplicated against that...

[06:25:22.0000] <bkardell>
lolol

[06:26:02.0000] <bkardell>
thanks annevk

[10:31:20.0000] <TabAtkins>
re: the hacktoberfest page, lol at a dang *monospace* font having a definitely-monospace "fi" ligature, wtfffff

[12:34:26.0000] <ondras>
TabAtkins: :)

[12:35:47.0000] <ondras>
unrelated: is CustomElement allowed to have no constructor() at all?

[13:00:30.0000] <annevk>
ondras: a custom element needs one, no?

[13:05:33.0000] <ondras>
annevk: seems to work without...

[13:06:56.0000] <ondras>
https://jsfiddle.net/mfrgyd29/

[16:18:24.0000] <zcorpan>
["altGlyph", "altGlyphDef", "altGlyphItem", "animateColor", "glyphRef"] are the SVG element names with case fixup in https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inforeign that are not in https://svgwg.org/svg2-draft/eltindex.html

[16:25:18.0000] <zcorpan>
SVG attributes with HTML fixup not in SVG 2 ["attributeType", "baseProfile", "glyphRef", "requiredFeatures", "viewTarget", "zoomAndPan"]

[16:26:46.0000] <zcorpan>
seemingly now new SVG elements or attributes with mixed case that aren't in the html parser list, which is good

[16:37:10.0000] <zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7285

[16:39:28.0000] <zcorpan>
I guess this is https://github.com/whatwg/html/issues/2168


2019-10-17
[17:23:36.0000] <gsnedders>
https://docs.google.com/presentation/d/1iDV-n3LTShhwL_B0I0jfWPVQ6j7RfrQHEjY850m4TL0/edit#slide=id.g62404ae426_0_12 if anyone wants to comment on my kinda half-written but more-or-less final draft about contributing to specs

[18:25:51.0000] <MikeSmith>
https://www.statnews.com/2019/10/16/reduced-brain-activity-extends-life-study/

[18:25:58.0000] <MikeSmith>
think less, live longer

[18:26:06.0000] <MikeSmith>
> The discovery was so surprising that it’s taken two years to be published (in Nature) because of how much additional data the outside scientists reviewing the study requested.

[18:26:14.0000] <MikeSmith>
> “If you say you have a cat in your backyard, people believe you,” he said. “If you say you have a zebra, they want more evidence.”

[20:38:58.0000] <Domenic>
ondras: all classes have a constructor. If you don't declare one the default is `constructor(...args) { super(...args); }`

[21:19:50.0000] <annevk>
gsnedders: slides look good, but not much to review otherwise 😊

[23:07:56.0000] <ondras>
Domenic: great, thanks for explanation

[01:42:57.0000] <hsivonen>
https://www.w3.org/Consortium/mission mentions One Web, but is there a write-up that more directly says what it means?

[03:32:37.0000] <MikeSmith>
hsivonen: off the top of my head, no. But I’ll ask others

[03:59:40.0000] <MikeSmith>
hsivonen: after some asking, I find it seems likely there isn’t a write-up anywhere that directly says what it means

[04:03:14.0000] <hsivonen>
MikeSmith: thanks

[04:04:44.0000] <Ms2ger>
Does it mean anything?

[04:04:58.0000] <hsivonen>
(I was hoping to find some appeal-to-authority material for making the case that it's bad on principle for a given HTML byte stream to show different text depending on whether the user's browser has German or Japanese UI localization.)

[04:05:46.0000] <hsivonen>
(German here standing in for random Latin and Japanese for random non-Latin.)

[05:53:47.0000] <annevk>
hsivonen: MikeSmith: https://www.w3.org/2006/Talks/1106-sb-OneWeb-Mobile2/#(5)

[05:54:20.0000] <annevk>
It often seems to be used as a gateway to talk about the mobile web 🙂

[05:56:17.0000] <hsivonen>
annevk: thanks. (doesn't fit my use case)

[05:56:44.0000] <hsivonen>
also, it's not often that I need to wait for an image to load with my Internet connection

[05:57:09.0000] <annevk>
hsivonen: if you take a broad definition of device it kinda works, but yeah

[05:58:19.0000] <hsivonen>
(hmm. given how slowly it loaded, I expected the image on the slide to be _huge_, but it's less than half a megabyte)

[06:16:47.0000] <annevk>
How does codepen even update? Only at random intervals?

[06:17:10.0000] <annevk>
Live DOM Viewer variants are often so confusing to me

[06:19:24.0000] <jgraham>
hsivonen: I think you have to appreciate w3.org recreating the late 90s loading experience for old slides :)

[06:19:36.0000] <hsivonen>
jgraham: :-)

[06:20:20.0000] <jgraham>
annevk: Oh I thought I was the only one who find them confusing

[08:02:03.0000] <annevk>
I quite like Glitch, but it feels heavyweight for trial and error

[14:52:12.0000] <Domenic>
Glitch can be a bit less heavyweight if you use a single glitch instance and add new pages for new test cases. Mine is https://boom-bath.glitch.me/.

[14:52:41.0000] <Domenic>
I also find the VS Code extension helps me edit things quicker, partially because the Glitch online editor is sub-par.


2019-10-18
[21:12:46.0000] <annevk>
Ooh yeah, if there integration with my editor… Will look into that. Reusing one seems interesting too.

[23:44:52.0000] <Ms2ger>
Huh: https://bugs.webkit.org/show_bug.cgi?id=202843

[00:32:56.0000] <MikeSmith>
Ms2ger: he’s doing that to get some hacktoberfest. gonna forward-date all the existing commits

[04:25:25.0000] <ondras>
what is the recommended way to make a <child> custom element react to its <parent> attribute's change? mutation observer? custom event?

[09:50:34.0000] <Domenic>
I wonder if our Wattsi tooling would become easier to use if it were compiled to wasm https://twitter.com/steveklabnik/status/1185212379753267202

[16:47:52.0000] <MikeSmith>
Domenic: definitely seems worth experimenting with at least


2019-10-19
[19:11:26.0000] <Domenic>
I guess we would still need a wasm runtime though, so e.g. Node.js.

[21:11:05.0000] <MikeSmith>
Domenic: would also need to handle interaction with the highlighter

[21:11:36.0000] <Domenic>
Yeah I mean if they've done all the work wiring up the FreePascal libraries then their HTTP library should be in there too and it could "just work"

[21:14:20.0000] <MikeSmith>
yeah

[21:15:41.0000] <Domenic>
So I guess the best end state we can hope for is adding a Node.js dependency in exchange for people being able to run wattsi locally at all times

[21:25:15.0000] <MikeSmith>
yeah but seems like that would still be a lot better than requiring contributors to install fpc and build wattsi

[21:25:53.0000] <MikeSmith>
and better that if we were to try to provide pre-compiled binaries for different OSes

[21:29:53.0000] <Domenic>
Agreed


2019-10-21
[16:33:14.0000] <Mek>
is there any (easy) way to pipe a nodejs readable stream into a whatwg writable stream or vice versa?


2019-10-22
[20:02:20.0000] <Domenic>
Mek: nope

[20:02:34.0000] <Domenic>
Mek: well, there are adapter packages on npm


2019-10-23
[04:13:20.0000] <ato>
annevk: $("html").focus() makes document.activeElement <html> in Firefox, but <body> in Chrome. Is this expected?

[04:48:58.0000] <Ms2ger>
Well, no

[04:49:46.0000] <ato>
I guess this is technically something a user could make happen through interaction with the Tab key.

[04:49:53.0000] <ato>
But it’s more a concern for automation, e.g. WebDriver.

[05:09:05.0000] <annevk>
ato: dunno, https://html.spec.whatwg.org/#focusing-steps looks broken as it changes the focus target to the viewport, but then nothing seems to really account for that (and the way it becomes the viewport also uses the wrong language)

[07:08:19.0000] <Domenic>
There's a mapping from viewport to document element somewhere

[07:09:00.0000] <Domenic>
https://html.spec.whatwg.org/#dom-documentorshadowroot-activeelement I think viewport -> Document -> body element

[07:09:27.0000] <Domenic>
This is extremely indirect and I suggested in https://github.com/whatwg/html/issues/4607 that we try to collapse everything to document element or body element and get rid of the "viewport' business.

[07:09:44.0000] <Domenic>
Although zcorpan pointed out "How should this work for viewports where there is no <body> element (like SVG)?"

[07:27:27.0000] <zcorpan>
saying that it's the Document that has focus could work, but doesn't map so well to the API, since it's window.focus() not document.focus()

[07:31:37.0000] <Domenic>
IMO activeElement is the more important API to match than the before-the-dot component of .focus()

[07:31:59.0000] <Domenic>
So I would probably define something like "the topmost focusable element" which for HTML is body and for SVG is ???

[07:32:21.0000] <zcorpan>
Domenic: #focusing-steps sometimes sets |new focus target| to a document, sometimes to a viewport. Is that a bug? (Haven't checked if the focus PR changes this)

[07:32:25.0000] <Domenic>
(maybe "default focused element" I dunno. "topmost" is probably not right given <html tabindex="0">)

[07:32:44.0000] <zcorpan>
Domenic: but <body> itself is not focusable unless you set tabindex

[07:33:06.0000] <Domenic>
zcorpan: yeah so "default focused element" seems better then

[07:38:11.0000] <ato>
annevk: Thanks. I’ll file an issue later today.

[07:40:08.0000] <annevk>
Domenic: activeElement is 1:1 with :focus I hope?

[07:40:39.0000] <Domenic>
I hope so too! But now I'm wondering about body :/

[07:42:15.0000] <zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7303 is different between chrome and firefox

[07:43:22.0000] <zcorpan>
<body> doesn't match :focus when the viewport/document/BC has focus

[07:48:42.0000] <zcorpan>
Domenic: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7306 for svg

[08:36:12.0000] <Domenic>
Well, lovely. So is activeElement or :focus the source of truth as to whether something's focused, I wonder.

[08:36:27.0000] <Domenic>
(I mean, we kind of get to decide ourselves, since it's spec internal.)

[08:37:15.0000] <Domenic>
My instinct is that saying that the body is the currently focused element, and patching things at :focus, is going to be easier than maintaining the body <-> viewport correspondence, and patching things up at activeElement.

[08:37:33.0000] <Domenic>
But maybe that  doesn't work given <body tabindex="0"> or some such.

[08:41:38.0000] <annevk>
Domenic: you'll have to consider documents without <body> too

[08:42:19.0000] <annevk>
Domenic: there's a lot of <body> special casing in specs so it might well make sense, but it can be removed or in case of SVG or something weird it might not be there to begin with

[08:42:36.0000] <Domenic>
Bleh

[08:43:19.0000] <Domenic>
Maybe document then. And patch up document -> body in the activeElement getter. The main thing I dislike is having non-nodes be focusable areas; it makes the model extra complicated.

[08:43:38.0000] <Domenic>
But maybe using non-element nodes isn't much better than using non-nodes.


2019-10-24
[06:52:58.0000] <smaug____>
is there somewhere a list of usage of HTML elements. Like which element is the most common or so. I'd expect span, div and p be perhaps the common ones

[06:55:29.0000] <MikeSmith>
smaug____: Opera MOMA  data

[06:57:44.0000] <annevk>
Pretty sure bkardell showed me a tool at TPAC that has such data, but I forgot the name

[07:01:17.0000] <smaug____>
oh right, on Sunday he showed something

[07:05:02.0000] <MikeSmith>
smaug____: https://raw.githack.com/operasoftware/devopera-static-backup/master/http/dev.opera.com/articles/view/mama-basic-document-structure/index.html#elems

[07:05:23.0000] <MikeSmith>
https://raw.githack.com/operasoftware/devopera-static-backup/master/http/devfiles.myopera.com/articles/570/elemlist-url.htm

[12:21:04.0000] <smaug____>
(hmm, why am I missing some irc notifications today)

[12:21:51.0000] <smaug____>
MikeSmith: thanks, though I was thinking frequency of all the elements. I could think of if one counts all the elements on all the pages, div and span might be rather common

[12:22:00.0000] <smaug____>
body wouldn't be common at all


2019-10-25
[17:00:02.0000] <Mek>
if I have some readable stream, and some writable stream. After I call readable.pipeTo(writable), is there any way to abort that later?

[17:02:33.0000] <Mek>
ah, I guess I can pass in an AbortSignal...

[17:06:41.0000] <Mek>
although that doesn't seem to work, or maybe I'm holding it wrong...

[17:56:39.0000] <MikeSmith>
smaug____: I suspect you still find that <a> was the most-frequently used

[17:58:24.0000] <MikeSmith>
and as far others, that data still would seem to suggest that <p> is more-frequently used than <div>

[20:38:31.0000] <Domenic>
Mek: not sure the AbortSignal aborting is implemented yet in Chrome

[20:39:33.0000] <Mek>
ah, that explains why it didn't work...

[20:43:30.0000] <Domenic>
Ping ricea... this keeps coming up and I'm not sure where it is on the priority list.

[23:59:00.0000] <ricea>
It's currently not on the list, but it's a small enough job that it maybe doesn't need to be.

[23:59:30.0000] <ricea>
Here's the issue to star if you haven't already: https://bugs.chromium.org/p/chromium/issues/detail?id=902939

[00:49:25.0000] <MikeSmith>
annevk: MDN BCD says StaticRange() constructor is only supported in Blink. Is that accurate?

[00:51:03.0000] <MikeSmith>
(ignoring Edge)

[00:51:43.0000] <MikeSmith>
hmm yeah Can I Use says the same

[00:57:53.0000] <annevk>
MikeSmith: it throws in Chrome for me, but works in Firefox

[00:58:52.0000] <annevk>
MikeSmith: also works in Safari

[00:58:59.0000] <annevk>
MikeSmith: so I guess that sounds backwards?

[01:04:23.0000] <MikeSmith>
annevk: hmm yeah

[01:04:54.0000] <MikeSmith>
/me goes to look at wpt results

[01:06:00.0000] <MikeSmith>
https://wpt.fyi/results/dom/ranges/StaticRange-constructor.html?label=master&label=experimental&aligned&q=staticrange

[01:06:41.0000] <MikeSmith>
annevk: matches what you said — passing in Firefo ans Safari, failing in Chrome

[01:07:04.0000] <annevk>
It'd be quite surprising otherwise 🙂

[01:09:47.0000] <MikeSmith>
well, so much for trusting BCD and Can I Use to be accurate..

[01:10:07.0000] <MikeSmith>
will raise a BCD issue for it

[01:10:26.0000] <MikeSmith>
or just do a PR

[01:35:48.0000] <annevk>
Hard to resist designing an API for Structured Headers

[06:26:54.0000] <annevk>
So the only way to create a BigInt object is with Object()?

[06:40:46.0000] <Domenic>
annevk: sounds right, like Symbol objects.

[06:41:14.0000] <Domenic>
Since the $primitiveType objects are generally evil, but necessary for consistency of the model, they're hidden away so that they're hard to create.

[06:41:17.0000] <Domenic>
(for new types)

[06:41:38.0000] <annevk>
Yeah, I have seen a lot of that discussion, but then promptly forgot about it 🙂

[06:42:00.0000] <annevk>
But today it became relevant as I was looking to convert some old BigInt test


2019-10-28
[07:24:36.0000] <Domenic>
annevk: can you remind me what's the difference between the type of origin isolation created by COEP/COOP and thus cross-origin-isolated, versus by making agent clusters origin-keyed? I'm wondering if self.crossOriginIsolated for the former might be confusing when we also introduce the latter.

[07:26:31.0000] <annevk>
Domenic: the former creates a special type of agent cluster that has more requirements on subresources and generally has less exposed WindowProxy objects

[07:26:59.0000] <annevk>
Domenic: the latter has less isolation from attackable subresources

[07:33:36.0000] <annevk>
the combination would be even more isolated

[07:34:46.0000] <annevk>
I wouldn't mind another name, but I'd like not to be on the hook for trying to come up with one, as getting to this one and having it be agreeable was already a long journey

[12:03:33.0000] <Domenic>
I'll ask around and see if there are other suggestions

[12:03:53.0000] <Domenic>
Let's assume it stays as-is for now.

[12:04:04.0000] <Domenic>
I guess maybe crossOriginIsolated vs. originIsolated

[12:09:24.0000] <TabAtkins>
Theoretically, if we were to add a MQ that matches based on the page's loading state, would the `readyState` name and values be acceptable to reuse? Or are they considered unfortunate legacy stuff?

[14:25:27.0000] <annevk>
TabAtkins: I’d look at the promise-state stuff

[14:25:41.0000] <annevk>
TabAtkins: that’s proposed

[14:37:07.0000] <TabAtkins>
Ah, thanks. That thread doesn't make names *clearer*, particularly, but I do agree we should align there when it happens.

[15:46:41.0000] <zcorpan>
smaug____: https://github.com/HTTPArchive/almanac.httparchive.org/pull/184

[15:47:33.0000] <smaug____>
zcorpan: that would have element popularity ?

[15:47:43.0000] <zcorpan>
smaug____: yes

[15:47:51.0000] <zcorpan>
https://github.com/HTTPArchive/almanac.httparchive.org/blob/9216e287474a13cc59c1929fefabd05281e27116/src/content/en/2019/markup.md#top-elements-and-general-info

[15:48:47.0000] <zcorpan>
ignoring html, head, body, the most common elements by frequency are div, a, span, li, img, script, p, option

[15:49:02.0000] <smaug____>
great, thanks

[15:49:26.0000] <smaug____>
very surprising that html, head or body are popular at all

[15:49:41.0000] <smaug____>
mm, are those still per site

[15:49:54.0000] <smaug____>
yes

[15:50:21.0000] <smaug____>
I'm interested in how many % of all the element on the web are <div> elements etc.

[15:50:36.0000] <zcorpan>
yeah, don't know where they are on the frequency. maybe bkardell can give you numbers

[15:51:36.0000] <zcorpan>
https://rainy-periwinkle.glitch.me is his tool (linked from that page)


2019-10-29
[00:32:07.0000] <annevk>
TabAtkins: yeah, I wish we could move those forward somehow. Pretty good win, though I don’t remember the latest there

[01:04:14.0000] <annevk>
domfarolino: what's the status of https://github.com/whatwg/html/pull/3752?

[03:37:43.0000] <domfarolino>
annevk: Just blocked on me addressing zcorpan’s last review and making more updates sorry for the huge lag

[03:38:59.0000] <annevk>
domfarolino: no worries

[03:40:32.0000] <annevk>
domfarolino: there is some concern with the auto value as it effectively changes the interoperable default to something unknown

[03:43:01.0000] <annevk>
domfarolino: if we could make progress on this that'd be great though, it seems WebKit is also looking at it again and we're in the early phases of planning

[03:43:25.0000] <annevk>
domfarolino: so final changes and especially tests would be good to settle on

[03:43:36.0000] <domfarolino>
annevk: yeah I believe it’s current form allows the UA to do what it wants for auto, I’m guessing this is a deal-breaker?

[03:44:21.0000] <annevk>
domfarolino: I'm not sure, but it's rather magical and could easily lead to subtle issues

[03:46:08.0000] <domfarolino>
annevk: I see. also how to spec iframes is unclear. I believe I’ve left some questions somewhere for you on the thread about doing that, but I’ll check. And I’ll update the PR sometime this week.

[03:48:20.0000] <annevk>
domfarolino: yeah, I wonder if we should tackle <iframe> separately since it's quite a bit different

[03:49:38.0000] <domfarolino>
Kinda what I’m thinking too

[06:53:10.0000] <Domenic>
For what it's worth Edge/IE lazy-loaded <img>s for a long time with no interop issues so IMO auto should be OK as a default. Before Edge died it was effectively already the default.

[06:54:21.0000] <gsnedders>
Quite what was their behaviour? Presto had lots of issues with this from scripts assuming img.onload would fire prior to document.onload or whatever

[06:55:32.0000] <Domenic>
Yeah unsure what they did with load events, but you could see it in the network panel/server, below the fold images would not get downloaded.

[06:56:13.0000] <gsnedders>
Like there's definitely subtle behaviour needed here for web compat

[06:57:10.0000] <annevk>
Yeah, load events is kinda the crucial issue here

[06:57:35.0000] <gsnedders>
And I think some Masonary-like layout things were using .width and .height to change layout after img.load?

[06:58:19.0000] <gsnedders>
which is why the Chrome lazyload stuff fetches the initial however many bytes of the image to get the size metadata

[07:11:09.0000] <annevk>
gsnedders: that's also not defined

[07:31:20.0000] <domfarolino>
gsnedders: Chrome doesn’t do that anymore

[07:31:58.0000] <domfarolino>
at least the change has been made to not do that anymore, not sure if it has shipped yet.

[07:33:04.0000] <annevk>
\o/

[07:42:35.0000] <gsnedders>
domfarolino: oh, okay, surprised it didn't break enough from Presto experiences!

[07:43:30.0000] <domfarolino>
gsnedders: Well Chrome also doesn’t auto-lazyload (unless you’re on Lite mode/data-saver or whatever it’s called, I think on mobile) so that probably helps

[07:55:09.0000] <gsnedders>
domfarolino: but there was plan to roll it out more generally

[08:01:29.0000] <domfarolino>
gsnedders: I believe so yeah, but I think that is somewhat contingent on on how rolling it out in Lite mode goes too

[09:13:45.0000] <jenny-m>
gsnedders: any chance you can provide feedback on https://github.com/web-platform-tests/wpt/issues/19836?

[09:17:09.0000] <gsnedders>
jenny-m: I definitely didn't start writing one earlier :)


2019-10-30
[03:37:29.0000] <MikeSmith>
anybody have problems reaching https://www.w3.org/ or https://validator.w3.org/nu/

[03:37:51.0000] <MikeSmith>
specifically, with Chrome do you get ERR_HTTP2_PROTOCOL_ERROR

[03:44:28.0000] <Ms2ger>
wfm

[03:48:07.0000] <MikeSmith>
Ms2ger: thanks

[03:54:34.0000] <annevk>
Writing side-effect-free dictionary member detection scripts is a lot of fun

[03:55:37.0000] <annevk>
That's not to say we shouldn't have something better, but until we find that I thing I'll enjoy writing these

[07:55:10.0000] <annevk>
zcorpan: so apparently <object> does resizing for SVG and also executes script

[07:55:36.0000] <annevk>
zcorpan: it's not clear this is good and there are bugs, but...

[07:56:36.0000] <zcorpan>
annevk: what's the context here?

[07:58:00.0000] <annevk>
zcorpan: https://twitter.com/annevk/status/1187722568322682881

[07:58:34.0000] <annevk>
(and some spelunking into embed/object to decide whether they navigate or not)

[08:01:18.0000] <zcorpan>
annevk: ah right. Yes, the resizing to the SVG's intrinsic size is why I said it's different from iframe auto-size for HTML

[11:42:57.0000] <jyasskin>
annevk: What's the best way to get advice on a problem I think implies a new URL scheme? An issue on the URL spec? Direct emails to you? Something else?

[13:31:29.0000] <annevk>
jyasskin: uri⊙wo might offer some advice; I have your email in my todos

[13:33:45.0000] <jyasskin>
annevk: Thanks! The actual review isn't super-urgent; I just wanted to make sure I didn't leave anyone out.

[13:38:20.0000] <annevk>
jyasskin: Fetch and HTML issues might be appropriate if it impacts fetching or navigation

[13:40:39.0000] <jyasskin>
The problem is around how we handle storage in unsigned packages, where I think we need the origin to be based on both the package URL and the claimed subresource origin within the package. Package handling and storage will definitely involve Fetch and HTML changes, so you'll get issues there too.


2019-10-31
[01:03:50.0000] <ondras>
hmh, is "-webkit-any-link" handled specially with respect to specificity? the UA's "a:-webkit-any-link" does not seem to be more specific/strong than my plain "a"...

[01:49:31.0000] <ondras>
or perhaps the UA origin is always weaker than Author origin, right

[04:13:27.0000] <MikeSmith>
annevk: not WPT tests for AbstractRange?

[04:13:46.0000] <annevk>
MikeSmith: tests in what sense?

[04:14:02.0000] <annevk>
MikeSmith: there must be IDL tests by now

[04:14:23.0000] <MikeSmith>
yeah there are IDL tests

[04:15:26.0000] <annevk>
MikeSmith: so btw, if this is about the upcoming DOM RD / W3C ?, note that I haven't seen any activity on infrastructure support for the W3C ? bit

[04:15:47.0000] <annevk>
MikeSmith: and I think I did mention to people that needed to be done

[04:16:29.0000] <MikeSmith>
annevk: yes, it is about that and what activity on infrastructure support do you mean?

[04:17:21.0000] <MikeSmith>
FYI https://w3c.github.io/mdn-spec-links/less-than-2.html?spec=dom&url=https://dom.spec.whatwg.org is something I set up to identify features that don’t have two implementations

[04:17:25.0000] <annevk>
MikeSmith: getting the second logo and some additional text in the draft, flipping some colors

[04:17:31.0000] <MikeSmith>
ah

[04:17:43.0000] <MikeSmith>
well we are a ways off from needing to do that yet

[04:18:07.0000] <MikeSmith>
but regardless I guess I am the person who will need to do the activity on that

[04:18:30.0000] <MikeSmith>
so lack of anything being done about it so far is just because of me not doing it

[04:18:36.0000] <annevk>
well, about six weeks and it involves changes to bikeshed and whatwg repos I think, so some coordination required

[04:19:31.0000] <annevk>
okay, I guess all I'm saying is that it would be good to have that sorted some time in advance so that when it comes to publishing that isn't a hurdle

[04:22:29.0000] <MikeSmith>
OK. I guess I should know what the publication schedule is, but anyway I have not been given a deadline yet

[04:23:32.0000] <annevk>
MikeSmith: I plan to publish the RDs, which include DOM, December 16, it's in your calendar as well I think

[04:23:49.0000] <MikeSmith>
yeah

[04:23:51.0000] <MikeSmith>
I know that

[04:23:57.0000] <MikeSmith>
from the WHATWG side

[04:24:22.0000] <annevk>
MikeSmith: since it's one document it'll have to be the same date

[04:24:33.0000] <MikeSmith>
OK I see now

[04:24:44.0000] <MikeSmith>
well, I have been neglecting it

[04:25:08.0000] <MikeSmith>
it’s not due to lack of others asking me to get some stuff done

[04:25:31.0000] <MikeSmith>
so I guess I need to get it all lined up soon-ish

[04:49:49.0000] <MikeSmith>
annevk: so https://wpt.fyi/results/dom/idlharness.window.html%3Fexclude%3DNode?label=experimental&label=master&aligned seems to be saying that AbstractRange is only supported in Firefox?

[04:52:05.0000] <annevk>
MikeSmith: could be, I think I filed bugs on other browsers; they implemented StaticRange before we created AbstractRange

[04:52:15.0000] <MikeSmith>
ok

[04:52:32.0000] <MikeSmith>
/me will look for the browser bugs

[06:57:43.0000] <Domenic>
annevk: MikeSmith: I think the plan was to update the RD after the fact with W3C logo/change in warning color/warning text/etc. Although not updating the date. This seems necessary because we need to first change it to CR and then to REC, so some in-place updating is necessary anyway.

[06:58:44.0000] <Domenic>
That said given that we don't have a mechanism to use "Bikeshed and linking database as of a specific date", there's a possibility the spec will start failing to build during the lag time, which will need some finesseing. I guess maybe we could just turn off warnings-as-errors if necessary.

[07:01:06.0000] <MikeSmith>
Domenic: yeah about the logo and addition of Status/boilerplate stuff, I had just been assuming it could wait til the actual W3C publication

[07:02:06.0000] <MikeSmith>
as far I understand, to do the W3C publication will require the usual process of steps of the W3C WG requesting transition, getting approval

[07:02:23.0000] <MikeSmith>
it also requires some statement of exit criteria

[07:03:13.0000] <MikeSmith>
but anyway I’ve been neglecting it all

[07:03:24.0000] <MikeSmith>
so I need to get on the ball

[07:04:15.0000] <MikeSmith>
there’s nothing I love more than process, so I always procrastinate so I and really savor every moment of it

[07:04:33.0000] <Domenic>
:)

[09:10:06.0000] <annevk>
Domenic: I thought those transitions would always take six months

[09:10:59.0000] <Domenic>
I don't remember anything about that... Not sure how it would work.

[09:11:14.0000] <annevk>
Not super enthusiastic about mutating what are supposed to be immutable documents. Are you sure the sg shares that understanding?

[09:12:28.0000] <Domenic>
I'm not sure. I just don't see how the W3C would approve something for CR and then approve something with 6 months worth of changes as REC.

[09:14:02.0000] <annevk>
Hmm, I thought that’s why we had annotations, but yeah

[11:19:28.0000] <Domenic>
annevk: dumb question, but I thought multiple headers got concatenated with commas, at least in the model? Or is that only request headers? https://github.com/WICG/origin-policy/issues/36

[11:23:37.0000] <annevk>
Domenic: yeah, that comment is somewhat dated, ideally they get combined with a comma first and then parsed

[11:23:49.0000] <Domenic>
OK good

[11:24:07.0000] <annevk>
Domenic: https://fetch.spec.whatwg.org/#concept-header-list-get-decode-split has a primitive

[11:24:45.0000] <annevk>
Domenic: if you don't allow multiple values you can use a simpler primitive of course and fail on a comma being present

[11:24:58.0000] <Domenic>
Hmm right

[11:25:03.0000] <Domenic>
Well structured headers use commas

[11:25:18.0000] <Domenic>
I guess they use it within the multiple values framework

[11:32:09.0000] <annevk>
Oh yeah, for structured headers we should probably define a high-level "get as structured value" that gives you typed things back

[11:33:01.0000] <annevk>
Mike added set a structured header the other day as a start

[11:36:56.0000] <Domenic>
I feel like if you squint and say dictionaries = ordered maps, lists = lists, the structured headers spec is already pretty good

[11:37:27.0000] <Domenic>
It was so cool to see actual defined error handling, omg. https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#rfc.section.4.2.2 tells me what to do on duplicate dictionary keys.

[11:38:03.0000] <annevk>
mnot slowly moving the IETF to the early 2000s

[12:51:15.0000] <annevk>
Domenic: did you see https://github.com/w3c/aria/issues/1058?

[12:51:26.0000] <annevk>
Domenic: also, do you know why they are all strings and not nicer types?

[12:51:51.0000] <Domenic>
annevk: yeah, they are basically enums with misleading names. E.g. there are a lot of things that are "true" / "false" / "some third value"

[12:54:08.0000] <Domenic>
annevk: did not see that issue; will respond

[12:55:59.0000] <annevk>
Domenic: there's a bunch of things that are effectively numbers

[12:56:07.0000] <annevk>
Domenic: and the enums aren't restricted to known values it seems

[12:56:15.0000] <annevk>
Domenic: which is generally how we prefer to reflect those

[12:56:31.0000] <Domenic>
Hrm

[12:56:58.0000] <annevk>
Domenic: and yeah, ARIA not using the proper boolean attribute syntax is annoying, I think I raised a formal objection  over that, which got ignored

[12:58:07.0000] <annevk>
Oh no, it was a higher-level concern, https://annevankesteren.nl/2011/01/wai-aria-objection

[12:59:51.0000] <Domenic>
annevk: open a new issue for the integers? I think we just missed that :-/

[13:01:08.0000] <Domenic>
In particular I think all the debates were around true/false vs. "true"/"false" and so when we felt that was settled we thought we were done.

[13:02:28.0000] <annevk>
Domenic: https://github.com/w3c/aria/issues/1110

[13:03:34.0000] <annevk>
Domenic: and when they only accept true and false a boolean seems better? Though you need a new type of reflect

[13:03:44.0000] <annevk>
Domenic: ARIA boolean reflect or whatever

[13:04:13.0000] <annevk>
nn

[13:04:29.0000] <Domenic>
annevk: I don't think that's a good idea, in particular it breaks the current model that setting `el.x = false` will delete the `x=""` attribute. Also it prevents future extension of the value space which the ARIA WG has disliked.