2020-09-01
[02:30:15.0000] <gsnedders>
MikeSmith: distracted :)

[02:53:50.0000] <gsnedders>
MikeSmith: also I don't think many people aside from the two of us care about those tests?

[03:00:33.0000] <MikeSmith>
gsnedders: inikulin is paying attention at least

[03:00:55.0000] <MikeSmith>
he reviewed and merged two earlier patches I submitted

[03:01:29.0000] <MikeSmith>
so I think we can say that he’d speak up if he objected

[03:01:58.0000] <MikeSmith>
at least

[03:07:55.0000] <MikeSmith>
(I mean specifically, inikulin very recently merged two patches I submitted — within the last month)

[03:30:13.0000] <gsnedders>
MikeSmith: commented on it, fwiw

[03:31:11.0000] <MikeSmith>
/me takes a look

[04:05:14.0000] <MikeSmith>
smaug____: about <dialog> being enabled, see https://github.com/mdn/browser-compat-data/issues/6466#issuecomment-684748163

[04:05:53.0000] <MikeSmith>
and specifically see https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8406 with dom.dialog_element.enabled set to false

[04:06:33.0000] <MikeSmith>
Nightly shows HTMLUnknownElement rather than HTMLDialogElement

[04:16:34.0000] <smaug____>
MikeSmith: right

[04:16:42.0000] <smaug____>
that all is expected, rigth?

[04:16:53.0000] <smaug____>
Nightly has the pref on by defeault

[04:17:01.0000] <smaug____>
default

[04:19:04.0000] <smaug____>
(I'm very good with typos today)

[04:19:41.0000] <MikeSmith>
smaug____: oh, OK

[04:20:17.0000] <MikeSmith>
smaug____: thanks (and thanks for commenting there)

[04:21:29.0000] <smaug____>
worth to ask sefeng (hmm, what is his github name) about dialog stuff

[04:22:43.0000] <smaug____>
ah, sefeng211

[04:22:48.0000] <MikeSmith>
thanks

[04:26:44.0000] <smaug____>
Enabling by default in Firefox depends on getting reasonable a11y/focus behavior in the specs

[07:17:39.0000] <saber1>
looks like we are all good :)


2020-09-02
[23:52:26.0000] <annevk>
MikeSmith: if https://github.com/whatwg/html/pull/5882 looks okay to you we can merge that and then rebase the other PR and land that too

[23:54:21.0000] <MikeSmith>
annevk: OK

[23:54:30.0000] <MikeSmith>
annevk: and thanks yeah, I had been planning to deal with that one case after merging this one first then rebasing

[23:54:53.0000] <MikeSmith>
and thanks also for catching and fixing the ID cases; I should have considered that

[23:58:26.0000] <annevk>
JakeA: https://github.com/whatwg/dom/pull/887

[23:59:35.0000] <annevk>
MikeSmith: are you rebasing? I'm happy to do it

[23:59:47.0000] <MikeSmith>
annevk: I’m rebasing it now

[23:59:48.0000] <annevk>
I see :-)

[00:04:06.0000] <MikeSmith>
annevk: OK, https://github.com/whatwg/html/pull/5881 is all green, if you could go ahead and push the button

[03:40:49.0000] <annevk>
andreubotella: so decode blocking in parallel doesn't so bad to me, but I'll grant you that it's not an ideal setup

[03:40:55.0000] <annevk>
seem so*

[03:53:15.0000] <andreubotella>
annevk: right, since at that point the behavior of the different stages isn't observable from the main thread

[03:55:57.0000] <andreubotella>
but I don't think it hurts to make the hooks useful concurrently

[04:15:35.0000] <annevk>
andreubotella: I guess for that you need some kind of incremental hook that you push a couple of items at a time

[04:16:00.0000] <andreubotella>
yeah, that'd be best

[04:16:51.0000] <andreubotella>
but having decode optionally take an output I/O queue would do it for now

[04:33:55.0000] <annevk>
andreubotella: how would that work though? That queue would travel across parallel boundaries magically?

[04:34:32.0000] <annevk>
Might not be too bad

[04:40:22.0000] <andreubotella>
I was thinking something like: on the event loop, the first task from the networking task source creates the parser and the input byte stream, and passes the ibs to a new thread

[04:40:57.0000] <andreubotella>
that thread then creates the input stream, passes the is to a new thread that runs the tokenizer, and itself runs the decode algorithm

[04:42:33.0000] <andreubotella>
decode optionally takes an output I/O queue (otherwise it creates it), and pushes end-of-queue to it after it's done

[04:43:28.0000] <annevk>
So yeah, you pass a queue across threads; might be good enough

[07:16:15.0000] <jgraham>
It is somewhat unclear in the infra standard what happens if you get a value from a map with a key that's not in the map

[07:18:29.0000] <annevk>
jgraham: you have to "exists" check first

[07:19:32.0000] <jgraham>
That is also unclear (and pretty strange)

[07:22:15.0000] <jgraham>
It seems to be mentioned for using the index notation that the value existing is assumed to be a precondition

[07:22:36.0000] <jgraham>
But not for the actual accessor algorithm

[07:23:43.0000] <andreubotella>
The "out of bounds" language for that precondition seems copied from the definition for list, and could be reworded with reference to keys in the map's entries.

[07:24:11.0000] <annevk>
jgraham: third paragraph of (including note) of https://infra.spec.whatwg.org/#maps seems pretty clear?

[07:24:41.0000] <annevk>
Oh sigh, key not index

[07:24:52.0000] <jgraham>
That's what I mean by "it seems to be mentioned for index notation"

[07:25:40.0000] <jgraham>
It isn't obvious to me that anything there applies if I "call" 'get the value of an entry' directly

[07:26:02.0000] <annevk>
I don't think we support map[1] though so maybe that should just be reworded

[07:26:47.0000] <annevk>
s/The index cannot be out-of-bounds, except when used with exists./The key has to exist./?

[07:27:15.0000] <annevk>
Happy to PR that if that would help

[07:28:13.0000] <jgraham>
To get the value of an entry

[07:29:10.0000] <jgraham>
in an ordered map given a key, return the value of the entry whose key is the given key. It is a spec error to call this with a key that does not exist; when that is not statically known specs must first ensure that the map contains key.

[07:30:17.0000] <jgraham>
Or something

[07:31:14.0000] <annevk>
I prefer my clarification, but we should add an example as this is a common pattern

[07:31:46.0000] <jgraham>
Your clarification still give the impression it's talking about the indexing syntax.

[07:32:43.0000] <annevk>
Ah yeah, we should also add an assert to the get thing

[07:51:54.0000] <jgraham>
 

[09:52:41.0000] <annevk>
Domenic: it seems https://jsdom.github.io/whatwg-url/ broke down somehow

[09:54:14.0000] <Domenic>
annevk: https://github.com/jsdom/whatwg-url/issues/168

[09:55:31.0000] <annevk>
Oh yeah, it still works in Chrome, but no other browser

[09:55:36.0000] <annevk>
That makes it kinda useless though

[09:56:59.0000] <annevk>
Oh, it's IDL bindings code?

[09:57:47.0000] <annevk>
omg https://github.com/tc39/ecma262/issues/678

[09:58:14.0000] <annevk>
/me steps away from the computer

[10:00:55.0000] <Domenic>
annevk: it's my JS-implemented IDL bindings code. webidl2js (which underlies whatwg-url which underlies live-url-viewer) implements [AllowShared] in a way that depends on a SAB global existing at startup time.

[10:01:21.0000] <Domenic>
I don't think 678 is relevant to this particular issue, but it is indeed scary... I'm surprised you haven't seen it before.

[10:01:29.0000] <annevk>
I have

[10:01:53.0000] <annevk>
I keep forgetting about it and then it's there again

[10:02:30.0000] <Domenic>
Heh yes

[10:02:45.0000] <Domenic>
Maybe Shu wants to fix it. He's been good about that sort of thing.

[10:03:08.0000] <annevk>
Very true

[10:12:11.0000] <Domenic>
Pushed a fix for live URL viewer to master; it should deploy momentarily. Although I wasn't able to test Safari so if you have that, let me know.

[10:12:27.0000] <Domenic>
One day I will be allowed back into the office to get my testing Mac...

[10:13:10.0000] <annevk>
In Safari I get "ReferenceError: Can't find variable: SharedArrayBuffer"

[10:13:30.0000] <annevk>
Oh, momentarily

[10:15:33.0000] <Domenic>
Hmm Travis says it's deployed but it is not...

[10:15:50.0000] <Domenic>
OK, now it is... caching, maybe

[10:17:07.0000] <annevk>
It seems to work, though Safari seemingly ignores about:blank in base

[10:17:13.0000] <annevk>
But no more console errors

[10:17:54.0000] <annevk>
I would have expected new WebAssembly.Memory to throw

[10:18:32.0000] <annevk>
Ah, I guess it ignores the shared member entirely

[10:26:25.0000] <shu>
annevk: Domenic: i'll queue it up... still need to finish up the incumbents thing. i've been holding off prodding the MDN article progress given the layoffs


2020-09-03
[02:14:33.0000] <annevk>
JakeA: I think you asked about this at some point: https://github.com/privacycg/storage-partitioning/issues/16

[02:16:53.0000] <JakeA>
Definition looks good to me

[04:03:57.0000] <noamr>
Hi annevk, I'm wondering how to proceed with https://github.com/w3c/csswg-drafts/issues/5165

[04:04:18.0000] <noamr>
(css image orientation/cross-origin)

[04:04:44.0000] <noamr>
seems like there was a resolution from the CSS group, with some ricochets afterwards about web compatibility.

[04:05:25.0000] <noamr>
If what's needed is a spec PR, I would be happy to work on that, but I wasn't clear if the direction was indeed resolved

[09:04:59.0000] <TabAtkins>
noamr: We should be good decision-wise; I haven't picked up the thread to figure out what edits I need to make yet. Will get to that soon.

[09:07:29.0000] <noamr>
Thanks TabAtkins. annevk, is this sufficient for us to proceed with the discussion on https://github.com/whatwg/html/pull/5574? We were waiting to resolve 5165 first but seems like it is resolved.


2020-09-04
[03:51:40.0000] <andreubotella>
annevk: https://github.com/whatwg/encoding/pull/215 is now ready for a final review

[03:52:15.0000] <andreubotella>
the original commit message would have to be changed, so I'm not sure if you want me to squash or rebase and when

[03:52:34.0000] <andreubotella>
and for that matter, I'm not sure that PR is editorial anymore, since it arguably introduces the blocking behavior

[04:11:59.0000] <annevk>
andreubotella: maybe put a tentative commit title/body in a comment? I can use GitHub UI to squash merge

[04:12:25.0000] <andreubotella>
ok

[07:51:00.0000] <haggar>
Is this the best place to talk about Firefox DOM structures?

[07:54:39.0000] <MikeSmith>
haggar: I guess the better place would be the #developers channel on https://chat.mozilla.org/, or some other channel there


2020-09-06
[23:11:09.0000] <mason___>
I can't find where in the spec it shows that a function can be used as the second argument of addEventListener. any help?

[00:04:01.0000] <deltab>
mason___: how formal do you want it?

[00:04:44.0000] <deltab>
https://dom.spec.whatwg.org/#introduction-to-dom-events  shows addEventListener being called with a function

[00:06:42.0000] <deltab>
but the DOM spec isn't just for JavaScript, so it abstracts the idea of a callback function into an interface

[00:07:10.0000] <deltab>
as you can see at https://dom.spec.whatwg.org/#interface-eventtarget

[00:18:19.0000] <mason___>
I was looking for something formal. but based on what you just said, maybe the JavaScript function special case is spec'd elsewhere?

[00:20:04.0000] <deltab>
it's specified as an EventListener there, a 'callback interface', which is defined for JavaScript in https://www.w3.org/TR/WebIDL/#es-user-objects

[00:22:03.0000] <deltab>
it doesn't have to be a function; it can also be an object with a handleEvent method

[00:23:16.0000] <mason___>
ah, there it is. thank you :)

[11:18:15.0000] <HughP>
Has anyone heard of any discussion to add MARC relator terms to html5 meta tags? Presumably via refinement of DC.Contributor.

[11:27:31.0000] <HughP>
Also how do I get an account to make a proposal?


2020-09-07
[19:42:59.0000] <MikeSmith>
HughP: in general about name values for the meta attribute, there’s really never any discussion about them. Instead, it’s a free-for-all: People use whatever they, with no coordination/collaboration

[19:43:49.0000] <MikeSmith>
... so there’s a lot of known redundancy, and a lot of values that people are using that are effectively private values that nobody else in the world cares about

[19:45:25.0000] <MikeSmith>
And that’s why the spec was changed (several years ago) to no longer require meta[name] values to be registered. So any name value you choose to use is valid now — without you needing to register it

[19:48:08.0000] <MikeSmith>
so IMHO at this point there’s not any real value in practice to adding any name values to the https://wiki.whatwg.org/wiki/MetaExtensions page

[19:49:03.0000] <MikeSmith>
nobody’s curating that page — and as you’ve found out, it has the big disadvantage that you need to have somebody create an account for you in order to add anything new to it

[23:03:27.0000] <HughP>
MikeSmith Thank you for pointing out https://html.spec.whatwg.org/multipage/semantics.html#other-metadata-names That was really helpful, and indeed I have seen some meta values in the wild which are not listed on that wiki page. I was wondering if this was an "every man for himself" sort of world. All the same the living standard still says that it

[23:03:28.0000] <HughP>
is good to consult the wiki page you reference as that is there to "advertise" that one is using such a tag. So, there should be some method for following through with the recommendation in the standard.

[00:33:24.0000] <noamr>
Hi Domenic! I have done some research work regarding tooltip/top-layer (https://github.com/whatwg/html/issues/4633). I have some bandwidth and I want to advance that work (I work on this on behalf of wikipedia)

[00:33:43.0000] <MikeSmith>
HughP: Yeah we originally anticipated that more actual coordination/collaboration would emerge around meta names, but it never ended up happening at all

[00:47:18.0000] <annevk>
MikeSmith: are you saying browsers shouldn't use new <meta name> values? Is that what's happening in practice? Otherwise it still seems useful to register, at least to inform implementers as to what values might step on someone else

[01:13:17.0000] <HughP>
annevk What I have seen in practice is that name_spacing is occuring. The case I am thinking about is that I have seen some meta tags which I presume are part of Webtrends Parameters package. http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf they take the form wt.xxx which

[01:13:17.0000] <HughP>
seems to be the way that they are name spaceing their tags.

[01:13:52.0000] <annevk>
That seems fine

[01:14:06.0000] <HughP>
that is I have seen some wt.xxx tags which are not in the documentation or the wiki

[01:15:26.0000] <annevk>
It still does seem somewhat useful to me if those are registered. Also for people trying to figure out what they might mean. But those names are also unlikely to clash with anything a browser might add.

[01:16:34.0000] <annevk>
Perhaps we should move https://wiki.whatwg.org/wiki/MetaExtensions to a Markdown page on https://github.com/whatwg/html so it can be easily PR'd by anyone with a GitHub account

[01:16:52.0000] <HughP>
yea, I really don't have a problem with that at all. It makes sense. I'm initially asked my question because I wanted to know if anyone had implemented DCMI's endorsement of the MARC relator vocabulary, as a refining element of the DC.Creator tag. I have seem some examples in XHTML but nothing in html5.

[01:17:15.0000] <HughP>
+1 to using github and PRs

[01:46:42.0000] <annevk>
noamr: it sounds like TabAtkins will take a look or is there something you still need from me?

[01:48:28.0000] <annevk>
andreubotella: I guess I should review your questions before merging...

[01:50:06.0000] <annevk>
andreubotella: I like the idea of run pushing end-of-queue

[01:52:39.0000] <annevk>
andreubotella: maybe even make Process do it

[01:52:58.0000] <annevk>
andreubotella: as that does all the pushing to the queue already

[01:54:25.0000] <annevk>
andreubotella: I'm not sure what to do about the fatal error case; I lean towards not pushing end-of-queue in that case but I suppose I could go either way

[01:59:48.0000] <annevk>
andreubotella: left a variant of this thought process on the PR

[01:59:52.0000] <noamr>
annevk: TabAtkins took a look, and said that the decision was made regarding orientation/same-origin... What I ask from you is to understand whether we can now unblock the conversation about resolution based on that decision

[02:00:46.0000] <annevk>
noamr: so the decision is still the same and the compat concerns do not carry weight?

[02:01:14.0000] <noamr>
that's what TabAtkins said earlier.

[02:02:44.0000] <annevk>
It would be good to see some signs of implementers committing to that, but I guess I can take a look at things assuming that's all in order...

[02:03:21.0000] <noamr>
annevk: in either case, the recent conversation about resolution has progressed in a way where it doesn't expose resolution to the embedder

[02:03:48.0000] <noamr>
and unlike orientation, it carries a significantly smaller baggage in terms of web compatibility

[02:05:12.0000] <annevk>
noamr: so I don't understand the same origin check before processing the metadata

[02:05:31.0000] <annevk>
noamr: I thought the plan was to always process the metadata, but hide it to certain APIs, depending

[02:05:47.0000] <noamr>
annevk: right, I haven't posted a new PR yet. I meant in the comments.

[02:06:17.0000] <MikeSmith>
annevk: the meta[name] values that browsers use get added directly to the spec, right? not to the wiki page

[02:06:21.0000] <noamr>
the idea was to change the behavior of srcset when EXIF resolution exists, so that you can't detect the EXIF resolution with it

[02:06:55.0000] <annevk>
MikeSmith: once browsers tell us, yes, but what I'm saying is that it would still be nice if browsers could check their new idea doesn't clash with an existing thing

[02:07:38.0000] <MikeSmith>
ah I see

[02:08:00.0000] <annevk>
noamr: I think the better way would be to let the image decode process take care of using and stripping EXIF data in case it's an opaque image, so we don't have to change all the callers

[02:09:20.0000] <noamr>
annevk: yes that makes sense. If srcset is not an issue, almost all the code for this can be an image-decoder implementation detail

[02:09:31.0000] <annevk>
noamr: anyway, iterating on this doesn't seem blocked to me; but I do think we need to get a bit further with resolution (including bugs filed and some intent to follow through) to be certain

[02:10:08.0000] <annevk>
noamr: if the image decode process did that you couldn't tell with srcset, right? Or am I missing something?

[02:10:24.0000] <noamr>
annevk: correct.

[02:10:38.0000] <noamr>
the reason why this was leaking outside of the image decoder was for srcset

[02:10:50.0000] <annevk>
MikeSmith: the other thing we could maybe say about <meta name> is that if you want to make shit up, consider using a character outside a-z

[02:11:11.0000] <noamr>
it would need to leak again for non-opaque images if we implement css image-resolution

[02:11:16.0000] <annevk>
MikeSmith: [a-z-]+ is what I would expect browsers to use for eternity

[02:11:36.0000] <MikeSmith>
annevk: yeah, that is a concrete idea worth pursuing

[02:12:05.0000] <annevk>
noamr: for non-opaque images we wouldn't make the EXIF built into the image data so that should be fine; for opaque images it would always appear to be missing

[02:13:23.0000] <MikeSmith>
annevk: but I also wish browsers would no longer use meta[name] to add anything. Next time it comes up, I hope an alternative is used. Before it becomes too late again

[02:14:07.0000] <MikeSmith>
the past pattern has been that browser projects have just unilaterally added their own meta[name] things, and then we ended up retroactively speccing it

[02:14:11.0000] <annevk>
MikeSmith: I have the feeling Apple and Microsoft and maybe Google as well do that thing on the regular

[02:14:11.0000] <MikeSmith>
iirc

[02:14:37.0000] <MikeSmith>
well I wish we could convince them to stop doing that

[02:14:53.0000] <MikeSmith>
it’s an abuse, IMHO

[02:16:19.0000] <annevk>
Not much disagreement there, depends a bit on how impactful it ends up being, but not really sure how to move the needle on that

[02:16:27.0000] <MikeSmith>
yeah

[02:22:27.0000] <noamr>
thanks for now annevk, I'll come up with a PR soonish

[02:22:54.0000] <annevk>
👍🏻

[03:56:45.0000] <andreubotella>
annevk: So I'll go ahead and not push end-of-queue on the failure case if that's okay

[03:57:18.0000] <annevk>
andreubotella: yeah that sounds good

[03:57:27.0000] <andreubotella>
ok

[03:57:40.0000] <annevk>
andreubotella: as I mentioned there, for the streaming fatal case we'll need a new hook anyway

[04:02:21.0000] <annevk>
andreubotella: perhaps that also means we should be a bit more restrained with where we add outparams for output

[04:02:54.0000] <annevk>
meh, I guess it's okay

[04:03:46.0000] <andreubotella>
my intention was to make all hooks usable for streaming if the output param was given

[04:04:14.0000] <andreubotella>
otherwise, `output` is created empty and eventually an end-of-queue is pushed to it before it gets returned

[04:04:50.0000] <andreubotella>
which btw, I'd appreciate some review on the optparams, since the infra PR is still under some discussion

[04:04:55.0000] <andreubotella>
Domenic?

[04:52:23.0000] <annevk>
jgraham: do you know offhand if Python 3 removed Error()?

[04:52:39.0000] <annevk>
Is Exception() basically equivalent?

[05:39:21.0000] <jgraham>
I don't think Error is a Python thing in Python 2?

[05:39:31.0000] <jgraham>
What are you trying to do?

[06:09:08.0000] <annevk>
jgraham: refactor a script that does raise Error(), but I'm not sure the path is ever triggered

[06:13:43.0000] <jgraham>
In [1]: raise Error()

[06:13:43.0000] <jgraham>
---------------------------------------------------------------------------

[06:13:43.0000] <jgraham>
NameError                                 Traceback (most recent call last)

[06:13:43.0000] <jgraham>
<ipython-input-1-630691b4ad4f> in <module>()

[06:13:43.0000] <jgraham>
----> 1 raise Error()

[06:13:46.0000] <jgraham>
NameError: name 'Error' is not defined

[06:13:48.0000] <jgraham>
(python 2.7)

[06:13:56.0000] <jgraham>
So yeah, that should be Exception


2020-09-08
[22:12:15.0000] <MikeSmith>
annevk: at https://encoding.spec.whatwg.org/#ref-for-ascii-code-point the Encoding spec says this:

[22:12:37.0000] <MikeSmith>
> These are “ASCII-incompatible” encodings and other than ISO-2022-JP, UTF-16BE, and UTF-16LE, which are unfortunately required due to deployed content, they are not supported.

[22:13:24.0000] <MikeSmith>
...while at https://html.spec.whatwg.org/multipage/infrastructure.html#ascii-compatible-encoding the HTML spec says this:

[22:13:32.0000] <MikeSmith>
> An ASCII-compatible encoding is any encoding that is not a UTF-16 encoding. [ENCODING]

[22:26:44.0000] <MikeSmith>
..

[22:27:33.0000] <MikeSmith>
So per that HTML spec language, ISO-2022-JP is an ASCII-compatible encoding

[23:20:53.0000] <MikeSmith>
hmm, actually ISO-2022-JP is actually an ASCII-compatible encoding, isn’t it?

[23:21:31.0000] <MikeSmith>
so that “other than ISO-2022-JP” part of the language in the Encoding spec should be dropped, shouldn’t it?

[00:45:06.0000] <annevk>
MikeSmith: it’s not due to the escapes

[00:45:38.0000] <annevk>
MikeSmith: we should prolly harmonize that language in HTML though

[00:51:46.0000] <MikeSmith>
annevk: Yeah I am asking because we have some code in the validator.nu parser that does a “is ASCII-compatible” check

[00:51:56.0000] <MikeSmith>
but I think it’s based on old spec language

[00:52:31.0000] <MikeSmith>
I think the current equivalent in the HTML spec is just the explicit checks for UTF-16

[00:53:36.0000] <MikeSmith>
anyway, I need to check that the code is actually doing something that current spec requires (and not something that it used to require and doesn’t now)

[01:40:37.0000] <annevk>
MikeSmith: HTML should just drop ASCII-compatible at this point; not sure why we kept it when we added UTF-16 encoding as a thing

[01:42:42.0000] <annevk>
MikeSmith: and I guess HTML's "UTF-16 encoding" could move to Encoding, but would like to land the refactoring PR for Encoding first

[02:22:34.0000] <MikeSmith>
annevk: refactoring PR is the “Rename Encoding's "streams" to "I/O queues"” PR?

[02:23:45.0000] <annevk>
MikeSmith: yeah

[02:23:49.0000] <MikeSmith>
k

[02:24:33.0000] <MikeSmith>
annevk: by the way, the specific check in the validator.nu code that I’m wondering about does this:

[02:24:35.0000] <annevk>
andreubotella: btw, realized that Domenic is out this week so do you want to wait or potentially do some tidying up later?

[02:25:12.0000] <MikeSmith>
> The encoding “foo” is not an ASCII superset and, therefore, cannot be used in an internal encoding declaration. Continuing the sniffing algorithm

[02:25:26.0000] <MikeSmith>
..in the the meta-scan code

[02:26:30.0000] <MikeSmith>
actually, it’s doing the same thing for the fully-parsed case too

[02:27:13.0000] <MikeSmith>
> Internal encoding declaration specified “foo”, which is not an ASCII superset. Not changing the encoding.

[02:29:21.0000] <MikeSmith>
since there’s earlier code that explicitly checks for UTF-16, then as far as I can see, that “not an ASCII superset. Not changing the encoding” would only get reached if the encoding is ISO-2022-JP and if ISO-2022-JP is considered to not be an ASCII superset

[02:31:14.0000] <MikeSmith>
ah

[02:31:19.0000] <MikeSmith>
that is this:

[02:31:21.0000] <MikeSmith>
> If the encoding that is already being used to interpret the input stream is a UTF-16 encoding, then set the confidence to certain and return. The new encoding is ignored

[02:32:39.0000] <MikeSmith>
...except that the spec says to do that ignore return only for UTF-16 encodings explictly (not for “not an ASCII superset” encodings)

[02:34:02.0000] <annevk>
Yeah, note that the specification has seen some refactoring already

[02:38:46.0000] <annevk>
MikeSmith: https://github.com/whatwg/html/commit/a73180679a40fce96b8e8fb6dfa5815a9bce30eb is probably of interest

[02:41:17.0000] <MikeSmith>
/me looks

[02:41:47.0000] <MikeSmith>
annevk: ah yeah that’s it

[02:41:53.0000] <MikeSmith>
2015

[02:42:23.0000] <MikeSmith>
I am kind of surprised how far out of conformance the validator.nu Java code is with the spec

[02:43:17.0000] <MikeSmith>
I mean specifically the encodings-handling code

[02:44:22.0000] <MikeSmith>
since it’s used for Firefox too, I would expect that’d necessarily mean that Firefox was also way out of conformance with the spec as far as encodings handling

[02:45:33.0000] <annevk>
MikeSmith: is it actually non-compliant though? Only checking for UTF-16 seems correct

[02:46:12.0000] <MikeSmith>
that is just one place I have found where the Java code is non-conforming

[02:46:25.0000] <annevk>
To stress the point a bit, the Encoding Standard's definition of ASCII-incompatible is completely non-normative

[02:46:35.0000] <MikeSmith>
OK

[02:47:19.0000] <annevk>
/me wonders if the big OK represents an annoyed MikeSmith 😊

[02:47:52.0000] <MikeSmith>
no, no — not annoyed at all

[02:48:55.0000] <MikeSmith>
anyway, another place that the Java code does not match the spec is that it implements the Charset Alias Matching thing rather than just trim-leading-trailing whitespace

[02:49:57.0000] <MikeSmith>
so I am kind of beginning to suspect that this is a part of the Java source that doesn’t actually get used in the Firefox code

[02:50:02.0000] <annevk>
oh yeah, that's bad

[02:50:15.0000] <annevk>
Pretty sure that's not in Firefox indeed

[02:50:48.0000] <annevk>
I wonder how many more times I will see Charset Alias Matching referenced in my life

[02:50:48.0000] <MikeSmith>
yeah, I think Henri must have separate C++ source for this

[02:50:52.0000] <MikeSmith>
haha

[02:51:11.0000] <MikeSmith>
more than you would like, I’m sure

[02:52:21.0000] <MikeSmith>
oh, actually I already know one specific place where the Firefox code does something very different from the Java code: the "replacement" encoding name/label

[02:52:41.0000] <MikeSmith>
there is zero code in the Java sources for dealing with the "replacement" encoding

[02:52:50.0000] <MikeSmith>
...yet Firefox handles it per-spec

[02:53:03.0000] <annevk>
R.I.P. He rid the web from Charset Alias Matching. OK chap.

[02:57:32.0000] <MikeSmith>
hahah

[03:05:08.0000] <andreubotella>
annevk: oh, I didn't know that. Let's merge now and fix later, then

[03:07:19.0000] <annevk>
andreubotella: sounds good, doing a final round of nits now

[03:07:45.0000] <andreubotella>
👍

[05:08:47.0000] <noamr>
annevk: hi, I've updated https://github.com/whatwg/html/pull/5574 to account for same-origin concerns as discussed.

[13:28:24.0000] <EveryOS>
Today I posted to the wicg discourse 1400 words worth of the most stupid, unrealistic idea I've ever had. At least it has not been deleted, so that's a plus...


2020-09-09
[07:09:56.0000] <annevk>
noamr: I still see multiple _img_ variables

[07:11:33.0000] <noamr>
annevk: right. I will add a var that points to the req's img, will make he code more succinct

[07:11:57.0000] <annevk>
noamr: it's also not clear to me that the image request has intrinsic dimensions

[07:12:12.0000] <annevk>
Some of this is probably because the current description of this element is still rather messy

[07:12:45.0000] <annevk>
The same-origin check can't be that way either as this seems to ignore redirects and such, instead we need to check the opaqueness of the response

[07:13:31.0000] <annevk>
noamr: I'd also prefer if for new internal fields that we introduce we clearly define the types and not just their initial value

[07:13:35.0000] <noamr>
it's copied from same-origin checks of canvas

[07:13:45.0000] <annevk>
yeah that's also wrong

[07:13:57.0000] <noamr>
regarding request - the image has intrinsic dimensions, and they're assigned before "update the image metadata"

[07:15:04.0000] <annevk>
but update the image metadata only has an image request, not an img

[07:15:06.0000] <annevk>
afaict

[07:15:20.0000] <noamr>
image request has an img

[07:17:35.0000] <noamr>
re. same-origin: is this necessary to put it in the spec at this point? currently image-resolution is not implemented so it's inert for the purposes of resolution. The general direction is set, I think that it needs to be define when Tab gets to fixing the spec for image-orientation

[07:18:57.0000] <noamr>
if it is, what would be a way to go about it?

[07:21:11.0000] <noamr>
(the same-origin thing is also why we're defining the new struct, which is currently not really in use)

[07:23:30.0000] <noamr>
annevk: re. types - is there a standard type for width+height struct? having a hard time finding it in the html spec

[07:25:57.0000] <annevk>
just spelling it out would suffice for now

[07:26:20.0000] <annevk>
"undefined or a struct consisting of a width and a height" or some such

[07:26:50.0000] <annevk>
And yeah, we do want the details to be ironed out before making changes

[07:26:58.0000] <annevk>
See https://whatwg.org/working-mode#changes

[07:29:41.0000] <noamr>
ok annevk. any pointers about a more proper place to pull the cross/same-origin definition from?

[07:30:51.0000] <annevk>
noamr: I think CORS-cross-origin is what we want here

[07:31:24.0000] <annevk>
(also works for non-CORS stuff, prolly needs a better name)

[07:31:43.0000] <annevk>
noamr: or the inverse which is also defined, CORS-same-origin

[07:33:54.0000] <noamr>
gotcha annevk, thanks

[07:36:13.0000] <noamr>
I fixed all of it now, I believe. (new PR uploading)

[13:00:40.0000] <EveryOS>
So I guess my edit button just doesn't exist https://usercontent.irccloud-cdn.com/file/ukotJc9X/image.png

[13:00:56.0000] <EveryOS>
I wanted to un-stupidify my idea

[13:02:36.0000] <EveryOS>
Discourse was letting me edit my post fine yesterday

[13:03:51.0000] <EveryOS>
I'll have to use a comment instead, I guess.

[14:45:44.0000] <EveryOS>
Ok, I've typed up my revisions to my idea, just need to log into Discourse and submit

[14:45:44.0000] <EveryOS>
It's also long. I feel like I'm giving too many walls of text

[14:51:38.0000] <EveryOS>
If I decide that I still don't like this later on, I'll just flag my topic for deletion.


2020-09-10
[01:03:37.0000] <annevk>
yoav: to be sure, that test passes in all browsers?

[01:05:10.0000] <yoav>
/me verifying

[01:06:08.0000] <yoav>
yup

[01:08:38.0000] <annevk>
thanks, all merged

[03:07:02.0000] <zcorpan_>
annevk: do you know why CSP-blocked images in firefox are display: none !important ?

[03:07:38.0000] <zcorpan_>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8451

[03:10:27.0000] <annevk>
ecobos might know, but that sounds weird

[03:11:11.0000] <annevk>
Ideally they would be no different from any other kind of network error

[03:17:12.0000] <zcorpan_>
ecobos: they're matching :-moz-supressed I think https://hg.mozilla.org/mozilla-central/file/tip/layout/style/res/html.css#l665

[03:27:58.0000] <andreubotella>
I'm refactoring the HTML parser to use I/O queues in a bit of an informal way to be fleshed out later

[03:28:01.0000] <andreubotella>
and I'm not sure what language to use to say that the tokenizer and tree constructor must run on the same thread

[03:40:18.0000] <MikeSmith>
andreubotella: are implementations of the parser algorithm required to use threads to begin with?

[03:40:35.0000] <MikeSmith>
that seems like an implementation detail

[03:41:25.0000] <andreubotella>
not until now, but as part of encoding#215 annevk and I realized that "streams" had some holes in them, and decided to go with a blocking read

[03:42:51.0000] <MikeSmith>
I see

[03:42:51.0000] <andreubotella>
I'm now realizing that this might need some restructuring of the way the reentrancy works

[03:43:01.0000] <andreubotella>
which is pretty much black magic to me

[03:43:48.0000] <andreubotella>
thus why I'm doing this informally on html#5874, to be fleshed out later

[03:43:59.0000] <MikeSmith>
well I think as far as the spec language goes around the tokenizer and tree constructor, I would think just some language about “blocking read” would suffice, without mentioning threads

[03:44:14.0000] <MikeSmith>
but now I realize that is probably what you were already saying yourelf

[03:44:50.0000] <MikeSmith>
I mean how to word that, without explicitly saying, “must run on the same thread“

[03:45:41.0000] <andreubotella>
I'm specifying that the decode algorithm and the tokenizer/tree constructor must run in parallel to the event loop and to each other

[03:45:57.0000] <andreubotella>
since the reads from the network are enqueued onto the input byte stream on the event loop

[03:46:31.0000] <andreubotella>
but I'm leaving it at that, with maybe some note about implementations having to bend the spec to modify the DOM from a thread

[03:50:07.0000] <MikeSmith>
yeah such notes are really helpful in making clear what needs to happen in normal practice, when the spec language gets that abstract

[03:50:53.0000] <MikeSmith>
anyway what you describe sounds pretty interesting

[03:52:58.0000] <MikeSmith>
(lately I’ve been working a lot on bug fixes and updates to the validator.nu Java implementation of the HTML parser, so I’m especially interested in any possible evolutions of the parser algorithm)

[03:54:38.0000] <andreubotella>
this is meant to be an editorial change, since the bug was in the way Encoding streams switched from being data structures in memory on one moment to representing a sequence of bytes to come from the network on the next

[03:54:44.0000] <andreubotella>
implementations shouldn't have that problem

[03:59:10.0000] <zcorpan_>
hsivonen: is the speculative parser kicked off upon an <script> without a src attribute?

[04:08:34.0000] <zcorpan_>
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8457 suggests there's no speculation for an inline classic script

[04:14:01.0000] <zcorpan_>
hsivonen: I'm a bit confused by your comments here https://github.com/privacycg/proposals/issues/19#issuecomment-690162075

[04:16:00.0000] <zcorpan_>
hsivonen: so you mean fetches can happen before the parser inserts stuff the to DOM even though there's no speculative parsing?

[04:17:22.0000] <ecobos>
zcorpan_: yeah, they're matching `:-moz-suppressed`... I don't have all the context of that but if you file a bug and cc me I can get to it. I agree it's pretty weird

[04:17:45.0000] <ecobos>
zcorpan_: (you can see the browser rules in devtools if you check the right checkbox in the settings, fyi)

[04:18:18.0000] <zcorpan_>
ecobos: I saw it in devtools :)

[04:18:33.0000] <zcorpan_>
ok I can file, thanks!

[04:18:43.0000] <ecobos>
zcorpan_: ah, so the "I think" was really "I know" :P

[04:19:29.0000] <zcorpan_>
ecobos: that assumes I trust devtools :P

[04:19:36.0000] <ecobos>
lol

[04:20:00.0000] <ecobos>
zcorpan_: well, this is some old code, so figuring out what depends on this is going to be fun... https://bugzilla.mozilla.org/show_bug.cgi?id=11011

[04:20:10.0000] <ecobos>
/me hadn't seen a 5-digit bug number in a while

[04:22:19.0000] <ecobos>
zcorpan_: It seems per the comments that that was supposed to "block images from this site" and such, so if it triggers for CSP it seems like a bug to me

[04:22:52.0000] <ecobos>
zcorpan_: anyhow I can look, feel free to cc/ni? me so I don't forget. Thank you!

[04:29:03.0000] <zcorpan_>
ecobos: https://bugzilla.mozilla.org/show_bug.cgi?id=1664156

[04:55:02.0000] <annevk>
Anyone else care to review a minor DOM Event introduction change? https://github.com/whatwg/dom/pull/890

[05:01:35.0000] <MikeSmith>
annevk: will look

[05:06:39.0000] <MikeSmith>
annevk: is that whole section marked non-normative?

[05:06:43.0000] <MikeSmith>
/me looks

[05:07:33.0000] <MikeSmith>
OK, it’s not, actually

[05:07:40.0000] <MikeSmith>
maybe it should be?

[05:18:47.0000] <annevk>
MikeSmith: probably, yeah

[05:44:58.0000] <MikeSmith>
annevk: added a general comment:

[05:45:06.0000] <MikeSmith>
> General comment (relevant to @kevinsung’s specific comment about “effectively”): To avoid ambiguity about what statements in the DOM spec are normative and which aren’t, it seems like it would be useful for non-normative sections of the published DOM spec to be rendered with explicit This section is non-normative text after the section headings — in the way the HTML spec is. But I guess more

[05:45:12.0000] <MikeSmith>
generally, that’s an issue for Bikeshed (in that, Bikeshed currently doesn’t have a feature for automatically emitting explicit This section is non-normative text in the way that the HTML spec has.

[05:45:24.0000] <MikeSmith>
...

[05:46:03.0000] <MikeSmith>
I don’t think Bikeshed has any such feature, but maybe it does and I just haven’t noticed

[06:50:00.0000] <andreubotella>
in wattsi, a definition with <dfn data-x=""> makes no sense, right?

[06:50:06.0000] <andreubotella>
as in, an empty data-x attribute

[06:52:57.0000] <zcorpan_>
andreubotella: html uses that in a few places, in Typographic conventions and Terminology

[06:53:53.0000] <zcorpan_>
andreubotella: for Terminology, I think it wants to define terms but not have links for each usage of that term

[06:54:01.0000] <andreubotella>
I see

[06:54:10.0000] <andreubotella>
So I suppose this is a mistake:

[06:54:12.0000] <andreubotella>
> The next input character is the first character in the input stream that has not yet been <dfn data-x="">consumed</dfn> or explicitly ignored

[06:56:28.0000] <zcorpan_>
andreubotella: I'm not sure why that doesn't use a normal <dfn>

[06:57:14.0000] <zcorpan_>
"Reconsume" is <dfn>ed, but "consume" is not

[07:47:00.0000] <annevk>
andreubotella: I doubt it's a real mistake since if anyone tried to link that with <span>consumed</span> it would not build

[07:47:29.0000] <andreubotella>
"consume the next input character" is ofc used a lot, just not linked

[07:47:33.0000] <annevk>
andreubotella: that does not mean the current state of affairs is ideal, a lot of this text is old and predates our more formal style

[07:48:18.0000] <annevk>
linking it does seem nicer

[09:30:47.0000] <andreubotella>
https://github.com/whatwg/html/pull/5874

[09:30:53.0000] <andreubotella>
those were a lot of "consume the next input character"

[09:31:08.0000] <andreubotella>
and I had to fight VSCode every time because it kept indenting the second line

[09:31:09.0000] <TabAtkins>
MikeSmith: Bikeshed doesn't have such a feature, no.

[09:31:33.0000] <andreubotella>
*misindenting rather

[12:52:47.0000] <zcorpan_>
https://github.com/privacycg/proposals/issues/19 - I have several questions, but might get a bit off topic for the issue :) (cc hsivonen )

[12:53:38.0000] <zcorpan_>
I think I recall the speculative fetches from normal HTML parser being a thing even before speculative parsing existed, but I'm not entirely sure. Was it a thing before speculative parsing?

[12:54:20.0000] <zcorpan_>
Do chromium and webkit also do this? (i.e. speculatively fetch resources from the HTML parser before the element is inserted to the DOM)

[12:54:42.0000] <zcorpan_>
Should we specify this?

[13:00:30.0000] <zcorpan_>
What's a reliable way to test it? <object>? (it gets processed "the element is popped off the stack of open elements of an HTML parser or XML parser,", in a queued task)


2020-09-11
[01:03:52.0000] <annevk>
zcorpan_: what's the difference?

[01:04:53.0000] <zcorpan_>
annevk: difference between what?

[01:05:35.0000] <annevk>
zcorpan_: speculative fetches and parsing

[01:06:46.0000] <zcorpan_>
annevk: so speculative fetches can happen both from speculative parser and non-speculative parser

[01:08:47.0000] <zcorpan_>
annevk: with normal parsing, the tree builder decides to speculatively fetch e.g. a stylesheet when it processes the "link" token. the parser batches DOM insertions so the element can be inserted to the DOM at some later time

[01:09:46.0000] <zcorpan_>
(and scripts have opportunity to modify the DOM in between)

[01:11:18.0000] <zcorpan_>
from what I can tell, that's the case that's relevant for https://github.com/privacycg/proposals/issues/19 -- not speculative fetches from speculative parser

[01:12:57.0000] <annevk>
Is the main difference that the speculative parser can be confused by document.write()? Though maybe the real parser can be confused by script too if it moved the node to a document that doesn't fetch?

[01:16:22.0000] <zcorpan_>
if by confused you mean that a speculative fetch turns out to be invalid, then yeah the normal parser can't be confused by document.write because ... there's no speculative parsing :) but indeed, a script can insert a CSP meta or move or remove a parent element after the normal parser started a speculative fetch

[01:20:56.0000] <zcorpan_>
othermaciej also mentioned predictive speculative fetches, which wouldn't come from either parser but happen as part of navigation or so

[01:25:39.0000] <annevk>
Thanks, to get back to the earlier questions, I think we should define when fetches can happen (and what "security context" they happen in) and how they get de-duplicated with "actual" fetches later

[01:45:02.0000] <zcorpan_>
:+1:

[01:58:15.0000] <MikeSmith>
annevk: FYI, I raised https://github.com/tabatkins/bikeshed/issues/1763 proposing that Bikeshed output have “This section is non-normative” text the way the HTML spec does.

[01:59:16.0000] <annevk>
MikeSmith: sounds cool

[01:59:39.0000] <MikeSmith>
from looking at the Bikeshed source, I think adding class=non-normative to any element will cause Bikeshed to consider that element and descendants to be non-normative

[02:00:01.0000] <MikeSmith>
but I don’t know if we are using sections in our Bikeshed specs

[02:00:35.0000] <MikeSmith>
if not, then maybe Bikeshed would need to support it through comments, as we do with the HTML spec

[02:00:46.0000] <MikeSmith>
<!-- NON-NORMATIVE SECTION -->

[02:01:37.0000] <annevk>
MikeSmith: we do not have sections currently, but we maybe should at least for algorithms as it adds some useful reading tools

[02:01:43.0000] <annevk>
such as highlighting variables

[02:01:48.0000] <MikeSmith>
hmm yeah

[02:02:43.0000] <MikeSmith>
well for now maybe if we just added class=non-normative to the headings in the spec sources

[02:03:28.0000] <MikeSmith>
and then the Bikeshed behavior would be to emit a “This section is non-normative” paragraph after any such heading

[02:03:43.0000] <MikeSmith>
...if that doesn’t sound too hacky

[02:04:52.0000] <MikeSmith>
that way at least we wouldn’t need to add explit section wrappers just to get this, and I wouldn’t need to implement the <!-- NON-NORMATIVE SECTION --> comment thing in Bikeshed

[02:05:16.0000] <MikeSmith>
to me, that <!-- NON-NORMATIVE SECTION --> comment thing seems much more like a hack than just putting some class on the headings

[02:12:59.0000] <annevk>
MikeSmith: yeah that seems fine

[08:48:28.0000] <Domenic>
Actual <section> wrappers would also allow position: sticky headings; see https://github.com/whatwg/whatwg.org/issues/320

[08:48:44.0000] <Domenic>
Also maybe Bikeshed/Wattsi could translate <h1> into <hN>  based on section depth

[08:48:47.0000] <Domenic>
To make authoring a bit nicer.


2020-09-14
[01:58:11.0000] <MikeSmith>
annevk: about the encoding support in the validator.nu parser, I’m remembering now that Henri had been working on a spec-conformant implementation previously

[01:58:59.0000] <MikeSmith>
...but it’s in a separate branch and it’s not had any new changes in a long time

[02:00:03.0000] <MikeSmith>
and there’s a note about it being “unfinished” but not with any details about what’s needed to finish it

[02:00:50.0000] <MikeSmith>
I kind of vaguely recall now that Henri had been working on Big5 decoder and maybe that’s what never got finished

[02:01:14.0000] <MikeSmith>
But I’m wondering if you remember any more from past discussions with him

[02:01:32.0000] <MikeSmith>
I think this would have been maybe 5 years ago

[02:48:21.0000] <smaug____>
annevk: could you interpret something for me :) https://html.spec.whatwg.org/#own-autocapitalization-hint "The autocapitalize IDL attribute, on getting, must return the string value corresponding to own autocapitalization hint of the element, with the exception that the default state maps to the empty string. On setting, it must set the autocapitalize content attribute to the given new value."

[02:48:38.0000] <smaug____>
The 'must return the string value corresponding to own autocapitalization hint of the element' part

[02:49:10.0000] <annevk>
That looks like a typo, but I'll have a look at what it might mean without that too

[02:49:35.0000] <smaug____>
how does that work when same hint maps to multiple values

[02:50:53.0000] <annevk>
smaug____: ah yeah, that's buggy

[02:53:43.0000] <annevk>
smaug____: so judging from the tests there is normalization going on

[02:54:34.0000] <smaug____>
or some specific mapping

[02:54:49.0000] <smaug____>
that sentences state maps always back to sentences string

[02:54:57.0000] <annevk>
smaug____: it seems that the idea is that the state name is also the canonical name

[02:55:07.0000] <smaug____>
right

[02:57:23.0000] <annevk>
smaug____: "For the purposes of reflection, the canonical keyword for the Anonymous state is the anonymous keyword." is what we have elsewhere, I guess I can PR a fix for that

[03:03:57.0000] <annevk>
Except of course it doesn't use reflection so the fix needs to be different

[03:09:06.0000] <annevk>
smaug____: https://github.com/whatwg/html/pull/5911

[03:09:45.0000] <smaug____>
thanks

[07:29:54.0000] <JakeA>
Is there anything wrong with making an interface that's indexable, iterable, but also an event target? Or is that looked down upon vs having an event target and a sequence?

[07:30:34.0000] <JakeA>
As in, the sequence and event target being different objects vs being the same object

[08:13:38.0000] <annevk>
JakeA: indexable is a bit frowned upon I think still

[08:17:50.0000] <JakeA>
ta

[08:19:45.0000] <annevk>
JakeA: Domenic came up with some new type specifically for array-like structures

[08:19:59.0000] <annevk>
JakeA: I think it's https://heycam.github.io/webidl/#idl-observable-array

[08:20:04.0000] <Domenic>
Not an interface though

[08:20:24.0000] <Domenic>
EventTarget + a sequence/frozenarray/observablearray would be best I think

[08:22:46.0000] <JakeA>
The context is https://github.com/webscreens/window-placement/issues/30 fwiw

[11:59:14.0000] <croraf>
I'm confused about what is the scope of WHATWG. Can I ask and discuss here?

[12:00:03.0000] <croraf>
I see that it manages a number of standards.

[12:10:36.0000] <croraf>
I see that its set of standards that are meant to be implemented by the browsers. But it also affects other parts of web infrastructure, like web servers, right?

[12:14:04.0000] <croraf>
For example the Fetch standard or the Storage standard shouldn't affect any other component of the web except the browser.

[12:14:46.0000] <croraf>
But the URL standard does affects other components of the web, not just the browser.

[12:33:00.0000] <annevk>
Sounds about right, though fetch() has been implemented by servers to some extent

[12:37:22.0000] <croraf>
annevk, yes, although this was not the intention of the standard I guess.

[12:38:12.0000] <croraf>
Now, my question is, how are WHATWG standards related to "Web IDL" standard?

[12:38:56.0000] <croraf>
https://heycam.github.io/webidl/

[13:05:06.0000] <Domenic>
croraf: almost all specs that define JavaScript APIs, including WHATWG specs and many others, use Web IDL.

[13:16:27.0000] <croraf>
I'm a bit confused why Javascript APIs are not defined in terms of Javascript but in another language?

[13:16:52.0000] <croraf>
Does Ecmascript need to conform to this Web IDL also?

[13:18:00.0000] <croraf>
Domenic,

[13:19:53.0000] <Domenic>
croraf: they are defined in terms of an abstraction layer, which reduces the boilerplate. For example you can declare your argument types in Web IDL and that abstracts away 3-4 steps per argument of validation code.

[13:23:18.0000] <zcorpan>
croraf: the ecmascript spec defines the ecmascript language without any dependency on webidl. webidl is on top of ecmascript. The fetch() API and others use webidl to get a consistent and more thought through API fundamentals on details such as argument conversion and validation

[13:23:48.0000] <croraf>
Domenic, your explaination makes sense, but I'm still a bit suspicious about this Web IDL. For example it defines a DOMString, so when designing an API you can for example say my function accepts one argument of type DOMString?

[13:24:24.0000] <Domenic>
Yes. And that allows specs to avoid writing the 3 steps in https://heycam.github.io/webidl/#es-DOMString for every argument.

[13:24:27.0000] <croraf>
If there was no WebIDL you would say my function accepts one argument of type ES String

[13:24:40.0000] <Domenic>
No, because you'd need to define what happens when the web developer passes a non-String.

[13:25:04.0000] <croraf>
Domenic, ok I see

[13:25:36.0000] <andreubotella>
If you look at the function definitions in the ECMAScript spec, you see that kind of checking that the arguments have a certain type all over the place.

[13:27:02.0000] <croraf>
zcorpan, I see, thanks. Btw using these 2 words next to each other is so confusing :D "more thought through API" for a non native speaker :D

[13:27:25.0000] <zcorpan>
heh :)

[13:28:38.0000] <croraf>
andreubotella, you want to say they repeat themselves all over the place. It would be better if they defined the "mnemonics" themselves

[13:28:40.0000] <croraf>
?

[13:28:57.0000] <croraf>
(I mean they have the absctract operations, and shortcuts like ? and !)

[13:29:42.0000] <croraf>
Hmmm, Ok the abstract operations are internal to ES.

[13:31:22.0000] <andreubotella>
you can still those abstract operations outside of ES; the Streams standard used them until recently, and some of the operations in WebIDL do

[13:31:48.0000] <andreubotella>
but the typechecking isn't very conducive to "mnemonics" of that kind unless you add a layer like WebIDL, I think

[13:32:40.0000] <croraf>
I have 2 more questions. One is who maintains the WebIDL, is it the same group that maintains the WHATWG?

[13:34:56.0000] <croraf>
The second is, is WebIDL only used in the API specs for Javascript running in the browser, or also to define interface between some other browser components?

[13:35:19.0000] <croraf>
(or some other systems like Node...)

[13:36:04.0000] <andreubotella>
WebIDL is maintained by the W3C, which is a different standards body, but it shares many people with the WHATWG

[13:36:28.0000] <andreubotella>
for example, I believe that our own annevk and Domenic are editors of WebIDL, or at least have merge permissions

[13:37:04.0000] <croraf>
And WHATWG is W3C+many others?

[13:38:41.0000] <croraf>
(that is W3C is one of the parties in WHATWG)

[13:39:12.0000] <andreubotella>
the W3C and the WHATWG are separate organizations, but they share many people because both of them define large chunks of the web platform, and so browser vendors have representation in both of them

[13:40:38.0000] <croraf>
andreubotella, thanks!

[13:41:23.0000] <croraf>
Now only one of my questions remains: Is WebIDL only used in the API specs for Javascript running in the browser, or also to define interface between some other browser components?

[13:42:43.0000] <andreubotella>
so WebIDL was originally meant as a compatibility layer between the browser code (written in C++ or Rust) and the JS APIs

[13:42:48.0000] <croraf>
Or better: "Is WebIDL only used in the API specs for libraries used by the Javascript running in the browser, or also to define interface between some other browser components?"

[13:43:02.0000] <andreubotella>
but in the last few years it has shown its use in porting web APIs to Node.js or Deno

[13:43:42.0000] <andreubotella>
I don't think WebIDL is used per se across browser components that aren't accessible from JS code

[13:43:59.0000] <croraf>
andreubotella, thanks, you helped me a lot.

[13:44:59.0000] <croraf>
When you say "...and the JS APIs" you mean the JS API these libraries expose for the browser's Javascript to use?

[13:45:00.0000] <andreubotella>
no problem

[13:45:09.0000] <andreubotella>
that's right

[13:45:16.0000] <croraf>
Thanks, all clear :)

[13:45:23.0000] <croraf>
You guys are awesome :)

[13:45:50.0000] <croraf>
Very precise in the answers, I guess the specs people are like that :D

[13:46:29.0000] <andreubotella>
heh, I just started contributing to the specs a few months ago

[13:46:35.0000] <andreubotella>
most of this is stuff I've picked up

[13:46:46.0000] <andreubotella>
*picked up on

[13:46:58.0000] <andreubotella>
my English is also not the best ever :)

[13:47:29.0000] <croraf>
Haven't noticed that.

[13:48:00.0000] <croraf>
I got interested couple of days ago when I explored the "fetch" API in the MDN documents.

[13:48:52.0000] <croraf>
If you dive thorough it you get to the point where you can read the incoming response using https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream/getReader

[13:50:32.0000] <andreubotella>
yeah, I also found my way here through MDN

[13:50:39.0000] <croraf>
Here it mentions that the mode parameter is of type DOMString.

[13:51:28.0000] <Domenic>
I wish MDN would not use IDL terms :(. They are really for implementations and code-generators. Web developers should never need to worry about what a "DOMString" is.

[13:51:59.0000] <croraf>
Yes!!!

[13:52:01.0000] <Domenic>
Similarly MDN says "interface" a lot, which is a confusing IDL term. For web developers they could just say "class"

[13:52:13.0000] <Domenic>
I have given them this feedback many times but they have not been willing to change.

[13:52:18.0000] <croraf>
They don't use it often. Rarely you encounter something like that.

[13:52:46.0000] <croraf>
Domenic, I think MDN is free to edit from anyone.

[13:52:57.0000] <Domenic>
Yeah, but fighting against the full-time editors is hard.

[13:53:18.0000] <croraf>
You think they might revert the change back also?

[13:53:33.0000] <croraf>
Or just that you cannot change on every place and continously?

[13:53:59.0000] <Domenic>
Mostly the latter. But also, they might revert the change because if I changed it in only one place it would be inconsistent, and they prefer consistency.

[13:54:38.0000] <croraf>
Domenic, also I checked this: https://developer.mozilla.org/en-US/docs/Web/API/DOMString

[13:55:10.0000] <croraf>
And it says that it maps directly to String.

[13:55:55.0000] <croraf>
I mean, in this direction this might be true actually.

[13:57:28.0000] <Domenic>
Yeah, I mean, it could explain that it will "stringify" whatever you pass in... but I'm not sure how helpful that is.

[13:58:16.0000] <croraf>
The root of the problem is that they used DOMString at all.

[14:01:36.0000] <andreubotella>
I suspect that the MDN folks wanted to preserve the distinction between DOMString/USVString/ByteString, since the latter two won't accept every ES string

[14:02:36.0000] <andreubotella>
but just throwing those terms at a JS developer won't help them very much

[14:07:27.0000] <croraf>
Is there a reason why mention DOMString here: https://pasteboard.co/Jr608kY.png

[14:08:13.0000] <croraf>
When it says that mode can have only 2 valid values, the "byob" and undefined.

[14:10:51.0000] <andreubotella>
I suspect that's a "mistranslation", since the WebIDL here uses very uncommon constructs

[14:11:33.0000] <andreubotella>
the Stream spec switched to using WebIDL a couple months ago, and some of the APIs weren't very WebIDL-friendly

[14:13:01.0000] <croraf>
https://streams.spec.whatwg.org/#rs-get-reader

[14:13:13.0000] <croraf>
this is the link andreubotella

[14:13:47.0000] <croraf>
I'm thinking of removing the mention of DOMString there :/

[14:14:09.0000] <andreubotella>
yeah, I don't think anyone would oppose to that

[14:15:43.0000] <andreubotella>
the parameter here uses a dictionary with a single non-required element, which is an enum with only one variant

[14:16:47.0000] <andreubotella>
in practice, the allowed values of mode are the enum variant ("byob") and undefined, but that's not easy to tell

[14:17:45.0000] <andreubotella>
I had to read through the relevant sections of WebIDL a couple times to figure out why Domenic used that

[14:20:44.0000] <croraf>
In the streams spec link, first step it checks if options["mode"] does not exist.

[14:21:27.0000] <croraf>
It links to "exist" definition, but I'm still not clear when is the object["key"] considered to exist.

[14:21:59.0000] <andreubotella>
if you look at the WebIDL block here: https://streams.spec.whatwg.org/#rs-class-definition

[14:22:07.0000] <andreubotella>
you see that the parameter to getReader is an optional dictionary

[14:22:11.0000] <croraf>
If the object itself does not exist or is undefined or is a string, what happens here.

[14:22:58.0000] <andreubotella>
iirc, WebIDL translates a dictionary into an Infra map, such that if the key is undefined, it "does not exist" by that definition

[14:24:15.0000] <croraf>
Yes. But if the options itself is undefined what happens at this step:

[14:24:16.0000] <croraf>
1. If options["mode"] does not exist, return ? AcquireReadableStreamDefaultReader(this).

[14:24:42.0000] <andreubotella>
the WebIDL block has: optional ReadableStreamGetReaderOptions options = {}

[14:25:08.0000] <andreubotella>
a.k.a. when the param is not given, the Infra map will be the same as if it was converted from an empty JS object

[14:25:17.0000] <andreubotella>
that is, empty

[14:25:32.0000] <andreubotella>
there's a lot of moving parts

[14:26:53.0000] <andreubotella>
I'd recommend you to first go through the Infra spec, and then check out some of the webidl conversion algorithms

[14:28:06.0000] <andreubotella>
for some quick intuition: the WHATWG spec algorithms for the most part don't deal with JS objects directly -- they deal with the WebIDL interfaces

[14:29:06.0000] <andreubotella>
a.k.a with the C++ objects that back the JS objects

[14:29:23.0000] <croraf>
Yes. I understand your last comment, yes. I'm missing a lot of basics. But just let make this clear. If the options is not given at all, or is given as undefined it will be set to an "empty object" right?

[14:30:04.0000] <croraf>
(or empty map)

[14:30:29.0000] <croraf>
(or empty Infra map :D, whatever)

[14:30:48.0000] <croraf>
as indicated by "= {}"

[14:31:17.0000] <andreubotella>
"= {}" means that the default JS value is an empty object (more or less...)

[14:31:25.0000] <andreubotella>
and WebIDL translates that to an empty Infra map

[14:32:11.0000] <croraf>
Now, one last question. What if I provide a string or a number as this options argument. How is this resolved from the IDL schema that we look at?

[14:32:35.0000] <andreubotella>
https://heycam.github.io/webidl/#es-dictionary

[14:33:00.0000] <andreubotella>
"an ECMAScript value `esDict` is converted into an IDL dictionary type by running the following algorithm"

[14:33:23.0000] <andreubotella>
in this case:

[14:33:23.0000] <andreubotella>
    If Type(esDict) is not Undefined, Null or Object, then throw a TypeError.

[14:35:21.0000] <croraf>
Cool. Indeed makes sense. Ty. I'm going to test if it really throws a TypeError :D

[14:37:33.0000] <Domenic>
That error might not yet be implemented in browsers. It's one of the subtle differences that occurred when we switched the spec to Web IDL, and implementations haven't fully switched yet.

[14:37:52.0000] <Domenic>
See the full list of subtle differences in https://github.com/whatwg/streams/pull/1035

[14:39:37.0000] <croraf>
Yes, chrome doesnt throw an error

[14:40:09.0000] <croraf>
https://pasteboard.co/Jr6duq5.png Domenic , andreubotella

[14:41:00.0000] <Domenic>
Yes, the old spec would look up 'the string'.mode, which was usually undefined

[14:41:42.0000] <croraf>
Cool cool. Ty andreubotella and Domenic and others :)

[14:41:56.0000] <andreubotella>
from my time lurking in that thread, I thought Chrome had switched to WebIDL for streams

[14:42:23.0000] <Domenic>
andreubotella: they did, but with a ton of `any` to match the existing semantics as much as possible.

[14:42:30.0000] <andreubotella>
I see

[14:43:25.0000] <croraf>
Btw I contributed a bit to a Rust JS engine. Cool project called boa. Primitive support though.

[14:44:00.0000] <croraf>
There is a much more advanced engine in development Jsparagus Mozilla backed, but dont know if it stopped with mozilla's cuts

[14:44:26.0000] <croraf>
Actually Jsparagus is maybe only a parser and compiler or something like that.

[14:45:00.0000] <croraf>
Boa is a parser and runner.

[14:45:20.0000] <croraf>
Fun stuff, rust is kind of fun.


2020-09-15
[20:55:01.0000] <annevk>
I still kinda think we should rename DOMString

[00:39:11.0000] <MikeSmith>
annevk: about Encoding, are you aware of implementations that implement the decoders and encoders per-spec?

[00:39:40.0000] <annevk>
MikeSmith: Chrome, Firefox, and soon Safari

[00:39:52.0000] <MikeSmith>
oh

[00:39:53.0000] <MikeSmith>
OK

[00:39:55.0000] <annevk>
or at least Safari TP

[00:40:24.0000] <MikeSmith>
I remain curious where the Firefox code for that lives

[00:40:54.0000] <annevk>
I want to blog about it when that happens as it's so cool that we're finally there, 11 years after starting to look into it

[00:40:59.0000] <zcorpan>
MikeSmith: https://github.com/hsivonen/encoding_rs

[00:41:08.0000] <MikeSmith>
/me looks

[00:41:10.0000] <annevk>
/me was about to paste that

[00:41:28.0000] <MikeSmith>
aha

[00:41:36.0000] <MikeSmith>
thanks

[00:41:39.0000] <annevk>
MikeSmith: https://github.com/hsivonen/chardetng might also be of interest

[00:43:15.0000] <MikeSmith>
/me looks

[00:44:16.0000] <MikeSmith>
ah I now recall Henri mentioning that elsewhere

[00:44:41.0000] <annevk>
there's posts/articles too, yes :-)

[00:47:28.0000] <MikeSmith>
the need to implement the decoders and encoders makes implementing a conforming HTML parser signficantly more work

[00:48:06.0000] <MikeSmith>
I think html5ever and parse5 don’t actually implement decoders/encoders per spec

[00:48:41.0000] <MikeSmith>
...but instead just rely on the character encoding support in the runtime

[00:56:52.0000] <zcorpan>
MikeSmith: I think node has an encoding standard implementation, see https://github.com/nodejs/node/issues/20365

[00:57:32.0000] <annevk>
zcorpan: I think that might be around non-compliant encoders/decoders

[00:57:55.0000] <zcorpan>
oh

[01:00:18.0000] <zcorpan>
maybe mathiasbynens encoders/decoders are of interest then https://www.npmjs.com/search?q=keywords:legacy-encoding MikeSmith

[01:00:57.0000] <MikeSmith>
/me looks

[01:01:06.0000] <MikeSmith>
ah cool

[03:25:37.0000] <zcorpan>
annevk: hmmmm, it seems hard to isolate the effect of encoding scanner in wpt, in particular if the speculative parser also looks for encoding declarations (which gecko does at least)

[03:27:15.0000] <annevk>
Well, we only need to document what is observable, so...

[03:27:55.0000] <MikeSmith>
getting 💥 Error: 403 Forbidden 💥

[03:28:06.0000] <MikeSmith>
...for https://github.com/whatwg/html/pull/5916

[03:28:39.0000] <MikeSmith>
dunno if that’s the same problem we had recently with another PR, or whether it’s a different problem

[03:29:13.0000] <annevk>
That seems different

[03:29:46.0000] <annevk>
Did w3.org start blocking PR Preview?

[03:29:52.0000] <zcorpan>
annevk: true. it's certainly possible to test things like <script><meta charset=A></script><meta charset=B>

[03:33:44.0000] <MikeSmith>
annevk: dunno maybe accidentally

[04:40:50.0000] <croraf>
<annevk> "I still kinda think we should rename DOMString," I already heard this opinion

[04:41:08.0000] <croraf>
annevk, do you get pinged when I enwrap your name in <>?

[04:41:24.0000] <annevk>
yes

[05:44:02.0000] <croraf>
Does `fetch` inspect the Content-Type header?

[05:45:58.0000] <croraf>
OK. The question is stupid, because it obviously provides Response.headers.

[05:47:05.0000] <croraf>
OK, once again I'm a bit confused by the MDN https://developer.mozilla.org/en-US/docs/Web/API/Response

[05:48:07.0000] <croraf>
This is mentioning Response *interface*, and lists the properties below, for example Response.headers. But this should be written as Response.prototype.headers?

[05:48:20.0000] <MikeSmith>
croraf: yes

[05:48:52.0000] <MikeSmith>
that’s a common problem with some MDN content, unfortunately

[05:49:14.0000] <croraf>
MikeSmith, so this *interface* is the WebIDL term, right?

[05:49:21.0000] <MikeSmith>
yes

[05:49:46.0000] <MikeSmith>
maybe probably it should instead talk about it object

[05:50:03.0000] <MikeSmith>
but again that’s kind of a common shortcoming in some MDN articles

[05:51:42.0000] <MikeSmith>
the articles in the https://developer.mozilla.org/en-US/docs/Web/JavaScript tree are written in a way that’s more correct and familiar

[06:13:11.0000] <croraf>
MikeSmith, Cool, I might even try to change this Response page these days, to see what happens.

[06:14:06.0000] <MikeSmith>
croraf: If you can make time to update it, that would be great

[06:15:10.0000] <croraf>
Becuase I remember reading that several times over the last years, and I remember it confused me so much, although it is kind of intuitive.

[06:15:22.0000] <MikeSmith>
yeah

[06:15:46.0000] <croraf>
So I was like: "Ok, lets not bother with the details this time."

[06:15:55.0000] <MikeSmith>
and in general with MDN, when you run into confusing articles, you can also file issues at https://github.com/mdn/sprints/issues/new/choose with details about changes that should be made

[06:16:19.0000] <croraf>
oh, cool

[06:16:43.0000] <MikeSmith>
but it’s better if you can make the edits directly

[06:17:00.0000] <MikeSmith>
I will be happy post-review any changes you make

[06:17:30.0000] <MikeSmith>
I get automated notifications for any changes to https://developer.mozilla.org/en-US/docs/Web/API articles, so I’ll see it regardless

[06:17:33.0000] <croraf>
MikeSmith, regarding this issues link, which category do WHATWG specs fit.

[06:17:50.0000] <croraf>
Ofc HTML goes into HTML, but the other specs?

[06:18:11.0000] <MikeSmith>
hmm good point

[06:18:28.0000] <MikeSmith>
I see now that https://github.com/mdn/sprints/issues/new/choose doesn’t have category for API docs

[06:19:16.0000] <MikeSmith>
I guess “Content issue template” is the general one

[06:19:33.0000] <MikeSmith>
but I will suggest that a specific API one be added

[06:20:17.0000] <MikeSmith>
croraf: actually though, the preferred way is to just follow a link from the MDN article

[06:20:24.0000] <croraf>
cool

[06:20:40.0000] <MikeSmith>
if you go to https://developer.mozilla.org/en-US/docs/Web/API/Response, there a Feedback drop-down at the top

[06:21:11.0000] <croraf>
Yes.

[06:21:29.0000] <MikeSmith>
yeah, from that you can select Report a content problem

[06:22:07.0000] <croraf>
One unlinked question. The URL spec from WHATWG does only relate to the URL object available by the browser or also with the web URL concept itself?

[06:22:19.0000] <MikeSmith>
both

[06:22:46.0000] <MikeSmith>
both the API/object and general definition of what a URL is

[06:23:15.0000] <croraf>
This is kind of unfortunate in my opinion. I hoped that WHATWG would only deal with the browser objects (APIs)

[06:23:27.0000] <croraf>
Would be more clean, so to say.

[06:23:56.0000] <MikeSmith>
well the problem is that in practice that clean separation is most often not possible

[06:24:39.0000] <croraf>
It is kind of unclear to me what WEB consists of. Could we say that WHATWG specifies things only strictly within the WEB?

[06:24:55.0000] <croraf>
(WEB consists of = what WEB actually is)

[06:25:03.0000] <MikeSmith>
and another specific problem in the case of URL is that the relevant RFCs are out of data and not maintained and in fact peole in IETF land think there is nothing that needs to be updated

[06:25:30.0000] <MikeSmith>
in fact many assert that the term URL should not be used but instead URI should be

[06:25:39.0000] <MikeSmith>
and so on and on and on

[06:25:49.0000] <croraf>
MikeSmith, does this mean that WHATWG specs sometimes conflict with the IETF one?

[06:25:55.0000] <croraf>
Or they only extend it?

[06:25:56.0000] <MikeSmith>
yes

[06:26:03.0000] <MikeSmith>
conflict

[06:26:06.0000] <croraf>
thanks.

[06:26:55.0000] <MikeSmith>
yeah, again, that’s because the responsible parties at the IETF usually don’t ever update their specs after they become RFCs

[06:27:14.0000] <croraf>
MikeSmith, I just read https://softwareengineering.stackexchange.com/questions/109517/how-is-ietf-different-from-w3c

[06:27:16.0000] <MikeSmith>
...even in cases where the specs are known to conflict with implememtations

[06:27:28.0000] <croraf>
I mean should IETF at all dead with such stuff?

[06:27:31.0000] <croraf>
Or the W3C?

[06:27:40.0000] <croraf>
Or is W3C a subcomitee of IETF?

[06:27:52.0000] <MikeSmith>
separate

[06:28:26.0000] <MikeSmith>
and the answers in that that stack question are not good

[06:28:57.0000] <croraf>
And the top voted answer?

[06:29:09.0000] <croraf>
- IETF works on Internet protocols, particularly at OSI layer 3 and 4.

[06:29:20.0000] <croraf>
- WWW, which is simply an application-layer protocol. The W3C works on WWW specifications

[06:29:43.0000] <MikeSmith>
that W3C generally does not work on protocols at all

[06:30:03.0000] <MikeSmith>
with some exceptions

[06:30:38.0000] <croraf>
Also the first answer conflicts with the second answer:

[06:30:43.0000] <croraf>
- IETF works on Internet protocols, particularly at OSI layer 3 and 4.

[06:30:54.0000] <croraf>
- IETF focuses on packet/line/terminal/telnet based protocols

[06:31:04.0000] <croraf>
telnet is Application layer

[06:31:27.0000] <MikeSmith>
about “Web”, you’ll notice that we use the term “the Web platform” — which basically means the set of standard technologies that are implemented nativelly in web browsers

[06:32:16.0000] <croraf>
So Web are basically the application implemented in the browsers?

[06:32:27.0000] <MikeSmith>
web platform

[06:32:35.0000] <croraf>
ok

[06:32:41.0000] <MikeSmith>
that Web is an information system

[06:35:51.0000] <croraf>
Does W3C also deal with defining the URL for example?

[06:41:02.0000] <MikeSmith>
W3C specs reference the WHATWG URL standard

[06:43:28.0000] <croraf>
Hmm, I indeed see that in MDN the entire Web/API section of articles uses WebIDL terminology. So it is not possible to change, because that would be 1 inconsistent out of 50.

[07:26:28.0000] <Domenic>
MikeSmith: annevk: I'm looking into why CI isn't building... maybe it's not picking up the latest Wattsi somehow.

[07:26:55.0000] <Domenic>
Well, it is picking up the latest Wattsi, which is preventing most PRs, but I'm unsure why https://github.com/whatwg/html/pull/5916 is failing CI...

[07:26:57.0000] <annevk>
Domenic: did I break it with my html-build change?

[07:27:13.0000] <annevk>
/me isn't sure about the timeline, but did land something today

[07:27:23.0000] <Domenic>
No, it's because we merged MikeSmith's change to make data-export + data-dfn-type an error (because they're redundant), which makes the current spec an error.

[07:27:29.0000] <Domenic>
So master doesn't build anymore

[07:27:38.0000] <Domenic>
But https://github.com/whatwg/html/pull/5916 should fix that

[07:27:43.0000] <Domenic>
But it's not passing validation

[07:27:56.0000] <Domenic>
I'll investigate for a bit, and rollback Wattsi if it's not an easy fix.

[07:28:26.0000] <annevk>
Domenic: didn't you need to update the Wattsi server manually?

[07:28:37.0000] <Domenic>
CI shouldn't be using the Wattsi server

[07:28:48.0000] <Domenic>
But yes I do need to do that soon enough

[07:29:48.0000] <annevk>
So looking at MikeSmith's PR the problem is that the output doesn't validate

[07:30:06.0000] <Domenic>
Right. Which indicates incomplete replacements maybe?

[07:30:16.0000] <annevk>
It seems we don't convert export/attribute back to data-...

[07:31:08.0000] <Domenic>
https://github.com/whatwg/wattsi/commit/b6a7eea5edacb73af77a457055bab81d6e93387c indicates we should, but maybe we didn't fully test...

[07:32:21.0000] <MikeSmith>
dang

[07:32:46.0000] <MikeSmith>
looking now

[07:33:53.0000] <MikeSmith>
are we sure the build is picking up the latest Wattsi?

[07:34:24.0000] <Domenic>
I think so, because it's giving the export + dfn-type error

[07:34:27.0000] <Domenic>
I'm testing locally now

[07:35:00.0000] <Domenic>
Yeah with latest Wattsi locally the attributes still appear in the source (noexport="", abstract-op="", ...)

[07:35:06.0000] <annevk>
I wish this was using GitHub CI already, it's much harder for me to retry Travis stuff

[07:35:08.0000] <Domenic>
It looks like the replacement might indeed be done in the wrong phase

[07:35:47.0000] <Domenic>
We should probably roll back https://github.com/whatwg/wattsi/commit/7e4d1e8f42b6d9f6a4a355c0213aa91b4f47605d specifically for now

[07:35:53.0000] <Domenic>
To un-break the build on master and let other PRs land

[07:36:11.0000] <Domenic>
Then figure out why the conversion code (noexport -> data-noexport, etc.) isn't working.

[07:36:24.0000] <MikeSmith>
I can reproduce it locally

[07:36:43.0000] <MikeSmith>
I think it’s not just the noexport -> data-noexport part

[07:37:03.0000] <MikeSmith>
I see alos “Attribute “element” not allowed on element “h4” at this point.”

[07:37:34.0000] <Domenic>
Yeah I don't think any of the replacements are working :(

[07:38:04.0000] <MikeSmith>
I would think most of them are working

[07:38:39.0000] <MikeSmith>
because I am only getting 35 errors

[07:39:03.0000] <MikeSmith>
if it were not working at all, I would think it’d be more like hundreds

[07:39:35.0000] <MikeSmith>
so my first guess is that that Wattsi code is not catching a subset of cases

[07:39:57.0000] <Domenic>
My output/index.html does not contain any data-dfn-type or data-export

[07:39:59.0000] <MikeSmith>
 but also I see some weird instances of “Attribute “dfn” not allowed on element “h5” at this point.”

[07:42:41.0000] <MikeSmith>
Domenic: for me:

[07:42:43.0000] <MikeSmith>
$ rg data-dfn-type output/ | wc -l 720

[07:43:25.0000] <Domenic>
Oh shoot my thing used the build server

[07:43:36.0000] <Domenic>
Forgot to set $PATH

[07:43:51.0000] <MikeSmith>
ah OK

[07:45:31.0000] <MikeSmith>
CI errors at https://travis-ci.org/github/whatwg/html/builds/727323337#L618 look like exactly the same set of errors I am getting locally

[07:46:22.0000] <Domenic>
Maybe <hN>s and <dfn>s are treated specially by Wattsi

[07:46:48.0000] <MikeSmith>
yeah must be that

[07:47:38.0000] <MikeSmith>
well now that I say that: Actually the Wattsi code doesn’t do anythign for these in hNs

[07:47:45.0000] <MikeSmith>
so that is expected

[07:48:18.0000] <MikeSmith>
the current Wattsi code only makes the translations for dfn elements

[07:49:42.0000] <MikeSmith>
so I guess the first fix that’s needed is to just duplicate the translation handling for dfn over to the hN-handling code

[07:49:53.0000] <Domenic>
Oh dang haha

[07:50:07.0000] <MikeSmith>
yeah, silly oversight :(

[07:50:20.0000] <MikeSmith>
but then I was not aware that we had this stuff on hNs

[07:50:33.0000] <MikeSmith>
I should not have just assumed

[07:50:52.0000] <MikeSmith>
well, I should have also run the HTML checker on the output locally

[07:51:44.0000] <MikeSmith>
incidentally, maybe we should have the build script be running the HTML checker

[07:51:58.0000] <MikeSmith>
locally I mean

[07:52:16.0000] <MikeSmith>
with an opt-out

[07:52:32.0000] <MikeSmith>
not run it for the -f case for sure

[07:53:03.0000] <MikeSmith>
anyway, will make the hN fix in Wattsi right now

[07:53:11.0000] <MikeSmith>
and then re-test

[07:59:58.0000] <MikeSmith>
OK well did that, and that eliminates all the HTML checker errors

[08:00:05.0000] <croraf>
Can interface be a mixin?

[08:00:06.0000] <MikeSmith>
including “Attribute “dfn” not allowed on element “h5” at this point.”

[08:00:35.0000] <MikeSmith>
Domenic: annevk: so I guess “dfn” is a valid dfn type

[08:00:42.0000] <MikeSmith>
/me checks the code

[08:01:14.0000] <MikeSmith>
croraf: yes, an interface defined in a spec can be mixin

[08:02:07.0000] <croraf>
Does this mean an interface can have some methods and/or properties implemented and still be an interface?

[08:02:32.0000] <zcorpan>
Domenic: annevk: hmmm, what happened here? I don't get that locally, and the PR is based on latest master https://travis-ci.org/github/whatwg/html/builds/727385861

[08:02:33.0000] <MikeSmith>
hmm, no, “dfn” is not a valid dfn type, so I don’t know why my change fixed that error

[08:02:55.0000] <Domenic>
zcorpan: see last hour of chat :)

[08:03:09.0000] <zcorpan>
Domenic: oh lol

[08:03:20.0000] <Domenic>
zcorpan: basically, new Wattsi breaks master, and we're working on fixing it

[08:03:34.0000] <MikeSmith>
croraf: don’t understand your question. For an interface mixin, the members are exposed from other interfaces that use that mixin

[08:03:59.0000] <zcorpan>
:+1:

[08:04:00.0000] <Domenic>
MikeSmith: so, upload your fix and we're good to go, no reverts needed?

[08:04:08.0000] <MikeSmith>
no reverts needed

[08:04:21.0000] <MikeSmith>
I will raise a PR with the patch shortly

[08:04:44.0000] <MikeSmith>
but we now have other errors that require updating the spec source

[08:05:09.0000] <MikeSmith>
the redundant export thing

[08:05:24.0000] <MikeSmith>
Error: <dfn> found with dfn type name and redundant export attribute; dfn is <h4> element containing "StructuredSerialize ( value )"; previous heading contents are "StructuredSerialize ( value )"

[08:05:28.0000] <MikeSmith>
Error: <dfn> found with dfn type name and redundant export attribute; dfn is <h4> element containing "StructuredSerializeForStorage ( value )"; previous heading contents are "StructuredSerializeForStorage ( value )"

[08:05:32.0000] <MikeSmith>
Error: <dfn> found with dfn type name and redundant export attribute; dfn is <h4> element containing "StructuredDeserialize ( serialized, targetRealm [ ,   memory ] )"; previous heading contents are "StructuredDeserialize ( serialized, targetRealm [ ,   memory ] )"

[08:05:36.0000] <MikeSmith>
Error: <dfn> found with dfn type name and redundant export attribute; dfn is <h4> element containing "StructuredSerializeWithTransfer ( value, transferList   )"; previous heading contents are "StructuredSerializeWithTransfer ( value, transferList   )"

[08:05:40.0000] <MikeSmith>
Error: <dfn> found with dfn type name and redundant export attribute; dfn is <h4> element containing "StructuredDeserializeWithTransfer ( serializeWithTransferResult,   targetRealm )"; previous heading contents are "StructuredDeserializeWithTransfer ( serializeWithTransferResult,   targetRealm )"

[08:05:46.0000] <MikeSmith>
Error count: 5

[08:06:06.0000] <MikeSmith>
so I will fix those by pushing a commit to the HTML spec PR

[08:08:41.0000] <Domenic>
Ah perfect

[08:08:52.0000] <croraf>
MikeSmith, I'm reading this "A mixin is a class or interface in which some or all of its methods and/or properties are unimplemented, requiring that another class or interface provide the missing implementations." from https://developer.mozilla.org/en-US/docs/Glossary/mixin

[08:09:23.0000] <croraf>
When it says "is a class or interface", are class and interface WebIDL terms?

[08:10:20.0000] <croraf>
Because I dont see class defined in WebIDL

[08:11:27.0000] <MikeSmith>
well it’s a class really

[08:12:01.0000] <MikeSmith>
arguably we rightly shouldn’t be using the term “interface” at all

[08:12:13.0000] <MikeSmith>
but the specs are

[08:12:46.0000] <MikeSmith>
so that MDN glossary entry should not be mentioning “class” I guess

[08:13:36.0000] <MikeSmith>
Domenic: TranslateShortSyntax() for the function name?

[08:13:53.0000] <Domenic>
MikeSmith: SGTM, or maybe "TranslateBikeshedSyntax"

[08:13:58.0000] <MikeSmith>
k

[08:15:06.0000] <zcorpan>
croraf: they're neither classes or interfaces, https://heycam.github.io/webidl/#idl-interface-mixins is a separate concept. interfaces can include an interface mixin

[08:16:09.0000] <croraf>
So interface mixin is basically an interface that can be extended by another interface, and that's it?

[08:16:43.0000] <croraf>
I mean you said it is not an interface, so i guess it technically is not.

[08:17:06.0000] <zcorpan>
right, it's a specification-level shorthand so you don't need to write the same things twice

[08:17:53.0000] <zcorpan>
interface A { undefined queueMicrotask(VoidFunction callback); } interface B { undefined queueMicrotask(VoidFunction callback); }

[08:17:59.0000] <zcorpan>
is equivalent to

[08:18:32.0000] <croraf>
But is it basically an interface that cannot be used as an interface itself but can be extended by other interfaces?

[08:18:37.0000] <zcorpan>
interface A {}; interface B {}; interface mixin C { undefined queueMicrotask(VoidFunction callback); }; A includes C; B includes C;

[08:19:35.0000] <croraf>
I'm not sure why it exists as a separate concept, why is it not just the interface itself zcorpan ?

[08:20:09.0000] <zcorpan>
croraf: they aren't extended by other interfaces, their members are folded into other interfaces

[08:20:33.0000] <Domenic>
Maybe the confusion is that "interface mixin" doesn't mean "interface that is a mixin". It means "mixin for use by interfaces"

[08:21:01.0000] <croraf>
Domenic, I understand. But I'm making a parallel with Java OO concepts.

[08:21:14.0000] <Domenic>
I don't think that will serve you well.

[08:21:17.0000] <croraf>
You have interfaces and interfaces can "extend" other interfaces.

[08:21:19.0000] <Domenic>
Web IDL is not like Java.

[08:21:24.0000] <Domenic>
Web IDL is a framework for generating code.

[08:21:31.0000] <Domenic>
And saving typing.

[08:21:42.0000] <Domenic>
The concepts in it are not OO concepts.

[08:21:51.0000] <Domenic>
The concepts in it are things that are useful to save typing by spec authors.

[08:21:58.0000] <croraf>
Well interface is basically an OO concept.

[08:22:14.0000] <croraf>
interface that applies to objects.

[08:22:15.0000] <Domenic>
The Web IDL interface is not an OO concept.

[08:22:16.0000] <andreubotella>
if you're coming from Java, WebIDL "interface" is *kinda like* a class, and a WebIDL "mixin" is *kinda like* an interface

[08:22:21.0000] <Domenic>
It is a way of generating spec code.

[08:22:48.0000] <Domenic>
The spec code that it generates mostly corresponds to a JavaScript class, but that's incidental, and as you can see, the names were not chosen to match up.

[08:23:08.0000] <croraf>
andreubotella, I think that both "interface mixin" and "interface" are like OO Java's interface.

[08:23:10.0000] <Domenic>
Trying to draw analogies will mostly hurt understanding.

[08:23:27.0000] <croraf>
interface mixing defines members that are included in interfaces

[08:23:46.0000] <croraf>
by using A includes Amixin

[08:24:15.0000] <croraf>
That seeems analoguous as having interface A and interface Amixin in java and doing  interface A extends Amixin {}

[08:24:36.0000] <MikeSmith>
Domenic: https://github.com/whatwg/wattsi/pull/136 (and I’ll do the HTML commit in about 90 minutes from now)

[08:24:49.0000] <croraf>
None have an implementation, so none are considered as class.

[08:26:05.0000] <Domenic>
MikeSmith: excellent, thank you. I can try to finish things off; if local testing works then I'll push and merge.

[08:29:53.0000] <croraf>
To ilustrate I dont know why you couldnt do: interface A {}; interface C { undefined queueMicrotask(VoidFunction callback); }; A includes C;

[08:37:56.0000] <andreubotella>
to see how a WebIDL interface is more like a class in OOP languages, consider that you can do `new URL()` or `var instanceof URL`, but you can't do that with a mixin

[08:38:37.0000] <andreubotella>
the fact that interfaces aren't implemented in WebIDL doesn't matter because WebIDL meant to describe APIs, not their behavior

[08:38:41.0000] <andreubotella>
*is meant

[08:39:12.0000] <Domenic>
MikeSmith: still some issues sadly :( https://github.com/whatwg/html/pull/5916#issuecomment-692797393

[08:39:19.0000] <Domenic>
I'll revert the conflict-checking commit for now

[08:39:42.0000] <zcorpan>
croraf: all webidl interface names are exposed as properties on the global. that's not desired for mixins

[08:40:11.0000] <andreubotella>
isn't there any intro documents for beginners to the web specs?

[08:40:48.0000] <croraf>
andreubotella, you can do new URL() because someone implemented the URL interface.

[08:41:10.0000] <zcorpan>
andreubotella: there's https://wpc.guide/ but it doesn't go into depth of details like these :)

[08:41:13.0000] <annevk>
croraf: an IDL interface really is a description of a class

[08:41:21.0000] <annevk>
Web IDL interface that is

[08:41:22.0000] <croraf>
And (by convention it seems) the interface mixins itself cannot be implemented but must be included in an interface.

[08:42:06.0000] <annevk>
andreubotella: I don't think so, sometimes specifications have introductions and maybe Web IDL should have a better one

[08:42:23.0000] <Domenic>
It's amazing to me how much confusion we're seeing caused just because Web IDL used the incorrect word "interface"

[08:42:31.0000] <Domenic>
I wish it'd used "flargle" instead, then nobody would have these questions.

[08:42:33.0000] <croraf>
An IDL interface doesnt specifiy the implementation, but an API

[08:42:41.0000] <Domenic>
They'd say "what's a flargle" and we could explain from scratch

[08:42:49.0000] <Domenic>
Instead of them bringing pre-concieved incorrect notions from Java or similar.

[08:42:50.0000] <annevk>
croraf: no it does specify an implementation

[08:43:15.0000] <andreubotella>
croraf: even in Java, you can't construct an interface with `new URL()`, URL would have to be a class

[08:43:21.0000] <annevk>
Domenic: I mean, "class" would work and we can still rename

[08:43:36.0000] <annevk>
and one day I hope we will

[08:43:48.0000] <Domenic>
annevk: quick LGTM on https://github.com/whatwg/wattsi/pull/137 would be good

[08:44:26.0000] <annevk>
I rubberstamped it

[08:46:39.0000] <croraf>
annevk, you see interface Headers here https://fetch.spec.whatwg.org/#headers-class this is not an implementation it is just a specification

[08:47:20.0000] <annevk>
croraf: ok

[08:47:29.0000] <croraf>
It has the class of the same name which implements this interface.

[08:47:40.0000] <croraf>
And that class is available in the browser.

[08:47:53.0000] <annevk>
And what defines that?

[08:48:08.0000] <andreubotella>
I'm starting to agree with annevk that it'd be worth renaming the concept

[08:48:10.0000] <croraf>
You mean the class?

[08:48:15.0000] <croraf>
annevk,

[08:48:23.0000] <croraf>
what defines the class?

[08:49:10.0000] <croraf>
The class' API is defined by the Class interface.

[08:50:34.0000] <andreubotella>
the point we're trying to explain is that, even by your model, there'd be one single class that implements the Headers interface, and the spec defines it with reference to the Headers interface, not as a separate class

[08:51:31.0000] <andreubotella>
but it'd be more productive to just see "WebIDL interface" and think of "class"

[08:51:39.0000] <annevk>
and also, part of your implementation is generated from the IDL construct, such as how to do argument coercion, etc.

[08:51:41.0000] <Domenic>
OK, master is back to building

[08:51:45.0000] <annevk>
\o/

[08:55:18.0000] <croraf>
andreubotella, I don't see your point. Not sure what you mean "there had to be one single class".

[08:55:53.0000] <croraf>
annevk, Haven't went into details but this is more like specifying how the implementation should behave.

[08:56:07.0000] <annevk>
croraf: the way this works, you cannot have multiple classes implementing the same interface

[08:56:50.0000] <annevk>
croraf: sure, but it's a lot more than just a shape

[08:57:01.0000] <croraf>
Well it is shape and behavior.

[08:57:43.0000] <croraf>
You cannot use the interface before someone implements it as a Class.

[08:58:02.0000] <croraf>
You can have several implementations of the interface.

[08:58:21.0000] <croraf>
Class1 implements Class,    Class2 implements Class,    etc.

[08:58:27.0000] <annevk>
You are making a bunch of assertions here, but I don't think these are backed up by any web standard

[08:59:28.0000] <annevk>
Which makes it hard to have a conversation; when we say "interface", we mean what Web IDL defines that to be

[08:59:49.0000] <Domenic>
+1, it is getting a bit frustrating.

[09:00:09.0000] <Domenic>
It seems like you see the word "interface" and assume it means what you want it to mean, instead of what the spec defines it to mean.

[09:02:33.0000] <andreubotella>
I think I'm going to file an issue about adding an intro for newcomers

[09:02:51.0000] <andreubotella>
they we could point everyone there

[09:02:54.0000] <andreubotella>
*then

[09:03:39.0000] <croraf>
Domenic, you said the concepts in WebIDL are not OO concepts. The first sentence in https://heycam.github.io/webidl/#idl-interfaces says "IDL fragments are used to describe object oriented systems."

[09:03:53.0000] <Domenic>
Then we should fix that sentence.

[09:08:13.0000] <andreubotella>
https://github.com/heycam/webidl/issues/918

[09:10:04.0000] <andreubotella>
btw, can anyone review https://github.com/whatwg/html/pull/5874?

[09:10:36.0000] <andreubotella>
I'd much appreciate the comments of parser folks

[09:10:57.0000] <croraf>
I think I understnad now what you trying to say. In Java the interface only specifies members and methods, it doesnt specify behavior.

[10:13:27.0000] <MikeSmith>
Domenic: thanks for the fixes. The remaining stuff will take me longer than what I have time left for I need to step away again. But can get back to it in the morning my time (~5 hours from now)

[10:13:40.0000] <Domenic>
MikeSmith: I think I've got it all working; running the final build now.

[10:18:04.0000] <TabAtkins>
Importantly, "object oriented systems" is not a synonym for "Java-like"; OO is a far wider and weirder set of concepts than most people who've been taught about OO typically understand.

[10:18:48.0000] <TabAtkins>
CLOS is OO, despite not having anything like a class or methods, just free functions which can have multiple implementations keyed by the types of their arguments.

[11:14:36.0000] <croraf>
TabAtkins, I don't know what CLOS is, but from wikipedia: "The basic building blocks of CLOS are classes and their methods, instances of those classes, and generic functions"

[11:15:33.0000] <croraf>
Although I agree that OO is not only Java-like OO. JS is OO, but radically different from Java's OO.

[11:16:23.0000] <TabAtkins>
CLOS doesn't have methods. If you specialize more than one argument, they call it a "multi-method", but it's literally the exact opposite of what a "method" is in JS/Java/etc, since it's explicitly *not* owned by a single class.

[11:19:05.0000] <croraf>
The important sentence in the WebIDL spec is: "Objects that implement the GraphicalWindow interface will expose these attributes and operations in a manner appropriate to the particular language being used."

[11:19:40.0000] <croraf>
That is more generic: "Objects that implement an interface will expose its attributes and operations in a manner appropriate to the particular language being used."

[11:20:20.0000] <croraf>
And they continue with: "In ECMAScript, the attributes on the IDL interfaces will be exposed as accessor properties and the operations as data properties whose value is a built-in function object on a prototype object for all GraphicalWindow objects; each ECMAScript object that implements GraphicalWindow will have that prototype object in its prototype chain."

[11:20:21.0000] <andreubotella>
notice that it talks about *objects* implementing an interface, not classes

[11:20:24.0000] <andreubotella>
WebIDL's "objects that implement an interface" is equivalent to Java's "objects that are instances of a class"

[11:20:28.0000] <croraf>
andreubotella, yes

[11:20:34.0000] <croraf>
I see.

[11:22:00.0000] <croraf>
Although the analogy is only partially valid. As class in JS also holds the implementation. While the WebIDL interface is just a "signature"

[11:22:55.0000] <croraf>
In pure Ecmascript you cannot just define the signature I guess (maybe in typescript), you have to define an implementation with it.

[11:23:01.0000] <Domenic>
No, it is not just a signature. We have told you this many times.

[11:23:27.0000] <andreubotella>
WebIDL isn't in the business of defining an interface's behavior, that's for the prose in the spec

[11:23:49.0000] <Domenic>
It defines the behavior for argument handling and various other pieces.

[11:23:55.0000] <andreubotella>
although the types come with transforms to/from JS

[11:24:12.0000] <croraf>
By signature I mean the list of attributes and operations. And as per the following the Interface defines just this: "Objects that implement the GraphicalWindow interface will expose these attributes and operations in a manner appropriate to the particular language being used."

[11:26:49.0000] <Webb>
Are there any artifacts supporting the XML syntax for HTML? I'd like to find anything that would help validate instances: Schemas, DTDs, RNG, Schematron, etc? I'd also like to find XML examples.

[11:29:01.0000] <Domenic>
Webb: https://validator.nu/ can validate.

[11:44:25.0000] <Webb>
Is there anything else? Anything normative or machine-readable?

[11:50:34.0000] <croraf>
andreubotella, we also have the term class like: https://fetch.spec.whatwg.org/#headers-class . Is the Headers interface just the IDL card on the top (the interface Headers {...}) or is part of the interface something from the prose?

[11:51:04.0000] <croraf>
The term class hear is meant the JS class I suppose.

[11:51:26.0000] <andreubotella>
it's part of the prose

[11:52:59.0000] <croraf>
andreubotella, is maybe the entire section 5.1 the description of the Headers interface?

[11:53:29.0000] <croraf>
(this section is the one linked above)

[11:53:55.0000] <andreubotella>
yeah

[11:54:16.0000] <croraf>
thanks. I'm clear now.

[13:52:44.0000] <isd>
What is the appropriate venue to talk about webrtc? from poking around I haven't found anything to do with it in the whatwg specs. The standards are IETF and w3c, but they look "done;" no updates on the mailing lists in over a year.

[13:53:57.0000] <Domenic>
isd: maybe their GitHub repositories?

[14:02:18.0000] <isd>
/me looks

[14:24:55.0000] <isd>
Hm. It doesn't look like the webrtc github org is very active/in good condition either. They have some pinned repos with test data & samples, but nothing that looks like a viable forum for discussion, and issues like this one don't give me a lot of confidence: https://github.com/webrtc/samples/issues/1350

[14:35:58.0000] <isd>
Is there a reason whatwg doesn't have anything in the specs about webrtc APIs? It seems odd to have an API that's essential to widely used applications just not be referenced at all.

[14:37:44.0000] <Domenic>
Well, specs are different from applications, and need different things.

[14:38:48.0000] <isd>
I'm not entirely sure I follow.

[14:39:18.0000] <Domenic>
Why would specs reference WebRTC APIs? Just because applications do, doesn't mean specs should.

[14:43:29.0000] <isd>
Perhaps I misunderstand the scope of whatwg: it seems like if applications in the wild are heavily using an API that is not in the standard, then that is an incompleteness in the standard? It seems like a goal is to specify the web platform, and this seems like it ought to be a part of that?

[14:46:04.0000] <Domenic>
The goal is not to specify the whole web platform. Each specification has a specific scope that it covers. There are many specifications, from many different organizations (to name a few: WHATWG, W3C, Ecma, IETF, Khronos, CABF, ...) which come together to form the web platform.

[14:49:19.0000] <isd>
I see.

[15:34:54.0000] <MikeSmith>
Domenic: I see you made all the fixes needed to the HTML patch

[15:34:58.0000] <MikeSmith>
and merged

[15:35:20.0000] <MikeSmith>
thanks much for taking care of that (and the Wattsi fixes that were needed too)

[15:39:43.0000] <MikeSmith>
isd: https://github.com/w3c?q=webrtc

[15:40:01.0000] <MikeSmith>
> 24 results for repositories matching webrtc

[15:40:40.0000] <MikeSmith>
isd: I think the WebRTC working group is quite actively still working on spec updates

[15:41:13.0000] <MikeSmith>
> Updated 16 hours ago

[15:41:16.0000] <MikeSmith>
etc

[15:41:34.0000] <croraf>
I'm checking the consume body https://fetch.spec.whatwg.org/#concept-body-consume-body when used with text(). Step 4 has two things suspicious to me.

[15:42:01.0000] <croraf>
A) it says "with the first argument given", what does that mean?

[15:43:18.0000] <croraf>
B) it says "and object's MIME type" with the link on MIME type saying that objects implementing Body gain MIME type. It is not clear to me how they get MIME type?

[15:47:32.0000] <croraf>
(MDN for example doesnt mention the MIME type property, and I couldn't find it in the response object gotten after fetch)

[15:48:05.0000] <croraf>
https://developer.mozilla.org/en-US/docs/Web/API/Body

[15:48:21.0000] <andreubotella>
"MIME type" there is a (browser-internal) variable

[15:48:41.0000] <andreubotella>
or field, rather

[16:01:06.0000] <croraf>
How would I know that? And the associated body is also an internal body field and not the one exposed by the IDL?

[16:01:21.0000] <croraf>
andreubotella,

[16:04:02.0000] <andreubotella>
interfaces and mixins can have associated fields, and they're usually marked as such, "a Response object has an associated response", "objects implementing the Body mixin have an associated body"

[16:04:27.0000] <andreubotella>
they're understood not to be exposed through the WebIDL API by default, but they can be

[16:16:15.0000] <croraf>
andreubotella, thanks once again. And the last thing if you can address my question A) above

[16:17:18.0000] <andreubotella>
that also wasn't obvious to me at first sight

[16:17:41.0000] <andreubotella>
`upon fulfillment` there takes some caller-specific code -- a closure, if you will

[16:17:58.0000] <andreubotella>
that closure should call package data with the first argument passed to it

[16:19:16.0000] <croraf>
OK, makes sense. Ty

[16:19:50.0000] <croraf>
Perhaps this "given" might be worded better.

[16:20:03.0000] <andreubotella>
yeah

[16:20:48.0000] <croraf>
The bullet 5. also has some strange wording.

[16:21:01.0000] <croraf>
"Return the result of upon fulfillment of promise given steps."

[16:21:13.0000] <isd>
MikeSmith: aha, thanks

[16:21:28.0000] <andreubotella>
croraf: see https://github.com/whatwg/infra/issues/320 for that

[16:21:35.0000] <croraf>
While WebIDL says: "To perform some steps upon fulfillment of a Promise<T> promise given some steps steps taking a value of type T, perform the following steps:"

[16:25:05.0000] <croraf>
andreubotella, my small objection is that you cannot "have the result of upon fulfillment" but you can "perform some steps upon fulfillment". Perhaps the outcome is equivalent and obvious to the experienced reader.

[16:27:31.0000] <andreubotella>
yeah, well, fetch here is using "upon fulfillment" as the name of the algorithm when it maybe should use "return the result of performing `steps` upon fulfillment"

[16:27:54.0000] <andreubotella>
feel free to open a pull request if that bothers you

[16:34:04.0000] <croraf>
https://heycam.github.io/webidl/#dfn-perform-steps-once-promise-is-settled this is the sentence that confused me the most

[16:34:44.0000] <croraf>
Like which "2 sets of steps... promise that is fullfilled, rejected, or BOTH". But I understand it now.

[16:35:12.0000] <andreubotella>
it's basically an equivalent of Promise.prototype.then, which can take one or two functions

[16:35:16.0000] <croraf>
They meant one set of steps when promise is fulfilled, one set when rejected, or provide 2 sets of step for both cases.

[16:39:11.0000] <croraf>
andreubotella, what if reading all bytes rejects its promise https://fetch.spec.whatwg.org/#concept-body-consume-body

[16:39:17.0000] <croraf>
This case seems not to be covered.

[16:40:30.0000] <croraf>
The promise in bullet 5 is defined in bullet 3. If it fails the upon fulfillment does nothing. And what is returned then?

[16:44:15.0000] <andreubotella>
I'm not too familiar with the promise operations in WebIDL, but from a first glance, it looks like the rejection would be ignored and the returned promise would succeed with undefined

[16:47:56.0000] <croraf>
thanks. It boils down to the return of upon fulfillment when the promise is rejected.

[16:49:01.0000] <croraf>
That is this: Return ! PerformPromiseThen(promise.[[Promise]], onFulfilled, onRejected, newCapability)

[16:49:07.0000] <croraf>
when rejected happens

[16:49:56.0000] <croraf>
(last bullet in React to promise in WebIDL)

[16:51:17.0000] <croraf>
PerformPromiseThen kind of leads me to the broken link in the ECMAScript spec.

[16:52:02.0000] <croraf>
(oh actually it takes some time to jump, so something crashes kind of)

[16:53:42.0000] <croraf>
Yes, I think the .text() in this specific case just returns a promise that gets rejected when the error in reading happens.

[16:54:07.0000] <andreubotella>
I'm not sure it does, since the rejection steps return undefined

[16:54:27.0000] <andreubotella>
that strikes me as a WebIDL bug, but I'll have to look deeper into it

[16:57:47.0000] <croraf>
Aha, I see. It says to return undefined as onRejectedSteps.

[16:58:01.0000] <croraf>
And then this "undefined" will be called.


2020-09-16
[17:02:30.0000] <croraf>
I mean, I was reading today that in ECMAScript if the onrejected is not provided there is a default happening.

[17:03:15.0000] <croraf>
Probably there is a default behavior happening in WebIDL also.

[17:04:57.0000] <croraf>
I mean actually this "PerformPromiseThen" in the last bullet of "react to a promise" https://heycam.github.io/webidl/#dfn-perform-steps-once-promise-is-settled is actually an Operation from ECMAScript

[17:06:12.0000] <croraf>
So it is the same as "promise.then(resolveFunction, undefined)" when promise gets rejected, that means the default behavior is invoket.

[17:07:49.0000] <andreubotella>
no, the subitems in step 3 are a spec-level algorithm that gets converted into a ES-level function on step 4, and that is passed to PerformPromiseThen

[17:09:49.0000] <croraf>
OK, this is invoked https://tc39.es/ecma262/#sec-createbuiltinfunction with (undefined, <<>>)

[17:10:58.0000] <andreubotella>
whenever you see "steps" in a web spec, you can probably substitute that with function/closure

[17:11:10.0000] <andreubotella>
onRejectedSteps is the algorithm in the substeps, not its return value

[17:12:24.0000] <croraf>
Aha, it is a list of steps to be performed later

[17:12:56.0000] <croraf>
A callback.

[17:13:03.0000] <andreubotella>
right

[17:13:31.0000] <croraf>
This is so spaghetti, my head hurts :D

[17:14:35.0000] <andreubotella>
interacting with ES internals sometimes gets like that, and especially for promises :)

[17:16:26.0000] <croraf>
So what happens then. The promise gets rejected with let's say TypeError (during byte reading).

[17:25:48.0000] <croraf>
const result = response.text() = readAllBytesPromise.then(resolve, onRejected)

[17:26:36.0000] <croraf>
The promise gets rejected and onRejected is called with TypeError argument. The result is another promise which gets resolved with the return of onRejected function.

[17:29:48.0000] <croraf>
The function 3. in https://heycam.github.io/webidl/#dfn-perform-steps-once-promise-is-settled returns undefined.

[17:29:48.0000] <croraf>
So the result of the entire operation is a promise that gets resolved with undefined.

[17:30:40.0000] <croraf>
This is what you said 45 min ago.

[17:30:53.0000] <croraf>
OK, go to sleep now. Bye.

[01:24:51.0000] <noamr>
Good morning annevk! https://github.com/whatwg/html/pull/5574/files has been updated with your previously requested changes, for when you get a chance

[01:39:46.0000] <annevk>
noamr: I'll have another look in a bit

[01:40:04.0000] <noamr>
thanks!

[01:40:14.0000] <annevk>
MikeSmith: Domenic: now that you have made these major changes to Wattsi, I'm wondering if we can change <span> to <a> and data-x to lt...

[01:40:37.0000] <andreubotella>
yes please

[01:40:39.0000] <annevk>
MikeSmith: Domenic: making the source even more similar to Bikeshed would be quite nice

[02:57:52.0000] <MikeSmith>
annevk: yea we can do that

[02:57:58.0000] <MikeSmith>
all

[02:58:34.0000] <MikeSmith>
could have done it all in those same HTML/Wattsi commits, but seemed better to get those landed first

[02:59:03.0000] <annevk>
baby steps

[03:00:02.0000] <MikeSmith>
yeah, especially with a patch as big as that spec patch was — one problem was that any time almost any other commit got merged to master, I needed to rebase that whole patch

[03:00:22.0000] <MikeSmith>
..which was a bit troublesome and also error-prone

[03:01:09.0000] <MikeSmith>
I guess <span> to <a> and data-x to lt will be big patches too

[03:03:20.0000] <annevk>
MikeSmith: yeah, I don't know how feasible it is to write a script that does the transformation, but that might be worth doing given the rebasing

[03:20:35.0000] <croraf>
andreubotella, have you maybe verified my/our conclusion? Is it a bug in the fetch and/or WebIDL specs?

[03:22:08.0000] <andreubotella>
croraf: since the note to that algorithm says it's equivalent to Promise.prototype.then, and it seems to be used elsewhere as if it's equivalent, I'd say that's a bug in WebIDL

[03:22:19.0000] <andreubotella>
I'll look at it again later and file the issue

[03:25:50.0000] <croraf>
andreubotella, cool

[05:32:42.0000] <noamr>
thanks for the review annevk, already applied/commented/resubmitted :)

[06:27:40.0000] <Domenic>
annevk: MikeSmith: I'm unsure about data-x -> lt since it won't work like Bikeshed does since Bikeshed contains cross-linking.

[06:28:00.0000] <Domenic>
Also we wouldn't want to turn what are currently data-x into visible-to-the-external-world data-lt=""

[06:29:04.0000] <Domenic>
s/Bikeshed contains cross-linking/Bikeshed does cross-spec linking/

[07:45:54.0000] <Domenic>
annevk: thoughts on https://github.com/heycam/webidl/pull/883#issuecomment-692972245 ?

[07:51:58.0000] <annevk>
Domenic: that looks about right, though I haven't thought about this in the context of the cross-origin isolated permission/capability

[07:52:59.0000] <annevk>
Domenic: good point about lt; I guess we should do <a> first and then figure out whether we want to stop using data-x or not

[14:26:29.0000] <Domenic>
Anyone know a better page than https://developer.mozilla.org/en-US/docs/Web/API/Document/domain for explaining document.domain and its evilness? The context is writing a web-developer-facing article about origin isolation and how using it will disable document.domain.


2020-09-17
[00:27:21.0000] <zcorpan>
Domenic: https://twitter.com/zcorpan/status/1202958734949060608

[04:17:29.0000] <yhirano>
annevk: hi

[04:22:28.0000] <annevk>
yhirano: heya

[04:23:20.0000] <yhirano>
annevk: do we have a wpt for document.domain mutation and cross-origin isolated?

[04:23:25.0000] <yhirano>
annevk: https://github.com/whatwg/html/pull/4734

[04:24:00.0000] <annevk>
yhirano: I don't recall; Tim Tung had that on his list, but maybe he didn't get to it

[04:24:17.0000] <annevk>
Tom Tung*

[04:24:54.0000] <yhirano>
annevk: ok then i'm going to add one.

[04:25:30.0000] <annevk>
yhirano: I think Domenic might have written some for Origin Isolation too

[04:25:41.0000] <annevk>
maybe that can be reused

[04:30:36.0000] <yhirano>
annevk: thanks

[05:47:21.0000] <andreubotella>
hm, looks like bikeshed builds are failing because TabAtkins added support for dark mode and v.Nu doesn't like the "color-scheme" CSS property

[05:50:10.0000] <annevk>
andreubotella: leave a comment on https://github.com/whatwg/meta/issues/188?

[05:50:51.0000] <annevk>
I guess we should figure out where this remaining CSS is added and try to get Bikeshed to not do that for WHATWG

[05:58:40.0000] <andreubotella>
annevk: that sounds like something that should be fixed in v.Nu, though

[06:41:05.0000] <Domenic>
Bikeshed really should not be injecting CSS into WHATWG specs...

[07:04:08.0000] <TabAtkins>
I filed an issue for y'all

[09:34:31.0000] <andreubotella>
croraf: https://github.com/heycam/webidl/issues/921

[09:34:54.0000] <croraf>
/me likes

[09:56:45.0000] <annevk>
JakeA: are there no tests for openWindow()?

[14:19:29.0000] <croraf>
Hi. When I encounter something like this: https://heycam.github.io/webidl/#a-promise-rejected-with in WebIDL should I consider this as a "macro" or as a "function"?

[14:20:05.0000] <croraf>
The difference is, do I just replace the caller with this code, or do I actually call this code?

[14:21:03.0000] <Domenic>
Function

[14:21:11.0000] <Domenic>
Macros are very few and called out explicitly as such

[14:21:30.0000] <Domenic>
Example of a macro: https://html.spec.whatwg.org/#spin-the-event-loop

[14:21:43.0000] <croraf>
Another example is the "1. React to promise" here https://heycam.github.io/webidl/#upon-fulfillment Do I call react, or I just imagine this bullet is replaced with the list bullets.

[14:21:47.0000] <croraf>
Domenic, ok, thx

[14:24:08.0000] <croraf>
This basically means, (and I think andreubotella noted that ) that there is another bug in here, because "upon fulfillment" https://heycam.github.io/webidl/#upon-fulfillment returns nothing, while it should return a promise generally.

[14:24:26.0000] <croraf>
Same with "upon rejection"

[14:24:51.0000] <andreubotella>
I looked into the different specs that used react, upon fulfillment and upon rejection

[14:25:16.0000] <andreubotella>
most don't use the returned promise, but some do

[14:26:03.0000] <andreubotella>
so either each of those callers have to be changed, or the WebIDL definition

[14:26:09.0000] <andreubotella>
it makes more sense to do the latter

[14:27:42.0000] <croraf>
What do you mean by changing the callers? The caller in fetch requires the returned promise.

[14:28:14.0000] <croraf>
Only if you meant that it should call "react" directly, passing the steps?

[14:29:04.0000] <croraf>
andreubotella, but this not make much sense to me, so only the latter option is possible, I think

[14:29:36.0000] <Domenic>
The intention at the time we wrote the Web IDL algorithms was to change the callers; upon fulfillment should be used when you have no plans to use the returned promise, and react should be used if you do want to use the returned promise.

[14:29:37.0000] <andreubotella>
it's not the only option, but sure, I mispoke there

[14:29:55.0000] <Domenic>
Maybe in the meantime a bunch of specs have started assuming "upon fulfillment" returns a promise, so we should just have it do so.

[14:30:27.0000] <andreubotella>
I'll check again, but I believe there were just a few cases

[14:31:13.0000] <andreubotella>
Domenic: could you review https://github.com/heycam/webidl/pull/922 and point that out?

[14:31:30.0000] <Domenic>
andreubotella: on my list for tomorrow morning :)

[14:31:31.0000] <croraf>
To think again, I actually dont see the reason of having "upon fulfillment" and "upon rejection" at all.

[14:32:11.0000] <croraf>
They are even more erroneous. Check this, what I found with andreubotella :

[14:34:09.0000] <croraf>
(let me think a bit more actually :) )

[14:35:48.0000] <andreubotella>
croraf: most of the things we talked about weren't bugs per se, they were either misunderstandings or editorial nitpicks

[14:36:10.0000] <croraf>
Actually I'm again not clear about this.

[14:37:19.0000] <croraf>
It says that "react accepts one or two sets of steps". But below it says:

[14:37:30.0000] <croraf>
React to promise:

[14:37:38.0000] <croraf>
 - If promise was fulfilled with value v, then:

[14:37:42.0000] <croraf>
           1. Perform steps with v.

[14:38:19.0000] <andreubotella>
I might not have made that clear, but "if promise was fulfilled with value v, then" isn't really part of the algorithm

[14:38:41.0000] <andreubotella>
it's a bit of an odd way to specify a callback parameter

[14:42:18.0000] <croraf>
If "React to promise" is similar to promise.then() so when promise is fulfilled with value "v" I guess "onFulfilled" is called with "v". And here it says that the steps are performed with "v".

[14:42:41.0000] <croraf>
Something must be wrong here.

[14:44:28.0000] <andreubotella>
haven't we already gone through that?

[14:45:06.0000] <croraf>
I guess that here it should only say "upon fulfillment" =  "React to promise with *steps* provided as steps to do when fulfilled"

[14:46:05.0000] <croraf>
And if this is true the "upon fulfillment" seems completely unnecessary!

[14:47:06.0000] <croraf>
( we have andreubotella )


2020-09-18
[18:35:03.0000] <MikeSmith>
Domenic: the updates you made to https://developer.mozilla.org/en-US/docs/Web/API/Document/domain look great

[23:31:57.0000] <MikeSmith>
annevk: I realize now some links were broken by the e-mail ↠ email change I made

[23:33:43.0000] <MikeSmith>
example: was https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email) but now https://html.spec.whatwg.org/multipage/#email-state-(type=email)

[23:34:23.0000] <MikeSmith>
I think it would be good if I fixed at least some of those

[23:35:12.0000] <MikeSmith>
...by adding back some anchors with the old fragment IDs

[23:35:59.0000] <MikeSmith>
I discovered the #e-mail-state-(type=email) one due to MDN having had a link to that fragment

[23:36:08.0000] <MikeSmith>
...and I already fixed the MDN link

[23:36:40.0000] <MikeSmith>
but of course there are likely links to that anchor in quite a few other places

[02:13:55.0000] <annevk>
MikeSmith: oh, maybe we should revert the MDN fix and just only keep the old ID working?

[02:30:50.0000] <anurag>
Hi, apologies if this is not the correct medium for this. I was interested in understanding HTMl standard and started at "Loading web pages". There I found an example stating that the following code snippet:

[02:30:50.0000] <anurag>
```

[02:30:50.0000] <anurag>
const popup3 = window.open();

[02:30:50.0000] <anurag>
popup3.close();

[02:30:50.0000] <anurag>
```

[02:32:46.0000] <anurag>
I am sorry for half a message. I am trying to understand how to send a message here.

[03:17:03.0000] <JakeA>
annevk: I'll ask about the openWindow thing

[03:17:37.0000] <annevk>
thanks, it seems we have some internal test that could potentially be converted...

[03:17:47.0000] <annevk>
JakeA: also, where there security issues related to openWindow?

[03:18:15.0000] <JakeA>
annevk: not that I'm aware of

[03:18:27.0000] <JakeA>
We might also have tests to upstream. I'll find out.

[03:18:46.0000] <JakeA>
I mean, it'd be surprising if we didn't

[03:55:53.0000] <croraf>
andreubotella, and others

[03:55:53.0000] <croraf>
https://github.com/heycam/webidl/issues/923

[04:15:21.0000] <JakeA>
annevk: we don't have good test coverage for openWindow, just https://source.chromium.org/chromium/chromium/src/+/master:content/browser/service_worker/service_worker_clients_api_browsertest.cc;l=134;drc=919ce657e4e37dfa13758f1eb8fe0e9ef7ab1b20;bpv=0;bpt=1, so if you have stuff that can upstreamed, that'd be great

[06:25:15.0000] <ondras>
a question regarding use-CORS-preflight flag. say I have a "POST /a" request that results in a preflight, succeeds and results in a http/303 redirection. the preflight flag is set, so the following "GET /b" still triggers the OPTIONS preflight. is this intentional?

[09:00:04.0000] <annevk>
ondras: we could maybe consider changing that, but doing that check again now the method changed and maybe some headers are dropped feels a bit dangerous

[09:30:13.0000] <ondras>
annevk: I see. so not really intentional, there does not seem to be a particular reason for that, just an implementation consequence that is a bit inconventient now

[09:30:26.0000] <ondras>
*inconvenient

[09:37:10.0000] <annevk>
ondras: yeah, it also predated explicitly requiring changing the method and such

[09:45:20.0000] <ondras>
annevk: okay, thanks


2020-09-21
[04:57:57.0000] <MikeSmith>
annevk: about the color-scheme thing, I will make a workaround for it right now

[04:58:50.0000] <MikeSmith>
but it’s unclear to me whether color-scheme is actually supported at all in any engine other than Blink

[04:59:10.0000] <MikeSmith>
and color-scheme is not documented at all in MDN, and there is zero data about it in BCD

[04:59:32.0000] <annevk>
MikeSmith: I'm not advocating for validator support btw, it seems fine to block on all that becoming more clear

[05:00:04.0000] <MikeSmith>
yeah I will just special-case it for now until we can otherwise get something better figured out

[05:01:12.0000] <andreubotella>
or we could switch off the bikeshed style-colors boilerplate

[05:01:40.0000] <MikeSmith>
andreubotella: that might be a better solution, if that is doable

[05:01:57.0000] <MikeSmith>
I don’t know which would be quicker to propogate

[05:16:24.0000] <MikeSmith>
annevk: I think you may have already pointed this out in another issue comment, but rightly I would hope Bikeshed would not be embedding any CSS styles into WHATWG specs at all

[05:16:50.0000] <MikeSmith>
any styles should be in external stylesheets

[05:17:32.0000] <MikeSmith>
or at least we should have an option for not having them embedded in the HTML source in style elements

[05:17:57.0000] <annevk>
MikeSmith: it already does (including JavaScript) for dfn

[05:18:04.0000] <annevk>
MikeSmith: I guess this new thing adds more

[05:18:13.0000] <andreubotella>
I'm not very familiar with the bikeshed code, but from a quick look it seems it wouldn't be hard to add a `Boilerplate: styles no` option

[05:18:15.0000] <annevk>
MikeSmith: it even seems to emit style attributes

[05:18:29.0000] <MikeSmith>
oh style attributes too

[05:19:06.0000] <MikeSmith>
well the HTML spec requires the content of style elements and attributes to be conforming

[05:19:31.0000] <MikeSmith>
but the HTML spec does not require content of external stylesheets to be conforming

[05:22:22.0000] <andreubotella>
but an unknown property wouldn't make a stylesheet non-conforming

[05:22:49.0000] <MikeSmith>
in fact it does

[05:23:20.0000] <MikeSmith>
an unknown property is indistinguisable from a misspelled property

[05:23:58.0000] <MikeSmith>
so asserting that unknown properties should be ignored is the same as saying that misspelled properties should be ignored

[05:24:35.0000] <annevk>
One problem with moving the dfn style sheets is that HTML has its own dfn styles, as per https://github.com/whatwg/whatwg.org/commit/3374e69f013e5939abc5f3fffaae50bb6eaf0bd3

[05:24:45.0000] <andreubotella>
HTML links to the css-syntax definition of conformant style sheet, and it talks about the syntax and the individual grammars of each feature

[05:24:51.0000] <annevk>
And I don't know if what Bikeshed does is completely unique

[05:24:52.0000] <MikeSmith>
I would hope that the value to developers of reporting font-colro as an error is clear

[05:25:03.0000] <andreubotella>
yeah, for reporting, sure

[05:25:12.0000] <annevk>
If what Bikeshed does is completely unique, it's probably easy-ish to just put it in standard.css and HTML will just ignore it

[05:25:14.0000] <MikeSmith>
annevk: yeah I know we have an opne issue about that

[05:25:18.0000] <annevk>
(until we solve HTML)

[05:25:47.0000] <annevk>
I'm not sure if this color-space stuff does anything beyond modifying the dfn stuff

[05:29:33.0000] <annevk>
Looking at the output this seems to be a lot of additional styles unrelated to dfn

[05:30:58.0000] <andreubotella>
We can probably switch off style-colors and style-darkmode now, and then see about moving the rest of styles

[05:37:06.0000] <annevk>
So "Boilerplate: style-colors off" seems to work, but "Boilerplate: style-darkmode off" does nothing?

[05:37:35.0000] <annevk>
andreubotella: yeah that seems good, but I'm not getting it to work (https://tabatkins.github.io/bikeshed/ also doesn't document all of this)

[06:00:00.0000] <andreubotella>
annevk, TabAtkins: that sounds like a bug

[06:53:42.0000] <MikeSmith>
annevk: https://github.com/whatwg/encoding/pull/230 is all green

[06:54:30.0000] <MikeSmith>
re-run any other pending CI builds for other repos/branches, and they should all turn green too

[06:55:53.0000] <annevk>
MikeSmith: thanks, though hopefully we can sort out the other thing soon too, since I realize I now approved a somewhat-large increase in file size too

[07:29:07.0000] <andreubotella>
annevk: https://github.com/tabatkins/bikeshed/blob/master/bikeshed/boilerplate.py#L236

[07:29:26.0000] <andreubotella>
it looks like style-darkmode is special-cased because it has to be output after the rest of style blocks

[07:29:47.0000] <TabAtkins>
Yeah I think I messed that up, apologies. Will fix in a bit, making breakfast now

[07:29:48.0000] <andreubotella>
and it doesn't seem to be checking the boilerplate maetadata

[07:29:54.0000] <andreubotella>
ok

[07:57:22.0000] <MikeSmith>
annevk: increatst in file size?

[08:44:52.0000] <TabAtkins>
All right, fix pushed for `Boilerplate: darkmode no` to work again

[08:50:32.0000] <Domenic>
annevk: is request's current URL = response URL for all HTTP(S) fetches?

[09:00:28.0000] <annevk>
Domenic: can a HTTP(S) fetch involve a service worker?

[09:00:59.0000] <Domenic>
annevk: yes, I guess so.

[09:01:51.0000] <Domenic>
annevk: the context here is https://github.com/WICG/portals/pull/247, in particular whether https://github.com/WICG/portals/pull/247/commits/bde960589245799aa4fa18d2d5e38d052bd9efe8 is the right change

[09:02:21.0000] <annevk>
Domenic: I think in that case there can be a difference as the response's URL list would be non-empty

[09:02:41.0000] <annevk>
Domenic: though note that navigation deals with this differently from subresources

[09:02:53.0000] <Domenic>
Yeah this is navigation, hmm.

[09:03:04.0000] <Domenic>
I've been staring at Fetch/navigation but not staring at service workers

[09:04:38.0000] <annevk>
Domenic: for navigation we use the request URL for authority but we also have a same origin limitation on service workers (or some such)

[09:05:17.0000] <Domenic>
That makes sense. Indeed, Jeremy noticed that all of navigation was using request URL so urged me to switch

[09:05:50.0000] <Domenic>
It seems like the service worker won't be able to change what we care about here, which is the HTTP(S)-scheme-ness of the URL in question.


2020-09-22
[02:50:57.0000] <jgraham>
I have a spec algorithm that takes a javascript object of arbitary type and runs some type-specific steps. How is one supposed to switch-on-type in a spec these days?

[02:51:25.0000] <annevk>
jgraham: is it converted to an IDL object?

[02:52:31.0000] <jgraham>
No, although maybe it can be? It can also be a primitive type if that makes a difference

[02:52:47.0000] <annevk>
jgraham: has it passed through IDL is the question I guess

[02:53:07.0000] <annevk>
but generally "if _x_ is a Foo"

[02:53:25.0000] <annevk>
or switching on _x_: <dl><dt>Foo<dd>...

[02:53:52.0000] <jgraham>
It hasn't passed through IDL; the use case is WebDriver where we want to convert an arbitary object from script into a wire representation

[02:55:21.0000] <jgraham>
But if I"m allowed to just act as if the type of x is a well defined concept without caring about the mechanics of how js encodes the type, what I have isn't so wrong

[02:56:07.0000] <annevk>
jgraham: you can use https://heycam.github.io/webidl/#es-platform-objects

[02:56:42.0000] <annevk>
jgraham: and for serialization you probably want some alignment with HTML's serialization algorithms for ES values

[02:58:46.0000] <jgraham>
Yeah, maybe

[02:59:21.0000] <jgraham>
It's definitely going to be different to that because different requirements, but it might make sense to use that to provide a value representation for more types

[03:00:32.0000] <annevk>
jgraham: HTML's serialization algorithm does do all the formal stuff correctly (or so we like to think)

[03:00:56.0000] <jgraham>
(the "different requirements" are basically that we pass back a handle that acts a weakref to the object, which doesn't make sense for the HTML case)

[03:02:26.0000] <jgraham>
(but we also provide a value for types where it makes sense, and only a value for primitives)

[03:04:50.0000] <jgraham>
(and also because JSON, we can't represent some things that structured serialize can)

[03:04:57.0000] <jgraham>
Anyway, that's useful thanks


2020-09-23
[02:10:28.0000] <annevk>
Does Boilerplate: in Bikeshed support both "omit X" and "X off"?

[02:14:11.0000] <annevk>
Ah, that's the legacy syntax

[02:14:41.0000] <annevk>
Reading the code always helps

[16:52:04.0000] <Domenic>
https://github.com/whatwg/html/issues/5939 is fun


2020-09-24
[18:13:31.0000] <zzeuss>
salem

[18:18:35.0000] <TSMax_1424841634>
hi

[00:58:19.0000] <annevk>
MikeSmith: if you have a moment I'd appreciate your take on https://github.com/tabatkins/bikeshed/pull/1767#issuecomment-697440570

[00:58:37.0000] <annevk>
MikeSmith: if you don't think that's a problem (or can be fixed separately) I'll rebase the tests and merge that PR

[01:57:44.0000] <MikeSmith>
annevk: looking now

[01:59:19.0000] <MikeSmith>
annevk: you mean the problem with the annotations in the review draft?

[01:59:48.0000] <MikeSmith>
that actually wasn’t broken before

[01:59:53.0000] <MikeSmith>
not sure what broke it

[01:59:55.0000] <annevk>
MikeSmith: yeah, Domenic's comments

[01:59:58.0000] <MikeSmith>
OK

[02:00:36.0000] <annevk>
MikeSmith: and then the smaller question is if there's anything actionable there for follow-up work

[02:00:38.0000] <annevk>
MikeSmith: the big question is whether my change would interfere with that

[02:01:09.0000] <MikeSmith>
I think we should go ahead and land your change regardless

[02:01:30.0000] <MikeSmith>
any issues with the review drafts can be fixed separately if needed

[02:02:14.0000] <MikeSmith>
I think we should prioritize making just the normal spec itself work as we want

[02:03:42.0000] <MikeSmith>
it doesn’t seem like any problems with the review-draft formatting should be a high priority at all, given the tiny set of people who we expect to actually use them

[02:04:04.0000] <MikeSmith>
but anyway, I can still make time to fix the review-draft problems

[02:04:28.0000] <MikeSmith>
I just don’t think we should block anything else on them

[02:06:10.0000] <MikeSmith>
nor IMHO should we stop and take extra time to take the changes you already have working and try to integrate them into the review drafts

[02:06:43.0000] <MikeSmith>
oh I misread a bit what you wrote

[02:07:20.0000] <MikeSmith>
I read “integrate” where you wrote “interfere”

[02:07:34.0000] <annevk>
It seems it came out in the wrong order, not sure how IRCCloud managed that

[02:08:16.0000] <MikeSmith>
well even if you changes do interfere with the follow-up work, we can just adjust the follow-up work as needed

[05:07:13.0000] <zcorpan>
Wondering why I have so little free disk space, I notice that I have servo, mozilla-central, *and* webkit lying around

[05:19:33.0000] <jgraham>
Not saying it's definitely all your servo target directory, but also, did you heck your servo target directory? :)

[05:19:37.0000] <jgraham>
*check

[05:26:32.0000] <andreubotella>
annevk, TabAtkins: https://github.com/tabatkins/bikeshed/blob/master/bikeshed/dfnpanels.py#L160

[05:26:46.0000] <andreubotella>
the dfn-panels style depends on the --text variable defined in style-colors

[05:28:05.0000] <annevk>
andreubotella: does this actively break things? I might have time later today to merge dfn styles into standard.css

[05:28:30.0000] <annevk>
I guess the main question is whether that would break anything in HTML

[05:29:40.0000] <andreubotella>
as far as I can tell, the black default doesn't change anything

[05:30:11.0000] <andreubotella>
but it's something I noticed we'd missed

[05:31:45.0000] <zcorpan>
jgraham: I've removed the servo directory already. I don't know where the servo target directory is or whether I have one

[05:37:59.0000] <jgraham>
zcorpan: It's under ervo iirc so probably already gone

[08:29:32.0000] <annevk>
Domenic: euh, is https://github.com/whatwg/html/issues/5940 a problem with how site is defined?

[08:30:15.0000] <annevk>
Domenic: at least it seems we might put the same IP address but different port into different agents?

[08:30:27.0000] <Domenic>
Hmm

[08:30:49.0000] <Domenic>
Yeah that does seem likely

[08:31:01.0000] <annevk>
wow

[08:31:47.0000] <Domenic>
This is pretty busted then....

[08:32:08.0000] <annevk>
I wonder if it's as simple as replacing

[08:32:10.0000] <annevk>
> If origin's host's registrable domain is null, then return origin.

[08:32:11.0000] <annevk>
with

[08:32:30.0000] <annevk>
If origin's host's registrable domain is null, then return (origin's scheme, origin's host).

[08:32:49.0000] <Domenic>
Hmm it very well might be

[08:33:04.0000] <MassDebates>
there are some css features that I'd like to experiment with, but no browser supports them on loadout!

[08:33:10.0000] <Domenic>
Well that changes the problem a lot

[08:33:14.0000] <MassDebates>
How does someone like me experiment with these new features?

[08:33:28.0000] <Domenic>
From a web compat issue to a spec-is-broken issue.

[08:35:14.0000] <annevk>
jochen__ would have preferred if we broke ports here, but I'm not sure we can

[08:35:33.0000] <Domenic>
Right, I mean, it'd get back to my idea of adding use counters and seeing how it goes

[08:35:46.0000] <Domenic>
Are there other uses of site where your suggested modification might cause problems?

[08:37:16.0000] <annevk>
I don't think so and it would still fit scheme-and-registrable-domain

[08:37:28.0000] <annevk>
It just means that a site is never a tuple origin

[08:37:45.0000] <annevk>
which simplifies a couple of things

[09:00:18.0000] <Domenic>
annevk: does this impact the definition of (schemelessly) same-site? From my first reading that seems OK...

[09:01:44.0000] <Domenic>
Why didn't we define same-site as "obtain a site" then compare piecewise? :-/

[11:02:56.0000] <andreubotella>
so I've been looking through the resources.whatwg.org stylesheets... and I'm a bit confused by review drafts

[11:03:11.0000] <andreubotella>
you'd think a version of the spec made for patent review wouldn't be treated as an unstyled build artifact

[11:12:58.0000] <annevk>
Domenic: not sure that would have caught this and same site was defined first, might still be worth doing though

[11:13:17.0000] <Domenic>
andreubotella: why would you think that?

[11:13:53.0000] <andreubotella>
it seems like patent review would be a job for humans

[11:14:52.0000] <Domenic>
Yeah, but the humans don't need pretty text for it. Just some text should do the trick.

[11:16:11.0000] <annevk>
(I haven't heard complaints from relevant humans)

[11:16:36.0000] <andreubotella>
ok, it just struck me as odd

[12:14:15.0000] <domfarolino>
annevk:

[12:14:18.0000] <domfarolino>
Whoops

[12:14:27.0000] <domfarolino>
annevk: Does FF have a tracking bug to change the default referrer policy?

[12:20:59.0000] <domfarolino>
nvm found https://bugzilla.mozilla.org/show_bug.cgi?id=1589074


2020-09-25
[00:38:14.0000] <annevk>
Very cool that we're almost rid of Travis CI

[03:54:24.0000] <MikeSmith>
I’ve spent the biggest single chunk of my time today trying to read up a bit on navigator.sendBeacon() and the current state of implementations around it, and then also the related issue of the visibilitychange not firing as expected in Safari when document.visibilityState transitions to "hidden"

[03:56:21.0000] <MikeSmith>
ended up adding warnings about the visibilitychange issue to all the related MDN articles, and raised https://github.com/mdn/browser-compat-data/pull/6763 to make corresponding updates to BCD for it

[03:57:29.0000] <MikeSmith>
...and then also raised https://github.com/mdn/sprints/issues/3722 about getting the MDN sendBeacon() article updated with an example that’s accurate

[03:59:46.0000] <MikeSmith>
and in between read through four related WebKit bugzilla issue (and adding comments and Related Bug entries that caused god knows how many other people to get spammed with notifications)

[04:01:08.0000] <MikeSmith>
and it all began earlier in the day from just deciding to casually glance at https://volument.com/blog/sendbeacon-is-broken

[04:01:39.0000] <MikeSmith>
anyway, I hope it leads to a resolution that helps cause a little less pain and frustration for web developers

[04:02:03.0000] <MikeSmith>
I’ll spend the rest of my time today praying..

[05:10:11.0000] <MassDebates>
I asked a question here yesterday, but I'm not sure if I didn't receive a response because it was errant or in the wrong place, or simply because I should wait longer.

[05:10:32.0000] <MassDebates>
How would I experiment with the css features not available on any browser? Is it possible for me to do?

[05:39:44.0000] <MikeSmith>
MassDebates: I don’t personally know how to answer that question, and I suspect others here don’t either — and I'd guess that’s why nobody responded.

[05:40:00.0000] <MassDebates>
Ah, okay, so errant question then

[05:40:04.0000] <MassDebates>
Thanks for letting me know.

[05:40:10.0000] <MikeSmith>
well the only response I can think of is to ask you questions back

[05:40:24.0000] <MikeSmith>
like, what do you mean by “experiment”?

[05:40:37.0000] <MassDebates>
I wanted to try writing some css for it and implement it and see how it looks.

[05:40:45.0000] <MassDebates>
for example this property:

[05:40:59.0000] <MassDebates>
https://developer.mozilla.org/en-US/docs/Web/CSS/text-overflow

[05:41:06.0000] <MikeSmith>
ok

[05:41:17.0000] <MassDebates>
I've made a bunch of small things that have recreated fade in many ways, and I was hoping I could try the real deal.

[05:41:24.0000] <MikeSmith>
by “implement”, you mean, write browser code for it?

[05:41:36.0000] <MikeSmith>
like, a browser patch for Chrome?

[05:41:49.0000] <MassDebates>
I was hoping I wouldn't have to

[05:41:57.0000] <MikeSmith>
OK

[05:42:08.0000] <MassDebates>
I was wondering if there was an actively worked on version that I could subscribe to the version of that would support some experimental features.

[05:42:26.0000] <MikeSmith>
I see

[05:42:39.0000] <MassDebates>
For example I signed up for a beta patch with Brave and I tried out some of their new features before they got rolled out to everyone.

[05:42:50.0000] <MassDebates>
I'm not sure if that exists for the people writing the browser patches themselves.

[05:42:55.0000] <MikeSmith>
I guess you know that browsers have some options that you can enable to turn on experimental features?

[05:43:12.0000] <MassDebates>
Yes, which is part of the reason why I came here

[05:43:46.0000] <MassDebates>
For example I'm familiar with https://www.google.com/intl/en/chrome/canary/

[05:43:55.0000] <MikeSmith>
OK, I don’t know if there is such an option for enabling experimental support for text-overflow; I will look now

[05:44:16.0000] <MikeSmith>
wait

[05:44:33.0000] <MikeSmith>
text-overflow is already supported, isn’t it?

[05:44:37.0000] <MassDebates>
yes

[05:44:45.0000] <MassDebates>
I'm looking at fade

[05:45:00.0000] <MassDebates>
The fade keyword clips the overflowing inline content and applies a fade-out effect near the edge of the line box with complete transparency at the edge.

[05:45:21.0000] <MikeSmith>
ah OK

[05:46:43.0000] <MikeSmith>
so sometimes the Browser Compatibility tables in MDN will have specific information about values that have experimental support

[05:47:18.0000] <MikeSmith>
and the data for that comes from, e.g., https://github.com/mdn/browser-compat-data/blob/master/css/properties/text-overflow.json

[05:47:57.0000] <MassDebates>
Okay

[05:48:01.0000] <MassDebates>
OKay thank you

[05:48:19.0000] <MikeSmith>
but if I look at the data there for that fade value at https://github.com/mdn/browser-compat-data/blob/master/css/properties/text-overflow.json#L119, I don’t see any notes about experimental support

[05:48:32.0000] <MassDebates>
Right

[05:48:59.0000] <MikeSmith>
yeah, so that’s a data point which suggests that no browsers have implemented it yet, even experimentally

[05:49:27.0000] <MassDebates>
I see, I misunderstood the table. I didn't see a value with experimental, only a key

[05:49:29.0000] <MikeSmith>
...and so there’s not gonna be any option you can flip on to try it

[05:50:08.0000] <MassDebates>
The people that make the drafts - how do they see what they're making?

[05:50:14.0000] <MassDebates>
the css spec

[05:50:30.0000] <MassDebates>
they write up quick little sandbox pared down concept examples?

[05:51:47.0000] <MikeSmith>
no in most cases they write a definition of the required behavior without actually writing any actual code to implement it

[05:52:08.0000] <MikeSmith>
the people who write the specs are usually not the people who write the browser code

[05:53:37.0000] <MikeSmith>
the spec comes first, the browser code comes after — sometimes very long after something is first specified

[05:54:18.0000] <MikeSmith>
and in the meantime there really is no way to test out a feature in the spec prior to it getting first implemented in a browser

[05:55:08.0000] <MassDebates>
That's a lot of trust to give to browsers

[05:55:25.0000] <MassDebates>
a lot of work too, I'm sure

[05:55:32.0000] <MikeSmith>
well I guess it’s also a lot of trust to give to spec writers

[05:55:49.0000] <MikeSmith>
but in practice, it’s in iterative process

[05:55:53.0000] <MassDebates>
Why? Browsers aren't compelled to support anything spec writers put out, no?

[05:56:04.0000] <MassDebates>
What trust is given to them?

[05:56:16.0000] <MikeSmith>
well spec writers don’t just pull stuff out of their hats

[05:56:35.0000] <MassDebates>
I'm not saying that, and I'm not saying they don't do things intelligently

[05:56:50.0000] <MikeSmith>
yeah I understand

[05:56:53.0000] <MassDebates>
ok

[05:57:12.0000] <MassDebates>
Okay, thank you for educating me on this process

[05:57:22.0000] <MassDebates>
I hope I didn't take you away from anything urgent/pressing.

[05:57:30.0000] <MassDebates>
I appreciate your time.

[05:57:44.0000] <MikeSmith>
cheers

[05:57:50.0000] <MikeSmith>
that’s what this channel is here for


2020-09-28
[02:04:44.0000] <annevk>
It's so frustrating GitHub only allows you to report a single user within a short period of time

[02:05:17.0000] <annevk>
Especially considering I'm logged in and have a track record of reporting actual spammers

[02:05:41.0000] <annevk>
And usually they're pretty good about feedback but I reported this issue twice and they're just like shrug

[02:48:20.0000] <MikeSmith>
annevk: I didn’t know they had such a limit

[02:49:01.0000] <MikeSmith>
I guess I’ve never reported multiple problems in close succession

[02:49:08.0000] <annevk>
MikeSmith: I often hit it in the morning as when dealing with GitHub notifications I try to deal with spam first

[02:49:13.0000] <MikeSmith>
ah yeah

[02:50:33.0000] <MikeSmith>
their entire reporting system opaque, unnecessarily

[02:51:10.0000] <annevk>
You do make me wonder if this is a timezone problem where the spam doesn't pile up in other timezones as much so it's not perceived as a problem

[02:58:27.0000] <annevk>
I have created another ticket, maybe three times works

[02:59:15.0000] <annevk>
Oh cool, for support requests there's now a ticket center where you can keep track of things online

[02:59:24.0000] <annevk>
Though I cannot view my spam reports there

[07:35:28.0000] <annevk>
Domenic: I haven't pinged plinss explicitly anywhere because it seems most of csswg.org is down, e.g., https://drafts.csswg.org/css-inline/

[07:35:37.0000] <Domenic>
Fun

[07:35:44.0000] <annevk>
So I would expect this to be known

[08:04:33.0000] <annevk>
Domenic: now I'm also doubting "and public-suffix roots need to be considered same-site to their subdomains."

[08:04:45.0000] <annevk>
Domenic: annevk.github.io is not same site with github.io, right?

[08:06:00.0000] <annevk>
Domenic: it might be that only your statement there was wrong as it seems the same site check does account for it

[08:06:25.0000] <annevk>
Domenic: but let's note that in the parenthesis fix commit message

[08:06:33.0000] <Domenic>
Sounds good

[08:06:38.0000] <Domenic>
I thought they would be considered same-site, hmm

[08:06:53.0000] <Domenic>
But yeah I guess that would be bad

[08:07:09.0000] <Domenic>
Will walk myself back through the algorithms after this meeting

[08:11:49.0000] <annevk>
👍🏻

[08:17:50.0000] <Domenic>
annevk: OK, that all makes sense. But as a related non-blocking question, I'm wondering why we define registrable domain at all? Instead of defining eTLD+1? Then we could say that site is always (scheme, eTLD+1) instead of branching on nullness of registrable domain.

[08:23:13.0000] <annevk>
Domenic: so how do you obtain eTLD+1 from a host?

[08:23:44.0000] <Domenic>
annevk: a modification of the https://url.spec.whatwg.org/#host-registrable-domain algorithm to return the host instead of null.

[08:24:01.0000] <annevk>
Domenic: it seems that would make github.io same site with annevk.github.io

[08:24:36.0000] <Domenic>
Hmm OK maybe what I am suggesting is not in fact an eTLD+1

[08:25:01.0000] <Domenic>
Is there a name for a thing where it's https://url.spec.whatwg.org/#host-registrable-domain but with step 1 returning host instead of null?

[08:25:22.0000] <annevk>
I think Gecko might call that effective domain

[08:25:26.0000] <annevk>
/me looks

[08:26:27.0000] <annevk>
Hmm maybe not

[08:36:28.0000] <annevk>
Domenic: I can't really find anything obvious, mostly it seems to be dealt with through fallback. I do wonder if implementations are truly consistent about all this though

[08:36:42.0000] <Domenic>
Hmm hmm

[08:37:19.0000] <annevk>
Domenic: it does seem like you need something like registrable domain; or you would need a separate type essentially

[08:37:31.0000] <Domenic>
When is it useful for it to be null?

[08:37:40.0000] <annevk>
Domenic: for the same site check

[08:38:00.0000] <Domenic>
I think same site could just become "is siteA[1] === siteB[1]"

[08:38:12.0000] <Domenic>
Where site[1] is this new thing

[08:38:49.0000] <annevk>
Well, if you look at how schemelessly same site is defined, I don't see how that's possible without it either being a distinct type somehow or having registrable domain

[08:39:01.0000] <annevk>
If we're talking about no functional changes

[08:39:20.0000] <Domenic>
No functional changes indeed

[08:39:48.0000] <annevk>
Basically, what's the definition of === as it cannot really be identity I think

[08:41:34.0000] <Domenic>
annevk: https://gist.github.com/domenic/49d7d2ec209bfae109ce6ec52148dffc is what I'm thinking

[08:42:11.0000] <annevk>
Domenic: sure, but what's equals?

[08:42:24.0000] <Domenic>
The same thing it is currently>

[08:42:45.0000] <Domenic>
If site[1] is a host, it's host-equals

[08:43:06.0000] <Domenic>
If site[1] is a registrable-domain-or-host, it's host-equals for hosts, string-equals for registrable domain

[08:43:32.0000] <annevk>
Okay, so you'd have an explicit registrable domain type

[08:43:41.0000] <annevk>
Currently it's just another domain

[08:43:57.0000] <Domenic>
No you'd use string

[08:44:12.0000] <annevk>
But how would you tell it's the registrable domain and not a domain?

[08:44:24.0000] <annevk>
Or not the public suffix, rather

[08:44:26.0000] <Domenic>
How would it matter?

[08:44:34.0000] <Domenic>
You already computed that in "obtain a site"

[08:44:39.0000] <Domenic>
Now you just have a string-or-IP-address

[08:44:44.0000] <Domenic>
or opaque host

[08:44:48.0000] <Domenic>
or empty host

[08:44:56.0000] <annevk>
yeah, but we obtain the registrable domain from it

[08:44:57.0000] <Domenic>
Oh wait those are both strings

[08:45:05.0000] <Domenic>
But you don't need to

[08:45:13.0000] <Domenic>
By the time you're in "same site" you just have a string-or-IP address

[08:45:17.0000] <Domenic>
You can compare those using normal ===

[08:45:56.0000] <annevk>
Oh that might be true, yes, hmm

[08:48:52.0000] <Domenic>
I'll raise an editorial PR for changing same-site and schemeless-same-site for discussion. That's separate from potentially changing the definition of registrable domain/obtain a site, I guess.

[08:49:41.0000] <annevk>
Domenic: there's also the question of what we'd want to expose to APIs, if ever

[08:50:03.0000] <annevk>
Domenic: for an API you might want to have registrable domain, but on the other hand maybe you don't to enforce consistency

[08:51:01.0000] <Domenic>
Yeah, I dunno, the API discussion seems rather theoretical to me

[08:52:00.0000] <annevk>
Domenic: it keeps coming up as we expose this in more and more places

[08:52:19.0000] <annevk>
Domenic: it seems we call this "base domain" in Firefox (frontend code at least; getBaseDomainFromHost)

[08:52:53.0000] <Domenic>
When I looked on Friday Chrome's code was not very good at mapping to the spec

[08:53:08.0000] <annevk>
Domenic: but that's implemented on top of registrable domain

[08:53:40.0000] <annevk>
(which is called eTLD+1 for reasons)


2020-09-29
[17:39:21.0000] <MikeSmith>
Krinkle: are y’all use the Beacon API?

[17:39:58.0000] <MikeSmith>
..and if so, is it working for you in the way you need?

[17:41:42.0000] <MikeSmith>
I ask because I’ve made some changes to the sendBeacon() MDN article recently, to try help steer developers in the right direction

[17:41:49.0000] <MikeSmith>
https://wiki.developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon$history

[17:42:23.0000] <MikeSmith>
see also https://github.com/mdn/sprints/issues/3722

[17:43:16.0000] <MikeSmith>
...and if you have other suggestions about how MDN could be updated to give better guidance on the Beacon API, lemme know — or chime in on https://github.com/mdn/sprints/issues/3722

[17:44:56.0000] <MikeSmith>
annevk: Domenic: by the way, see Phil Walton’s comments about the unload event at https://github.com/mdn/sprints/issues/3722#issuecomment-699526801

[18:36:41.0000] <Krinkle>
MikeSmith: if y'all=Wikipedia, then yes, we have used this in production for a while now and happy with its results.

[18:37:31.0000] <MikeSmith>
Krinkle: cool yeah (and that’s what I meant)

[18:37:46.0000] <Krinkle>
We don't use it for exit path generally. We do have one infrequent campaign to measure session duration which sometimes beacons from focus/blur/pagehide/visibilitychange, indeed never unload since that event wouldn't fire in most mobile scenarios due to freezing and closing without foregrounding.

[18:38:17.0000] <MikeSmith>
ah I see

[18:38:41.0000] <MikeSmith>
yeah unload is nearly useless for mobile

[18:39:02.0000] <Krinkle>
MikeSmith: I vaguely recall seeing https://volument.com/blog/sendbeacon-is-broken and finding it deceptive since my gut feeling is that sendBeacon works fine wherever you call it, even unload. the issue is just that unload often doesnt fire, there isn't any cirumstances afaik where code runs and calls sendBeacon() but it gets discarded by a browser for reasons specifically relating with how the code calling it got scheduled, right?

[18:39:21.0000] <MikeSmith>
yup

[18:39:24.0000] <Krinkle>
ok

[18:40:16.0000] <Krinkle>
I think the MDN currently is perhaps too strong and might leave a developer thinking there's a logical, spec or implemetnation correlation with unload specifically.

[18:40:17.0000] <Krinkle>
But..

[18:40:25.0000] <Krinkle>
I dont think that's harmful in any way.

[18:40:56.0000] <MikeSmith>
yeah the person who wrote that blog post is well-intentioned but I think they seem to just be wedded to the idea that unload should be the thing to use (because of the the name) and somewhat unable to see that unload is not what they think it iss

[18:41:06.0000] <Krinkle>
I'm aware you reduced the severity from a red warning to a little sentence. Just saying, it still certainly sounds like there is correlation. But I also can't think of a more concise way that's helpful.

[18:41:28.0000] <MikeSmith>
Krinkle: well see https://github.com/mdn/sprints/issues/3722#issuecomment-699526801

[18:41:35.0000] <MikeSmith>
> I'd also recommend updating the warning text to recommend never using the unload event—not with with API or any any other APIs

[18:41:44.0000] <MikeSmith>
> On the Chrome team, we're trying to get the message out that using the unload event is never a good idea. For example, Lighthouse v6.2.0 has added a no-unload-listeners audit, which will warn developers if any JavaScript on their pages (including from third-party libraries) adds an unload event listener, and we may even add a console warning to pages where the unload event is used.

[18:41:52.0000] <MikeSmith>
..

[18:41:57.0000] <MikeSmith>
so that’s pretty strong

[18:42:00.0000] <Krinkle>
Yeah, I think I commented on that post on some platform somewhere at the time that in our study the failure rate wasn't significantly different from e..g. new Image() or sync XHR from the same event handler. the issue was not with sendBeacon().

[18:42:12.0000] <MikeSmith>
OK

[18:43:50.0000] <MikeSmith>
about unload, given Phil Walton’s comments about what Chrome is doing for Lighthouse (and possible console warning), I think thinking we might want to add some kind of note/warning about unload to the HTML spec itself

[18:44:00.0000] <Krinkle>
MikeSmith: So yeah, I think strong wording with unload is not accurate but also harmless, and probably useful even. But perhaps on a related note - after seeing this latest edit, I actually thought that maybe we're using it incorrrectly. That is, it sounds now like it is meant to *only* be used to track unload-like scenarios, e.g. that caling it from click() or other scenarios would be unintended use.

[18:44:42.0000] <MikeSmith>
oh yeah I think so too

[18:44:54.0000] <MikeSmith>
unintended use, from what you describe

[18:45:21.0000] <MikeSmith>
though that doesn’t mean it won’t work, or would ever stop working

[18:45:36.0000] <MikeSmith>
it is more just a side effect

[18:46:10.0000] <MikeSmith>
well now that I say that, that might not be all true for Safari at least

[18:46:52.0000] <Krinkle>
hm.. why would you/browsers discourage use of sendBeacon() for e.g. regular UI events and things not relating to the page lifecycle? Is it not generally the recommended path for all async/expect completed beacons?

[18:47:14.0000] <Krinkle>
like a JS-click for opening a dialog or something.

[18:47:25.0000] <MikeSmith>
annevk: Domenic: I think maybe we have no precedent for adding a warning for a case like the unload event. But I wonder if we should for this

[18:47:49.0000] <MikeSmith>
Krinkle: I don’t think it should be discouraged

[18:48:25.0000] <MikeSmith>
actually I think you might want to even raise an issue in their github tracker to inform them of that use case

[18:48:49.0000] <MikeSmith>
It might be something they already took into account, I dunno

[18:49:30.0000] <MikeSmith>
I am not very familiar at all with that API, so it could just be my own ignorance that makes me see that use case as surprising

[19:04:02.0000] <Krinkle>
MikeSmith: I don't know if it's representative, but to me it's the opposite. We've never specifically targetted tracking unloads. Only every other use case imaginable :P

[19:04:17.0000] <Krinkle>
but then again, I suppose that might have something to do with working with a non-profit.

[19:07:18.0000] <MikeSmith>
Krinkle: why would it have anything to do with working for a non-profit?

[19:08:07.0000] <Krinkle>
I'm implying that heavy tracking of eye-ball time or page abandonment is something a non-profit is much less likely to be interested in.

[19:08:43.0000] <MikeSmith>
aha

[19:08:50.0000] <MikeSmith>
yeah, true

[19:10:06.0000] <Krinkle>
/me edited mdn:Beacon_API earlier today to say it is no longer experimental

[19:10:18.0000] <MikeSmith>
yeah I saw that

[19:10:26.0000] <MikeSmith>
that is why I pinged you

[19:11:00.0000] <Krinkle>
k, I figured, but wasn't sure :)

[19:11:11.0000] <MikeSmith>
yeah, I get notifications when basically every web-platform MDN article other that CSS stuff gets updates

[19:11:28.0000] <MikeSmith>
..which is actually a lot less notifications than you imagine

[19:11:53.0000] <MikeSmith>
*than you might imagine

[19:13:13.0000] <MikeSmith>
Krinkle: by the way, about WikiMedia and way off-topic, but I came across https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_Cancer due to http://calpaterson.com/mozilla.html linking to it

[19:13:45.0000] <MikeSmith>
...which should have a far less obnoxious title but the data there still surprised md

[19:15:13.0000] <MikeSmith>
specifically, that WikiMedia Foundation revenue was $120,067,266 last year, of which $91,414,010 was spent (I guess mostly on staff compensation; it shows currently 415 people on the payroll; 284 staff, 131 contractors

[19:16:27.0000] <MikeSmith>
anyway, I guess I just had no idea of the scale, as far as revenue and costs and staffing

[19:17:43.0000] <Krinkle>
(That page is a personal sandbox and not a peer-reviewed article. I think that's clear, but just stating it for the record.)

[19:19:48.0000] <Krinkle>
those numbers sound about right yeah - https://wikimediafoundation.org/about/annualreport/2019-annual-report/financials/

[19:20:48.0000] <MikeSmith>
/me looks

[19:21:20.0000] <Krinkle>
For software engineering, SRE, DC ops, network ops its about ~250 globally I believe.

[19:22:19.0000] <Krinkle>
essentially running from about 400 apache servers with a 20 server in-house edge cache over 4 pop sites https://wikitech.wikimedia.org/wiki/Clusters

[19:22:55.0000] <MikeSmith>
that seems about right, as far as staffing

[19:23:20.0000] <MikeSmith>
well, actually, it seems very low staffing, for running one of the top 10 sites in the world

[19:23:55.0000] <Krinkle>
yeah, for sure. It's getting quite hard to fill positions where you're effectively required to know everything about everything in every area :P

[19:24:09.0000] <MikeSmith>
it’s gotta be pretty fun to work on something which gets that scale of people using it

[19:24:17.0000] <MikeSmith>
haha

[19:24:23.0000] <Krinkle>
this year we're getting our second dedicated full-time DBA to look after the MySQL/MariaDB core database cluster.

[19:24:35.0000] <Krinkle>
which is long long overdue

[19:24:57.0000] <MikeSmith>
wow, only person been doing that?

[19:25:05.0000] <MikeSmith>
well, DBAs are expensive

[19:25:20.0000] <Krinkle>
well, 1 full-time. but I suppose 0.1% of a few dozen folks does add up

[19:25:27.0000] <MikeSmith>
yeah

[19:26:30.0000] <MikeSmith>
anyway, as far as revenue "Donations and contributions     110,972,163" is inspiring

[19:26:40.0000] <Krinkle>
these last 3 years have been challenging, converting ourself from a "we're tiny, just getting started, everybody knows each other and knows what to do and gets to do it" to "yeah, no, we're not small anymore, let's formalise things and add (some) bureaucracy".

[19:26:58.0000] <Krinkle>
I believe our fundraisers like to say that the average donation is $10

[19:27:29.0000] <Krinkle>
specifically meant to convey that we're not reliant on any big corporate donors

[19:27:58.0000] <MikeSmith>
the "we're tiny, just getting started, everybody knows each other" part I can imagine being hard. It’s hard and not as fun once you have to put more bureaucracy around it all

[19:28:11.0000] <Krinkle>
yeah.

[19:28:29.0000] <Krinkle>
I've seen the org double 3x in my time here. I joined when we were around 89 staff I think?

[19:29:06.0000] <Krinkle>
well, I guess that's 2x taking into account the first doubling

[19:29:35.0000] <MikeSmith>
I would imagine myself hoping it could just stay small

[19:29:53.0000] <Krinkle>
but I'm actually glad we're letting go of some of the informality. I've seen first-hand the problems it causes when inability to on-boarding means I'm personally on the hook to investigate any/all incidents

[19:29:57.0000] <MikeSmith>
working for a big-staff organization is just less fun

[19:30:23.0000] <MikeSmith>
ah yeah, about being on-hook

[19:30:48.0000] <MikeSmith>
can’t do that forever

[19:31:04.0000] <Krinkle>
19 year old me certainly thought he could.

[19:33:06.0000] <MikeSmith>
anyway for me personally, looking just at the donations side, if W3C could manage to get donations on the order of just 1% of that 110,972,163, I reckon that even that would be at least 10 times what donations we are getting at W3C now

[19:33:28.0000] <Krinkle>
the start of that 3-year "let's get serious" was the infamous period described in those links with keywords "lila" and "knowledge/search engine". Ideas I can't express much opinion over whether it was smart, but I do know that only a minority stood behind them, and within a few months those were no longer part of the org.

[19:33:46.0000] <MikeSmith>
ah yeah

[19:34:14.0000] <Krinkle>
had very long and widespread moral implications beyond their tenure, but at least it was fairly quickly dealt with.

[19:34:25.0000] <Krinkle>
we lost some good folks during that time

[19:35:59.0000] <Krinkle>
I know fairly little about how the W3C is internally organised actually, come to think of it.

[19:36:08.0000] <Krinkle>
Are you full-time there?

[19:36:23.0000] <MikeSmith>
yeah, we have almost no contractors

[19:37:08.0000] <MikeSmith>
well that is not true: we have people who work on grant money, a lot for accessibility-related work

[19:37:35.0000] <Krinkle>
I've mainly been exposed to the working groups part, which to my knowledge is mostly "contributed/sponsored" time, e.g. like how Wikimedia, and Google are members with some of their staff spending some or all of their time on standards work.

[19:38:20.0000] <MikeSmith>
right

[19:39:07.0000] <MikeSmith>
the staff mostly do not write specs nor chair groups

[19:39:36.0000] <MikeSmith>
but instead do on-boarding for chairs, and somewhat, management of chairs

[19:40:00.0000] <MikeSmith>
many groups and chairs actually need a lot of pushing

[19:40:32.0000] <MikeSmith>
groups tend to degrade a bit into inaction or infrequent action

[19:41:06.0000] <MikeSmith>
..unless someone is pushing them to stay on top of things

[19:42:51.0000] <MikeSmith>
Philippe Le Hégaret is the one who does the best pushing

[19:43:22.0000] <MikeSmith>
and he has people who report to him who are the ones that need to be pushing chairs and group

[19:43:33.0000] <MikeSmith>
so Philippe pushes the pushers

[19:45:07.0000] <Krinkle>
I see, and #lazyweb - who would generally be the stakholders for which pushers are activated on behalf of? Is that like other memberr orgs? Or does the formal line end there and would they proactively start this on their own based on public interest.

[19:45:39.0000] <Krinkle>
or based on agreed upon deadlines/commitments?

[19:46:04.0000] <MikeSmith>
roughly based on schedules in working-group charters

[19:47:37.0000] <MikeSmith>
but more broadly based on a grander notion that working groups are assets held in trust for the wider web community, churning out new useful web technologies at a regular pace/heartbeat

[19:47:48.0000] <MikeSmith>
drumbeat, etc

[19:49:19.0000] <MikeSmith>
so, keep stuff moving through the pipeline and getting shipped in browsers and deployed adopted, so that we can have time/resources to work on the next new thing, and the next

[19:50:36.0000] <MikeSmith>
but we on the W3C team are in the weird position where we have zero authority to actually keep others working on schedule

[19:50:52.0000] <Krinkle>
right!

[19:50:58.0000] <MikeSmith>
yeah

[19:51:25.0000] <Krinkle>
It's great that all that exists though. I wasn't specifically aware of this, but it makes a lot of sense and I'm glad the W3 is investing in that.

[19:51:45.0000] <Krinkle>
perhaps we've not yet been naughty enough to be deservant of said push :)

[19:52:00.0000] <MikeSmith>
heh

[19:52:12.0000] <MikeSmith>
anyway, there are only about 20 people in total who do the direct engagement like that with groups

[19:52:42.0000] <Krinkle>
and an order of magnitude more working groups, right?

[19:52:46.0000] <MikeSmith>
or who are otherwise the “technical” people on staff who do that kind of problem-solving sfuff

[19:52:50.0000] <Krinkle>
distinct wgs*

[19:52:57.0000] <MikeSmith>
yeah we have a lot of groups

[19:53:16.0000] <MikeSmith>
but some groups are run well without as much pushing

[19:53:59.0000] <MikeSmith>
but anway the only real authority I and others at W3C have is that we can replace working-group chairs who don’t do their jobs, and appoint chairs to begin with

[19:54:24.0000] <MikeSmith>
well I can also get groups shut down, if they are not producing the way they should be

[19:54:56.0000] <MikeSmith>
but in practice it’s a lot of hard work to shut a group down — too much inertia

[19:55:17.0000] <MikeSmith>
anyway, more than you wanted to know, I’m sure

[19:55:34.0000] <Krinkle>
that's alright. this is good to keep in the back of my mind.

[19:56:20.0000] <Krinkle>
as I slowly unwind down towards a more healthy 40h work week, I'd very much like to do more on the webapps/webperf/whatwg groups.

[19:56:36.0000] <MikeSmith>
it would be really great if you could

[19:57:01.0000] <Krinkle>
for now my time is limited to reading up on emails 10min a week, and attending the bi-weekly video call

[19:57:10.0000] <MikeSmith>
yup, understood

[19:57:24.0000] <MikeSmith>
but as far as WGs, webperf is one that could use more active participation from people who don’t work at Google

[19:57:42.0000] <MikeSmith>
Google is very much carrying most of the weight in webperf

[19:58:16.0000] <MikeSmith>
you would be a major asset their

[19:58:29.0000] <MikeSmith>
your insights from your experience

[19:58:35.0000] <Krinkle>
yeah, and generally upto 1 person from Apple or Mozilla

[19:59:01.0000] <Krinkle>
would like to see more involvement from there as well.

[19:59:48.0000] <Krinkle>
I often feel aligned with some of the ideas from Apple in that group, but not as much proactive work toward concrete ways to realize those ideas. I'd like to try some of that.

[20:02:06.0000] <MikeSmith>
I hear you, about alignment

[20:02:32.0000] <MikeSmith>
there are issues with some of webperf API designs

[20:03:00.0000] <MikeSmith>
but IMHO those are artifacts of not enough others paying attention and taking time to be involved

[20:04:46.0000] <MikeSmith>
well, also webperf editors need to take more responsibility themselves for taking initiative to do better implementor engagement, the way that WHATWG editors do

[20:05:12.0000] <MikeSmith>
browser implementor are chronically busy and lazy and have limited attention specs :p

[20:06:09.0000] <MikeSmith>
*attention spans

[20:11:07.0000] <Krinkle>
ack yeah, we need that.

[20:11:18.0000] <Krinkle>
I admitedly have no experience doing that thus far, though.

[00:19:45.0000] <annevk>
MikeSmith: yeah maybe, although it has been improvement, the lifecycle of a document is still somewhat poorly written out so I suspect there's a bunch of browser inconsistencies too

[00:19:53.0000] <annevk>
improved*

[00:20:01.0000] <annevk>
or maybe I meant to write seen

[00:23:17.0000] <annevk>
GitHub Actions is so much faster than Travis CI, it's hard to believe

[03:24:19.0000] <annevk>
littledan: so what's really the difference conceptually between accomplishing error or module through keying or the PR mechanism? The module map isn't directly observable. Implementations can optimize this either way. I guess there's something I'm missing and we probably discussed this a couple months back as well?

[03:29:13.0000] <zcorpan>
yoav: does chromium run "update the image data" during a forced reflow?

[03:32:27.0000] <yoav>
zcorpan: not sure off the top of my head...

[03:32:43.0000] <yoav>
related to https://github.com/whatwg/html/pull/5894 ?

[03:33:33.0000] <zcorpan>
yoav: yeah, I was playing around in live dom viewer. Seems this isn't interoperable: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8516

[03:35:43.0000] <zcorpan>
webkit even keeps the old dimensions applied

[03:36:41.0000] <yoav>
hmm

[03:36:47.0000] <yoav>
what's the specified behavior?

[03:39:25.0000] <zcorpan>
yoav: https://html.spec.whatwg.org/multipage/images.html#relevant-mutations runs "update the image data", which queues a microtask in step 7 before selecting an image source in step 9

[03:40:20.0000] <zcorpan>
yoav: so to the currently running script it's still the old image

[03:40:26.0000] <yoav>
ok, yeah

[03:40:58.0000] <yoav>
I believe that should be running for relevant mutations but not sure about other forced reflows

[03:41:56.0000] <yoav>
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/html_source_element.cc;l=115?q=html_source_element&ss=chromium%2Fchromium%2Fsrc:third_party%2Fblink%2Frenderer%2F&start=1

[03:42:08.0000] <yoav>
(for HTMLSourceElement specifically)

[04:03:28.0000] <annevk>
andreubotella: I'll likely fix the JSON mistake in default-RD in https://github.com/tabatkins/bikeshed/pull/1726

[04:11:21.0000] <andreubotella>
annevk: I did fix it in my PR, but if you're merging that first, sure

[04:12:31.0000] <annevk>
andreubotella: I think to merge your PR we need to merge the whatwg.org PR and you wanted to wait for the HTML PR before doing that, right? If so, I would expect this to go first

[04:12:57.0000] <annevk>
This does require a bunch of follow-up work, but none of it blocking

[04:13:47.0000] <andreubotella>
I'm about to push the changes MikeSmith wanted me to do

[04:13:56.0000] <andreubotella>
they'll need some review, though, so yeah, go ahead

[04:15:48.0000] <annevk>
andreubotella: I can rebase if it comes to that, but I kinda hope that git is smart enough

[04:26:58.0000] <littledan>
annevk: I think these differences are observable. For example, even with the `type`-only restriction, there are observably different numbers of fetches if you import with different types (I think we did discuss this some months ago, and I'm fine with concluding that this is an unimportant edge case).

[04:27:06.0000] <littledan>
The thing I'm more concerned about is non-type assertions. I'd prefer for these to be ignored and not treated as part of the cache key. If we can agree on that, then I'm fine with this greater number of fetches for varying `type`, though I still don't understand the motivation.

[04:34:03.0000] <littledan>
it's also observable what we choose for non-`type` assertions. For example, if we permitted them and ignored them but treated them as part of the key, or had an error on all of them. The choice here has implications for what other kinds of assertions we could compatibly add in the future.

[05:36:32.0000] <zcorpan>
yoav: what I really wanted to do was something more fancy: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8517

[06:16:29.0000] <annevk>
littledan: so I'm not sure that's true in the context of the memory cache (which is undefined, but still)

[06:17:20.0000] <littledan>
annevk: Does this depend on the cache headers of the response?

[06:17:27.0000] <annevk>
littledan: I think it would help to spell edge cases out to make an informed decision

[06:17:39.0000] <annevk>
littledan: well, there's that too, but the memory cache does not depend on that

[06:17:51.0000] <littledan>
oh, I see. where can I learn more about the memory cache?

[06:18:21.0000] <annevk>
littledan: I guess in WebKit/Chromium's codebase? https://github.com/whatwg/fetch/issues/590 has some context

[06:22:49.0000] <annevk>
andreubotella: seems git deals with it fine

[06:25:12.0000] <annevk>
TabAtkins: can you separate text macros by anything other than a newline?

[06:25:38.0000] <annevk>
TabAtkins: e.g. Text Macro: X XVAL, Y YVAL

[06:26:22.0000] <andreubotella>
annevk: rebased

[06:26:24.0000] <annevk>
TabAtkins: oh, I also get "Unknown include/exclude-if condition 'boilerplate:ipr'"

[06:39:59.0000] <annevk>
Maybe csswg.org is not up-to-date yet

[06:41:11.0000] <annevk>
Hmm no that doesn't make sense

[06:43:30.0000] <annevk>
TabAtkins: could that be because there's no continue statements after the yield?

[06:51:01.0000] <andreubotella>
annevk, TabAtkins: The conditional includes seem to be handled only after the macros are replaced, so the build is failing without the LATESTRD macro

[06:51:26.0000] <andreubotella>
this might not be something worth fixing, since if the include ends up in the spec, there's no downside in using [LATESTRD?]

[06:51:51.0000] <andreubotella>
*something worth fixing from the Bikeshed side, not from the WHATWG side

[06:53:03.0000] <annevk>
andreubotella: where did you see that failure?

[06:53:22.0000] <andreubotella>
building locally on my rebased branch

[06:53:41.0000] <annevk>
andreubotella: I see, we could make it LATESTRD? I guess

[06:57:42.0000] <annevk>
andreubotella: I'll do that and it seems to me that https://github.com/tabatkins/bikeshed/pull/1774 fixes the other issue

[07:00:04.0000] <annevk>
andreubotella: https://github.com/tabatkins/bikeshed/pull/1775 if that seems reasonable to you as well I'll land these so we can get on with it :-)

[07:00:14.0000] <annevk>
and if it continues to fail I'll back it all out

[07:00:30.0000] <andreubotella>
that's fine by me

[07:03:07.0000] <annevk>
It takes a long time to build DOM locally

[07:08:55.0000] <annevk>
andreubotella: bikeshed fixes are landed

[07:09:38.0000] <annevk>
TabAtkins: please review when you're awake and let me know if I should never do that again 😊

[07:14:20.0000] <zcorpan_>
I don't follow how what the spec does for <script src=X></script> where X is: document.write("<script src=Y></script><img src=Z>");

[07:14:37.0000] <zcorpan_>
first there's https://html.spec.whatwg.org/multipage/parsing.html#scriptEndTag

[07:15:08.0000] <zcorpan_>
"Prepare" will mark the script as the pending parser-blocking script, for the first script

[07:15:28.0000] <zcorpan_>
"script nesting level" is zero, so the Otherwise steps are run

[07:15:56.0000] <zcorpan_>
so far so good. This is where I want to kick off the (first) speculative parser

[07:17:49.0000] <zcorpan_>
but then the script is loaded and executed (step 10), and the document.write will invoke the tree builder reentrantly, reaching this part again but with "script nesting level" being 1

[07:18:29.0000] <zcorpan_>
where the spec says "Set the parser pause flag to true, and abort the processing of any nested invocations of the tokenizer, yielding control back to the caller. (Tokenization will resume when the caller returns to the "outer" tree construction stage.)"

[07:19:33.0000] <zcorpan_>
and that's what I don't get. how is the Y script loaded and executed?

[07:19:55.0000] <zcorpan_>
Where should I kick off a second speculative parser to find the img in the document.write string

[07:31:39.0000] <annevk>
Creating a bunch of PRs always leads to finding lots of novel xref issues, sigh

[09:30:23.0000] <TabAtkins>
annevk: You do multiple text macros by supplying the key multiple times. Text macros can expand into *any* text, so I couldn't rely on any delimiter at all.

[09:40:13.0000] <annevk>
TabAtkins: yeah, fair

[09:40:46.0000] <TabAtkins>
(Newline happens to work because of the shorthanding where if you newline+indent, it's the same as repeating the previous key.)

[10:16:37.0000] <TabAtkins>
annevk: I've also added a note to the docs about making sure you make the macro optional if you're conditioning on its existence; the ordering of macros vs conditionals isn't something I can change. Thanks for noticing it!

[11:01:27.0000] <devsnek>
would the web still be interested in that "blöcks" proposal

[11:02:09.0000] <devsnek>
i was thinking of looking at it again, my motivation more being node's worker api

[11:52:32.0000] <annevk>
TabAtkins: thanks, expected as much; credit to andreubotella though

[12:31:48.0000] <Domenic>
devsnek: a while back folks from Chrome pivoted away from workers and to scheduling (https://github.com/WICG/main-thread-scheduling) because they found the cross-thread communication overhead was prohibitive for realistic use cases. I will see if I can find the analysis they did. So, it's no longer considered high priority to make workers more ergonomic, from Chrome's perspective.

[12:32:44.0000] <Domenic>
That said, I think for people who *are* using workers on the web, blöcks would be nice. Maybe nice enough for the web to spec and ship a worker blöck, although as usual speccing/shipping sugar features that can also be accomplished in libraries seems hard for any vendor to prioritize.

[12:46:41.0000] <devsnek>
Domenic: thanks for the info


2020-09-30
[20:19:00.0000] <MikeSmith>
when you say, “pivoted away from workers and to scheduling” and “for people who *are* using workers on the web”, it sounds like you’re suggesting that any use cases that could be met with workers could be satisfied completely with a native scheduling API instead, and that would be better?

[20:19:17.0000] <MikeSmith>
or am I reading too much into what you wrote?

[21:26:49.0000] <shu_>
i’ll push back a bit, speaking for V8, i think there’re capability gaps in the platform to be bridged for better multithreaded programming that’s complementary to scheduling. if we bridge those, or perhaps while bridging them, something like blöcks become more attractive to the platform

[21:59:39.0000] <annevk>
shu_: what are the gaps? C threads in Wasm?

[01:19:33.0000] <annevk>
Domenic: https://github.com/whatwg/console/pull/187

[01:19:52.0000] <annevk>
(or someone else with review power)

[02:07:04.0000] <annevk>
zcorpan_: are you interested in solving https://github.com/whatwg/quirks/pull/53?

[02:08:09.0000] <annevk>
there are some auto references it's confused about and I wasn't able to find a solution within 30s, but I can look longer later

[02:17:06.0000] <zcorpan_>
annevk: I can fix

[02:17:30.0000] <zcorpan_>
looks like css2 is confusing bikeshed

[02:17:45.0000] <zcorpan_>
or quirks is doing something wrong

[02:20:22.0000] <zcorpan_>
https://github.com/whatwg/quirks/pull/54

[02:34:12.0000] <annevk>
zcorpan_: mind pushing that as a fixup commit to the other PR?

[02:34:22.0000] <annevk>
zcorpan_: and then I'll squash land if you approve

[02:35:00.0000] <annevk>
or you can approve and I'll do it

[02:35:10.0000] <zcorpan_>
annevk: why not land #54 and rebase 53?

[02:37:23.0000] <annevk>
zcorpan_: it's not what I did elsewhere, but sure

[02:37:51.0000] <annevk>
zcorpan_: still need your approval

[07:40:32.0000] <Domenic>
MikeSmith: No, I'm not going that far. I'm saying that if your goal is to improve performance, trying to move currently-main-thread stuff to workers is not a great investment in the general case, because of the communications overhead. E.g. people talked about doing all the "M" and "C" parts of MVC in a worker; some benchmarking showed that any gains in removing main-thread contention there are lost by the cross-thread

[07:40:32.0000] <Domenic>
serialization overhead.

[07:41:26.0000] <Domenic>
annevk: my comment about not unnecessarily removing the centralized link defaults stands on console.

[07:42:02.0000] <annevk>
Domenic: I don't see that comment?

[07:42:19.0000] <Domenic>
annevk: oops, was sitting in drafts :(

[07:42:56.0000] <annevk>
Domenic: this isn't about defaults though

[07:43:17.0000] <annevk>
Domenic: there's a difference between for=/ whatever list thing URL defines

[07:43:30.0000] <annevk>
which I guess has for=URLSearchParams if I would have to go from memory

[07:43:38.0000] <Domenic>
Link defaults says that whenever you see [=list=] it should be Infra's for="/" list

[07:43:47.0000] <Domenic>
You deleted that and instead made it [=/list=] everywhere

[07:44:28.0000] <annevk>
I mean, that's not quite what it does

[07:44:46.0000] <annevk>
There's a difference between defaulting to / and specifying some specific document that might change over time

[07:45:03.0000] <annevk>
I think not listing specific documents is better

[07:45:11.0000] <Domenic>
I understand, which is why I said it's the editor's call.

[07:45:19.0000] <Domenic>
(I disagree)

[07:45:25.0000] <Domenic>
I don't think it's something that should be changed in a "link to the RD" commit.

[07:46:29.0000] <annevk>
Domenic: also, if Infra gains another <dfn>list</dfn> it'll continue complaining

[07:46:40.0000] <Domenic>
I understand it's your preference

[07:46:44.0000] <Domenic>
I don't think it's appropriate to change in this PR

[07:47:26.0000] <annevk>
sigh

[07:47:31.0000] <Domenic>
(and I don't particularly have the energy at the moment to argue about why I prefer the opposite.)

[07:47:35.0000] <annevk>
Someone else can do this then

[07:47:59.0000] <Domenic>
Wow, so you won't help link to RDs unless you get to make unrelated changes to how standards are done?

[07:49:08.0000] <annevk>
I mean, I was just trying to fix the build and your attitude about it made me lose my energy, so to say

[07:49:18.0000] <Domenic>
Fair enough

[08:55:20.0000] <shu_>
annevk: i see two areas where there're gaps: 1) better support for actor-like run-to-completion style programming. in particular, i'm thinking better transferring of JS object graphs (including code), 2) more useful racy accesses on shared memory (i.e. "traditional" multithreaded programming) without having to come up with your own object models and write your own mutexes

[09:06:15.0000] <noamr>
Hi TabAtkins and annevk, I want to help progress on https://github.com/whatwg/html/issues/5165 and https://github.com/w3c/csswg-drafts/issues/5165 (EXIF orientation/resolution and same-origin). What would be a good next step? Create a PR for HTML spec for the same-origin/orientation issue?

[10:15:49.0000] <Domenic>
Wow the spam is really ramping up

[10:16:00.0000] <Domenic>
Oh it's probably October in some parts of the world

[10:19:50.0000] <Domenic>
There's a new "spam" label we can use according to https://hacktoberfest.digitalocean.com/faq/ but this still sucks

[12:27:17.0000] <Domenic>
Eyeing this option... https://usercontent.irccloud-cdn.com/file/m3utstGN/repository-interaction-limits.png

[12:43:09.0000] <TabAtkins>
that seems useful to turn on

[12:43:21.0000] <TabAtkins>
noamr: Plz ping me tomorrow!

[12:43:53.0000] <noamr>
sure TabAtkins.

[12:44:00.0000] <noamr>
thanks!

[12:44:48.0000] <zcorpan_>
Domenic: can it be enabled for a whole org?

[12:45:56.0000] <Domenic>
Looks like it can

[12:46:23.0000] <Domenic>
I worry a bit about putting off legitimate contributors or e.g. browser employees who haven't done much GitHubbing...

[12:50:37.0000] <zcorpan_>
Domenic: yeah. How severe is the spam problem? Also that setting limits all interactions, not only PRs

[12:50:48.0000] <Domenic>
About 4 spam PRs per hour

[12:51:04.0000] <zcorpan_>
bleh

[12:56:02.0000] <zcorpan_>
Domenic: only for html, though?

[12:56:06.0000] <Domenic>
Yeah

[12:56:41.0000] <zcorpan_>
Maybe we can enable that setting for html, and document in CONTRIBUTING what to do if you're trying to open a PR and are blocked

[12:57:23.0000] <zcorpan_>
(or trying to comment or open a new issue, which will also be blocked)

[12:57:55.0000] <zcorpan_>
maybe github should provide more granularity here

[13:07:45.0000] <zcorpan_>
sent a ticket to github support

[14:05:30.0000] <croraf>
I know that per HTML standard it is erroneous to put "button" or "input type=checkbox" inside the "button".

[14:06:00.0000] <croraf>
But what about ARIA's "role=button" inside "button" or inside "role=button"?

[14:06:18.0000] <croraf>
Shouldn't this be consistent?

[14:13:17.0000] <zcorpan_>
croraf: that would make sense

[14:13:54.0000] <zcorpan_>
I don't think ARIA has many content model rules

[14:18:49.0000] <zcorpan_>
croraf: file an issue for aria?

[14:22:48.0000] <croraf>
zcorpan_, I dont know, because even the browsers do not conform to that.

[14:22:57.0000] <croraf>
I tried button in button, and I don't even get a warning.

[14:23:27.0000] <zcorpan_>
croraf: well, this is a conformance requirement for documents, not for UAs

[14:23:48.0000] <zcorpan_>
browsers are not required to warn you when you use invalid HTML

[14:25:12.0000] <croraf>
zcorpan_, who are UA's the implementors? what that shortcut means?

[14:26:15.0000] <croraf>
Not also sure what you mean by "conformance requirement for documents"

[14:26:54.0000] <Domenic>
Woohoo, https://blog.domenic.me/hacktoberfest/ is #1 on HackerNews :D

[14:26:56.0000] <zcorpan_>
Sorry, UA = user agent, like browsers (but not only browsers)

[14:28:16.0000] <zcorpan_>
croraf: different requirements in specs apply to different conformance classes. In this case, disallowing buttons in buttons is a requirement for web developers / authors / documents only

[14:29:21.0000] <zcorpan_>
Domenic: s/then for hosting/them for hosting/

[14:29:30.0000] <Domenic>
ty

[14:32:08.0000] <devsnek>
haven't been to the orange site in a while

[14:32:16.0000] <devsnek>
forgot how disconnected the comments are

[14:32:40.0000] <croraf>
zcorpan_, I see

[14:33:15.0000] <devsnek>
i wonder why the html spec is getting so much, when node hasn't gotten any

[14:33:54.0000] <Domenic>
It seems really random

[14:33:56.0000] <Domenic>
I thought it was popularity

[14:34:03.0000] <Domenic>
But some people are saying their computer club website is getting them

[14:34:20.0000] <devsnek>
btw vultr/choopa is very good

[14:35:54.0000] <croraf>
zcorpan_, I found a sentence now in ARIA specs: For example, an element with role=button is interactive content and therefore cannot contain interactive content descendants.

[14:37:27.0000] <zcorpan_>
croraf: ooh, good catch! so it's here https://w3c.github.io/html-aria/#allowed-aria-roles-states-and-properties not in the main aria spec

[14:37:37.0000] <zcorpan_>
too many aria specs

[14:38:34.0000] <zcorpan_>
MikeSmith: this seems to not be implemented in validator.nu ^

[14:39:54.0000] <croraf>
zcorpan_, yes, I think that is the same document I'm checking: https://www.w3.org/TR/html-aria/#allowed-aria-roles-states-and-properties

[14:40:23.0000] <croraf>
but I see there are other documents

[14:41:52.0000] <zcorpan_>
croraf: yeah but TR/ are often outdated compared to the editor's draft

[14:42:50.0000] <zcorpan_>
first thing you want to do when landing in a w3c spec is to click the "Latest editor's draft" link at the top

[14:50:30.0000] <croraf>
I see.