2020-01-01
[11:23:20.0000] <GPHemsley>
Upgraded MediaWiki to 1.31.6 (latest 1.31 point release) but had to file https://phabricator.wikimedia.org/T241686

[11:23:54.0000] <GPHemsley>
Doesn't appear to affect anything other than the upgrade process itself, so we should be good to go

[11:40:39.0000] <GPHemsley>
external-loading gadgets have also been disabled by default

[11:42:13.0000] <GPHemsley>
Happy New Year everyone


2020-01-02
[04:49:18.0000] <smaug____>
Anyone know if https://bugs.webkit.org/show_bug.cgi?id=179020 is enabled by default in Safari?

[04:51:35.0000] <smaug____>
though, I guess it didn't add support for contextmenu

[04:55:28.0000] <annevk>
smaug____: per https://github.com/whatwg/html/issues/3251 I'm guessing they might have, but dunno really

[06:59:36.0000] <jgraham>
smaug____: https://wpt.fyi/results/html/semantics/interactive-elements/contextmenu-historical.html?label=master&label=experimental&aligned&q=contextmenu-historical.html any help?

[07:00:30.0000] <smaug____>
jgraham: ah yes. thanks. But I wonder if Safari still some kind of support for menus

[07:00:55.0000] <smaug____>
I don't have a mac with touchbar

[07:00:58.0000] <smaug____>
to test

[07:02:34.0000] <annevk>
smaug____: ping me Monday if you still wanna know

[07:02:56.0000] <smaug____>
ok. or I can try to find someone from Apple.

[07:03:15.0000] <smaug____>
perhaps I should just ping in github

[07:04:10.0000] <jgraham>
(Un)fortunately the only Mac I have access to is from 2011, so I can't really help :)

[07:05:09.0000] <smaug____>
The background for this is a Gecko bug where type=contextmenu "isn't working" with Shadow DOM, but it of course isn't defined anywhere what "working" means in that case.

[07:11:50.0000] <annevk>
smaug____: we should remove type=contextmenu, no?

[07:11:59.0000] <annevk>
Surprised we still have it

[07:12:30.0000] <smaug____>
yeah. Though it has come up couple of times at TPAC that people would like to have something similar

[07:13:57.0000] <annevk>
smaug____: that's fair, but would require a new design agreement anyway

[07:14:21.0000] <smaug____>
yup

[07:14:44.0000] <smaug____>
would be of course good to understand what webkit has now, if anything


2020-01-03
[08:15:38.0000] <MikeSmith>
annevk: when I run bikeshed on the dom.bs source, I get link errors:

[08:15:40.0000] <MikeSmith>
LINK ERROR: No 'dfn' refs found for 'service worker' with for='ServiceWorkerGlobalScope'.

[08:15:44.0000] <MikeSmith>
<a data-link-for="ServiceWorkerGlobalScope" data-link-type="dfn" data-lt="service worker">service worker</a>

[08:15:46.0000] <MikeSmith>
LINK ERROR: No 'dfn' refs found for 'service worker events'.

[08:15:49.0000] <MikeSmith>
<a data-link-type="dfn" data-lt="service worker events">service worker events</a>

[08:15:52.0000] <MikeSmith>
LINK ERROR: No 'idl' refs found for 'slotchange'.

[08:15:52.0000] <MikeSmith>
you getting those also?

[08:15:55.0000] <MikeSmith>
{{HTMLSlotElement/slotchange}}

[08:15:57.0000] <MikeSmith>
...

[08:18:55.0000] <annevk>
MikeSmith: I haven't done anything recently

[08:19:19.0000] <annevk>
MikeSmith: did you update bikeshed recently/

[08:20:47.0000] <MikeSmith>
annevk: yeah, I think my bikeshed environment is up to date, but I will re-update it and see


2020-01-06
[21:11:22.0000] <TimothyGu>
Is there something that says that the `pattern` attribute is only used for constraint validation if it applies?

[21:19:29.0000] <TimothyGu>
Ah found it: https://html.spec.whatwg.org/multipage/input.html#common-input-element-attributes

[09:17:34.0000] <annevk>
TabAtkins: there'll be much rejoicing

[10:43:41.0000] <Domenic>
annevk: ping on https://github.com/whatwg/html/pull/5154 if you're able


2020-01-07
[00:20:16.0000] <ondras>
hmh, has "checked" been an HTMLInputElement's attribute for a long time? I thought this one is only present on [type=radio] and [type=checkbox] ...

[00:46:39.0000] <annevk>
ondras: they all share the same class, so yes

[00:49:35.0000] <ondras>
I am pretty certain I had a working (in Electron, few major versions ago) code that used `"checked" in node` to differentiate radios/checkboxes...

[00:51:38.0000] <annevk>
2003 predates Electron, right? https://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-6043025

[00:52:08.0000] <ondras>
yeah :-)

[00:52:34.0000] <ondras>
well obviously they got this wrong initially and fixed it afterwards.

[09:36:35.0000] <annevk>
TabAtkins: TV Text is alt which generally shouldn’t match the title I think

[09:37:21.0000] <annevk>
TabAtkins: also wanted to make it match what we before

[09:38:04.0000] <TabAtkins>
title="" and alt="" do different thing, yes. But I was given to understand that <title> on an SVG was appropriate for "alt text" in a11y tools. Is this wrong?

[09:39:13.0000] <annevk>
TabAtkins: maybe, but it can output <img> too

[09:39:34.0000] <TabAtkins>
Sure, but the code isn't using <img title> at all.

[09:39:39.0000] <annevk>
TabAtkins: I could revert the inline SVG bits though

[09:39:58.0000] <annevk>
TabAtkins: it is?

[09:40:14.0000] <TabAtkins>
Sigh, I'm blind.

[09:40:24.0000] <TabAtkins>
Hm then.

[09:40:51.0000] <TabAtkins>
Okay, so I'm not a fan of the Title vs Text naming distinction here, but I'll do some research and see what I want to do.

[09:41:51.0000] <TabAtkins>
Hm, per https://a11yproject.com/posts/title-attributes/ title= and alt= should be identical if you feel the need to use title= at all

[09:43:28.0000] <annevk>
TabAtkins: Hmm the content is equivalent

[09:44:27.0000] <annevk>
TabAtkins: the difference is mainly about it appearing inline or not

[09:45:36.0000] <TabAtkins>
Right.

[09:46:20.0000] <TabAtkins>
So, to the best of my knowledge: on <img>, should use identical title= and alt= (they convey same information in different modalities, and dont' interfere with each other in screen readers); on <svg>, a <title> child is sufficient for both.

[09:48:13.0000] <annevk>
TabAtkins: I meant the diff between alt and title HTML has for this today, to be clear

[11:13:38.0000] <bathos>
Last I checked, some agents (a) don’t read svg <title> and so need alt while others (b) will read both alt and <title>. So I stopped using <title>, since alt worked the same everywhere.

[11:14:00.0000] <bathos>
This was a few years back so I don’t know if that’s still useful info.

[11:55:47.0000] <bathos>
(phrased that ambiguously I just realized — in (b) I meant reading both of them if both were present. so it was no-win — using <title> with no fallback could lead to no title, while using <title> with a fallback could lead to the title being announced twice.)

[12:00:22.0000] <annevk>
bathos: thanks, I guess that’s worth looking into, though WHATWG isn’t affected

[12:03:01.0000] <bathos>
Ah, sorry, I had no context for the discussion — just saw talk of what looked like a hot stove I once touched and instinctively shared the tale

[12:38:02.0000] <annevk>
bathos: I mean, most other specs will be, so TabAtkins will care I suspect; please keep sharing

[12:39:57.0000] <TabAtkins>
bathos: That's for an inline <svg> element? I wasn't aware <svg alt> was supported.

[12:40:24.0000] <TabAtkins>
If you're just referring to SVG-in-<img>, that's a different thing and I'm definitely just using <img alt> there.

[12:41:03.0000] <bathos>
yes, inline ... well, at least that’s how I recall it, I could have mixed it up.

[12:47:51.0000] <a-ja>
bathos: i missed start of convo...what you trying to use alt to accomplish? a11y or ?

[12:49:25.0000] <TabAtkins>
a-ja: It was me, actually.

[12:49:33.0000] <bathos>
I wasn’t, at least not just now — I was recalling an issue I encountered a few years ago which seemed like it might have been relevant to an earlier question (“But I was given to understand that <title> on an SVG was appropriate for "alt text" in a11y tools. Is this wrong?”)

[12:50:05.0000] <TabAtkins>
Figuring out what the best way to label the tracking-vector image (a fingerprint) with the text that "this is a potential tracking vector", for both <svg> and <img>.

[12:50:46.0000] <bathos>
I found this in an article from 2013 which sounds like it might be the issue I hit: “Jaws 15 and Internet Explorer 10 is the best combination at present, although nested SVG images are not well supported. NVDA and Internet Explorer present the role, title and desc, but support is erratic with multiple images announced and repetition of the title and desc. In all other browser/screen reader combinations the SVG is

[12:50:46.0000] <bathos>
ignored.”

[12:50:49.0000] <a-ja>
title/description combined with aria-labelledby/aria-described-by, but there are buggy tool impl's.

[12:51:02.0000] <TabAtkins>
For <img> it seems to be reasonably accepted that using identical text in title= and alt= is best - screenreaders get the same info, and people with mice get slightly upgraded experiences over those without.

[12:52:30.0000] <bathos>
That’s great to know re: aria-labelledby.

[12:57:47.0000] <a-ja>
e.g. <svg aria-labelledby="title" aria-describedby="description"><title id="title">title></title><description id="description">description</description>...</svg>

[13:01:12.0000] <a-ja>
https://css-tricks.com/accessible-svgs/     <-- "2. Inline SVG" describes bug workaround

[13:05:13.0000] <a-ja>
it suggests <svg aria-labelledby="uniqueTitleID uniqueDescID" role="img">

[13:06:42.0000] <a-ja>
validator doesn't like it, though, IIRC

[13:10:15.0000] <TabAtkins>
Not using a <desc> anyway, so that trouble is avoided.

[13:10:30.0000] <a-ja>
easy-peasy then

[13:15:41.0000] <a-ja>
"I[sic] recommended (based on browser/screen reader support) to use <img src="svg.svg> if possible"

[13:17:00.0000] <a-ja>
cuz of multiple workarounds involved for JAWS/NVDA/Chrome/Firefox

[13:32:31.0000] <TabAtkins>
Hm, I'd have to do an SVG data url then, as I'm trying to avoid having random Bikeshedded specs depend on a common external image, thus the inline SVG.

[13:44:11.0000] <a-ja>
another consideration perhaps...need licensing info embedded?

[13:47:04.0000] <TabAtkins>
No.


2020-01-08
[13:27:37.0000] <Domenic>
Ooh, progress on cookie parsing interop https://github.com/httpwg/http-extensions/issues/159


2020-01-09
[00:45:27.0000] <mathiasbynens>
annevk: is it fair to say Mozilla is supportive of `timezonechange` (https://github.com/whatwg/html/pull/3047)?

[00:45:43.0000] <mathiasbynens>
(your helpful involvement in the thread implies support, but I don't see it explicitly articulated anywhere)

[00:49:24.0000] <annevk>
mathiasbynens: we definitely were at some point, but I'd have to double check

[00:51:12.0000] <mathiasbynens>
annevk: i'm asking for the "intent to prototype" blink-dev thread, fwiw

[00:51:17.0000] <mathiasbynens>
https://groups.google.com/a/chromium.org/d/msg/blink-dev/4BUSE2aTQEc/bNQv4jyTCQAJ

[00:52:18.0000] <lilltiger>
just drop timezones all-toghter.. just causes issues

[00:52:42.0000] <annevk>
mathiasbynens: the answer right now is unknown, I've asked some folks, and you could also ask on https://github.com/mozilla/standards-positions though prolly a bit heavyweight

[00:53:24.0000] <annevk>
lilltiger: yeah, mathiasbynens, why not add Swatch Internet Time to JavaScript instead?

[00:53:54.0000] <mathiasbynens>
setTimeout(fn, 42beats);

[00:55:43.0000] <lilltiger>
annevk: I had never heard of SIT, but yes, something like that, not sure of 1000 is a good number to use, but makes a lot more sense then timezones

[00:56:23.0000] <lilltiger>
I would be happy to just scrap all timezones and keep 24h/days, but might be some better way

[00:56:35.0000] <mathiasbynens>
annevk: thanks, I've filed https://github.com/mozilla/standards-positions/issues/241

[00:58:01.0000] <annevk>
As a European living in Europe it'd be quite easy to adjust to a world without timezones, but not sure the remainder of the world sees it that way

[00:58:21.0000] <annevk>
Maybe first we can get rid of daylight saving time and such

[01:00:48.0000] <lilltiger>
annevk: well I wouldent care if would adjust it to the day/night cyckle of china.. as long as I can say 13:45 and evryone all over the world would instatly know when that would be for them..

[04:16:01.0000] <MikeSmith>
annevk: what’s the deal with the DocumentEvent interface that was in DOM Level 2 Events?

[04:16:11.0000] <MikeSmith>
it was never implemented anywhere?

[04:16:25.0000] <MikeSmith>
https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-document

[04:17:05.0000] <annevk>
MikeSmith: old-style mixin

[04:17:12.0000] <MikeSmith>
ah

[04:17:17.0000] <annevk>
MikeSmith: these days we define createEvent() directly on Document

[04:17:32.0000] <MikeSmith>
yeah OK

[04:17:34.0000] <annevk>
(and I think it was implemented as such too)

[04:17:39.0000] <MikeSmith>
k

[04:17:44.0000] <MikeSmith>
old DOM specs are very confusing

[04:18:13.0000] <annevk>
Yeah, I'm glad we managed to replace them

[07:02:34.0000] <zcorpan>
annevk: in https://github.com/web-platform-tests/wpt/issues/18354 "Framing URIs in non-"allow-same-origin" frames."

[07:03:01.0000] <zcorpan>
annevk: does that mean like coop-sandbox.https.html but without allow-same-origin?

[07:05:06.0000] <annevk>
zcorpan: I suspect so


2020-01-10
[18:30:14.0000] <MikeSmith>
still not poossible to build Firefox on macOS 10.15?

[19:10:39.0000] <MikeSmith>
https://w3c.github.io/media-playback-quality/#dom-videoplaybackquality-corruptedvideoframes doesn’t seems like a good way to indicate something is deprecated

[19:10:50.0000] <MikeSmith>
> [DEPRECATED] The corruptedVideoFrames attribute MUST return the total number of corrupted frames that have been detected.

[19:11:32.0000] <MikeSmith>
specifically, marked as [DEPRECATED] but still has language with a normative MUST

[19:13:06.0000] <MikeSmith>
hmm OK now I see https://github.com/w3c/media-playback-quality/pull/21

[19:13:28.0000] <MikeSmith>
> This is reverts the full removal of corruptedVideoframes (#20) in favor of a softer deprecation.

[02:59:56.0000] <zcorpan>
annevk: the coep sandbox.https.html test is a bit confusing

[03:01:43.0000] <annevk>
zcorpan: what part?

[03:02:36.0000] <zcorpan>
annevk: I think it'd be clearer if record() stored "accepted" if the promise was accepted, and "rejected" if it was rejected, and then the asserts check those values

[03:04:00.0000] <annevk>
zcorpan: maybe, though I think there's a possibility of combining this code with some other code that does a similar thing so maybe that could be done together

[03:04:34.0000] <annevk>
zcorpan: that is, ideally it uses resources/script-factory.js I think

[03:06:00.0000] <zcorpan>
annevk: aha, that uses this pattern as well. hmm. I guess I'll file an issue to discuss this

[03:34:35.0000] <zcorpan>
filed https://github.com/web-platform-tests/wpt/issues/21129

[06:07:17.0000] <annevk>
zcorpan: see https://github.com/whatwg/html/issues/4921 in particular for the remaining CSP comment

[06:07:47.0000] <annevk>
zcorpan: will you file a Firefox bug on the CORP thing?

[09:04:40.0000] <Domenic>
I'm quite surprised with the direction in https://lists.w3.org/Archives/Public/public-webappsec/2020Jan/0004.html . Personally I find all these webappssec and webperfwg specs that fetch calls out to to be really hard to follow and keep track of, and keeping them maintained in fetch would have been way nicer.

[09:14:08.0000] <bathos>
https://invented-adapter.glitch.me/ <-- anybody know which if either of these is correct? or if it’s specified? (SVGScriptElement type=module)

[09:23:13.0000] <Domenic>
Chrome looks "correct" but I imagine the spec for SVG is not updated to handle modules yet so it's possible Firefox is correct-per-spec.

[09:24:06.0000] <Domenic>
https://svgwg.org/svg2-draft/interact.html#ScriptElement so I guess it depends on how you interpret "A ‘script’ element is equivalent to the ‘script’ element in HTML"


2020-01-11
[19:45:41.0000] <domfarolino>
Strong agreement regarding consolidation of the above web* specs to Fetch

[22:44:47.0000] <annevk>
Do weigh in in the thread

[09:25:27.0000] <SimonSapin>
ISO-8859-1 (the one that maps to U+0000...U+00FF, not windows-1252) is not available in Encoding, is it?


2020-01-12
[21:31:36.0000] <Domenic>
SimonSapin: no. In specs it's called isomorphic encode/decode.

[21:31:56.0000] <Domenic>
Fun fact, the actual ISO standard does not have mappings for 0xF0-0xFF

[21:33:15.0000] <Domenic>
Er, I meant to say that it doesn't have mappings for 0x8F-0xFF. But also I might be misremembering, based on Wikipedia at least.

[21:33:37.0000] <Domenic>
argh 0x80-0xFF. The second half.

[21:34:04.0000] <Domenic>
Also I'm just wrong, that makes no sense, then it would be ASCII. Please ignore me, I am walking away from the computer now.

[23:38:53.0000] <SimonSapin>
Domenic: I assume you mean 0x80-0x9F

[23:39:03.0000] <SimonSapin>
Wikipedia says "ISO-8859-1 is the IANA preferred name for this standard when supplemented with the C0 and C1 control codes from ISO/IEC 6429"

[23:40:55.0000] <SimonSapin>
Anyway, the context was smuggling arbitrary bytes in application/x-www-form-urlencoded

[23:40:57.0000] <SimonSapin>
 name/values pairs because Bittorrent

[23:40:59.0000] <SimonSapin>
https://github.com/servo/rust-url/issues/578


2020-01-13
[20:09:19.0000] <bathos>
Am I correct to understand that the restrictions on the text content of src-having script elements described here are a well-formedness sort of thing which doesn’t impact how script elements are handled? https://html.spec.whatwg.org/multipage/scripting.html#inline-documentation-for-external-scripts

[20:11:19.0000] <gsnedders>
bathos: no impact on how they're handled

[20:11:31.0000] <bathos>
thanks

[20:11:45.0000] <gsnedders>
bathos: IIRC, some old UA ran the content if the src failed to load

[20:11:56.0000] <gsnedders>
But honestly it's years ago and I don't really remember :)

[20:12:00.0000] <bathos>
(also thanks Domenic re: the previous question I had about SVGScriptElement)

[20:15:15.0000] <bathos>
gsnedders that makes sense. I started wondering about it in part because the pattern there doesn’t permit arbitrary whitespace, as the last character is required to be '\n', and I was sure I’d at some point written [[INDENT HERE]]<script src=...>\n[[INDENT HERE]]</script> before, which apparent isn’t legal.

[20:15:36.0000] <bathos>
apparently*

[20:17:08.0000] <gsnedders>
bathos: it's also entirely possible the spec is nonsense :)

[21:57:30.0000] <annevk>
bathos: I’d file a bug, that req is bogus

[08:41:23.0000] <Domenic>
I'm watching the COOP/COEP tests fly by and kudos to all involved. It's impressive that we're getting all the tricky cases tested this time around on a new feature. Namely about:blank/data: URLs/blob: URLs.

[08:50:19.0000] <annevk>
Thanks, they're surprisingly time consuming

[08:50:36.0000] <annevk>
I guess in part since we never really fully tackled them

[15:43:00.0000] <MikeSmith>
TabAtkins: about the "Fixup!" thing in git commit messages, it’s the result of running git from the command line with `git commit --fixup=SOME_HASH`

[15:43:21.0000] <TabAtkins>
ah kk, hm

[15:44:27.0000] <MikeSmith>
yeah, the intent is that later, when the changes are ready to be merged, you can just do `git rebase --autosquash` and they’ll all be squashed back into that SOME_HASH change

[15:44:54.0000] <MikeSmith>
but anyway it’s just a laziness/convenience things

[15:44:57.0000] <MikeSmith>
*thing

[15:55:42.0000] <TabAtkins>
Ah, wasn't aware of that feature. that's fine then.

[15:55:56.0000] <TabAtkins>
I just can't tell what you're actually doing in each. ^_^

[15:57:39.0000] <MikeSmith>
TabAtkins: yeah, after you mentioned it, I’ve since been instead writing and including real commit messages


2020-01-14
[16:08:18.0000] <MikeSmith>
Domenic: does wattsi actually do syntax-highlighting for ABNF blocks as expected?

[16:10:04.0000] <MikeSmith>
nm

[16:10:12.0000] <MikeSmith>
looking at https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address, I see that it does

[16:25:35.0000] <TabAtkins>
heck yeah pygments

[16:26:58.0000] <MikeSmith>
:)

[16:28:09.0000] <MikeSmith>
now I’m struggling to remember how the Free Pascal HTTP client code in wattsi actually works..

[17:14:21.0000] <MikeSmith>
TabAtkins: as far as I can tell, invalid WebIDL does not seem to cause the highlighter server to respond with a 400

[17:16:08.0000] <MikeSmith>
testing with some invalid WebIDL, it does as expected emit an error message:

[17:16:23.0000] <MikeSmith>
> IDL SYNTAX ERROR LINE: 4 - skipped: "readonly attribute unsiggned long length"

[17:16:51.0000] <MikeSmith>
but the HTTP response code is still 200

[17:17:17.0000] <MikeSmith>
(this is after pulling the latest highlighter code, with the response-code change)

[17:19:02.0000] <MikeSmith>
does the syntaxError function in highlighter/widlparser/widlparser/tokenizer.py actually cause an exception to be thrown? or does it just report an error?

[00:55:09.0000] <andreubotella>
Hi

[00:55:19.0000] <andreubotella>
I just raised my first issue for the encoding standard and I'd like to work on the PR

[00:55:24.0000] <andreubotella>
but I have a couple questions about the contributor agreement

[01:55:52.0000] <annevk>
TabAtkins: oh my, I need to write another bikeshed PR as the <img> does not have a width and height

[01:56:41.0000] <annevk>
TabAtkins: though maybe the gigantic notice at https://whatpr.org/infra/115.html#tracking-vector is what the web needs... hmm

[02:05:31.0000] <Ms2ger>
Fwiw, I'll be taking the rest of the month off

[02:06:06.0000] <annevk>
Ms2ger: enjoy / take care

[07:30:06.0000] <TabAtkins>
annevk: put a width/height on the svg file?

[07:31:21.0000] <annevk>
TabAtkins: bad for various reasons, no?

[07:31:43.0000] <TabAtkins>
No

[07:31:50.0000] <annevk>
Progressive rendering?

[07:32:01.0000] <annevk>
Also what if it was not SVG?

[07:32:45.0000] <TabAtkins>
It's completely fine, doesn't make it less flexible. The paining is assumed to be abspos, so the sizing doesn't affect layout. If it's not svg I expect the image to be sized correctly in the first place too

[07:33:08.0000] <annevk>
Why not 2x or 3x?

[07:33:22.0000] <annevk>
This seems like a weird thing to object to

[07:33:34.0000] <annevk>
And we might not want abspos forever

[07:33:57.0000] <TabAtkins>
If it's 2x it should be in srcset not "big src, force it small"

[07:34:23.0000] <TabAtkins>
(which I'm happy to adjust for fwiw)

[07:35:42.0000] <TabAtkins>
If you ever don't want it abspos I'm happy to discuss new features to make it work better at that point, but all the renderings over seen so far are abspos.

[07:38:32.0000] <annevk>
TabAtkins: I don't see what the big deal is with adding width/height

[07:39:03.0000] <TabAtkins>
More controls piling into the feature without a current need.

[07:39:07.0000] <annevk>
TabAtkins: it'd be rather inconsistent for WHATWG to have an SVG with intrinsic width/height

[07:39:30.0000] <TabAtkins>
I don't understand.

[07:39:45.0000] <annevk>
TabAtkins: can we then just switch to have a single WHATWG toggle?

[07:39:53.0000] <annevk>
TabAtkins: and the default is the inline SVG?

[07:40:01.0000] <TabAtkins>
There's nothing wrong with an svg having a width/height.

[07:40:04.0000] <annevk>
TabAtkins: because isn't that all that's been requested so far?

[07:40:11.0000] <annevk>
TabAtkins: there's also nothing wrong with an SVG without that

[07:40:24.0000] <TabAtkins>
Except for default sizing, sure.

[07:40:33.0000] <annevk>
which we don't want for our images

[07:40:43.0000] <annevk>
see https://resources.whatwg.org/

[07:43:54.0000] <TabAtkins>
So stepping back a second, you're requesting a way to specify the size of your img. That's reasonable. There are two ways to do this - specify width/height on the <svg>, or on the <img> pointing to the SVG. On the img requires more work from me (impl, test, docs, future people having to read the docs and consider if they need to do something with that metadata), the other requires five seconds from you.

[07:44:04.0000] <TabAtkins>
They're otherwise identical in behavior given current styling.

[07:44:19.0000] <TabAtkins>
I don't understand the pushback, then.

[07:45:15.0000] <TabAtkins>
(I think it's actually considered a best practice to put a width/height on an svg, precisely to avoid this kind of "omg it's so big" sizing problem. It has no effect on the scalability of the svg, after all.)

[07:45:32.0000] <annevk>
TabAtkins: I supplied the PR

[07:45:43.0000] <annevk>
TabAtkins: I can also write a PR that reduces the amount of metadata as suggested above

[07:47:44.0000] <annevk>
And again, all I'm trying to ensure is consistency with our established practice of doing images

[07:48:20.0000] <annevk>
Having to revisit that because of tooling limitations that are easily addressed (there's a working patch) seems very strange

[07:50:00.0000] <annevk>
TabAtkins: I'll also volunteer to document the other Tracking Vector metadata thingies, if that helps at all

[07:50:10.0000] <annevk>
(from a simple grep they don't seem to be documented at least)

[07:51:56.0000] <TabAtkins>
Overall it's not a big deal, it's just that putting width/height on the svg itself is an easier, better idea most of the time anyway.

[07:52:45.0000] <annevk>
I'd love to understand why that's better than putting it on <img> directly

[07:52:50.0000] <annevk>
Seems to be that in general the opposite is true

[07:55:05.0000] <TabAtkins>
Viewing the image directly shows it at intended size (not fullscreen); it gives the <img> intrinsic dimensions; it means casual reference of it in an <img> won't break your layout until you remember to re-add width/height; it means (very slightly) less bytes sent to the user if you use the image more than once ^_^

[07:55:30.0000] <TabAtkins>
Unrelated: OMG i can't figure out which keyboard layout i used to use, this current one is fucking KILLING ME with its dead keys

[07:56:53.0000] <annevk>
I guess we disagree on good/bad for some of these and I wonder if compression doesn't solve the last one

[07:57:12.0000] <TabAtkins>
Thus the "very slightly", yes ^_^

[08:02:54.0000] <TabAtkins>
annevk: Related, aren't y'all using the exact same SVG that I'm inserting by default? Why customize it?

[08:04:15.0000] <TabAtkins>
(I used that specific SVG *because* it was the one suggested by zcorpan for WHATWG's use.)

[08:06:09.0000] <annevk>
TabAtkins: that came up in the original issue somewhere iirc, we don't want inlined SVG

[08:06:20.0000] <TabAtkins>
Oh, I must have missed that.

[08:09:42.0000] <TabAtkins>
Hm, that thread was in infra, right?

[08:10:09.0000] <annevk>
Maybe?

[08:10:48.0000] <annevk>
TabAtkins: https://github.com/whatwg/infra/issues/20#issuecomment-289709903

[08:11:17.0000] <TabAtkins>
Ah, caching, right.

[08:53:13.0000] <annevk>
TabAtkins: anyway, it'd be great if we could agree on a way forward; would adding documentation help? Would you prefer a simple switch that has inline by default and otherwise enables a WHATWG mode? Or perhaps we could have a one line setting where we include the HTML to be inserted literally? Spitballing here...

[08:53:50.0000] <TabAtkins>
Yeah I'm just gonna accept it later today

[08:57:28.0000] <TabAtkins>
screenshot showing the tracking vector image overlapping the text on a narrow phone screen https://usercontent.irccloud-cdn.com/file/EplnfaoQ/Screenshot_20200114-073026.png

[08:58:05.0000] <TabAtkins>
This convinced me that we will want to have it inline sometimes, and so <img width height> is desirable

[08:58:27.0000] <annevk>
That's probably a better idea than what we are trying to do today

[08:58:35.0000] <annevk>
(making the image smaller)

[08:58:58.0000] <annevk>
/me files an issue

[09:03:39.0000] <TabAtkins>
Since it is before the text, a `float: right` should do the job quite nicely.

[13:54:02.0000] <tejr>
Can anyone tell me if it would be appropriate to ask for advice on good semantic markup practices in here, if I'm unsure about something even having read the spec?

[13:54:21.0000] <tejr>
(Well, what I think are the relevant parts of the spec, anyway...)

[14:01:02.0000] <TabAtkins>
yeah this place is fine to ask that sort of question

[14:49:03.0000] <tejr>
OK.  I note that WHATWG's specification for <cite> seems to differ from the W3C one I was used to, in that it says e.g. an author's name should not be part of the citation.

[14:49:29.0000] <tejr>
Is there a recommended pattern of markup for a full citation of a work--author, title, edition, year of publication, ISBN number...?  Have I missed it in the spec's recommendations?

[14:50:14.0000] <tejr>
My markup works fine and I'm happy enough with it; I am simply curious to know if there is a typical pattern for semantic markup for this

[14:52:30.0000] <tejr>
Here is what I'm doing: http://ix.io/27qw/html

[15:12:11.0000] <a-ja>
tejr, i think intent is to cite a work rather than its author

[15:18:06.0000] <a-ja>
have a look at https://schema.org/citation and https://schema.org/CreativeWork

[15:42:11.0000] <tejr>
Thank you

[15:51:25.0000] <tejr>
a-ja: On reading this, it's exactly what I needed, and something very useful to learn in general; thanks very much

[15:53:57.0000] <a-ja>
no prob, also do a search on "citation styles"...not that they're any help with markup

[15:54:25.0000] <tejr>
Yeah, I'm aware of those, I thought I was following one correctly there--I'll double-check that, too


2020-01-15
[17:20:08.0000] <Domenic>
An important question to ask is "who is consuming this markup". Are you trying to make it easier to read if someone is editing it in a text editor? <span class="author"> or <span data-author> seem reasonable. Are you trying to style it? Same thing. Are you trying to make it easy to consume by other parts of your code (e.g. JS)? Same thing. Are you trying to make it more accessible? This isn't applicable; no accessibility

[17:20:08.0000] <Domenic>
technology distinguishes between authors, titles, editions, years of publication, or ISBN numbers vs. any other run of text.

[17:20:48.0000] <Domenic>
The case where you need specific standardized markup patterns here would be if you want other software, which you don't write or control, to be able to scrape your page and extract this data. In those cases schema.org is used by at least some of that software, so it might be a good fit for you.

[17:22:07.0000] <tejr>
Thanks Domenic, food for thought

[17:29:10.0000] <a-ja>
oh yeah, forgot earlier work: http://microformats.org/wiki/citation and http://microformats.org/wiki/h-cite

[17:30:02.0000] <a-ja>
/me thanks Domenic for the additional context

[06:28:07.0000] <annevk>
So I look into some Referrer Policy stuff to see how it dealt with inheritance and the tests are just broken? E.g., referrer-policy/generic/inheritance/iframe-inheritance-data.html

[06:38:33.0000] <jgraham>
Which kind of broken? Not working at all or wrong in what they test?

[06:38:46.0000] <jgraham>
mkwst might know more about those tests

[06:39:11.0000] <annevk>
jgraham: not really working

[06:40:16.0000] <annevk>
And I can fix all these things, but I kinda feel tired from having to clean up all the mess and not being able to do my own things because of that

[06:42:28.0000] <jgraham>
YEah, I understand :/

[06:42:43.0000] <jgraham>
jochen⊙co seems to have written that test

[06:42:57.0000] <jgraham>
Came from a Chromium import

[06:51:11.0000] <jgraham>
(and also fails in Chrome, which is surprising)

[07:56:05.0000] <annevk>
jochen__: ^ if you have time

[12:39:07.0000] <ondras>
hm, I *think* I found a firefox bug - or perhaps the behavior is correct?

[12:39:11.0000] <ondras>
https://jsfiddle.net/8fq26dLa/1/

[12:39:28.0000] <ondras>
it only happens with touch

[12:39:47.0000] <ondras>
in Firefox, there is no "pointerup" fired when the button is touched (up+down)

[12:40:01.0000] <ondras>
probably because the button gets removed during the pointerdown handler


2020-01-16
[00:08:18.0000] <mkwst>
annevk: https://chromium-review.googlesource.com/c/chromium/src/+/2003311.

[00:19:49.0000] <annevk>
mkwst: thanks, makes sense it was something like that

[00:21:23.0000] <annevk>
Still gotta write some javascript: URL tests to confirm how inheritance works I guess

[00:22:52.0000] <mkwst>
Yeah, sorry for the mixup. We try to be good about maintaining tests, but this was clearly our fault.

[00:23:33.0000] <mkwst>
Hopefully `javascript:` will be the same as `about:srcdoc`, which is tested.

[00:37:22.0000] <annevk>
mkwst: javascript: has a source and a target, so there are different scenarios there

[00:37:58.0000] <annevk>
and I thought the hope is that it reuses target's stuff somehow?

[00:38:02.0000] <annevk>
anyway, gotta test

[02:03:46.0000] <yhirano>
annevk: is the client for a top-level navigation request set? Is it set to the previous document?

[02:08:32.0000] <annevk>
yhirano: I don't think it should be set if the user enters the address

[02:08:40.0000] <annevk>
yhirano: but none of that is well defined at the moment

[02:09:07.0000] <yhirano>
how about the case where the user clicks a link?

[02:31:16.0000] <annevk>
yhirano: in that case you need a client for referrer computation

[02:46:33.0000] <yhirano>
annevk: thank you

[05:15:41.0000] <annevk>
TabAtkins: https://github.com/tabatkins/bikeshed/pull/1587

[06:36:30.0000] <mathiasbynens>
in which hsivonen beautifully describes 3 distinct scenarios in which Firefox reloads due to late or missing <meta charset>: https://github.com/GoogleChrome/lighthouse/issues/10023#issuecomment-575129051

[08:21:54.0000] <botie>
bkardell, at 2019-06-19 04:15 UTC, MikeSmith said: congrats on joining Igalia

[10:52:15.0000] <Bakkot>
is there a way to ping people re: https://github.com/whatwg/html/issues/5102 short of just bumping the issue? @mkwst maybe? I'm trying to update Salvation (a library for working with CSPs) and stuff like this issue is making it hard to know what the right behavior to implement is.

[10:55:28.0000] <Bakkot>
(also is there a good channel for discussion of CSPs in general?)

[11:33:15.0000] <Domenic>
Bakkot: I think you've done all the pinging I could think of, except maybe emailing public-webappsec⊙wo?

[11:33:42.0000] <Domenic>
What we ideally would get here is Safari/Chrome/Firefox's opinion how strongly each feels about their current behavior. Absent any such signals, we should update the spec to match the majority.

[11:50:21.0000] <Bakkot>
neat, thanks Domenic.

[12:17:26.0000] <bathos>
Regarding "Other specifications can also define body-ok keywords." in https://html.spec.whatwg.org/multipage/links.html#linkTypes, is there an authoritative list of these externally defined tokens or a way to search for them? One I know of is "manifest" (https://w3c.github.io/manifest/#linking) but I’m unsure if there are others.

[12:25:06.0000] <annevk>
bathos: no, and these days I suspect we’d favor inlining it all, if any are defined externally

[12:30:00.0000] <bathos>
yeah, extension points are tricky unless they involve a very search-friendly term (e.g. imo that’s why stuff like "HostEnsureCanCompileStrings" works okay — it’s unambiguous what you’re looking for). I was able to find this at least: https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/html/semantics/rellist-feature-detection.html#9-15

[12:31:13.0000] <bathos>
so at least in moz, the only acknowledged tokens not appearing in HTML appear to be "manifest", "apple-touch-icon", and "apple-touch-icon-precomposed"

[12:31:46.0000] <bathos>
oh and "bookmark", which is in HTML but disallowed on <link>

[12:35:46.0000] <TabAtkins>
annevk: Thanks, I'd missed your comment that deps had landed.

[13:16:38.0000] <MikeSmith>
Bakkot: yeah I’d also like to see that issue get resolved


2020-01-17
[23:34:27.0000] <jochen__>
annevk: Hiroshige is refactoring those tests. Maybe they're temporarily broken or smth?

[23:47:58.0000] <mkwst>
jochen__: Yes. This test was broken by that refactoring. It's less broken now. :()

[23:48:08.0000] <mkwst>
Bakkot: I put it on my list for this morning.

[02:04:07.0000] <ondras>
@JakeA: figured out that spamming twitter might not be the best way. Perhaps you can forward me to someone in particular to solve my Lighthous issue here on IRC?

[02:07:26.0000] <JakeA>
ondras: best plan would be to file an issue on the lighthouse repo with a reduced example

[02:07:53.0000] <JakeA>
ondras: please send it my way too, I'm curious 😀

[02:08:25.0000] <ondras>
JakeA: it is a very simple static web/app with one html, one css and one js

[02:08:27.0000] <ondras>
JakeA: https://ondras.github.io/rri/

[02:08:39.0000] <ondras>
not sure whether this would work as a "reduced" example though :/

[02:08:55.0000] <ondras>
just tried installing chrome-unstable (81), still reports the weird non-sw response

[02:09:49.0000] <JakeA>
ondras: it's best to remove everything that doesn't contribute to the bug. You might find it isn't a lighthouse bug while doing that

[02:10:27.0000] <ondras>
yeah.

[02:26:39.0000] <ondras>
JakeA: I *think* I can see why the problem happens. It seems that the "offline" Lighthouse simulation does not limit the SW from performing a fetch. So even when in Lighthouse/offline, my SW performs a fetch (its strategy is online-first), returns the fetched data and this is considered "not returned from a sw"

[02:41:34.0000] <ondras>
@JakeA: reduced, published, submitted: https://github.com/GoogleChrome/lighthouse/issues/10237

[02:53:10.0000] <JakeA>
ondras: this is an A+ reduction!  At a glance, yeah, it looks like Lighthouse is in the wrong

[02:58:29.0000] <ondras>
JakeA: thanks. Looks like people generally recommend returning a cached version, even with stale-while-revalidate...

[02:59:25.0000] <JakeA>
ondras: online-first is problematic, but it's better than online-only

[02:59:37.0000] <annevk>
So I change some srcdoc stuff with javascript in this referrer policy test and Firefox logs a different referrer and Chrome yields undefined

[02:59:42.0000] <annevk>
Good times

[03:00:03.0000] <JakeA>
ondras: if you've got a connection, but it's just hanging, it still leaves the user with a while screen until it times out

[03:00:18.0000] <ondras>
JakeA: should be solvable with a timeout

[03:00:51.0000] <JakeA>
ondras: that's a bit better, but it still means you have that timeout per request

[03:01:30.0000] <JakeA>
2 seconds for the html, then another 2 for the CSS and js, then another 2 for the data… even a short timeout can become a long delay

[03:04:58.0000] <ondras>
yes, the timeout would be a safety hatch, not a primary usage scenario

[12:57:44.0000] <smaug____>
Does some document explain mapping from ES spec language to things like microtasks

[13:00:42.0000] <smaug____>
Domenic: you might know

[13:01:20.0000] <Domenic>
smaug____: https://html.spec.whatwg.org/multipage/webappapis.html#enqueuejob(queuename,-job,-arguments)

[13:01:43.0000] <Domenic>
Or I guess https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-job-queue has a bit more background

[13:02:15.0000] <smaug____>
Domenic: ok, and how should one interpret https://tc39.es/proposal-weakrefs/#sec-clear-kept-objects

[13:02:31.0000] <smaug____>
"synchronous sequence of ECMAScript execution"

[13:03:00.0000] <Domenic>
No idea, seems like vague BS to me

[13:03:03.0000] <smaug____>
I couldn't find that kind of sentence in the es spec

[13:03:22.0000] <smaug____>
Domenic: ok, it felt like that to me too :)

[13:03:46.0000] <Domenic>
smaug____: ah it looks like https://github.com/whatwg/html/pull/4571/files is the actual intended integration

[13:05:06.0000] <Domenic>
smaug____: in particular https://whatpr.org/html/4571/webappapis.html#perform-a-microtask-checkpoint

[13:05:18.0000] <smaug____>
thanks

[13:31:50.0000] <andreubotella>
hey

[13:32:19.0000] <andreubotella>
the other day I opened my first bug on a standard, which turned out to be a good first issue, and I'd like to work on the PR

[13:32:44.0000] <andreubotella>
but I have a couple questions about the contributor agreement before I get started on it

[14:25:32.0000] <MikeSmith>
andreubotella: what are your questions

[14:26:07.0000] <andreubotella>
right

[14:27:04.0000] <andreubotella>
The agreement talks about getting your employer/client company to sign it if they work in "web technologies".

[14:27:21.0000] <andreubotella>
does that only mean browser developing, or does it extent to web dev too?

[14:28:48.0000] <MikeSmith>
andreubotella: it is unclear exactly what that term "web technologies" in the Participant Agreement means

[14:28:56.0000] <MikeSmith>
the agreement does not define the term

[14:29:13.0000] <andreubotella>
okay, so I guess I'll move to point 2 then.

[14:29:26.0000] <andreubotella>
I do web dev for a few clients, but I noticed and worked on this issue on my time.

[14:29:43.0000] <andreubotella>
I guess I don't need to have them sign, right?

[14:29:44.0000] <MikeSmith>
see https://github.com/whatwg/sg/issues/67

[14:31:03.0000] <MikeSmith>
if you are an independent developer working for clients, that "web technologies" requirement is not relevant

[14:31:41.0000] <MikeSmith>
your clients are not your employer, in the sense the agreement means

[14:31:56.0000] <MikeSmith>
you are your own employer

[14:33:06.0000] <andreubotella>
ok, I thought I understood it to refer to clients too

[14:33:13.0000] <MikeSmith>
no

[14:33:22.0000] <MikeSmith>
it doesn't, not to clients

[14:33:31.0000] <andreubotella>
ok

[14:33:34.0000] <andreubotella>
so that solves it

[14:33:35.0000] <andreubotella>
thanks so much

[14:33:40.0000] <MikeSmith>
cheers

[14:34:35.0000] <andreubotella>
is there any process to go about working on the issue, other than just saying I'm working on it in a comment and then linking to the bug in the pull request?

[14:35:31.0000] <MikeSmith>
just saying in a comment that are you working on it is fine

[14:35:40.0000] <MikeSmith>
but if you want, you can also ask the spec editor(s) to assign the issue to you

[14:35:42.0000] <andreubotella>
right

[14:35:55.0000] <andreubotella>
thanks so much

[14:35:59.0000] <MikeSmith>
no problem

[14:36:14.0000] <MikeSmith>
thanks for working on stuff

[14:36:23.0000] <andreubotella>
sure

[14:37:01.0000] <andreubotella>
I read a lot of web standards, and the ambiguity in terms between code points and scalar values in Encoding was bugging me

[14:37:09.0000] <andreubotella>
and then I noticed some security implications

[14:37:15.0000] <andreubotella>
so that's the least I could do

[14:38:00.0000] <MikeSmith>
ah cool


2020-01-21
[11:11:56.0000] <Domenic>
annevk: ping on https://github.com/whatwg/html/pull/4966

[12:17:10.0000] <annevk>
Thanks will look tomorrow

[12:17:31.0000] <annevk>
Bit behind on notifications


2020-01-22
[06:47:28.0000] <JakeA>
Does anyone know how `requestStorageAccess` works? As in, what happens to existing storage connections to things like idb and the cache API? Do storage events fire on localstorage as things change over?

[06:51:46.0000] <Domenic>
Let me just consult the spec for that... oh wait...

[06:53:07.0000] <JakeA>
indeed

[06:53:09.0000] <annevk>
JakeA: I have tried to get that moving, but that is not defined and at least I have not seen much coordination around it

[06:54:19.0000] <JakeA>
annevk: any idea what Firefox does? No worries if you don't know off the top of your head

[06:55:27.0000] <annevk>
JakeA: iirc there's "blocked", "third-party", and "first-party" as modes, I'm not sure you can migrate from "blocked"

[06:56:18.0000] <annevk>
JakeA: I think for localStorage you get new objects, but I haven't tested any of this in much detail as I was trying to get other people to work on it

[06:56:50.0000] <annevk>
I wouldn't take whatever we do as a requirement though

[06:57:54.0000] <JakeA>
annevk: Fair enough. I kinda wish `requestStorageAccess` returned a 'storage bucket' for the top-level origin. That'd solve the open-connections issue, but I guess it'd create lots of other problems.

[06:58:33.0000] <annevk>
JakeA: one thing I never really got clear in my head is what the threat model is during a transition

[06:58:52.0000] <annevk>
JakeA: it might be good to start there before figuring out API specifics

[06:59:16.0000] <JakeA>
True. Even in the current model you'll end up with a combination of data sources, even if some of them are just held in memory.

[06:59:24.0000] <annevk>
exactly

[07:53:34.0000] <hober>
JakeA annevk Domenic: sorry it's taken so long. we're going to spin up an issue tracker in the privacycg for it; it got pretty difficult to follow all the discussion in whatwg/html#3338. the output of that work will be an HTML PR.

[07:54:20.0000] <annevk>
hober: 🎉

[07:56:55.0000] <JakeA>
hober: Cheers! Does Safari treat a `window.open`'d  as third party, or is this fine since it's got the origin visible?

[07:58:38.0000] <hober>
JakeA: i don't know offhand

[07:58:53.0000] <JakeA>
No worries, I can give it a test

[09:08:17.0000] <littledan>
Domenic: It's great to see your work on origin policy. I'm wondering, is this hoped to enable ServiceWorker on first load eventually?

[09:09:00.0000] <Domenic>
littledan: I'm not aware of any such plans. We had Link: rel=serviceworker; at some point but unshipped that, so I assume the reasons for not pursuing service worker on first load are still valid.

[09:10:30.0000] <littledan>
Domenic: Do you have a good reference for this? I'm asking because I'm reviewing another proposal that adds a response header that points to a script that runs before any other script.

[09:10:50.0000] <littledan>
and I'm curious whether there are some similar problems/solutions. Maybe it's not problematic to ask for a script to run "first" in a response header?

[09:10:51.0000] <Domenic>
littledan: I don't, but JakeA might.

[09:11:19.0000] <annevk>
/me is reminded of https://en.wikipedia.org/wiki/Proxy_auto-config

[09:11:28.0000] <annevk>
(beware, that's terrible)

[09:12:28.0000] <annevk>
littledan: how is it different from starting your HTML document with that script?

[09:13:05.0000] <littledan>
(I thought it was terrible but they say no one else raised this concern)

[09:13:34.0000] <littledan>
annevk: The idea is that this can be added centrally more easily, based on how sites are deployed in practice

[09:15:14.0000] <Domenic>
I mean in general adding more means of script execution is a pretty big project, and I wouldn't advise people to take it on, but it keeps happening.

[09:15:42.0000] <annevk>
My comment was about PAC, I kinda like the idea of letting script run in response to a navigation, but not if the only aim is to make deployment easier

[09:16:40.0000] <littledan>
similar prototype systems showed that it was basically fatally impractical to try to get something to run first, it's claimed

[09:17:28.0000] <littledan>
this is for loading a security policy for the page

[09:20:53.0000] <littledan>
annevk: For what sorts of purposes do you think it'd be acceptable to let a script run in response to navigation?

[09:23:35.0000] <annevk>
littledan: mainly the case of being able to rely on a service worker being there

[09:24:31.0000] <annevk>
(which as Domenic pointed out has been tricky historically and probably still us due to the performance impact)

[09:29:16.0000] <littledan>
well, thanks for your help understanding this


2020-01-23
[23:39:18.0000] <JakeA>
littledan: we've always felt that putting a service worker install step ahead of navigation is something we want to avoid

[23:39:43.0000] <JakeA>
It could easily put a few 100k ahead of the first html response byte

[23:39:52.0000] <JakeA>
well, request byte

[02:37:57.0000] <littledan>
JakeA: Does this extend to running other kinds of setup scripts at the beginning of page load, as indicated by, e.g., a Response header?

[02:39:33.0000] <littledan>
JakeA: Is there a written explanation of this somewhere? Or would you maybe be available to get in touch with someone who does have a proposal of this type, with the motivation that putting in a response header is easier in practice to deploy than adding a prefix to the html (apparently, people get the ordering wrong in practice)

[02:40:47.0000] <littledan>
This is for https://github.com/privacycg/proposals/issues/3

[02:42:41.0000] <JakeA>
littledan: <script> is blocking by default, and it feels like it's been the source of web performance issues for decades since. https://github.com/WICG/import-maps#installation for instance recommends against external import-maps, but there are also lots of articles against blocking scripts, like http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/

[02:42:45.0000] <JakeA>
I'll take a look at the issue

[02:43:19.0000] <JakeA>
Part of the problem is we never really figured out how to make H/2 push work

[02:43:34.0000] <littledan>
:(

[02:43:37.0000] <littledan>
specifically I'm referring to Trust-Label-Script:

[02:43:59.0000] <littledan>
I was wondering if Origin Policy could help, since you then could move that fetch a bit earlier

[02:44:18.0000] <littledan>
there's also the possibility of some built-in policies. But it looks like Trusted Types started with this and then moved away from it.

[02:45:02.0000] <littledan>
it seems like this script would have to run before other scripts do, but it wouldn't have to block parsing the HTML document or fetching and parsing the scripts, just executing them

[02:46:02.0000] <JakeA>
When is the origin policy fetched?

[02:46:56.0000] <JakeA>
Ahh I see, it gets it if the response has a particular header

[02:51:09.0000] <JakeA>
littledan: I've just skim-read this, so I might be wrong, but it seems like this thing only impacts other script execution, right? That means the Trust-Label-Script would need to be executed before other script, but it doesn't need to block html & css rendering

[02:51:54.0000] <littledan>
JakeA: That's my understanding as well

[02:53:17.0000] <JakeA>
littledan: That seems less bad. It blocks the execution of script, but not the loading of script (you'd still be able to fetch a whole module graph right? That doesn't count as execution)

[02:54:25.0000] <littledan>
JakeA: Right, though I wonder if it might be a little more linearizing in current implementations, unless there's a big refactoring

[06:02:13.0000] <JakeA>
I've just seen a spec using https://heycam.github.io/webidl/#this rather than https://dom.spec.whatwg.org/#context-object. Are they equivalent? Should 'context object' be considered deprecated in specs?

[06:16:41.0000] <Domenic>
JakeA: yes and yes. It'd be nice if we could update DOM and kill context object...

[06:18:28.0000] <JakeA>
Domenic: mind if I make a PR to the DOM spec that replaces internal usage, and adds a note to the [=context object=] definition to suggest it's deprecated?

[06:18:50.0000] <Domenic>
JakeA: sounds great to me, although I'd kind of prefer removing the dfn entirely and then causing all the consumers to update.

[06:19:47.0000] <JakeA>
Domenic: I'll do that. I just figured that, given how much it's used, it might be 'cruel' to just get rid of it. I'll get rid of it and we can discuss in the PR

[06:20:00.0000] <Domenic>
Perfect, yeah

[06:20:20.0000] <Domenic>
Will be good to get annevk's opinion too, as DOM editor.

[06:21:49.0000] <annevk>
I'm supportive of moving away from it, I'm not sure how much downstream usage there still is though, would be good to find out before removing completely

[06:22:10.0000] <annevk>
I know some refactoring work I was doing in Encoding got blocked on an IDL style question that still isn't resolved

[06:22:39.0000] <JakeA>
It's used loads in service worker and background fetch, that much I know 😀

[06:25:31.0000] <TabAtkins>
I really need to dust off and finish the backref-tracking code...

[06:27:01.0000] <TabAtkins>
Oh weird, looks like the set of specs I'm relying on currently is "what's in Bikeshed's testsuite". I know that's not a super-informed choice, but I wonder if it is good enough.

[07:06:19.0000] <JakeA>
Another request to drop manual text wrapping from specs

[07:08:42.0000] <annevk>
Yeah, it's quite a drain on productivity, we really ought to automate it or change the rules

[07:08:45.0000] <TabAtkins>
Or switch to the Morally Correct semantic linewrapping.

[07:09:09.0000] <TabAtkins>
(i'm fine with either in the specs i edit, just so long as it's not an XXchar limit)

[07:09:22.0000] <annevk>
/me retreats 

[07:17:12.0000] <JakeA>
TabAtkins: Is there a way to mark a definition as deprecated, so bikeshed will warn if it's used but not fail?

[07:17:33.0000] <TabAtkins>
Hm, not really. You can mark it not exported, but that'll make it fail.

[07:17:43.0000] <TabAtkins>
That's definitely something I'd be happy to add tho.

[07:17:50.0000] <JakeA>
I'll file it

[07:17:55.0000] <TabAtkins>
danke

[12:02:21.0000] <eeeps>
annevk: if you could find some time to chat about https://github.com/whatwg/html/pull/5112#discussion_r370326608, clearly I... need help

[13:15:18.0000] <annevk>
eeeps: European office hours would be ideal


2020-01-24
[07:10:44.0000] <eeeps>
annevk: guten tag/abend

[07:13:14.0000] <eeeps>
re: https://github.com/whatwg/html/pull/5112#discussion_r370637869... if I go with a step 22 right after the fetch, should I "still wait until the result of fetch is either an error or response?", and queue a task? Like, could the current language just be copy and pasted?

[07:14:28.0000] <eeeps>
(the other place that it seemed like it might make sense to do this was not asap but just in time - right before the image presentation was updated, after the UA could determine the width/height of the image)

[07:14:53.0000] <eeeps>
Good to know that headers are available asap though (and that there's a response object to work with...)

[07:16:42.0000] <eeeps>
And re: the larger question, about this only working for <img> - yep, that's an issue. Would you consider that a blocker or is it still useful to extend the <img> loading mechanics in ways that can be abstracted along with the rest of it?

[08:22:13.0000] <annevk>
eeeps: after the fetch there's a step that says "when the networking task source queues a task do x" you can do your thing during x

[08:23:11.0000] <annevk>
eeeps: it's a preexisting issue, but we should maybe make it more visible if we end up doing this, e.g., by having a bit fat issue marker that says this algorithm is to be abstracted and reused by various other places, such as background-image, etc.

[08:31:59.0000] <eeeps>
annevk: and I should still "Wait until the result of fetching is either a response or an error?" IIUC the response comes back, and is then populated by data incrementally, by the networking task source...

[08:32:19.0000] <eeeps>
"comes back" = is returned by Fetch

[08:32:52.0000] <annevk>
eeeps: the moment you get a task you have a response

[08:33:02.0000] <annevk>
eeeps: and that response will have all the headers as that's atomic

[08:33:11.0000] <annevk>
eeeps: the response body is not atomic however and will stream in

[08:33:19.0000] <annevk>
eeeps: does that help?

[08:35:19.0000] <eeeps>
That helps a lot, I think it clears up my core confusion. I'll move the logic and make a big fat issue marker. Thank you!

[09:20:07.0000] <annevk>
JakeA: https://twitter.com/jaffathecake/status/1220642131758518272 was very confusing to me

[09:20:21.0000] <annevk>
JakeA: I was like, you click the link, it goes there, all is well, no?

[09:20:37.0000] <annevk>
JakeA: anyway, TIL not everyone uses tab

[09:22:47.0000] <JakeA>
annevk: I'm not really a tabber. In general I think I use computers like a 90 year old man who find tin foil "a bit too advanced"

[09:23:13.0000] <JakeA>
I should force myself to learn more shortcuts

[09:24:23.0000] <annevk>
JakeA: making GitHub useful for mouse users by shitposting is worth it though

[09:24:44.0000] <annevk>
but yeah, shortcuts are nice and I should update my knowledge of them

[09:25:42.0000] <annevk>
/me learned cmd+spacebar recently...

[09:28:24.0000] <JakeA>
annevk: is that a GitHub thing? I think I have that as a global Alfred hotkey

[13:06:56.0000] <annevk>
JakeA: macOS


2020-01-27
[17:18:58.0000] <domfarolino>
annevk: Finally rebased the lazyload PR and addressed your nit. I've responded to your latest comment as well; once we resolve that and once I file a follow-up issue, I think we might be finished after all.

[23:14:55.0000] <annevk>
domfarolino: sounds great!

[02:20:39.0000] <moshevds>
Hi all. I'm discussing a way for wasm-bindgen to allow Webassembly generated with that tool to allow registering event listeners in Service Workers. Because Service Workers require this registration to happen on first execution, it seems that WebAssembly.Instance is the only way to do this.

[02:21:52.0000] <moshevds>
However, a fear that WebAssembly.Instance might disappear has been raised. What is the best way (or community to ask) for me to get some assurances that there is no intention to remove support for running Webassembly before the window for registering listeners has passed? (By retaining WebAssembly.Instance at least until an alternative exists.)

[02:22:51.0000] <moshevds>
The issue where we have been discussing this is at: https://github.com/rustwasm/wasm-bindgen/issues/1976

[03:19:36.0000] <yhirano>
annevk: https://github.com/whatwg/html/issues/5223

[03:21:46.0000] <yhirano>
annevk: currently we're not revealing redirect location, are you concerned about the case where malicious developers uses SAB to extract such secret information through SPECTRE-like attacks?

[07:25:59.0000] <annevk>
yhirano: yes

[07:26:53.0000] <annevk>
yhirano: or secrets in other headers or the response body

[12:23:03.0000] <Domenic>
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.2 and surrounding sections is pretty fun... look at that deep integration with Fetch and HTML inside an IETF document.

[12:25:04.0000] <Domenic>
Eh except > The term "origin", the mechanism of deriving an origin from a URI, and the "the same" matching algorithm for origins are defined in [RFC6454].


2020-01-28
[21:00:49.0000] <yhirano>
annevk: In that case this problem is not specific to cross-origin, not specific to navigation and not specific to "manual" redirect mode.

[21:03:11.0000] <yhirano>
annevk: const res = fetch(url, {mode: 'same-origin', redirect: 'follow'})

[21:03:13.0000] <annevk>
yhirano: I'm not sure I follow, but yeah, maybe, really depends on how redirects work which may well vary across engines

[21:05:35.0000] <yhirano>
annevk: if the fetch is initiated on a COEP enabled environment and experienced redirects, having the redirect information in the dom process would be problematic from your POV, right?

[21:07:10.0000] <annevk>
yhirano: in general I'd consider it problematic, but yes

[21:37:52.0000] <yhirano>
annevk: thanks, I commented at the bug.

[23:03:25.0000] <annevk>
yhirano: somewhat surprised you handle redirects in that process

[23:04:15.0000] <annevk>
yhirano: we might have something similar atm though due to extensions and maybe CSP

[23:04:49.0000] <yhirano>
annevk: for subresources we do that (and that was why we could implement CORS in the renderer processes)

[23:05:44.0000] <annevk>
yhirano: you mean out of?

[23:09:06.0000] <yhirano>
annevk: redirect is partially handled in the network process, but the network process ask the renderer process if it would follow the redirect. The legacy CORS implementation lives in the renderer process and cancels the redirect if the CORS check fails. The new CORS implementation is implemented in the network process. Is that clear?

[23:16:42.0000] <annevk>
yhirano: yeah, thanks; I think that does mean that long term it's not that infeasible for redirects to be handled completely in the networking process

[23:17:01.0000] <annevk>
yhirano: and maybe that also means there's nothing much to do for COEP

[00:43:13.0000] <smaug____>
What is uncustomized in https://html.spec.whatwg.org/#upgrades about?

[00:43:18.0000] <smaug____>
I can't see that elsewhere in the spec

[01:45:11.0000] <MikeSmith>
smaug____: looks like Domenic added that a few weeks ago in https://github.com/whatwg/html/commit/2793ee4a461c6c39896395f1a45c269ea820c47e

[01:45:38.0000] <MikeSmith>
and background is at https://github.com/whatwg/html/pull/5126 and at https://github.com/whatwg/html/issues/5118

[02:05:30.0000] <mkwst>
annevk yhirano: Chromium currently does more checks in the renderer process than I think we want to do. It hasn't yet been worth the trouble to move, for example, CSP and MIX redirect checks out of the renderer and into the browser process. Ideally, we'd be verifying all of that the way that it's specified (e.g. the innards of Fetch => browser process).

[02:06:05.0000] <mkwst>
At the moment, we have been focusing on the bigger problems (e.g. CORS),  but I imagine we will get to the rest of the checks over time.

[02:06:32.0000] <mkwst>
As annevk notes, I don't think the COEP spec would need to change for us to do that.

[03:22:04.0000] <annevk>
mkwst: the main impact on COEP is whether people should be able to hold an opaque-redirect response

[03:22:33.0000] <annevk>
mkwst: for opaque responses we've made some adjustments to the cache API and such, but these don't directly apply to opaque-redirect responses as those can be same-origin as well

[03:22:59.0000] <annevk>
(I guess they do apply to cross-origin redirects at least, but that doesn't address all vectors)

[03:23:40.0000] <mkwst>
annevk: Do opaque-redirect responses come up anywhere other than navigation?

[03:24:12.0000] <annevk>
mkwst: you can get one via fetch()

[03:24:20.0000] <annevk>
mkwst: iirc

[03:24:30.0000] <annevk>
mkwst: and definitely with fetch() in a service worker

[03:24:45.0000] <mkwst>
annevk: Hrm. Maybe we could not do that instead of doing it?

[03:25:21.0000] <mkwst>
I thought that was just an internal bit of the navigation algorithm. It surprises me a little that we expose it via `fetch()`.

[03:25:35.0000] <annevk>
mkwst: well, we need to support navigation from service workers

[03:25:46.0000] <annevk>
mkwst: including their redirect handling

[03:26:43.0000] <annevk>
mkwst: I'm less clear on the remainder

[03:28:38.0000] <mkwst>
annevk: Yes. It makes sense that it could be visible to SW, I just didn't think about it that way. In my head we gave the SW a crack at the initial request, and somehow magically jumped back to the HTML algorithm for the rest.

[03:29:01.0000] <yhirano>
annevk: I'm still not sure what part of the problem is navigation specific (or, opaque-redirect specific).

[03:29:40.0000] <mkwst>
yhirano, annevk: Yeah, it doesn't initially seem to me that there's much difference between an opaque-redirect response and an opaque response more generally.

[03:49:01.0000] <annevk>
mkwst: yhirano: an opaque response is always cross-origin from you

[03:49:27.0000] <annevk>
mkwst: yhirano: an opaque-redirect response is not and therefore might not have CORP

[03:49:37.0000] <annevk>
mkwst: yhirano: does that help?

[03:51:33.0000] <yhirano>
annevk: mkwst: how about followed same-origin redirect?

[04:28:50.0000] <annevk>
yhirano: what do you mean?

[04:30:59.0000] <yhirano>
annevk: https://github.com/whatwg/html/issues/5223#issuecomment-579087618

[04:32:38.0000] <MikeSmith>
about the CSS Shepherd tool, does anybody know what the set of specs is that the indexes?

[04:33:01.0000] <annevk>
yhirano: that doesn't yield an opaque-redirect response though

[04:33:39.0000] <annevk>
yhirano: if it's followed it doesn't really matter as it doesn't have to be observable (assuming a better architecture will eventually be in place as per earlier comments)

[04:50:31.0000] <yhirano>
annevk: hmm... with that assumption forbidding redirect: 'manual' for non-navigation requests may help future implementers.

[04:56:43.0000] <annevk>
yhirano: yeah, or only inside COEP as a start (though it seems hard to restrict in that way)

[07:07:16.0000] <Domenic>
smaug____: https://dom.spec.whatwg.org/#concept-element-custom-element-state

[07:07:50.0000] <smaug____>
ah, DOM

[07:07:51.0000] <smaug____>
thanks


2020-01-29
[18:13:44.0000] <MikeSmith>
TabAtkins: do you know if it's intentional that Shepherd doesn't index the ECMAScript spec?

[18:14:13.0000] <TabAtkins>
Yes it is

[18:16:26.0000] <MikeSmith>
ah ok

[18:18:18.0000] <MikeSmith>
TabAtkins: what are the criteria for which set of specs Shepherd does index?

[18:18:36.0000] <TabAtkins>
I'd like to include them, but I need to more their dfn usage to see what types should be used, and have them mark themselves up appropriately.

[18:18:52.0000] <TabAtkins>
*more=model

[18:19:54.0000] <MikeSmith>
I see

[21:09:25.0000] <TimothyGu>
Domenic: I hate to mention this, but it really seems like the best option for both users and spec authors is to introduce a willful violation of JS that says that IsArray must return true for ObservableArrays. Is that route really an impossibility?

[21:10:11.0000] <Domenic>
TimothyGu: I think the best route is to just use a proxy. It solves some other issues too.

[21:11:43.0000] <TimothyGu>
It sounds like a lot of work just to spec it, and even with a proxy-based setup I feel like implementations would probably just approximate it by hacking IsArray…

[21:12:41.0000] <Domenic>
Spec's almost done. Happy to leave implementations to the implementers, but they'd also need to be sure that .constructor is Array, .__proto__ is Array.prototype, etc.


2020-01-30
[21:04:33.0000] <domfarolino>
annevk: Any chance you will get to checking out the lazy load PR by EOW?

[21:26:23.0000] <annevk>
domfarolino: we have an All Hands this week, but maybe


2020-01-31
[19:32:20.0000] <TimothyGu>
Has anyone used GitHub Actions to deploy Bikeshed-based specs? (Instead of Travis CI)

[19:32:45.0000] <TimothyGu>
TabAtkins maybe? ^^

[19:33:13.0000] <TimothyGu>
Asking as it looks like ReSpec has some unofficial GitHub Actions integration

[19:34:40.0000] <TabAtkins>
Dunno if anyone's done it yet, but I would be *very* interested in seeing one. Should def be possible.

[00:37:43.0000] <MikeSmith>
irc.mozilla.org seems to have just gone down?

[07:04:36.0000] <Domenic>
MikeSmith: I don't know if it was planned to shut down the server, but they at least planned to stop using it, so I wouldn't be surprised if it was down for good now...

[09:42:46.0000] <bkardell>
so, I'm putting together a pull to replace https://github.com/whatwg/html/pull/4893 - and I'm wondering if we should point the MathML reference to core instead of W3C MathML 3 which it is trying to resolve into an agreeable starting point?  The IDL there which actually _uses_ this renamed interface is what is shipping and observable

[09:48:35.0000] <Domenic>
bkardell: that seems good to me; my understanding is that MathML Core is closer to what's implemented in browsers than MathML 3

[09:48:50.0000] <Domenic>
It might make sense to do that update as a separate PR or as a separate commit in the same PR

[09:49:17.0000] <bkardell>
ok I will do 2 prs - should they be in any specific dependency order or something

[11:02:13.0000] <bkardell>
hmm... is that looked up in a registry or index Domenic ? I dont see it here somewhere

[11:02:30.0000] <Domenic>
What is "that"?

[11:10:16.0000] <bkardell>
Domenic: whoops, sorry on the PR- my bad... wow that was embarassing :-p

[11:10:27.0000] <Domenic>
No problems

[11:10:31.0000] <bkardell>
Domenic: "that" being the reference to MathML 3

[11:12:10.0000] <Domenic>
bkardell: Ctrl+Fing for "w3.org/Math" should find a lot of references

[11:34:32.0000] <bkardell>
Domenic: what do i have to do to sign up, I should be included as part of https://github.com/orgs/Igalia/people

[11:37:40.0000] <Domenic>
bkardell: https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/publicizing-or-hiding-organization-membership

[11:42:02.0000] <bkardell>
ha ok - updated

[12:02:17.0000] <bkardell>
ugh, I need to be more patient with the pulls, sorry  - my machine is being really laggy and I was trying to rush through it so I could reboot... re: tests Domenic - I'm not sure what you mean that it's not clear how they relate... the challenge I think is that the name of the interface itself is as you say not the important part since HTML leaves that to the other spec...

[12:02:26.0000] <bkardell>
brb going to reboot

[12:06:31.0000] <Domenic>
bkardell: those tests appear to have nothing to do with HTMLorSVGElement's properties? They are just testing other random parts of MathMLElement?

[12:11:30.0000] <bkardell>
ah I see what you mean - yeah, it's testing the MathMLElement which is enabled by it... so you just want me to not mention those others and then address your comments + the one test

[12:11:40.0000] <bkardell>
Domenic: do I have that right?

[12:14:35.0000] <bkardell>
maybe what I should have is just an entry like annevk's https://github.com/whatwg/html/commit/81e82437a7ef1ee37d4ce2b5a982bc297d5b58b1 and https://github.com/web-platform-tests/wpt/pull/10110/files?

[12:39:29.0000] <bkardell>
yeah ok I have to wade through all the tests and tweak this actually.. there are more in here that are probably better applicable even

[13:17:18.0000] <bkardell>
thanks for your help and patience here Domenic - I'm going to pick this back up on monday and just call it a day here - I can't seem to get my commit to work right with this trailing whitespace, or squash properly so I'm clearly not being productive here :)  Time for some rest.

[13:17:37.0000] <Domenic>
bkardell: no worries. Don't worry about the squashing; we can take care of that.

[13:18:23.0000] <Domenic>
bkardell: sorry about the tests, right, I mean I'm hoping the PR can list which tests test features of HTMLOrSVGElement, and not mention tests that don't.

[13:18:24.0000] <bkardell>
ok cool... I changed the tests links btw, idk if those are maybe more helpful but they are related to the idl more directly and your questions

[13:19:12.0000] <bkardell>
they are, I think, the ones rniwa mentioned on the other issue relating to normative changes shipping

[13:19:13.0000] <Domenic>
Yeah those new test links look great

[13:19:25.0000] <bkardell>
ok

[13:19:26.0000] <Domenic>
Just missing autofocus and nonce

[13:19:31.0000] <bkardell>
enjoy your weekend~

[13:19:48.0000] <bkardell>
thanks again