00:41
<MikeSmith>
TabAtkins: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)> when running bikeshed update
00:42
<MikeSmith>
any clues?
00:43
<MikeSmith>
this is after rebasing my mdn-annotations branch against current master, and fixing python2-isms to be python3-compatible
00:46
<TabAtkins>
Hm, i'll check
00:53
<MikeSmith>
TabAtkins: it seems to maybe be a macOS-specific problem
00:53
<MikeSmith>
I’m using the Apple-installed system Python3
00:54
<MikeSmith>
I guess I could try installing python3 from homebrew
00:54
<TabAtkins>
That would explain why I didn't run into it
00:55
<MikeSmith>
yeah
01:26
<MikeSmith>
url in Worker(url) constructor must be same-origin, but where the spec actually state that requirement?
01:27
<MikeSmith>
from https://html.spec.whatwg.org/multipage/workers.html#dom-worker it’s not clear there is a such a requirement
01:27
<MikeSmith>
just a non-normative note
01:27
<MikeSmith>
> Any same-origin URL (including blob: URLs) can be used. data: URLs can also be used, but they create a worker with an opaque origin.
01:29
<MikeSmith>
well there is the SecurityError in the first step, but that’s optional
02:01
<MikeSmith>
TabAtkins: with python3 installed from homebrew, I don’t get that SSL error
02:02
<MikeSmith>
so I think the Apple-installed Pthonall hope of getting responses to my questions there
02:02
<TabAtkins>
Interesting, okay
02:03
<MikeSmith>
(oofs, fat-fingered a copy/paste there; please ignore)
02:03
<MikeSmith>
to my questions there
02:03
<TabAtkins>
People always used to have problems with the system version if py2 on Mac too. Word but unsurprising, I guess
02:03
<MikeSmith>
(dang did it again)
02:04
<MikeSmith>
TabAtkins: yeah I think there is no system-installed Python3 on macOS, yet
02:04
<MikeSmith>
it is instead installed by XCode
02:04
<MikeSmith>
or maybe that was true for Python2 as well, I dunno
02:05
<MikeSmith>
and in general I think some XCode-installed stuff can break when you also install stuff from homebrew
02:11
<MikeSmith>
TabAtkins: OK, the SSL thing seems to be a known issue; I found https://stackoverflow.com/a/60334957/441757, which claims “Apple will not fix this, because Apple does not think this is a problem”
02:11
<MikeSmith>
see also https://github.com/HandBrake/HandBrake/issues/2216#issuecomment-527114519
02:13
<MikeSmith>
apparently whatever Apple person responded to it seemed be saying the solution is to not use urllib but instead use the requests library
02:13
<MikeSmith>
well, or else explicitly pass cafile to urllib
02:27
<MikeSmith>
TabAtkins: OK, it can be “fixed” by importing certifi and giving a cafile arg to all urllib.request.urlopen calls
02:27
<MikeSmith>
e.g., urllib.request.urlopen(ghPrefix + "manifest.txt", cafile=certifi.where())
02:28
<MikeSmith>
dunno whether it’s worth doing that or not, since in the case of XCode-installed Python3, that would require the user to pip install certifi, which I think they need root perms to do
02:29
<MikeSmith>
but I can make a patch/PR for it anyway
03:58
<Domenic>
MikeSmith: worker thing looks like a legit bug; may have gotten lost when I tried to allow cross-origin module workers and then annevk undid that. Please file; can fix tomorrow.
04:16
<MikeSmith>
Domenic: OK, will do — thanks
06:34
<annevk>
I don’t think it’s a bug, it’s supposed to fail during fetching and does
06:37
<annevk>
Bakkot: yeah I guess, it still seems really vague to me overall. I guess I’d prefer not doing anything or providing an explicit hook
07:11
<MikeSmith>
annevk: which spec states that it must fail? Fetch?
07:28
<annevk>
MikeSmith: yeah, fetch mode is "same-origin"
09:07
<annevk>
Domenic: https://github.com/whatwg/html/issues/3238#issuecomment-601383619 looks great. Curious though, why not an identifier? Tricky due to IDL's weird identifier rules?
09:35
<annevk>
Why is CSS Images 4 not a superset of 3?
09:43
<gsnedders>
annevk: I think all the work is happening in level 3, and level 4 is outdated?
09:44
<annevk>
gsnedders: not entirely, HTML depends on 4 for something
09:44
<annevk>
gsnedders: I was looking at https://github.com/whatwg/html/pull/5358 which made me wonder
09:45
<gsnedders>
¯\_(ツ)_/¯
10:11
<andreubotella>
"Outdated" here means that it doesn't yet incorporate all of images-3's changes, right?
10:12
<andreubotella>
not that it's deprecated or anything
10:12
<andreubotella>
because on a project for a client of mine I have a tracking bug for images-4 since we could really use object-fit: cover scale-down;
10:13
<gsnedders>
andreubotella: right, I think it still shows broad ideas for new features in l4, but how stable they are idk
10:14
<andreubotella>
right
10:14
<andreubotella>
thanks
12:13
<grvpanchal>
MikeSmith Framework iterate an array over div using either v-for, ng-for Array.map(). Can there be a rules for iterating on HTML. we have array type HTML elements like ul, ol, dl, table, tr. Something like only those would be used?
12:14
<grvpanchal>
MikeSmith Can there be new elements for grid layout?
12:23
<MikeSmith>
grvpanchal: I don’t know why you are asking me in particular
12:25
<grvpanchal>
I saw yor name in w3.org/html/wg/next/markup/
12:26
<MikeSmith>
aha
12:26
<MikeSmith>
that doc is very out of date
12:27
<grvpanchal>
ohh ok
12:27
<grvpanchal>
If I have to propose such changes How do I go along?
12:28
<MikeSmith>
grvpanchal: well these days if you have a problem that you’re hoping to solve, the place to post a description of the problem is https://github.com/whatwg/html/issues
12:28
<MikeSmith>
I don’t suggest you start by proposing specific changes
12:28
<annevk>
grvpanchal: prolly best to start at https://whatwg.org/faq#adding-new-features and https://whatwg.org/working-mode
12:29
<MikeSmith>
grvpanchal: yeah what annevk said — see step #1 at https://whatwg.org/faq#adding-new-features
12:29
<grvpanchal>
Thanks MikeSmith annevk
12:32
<grvpanchal>
I was thinking if there are three different implementation on grid layout i.e. float, display:flex and display:grid. Why not native grid elements that transcend through web component's shadow DOM?
12:33
<grvpanchal>
what do you guys think?
12:33
<MikeSmith>
TabAtkins could definitely give some insight on that
12:34
<annevk>
grvpanchal: it seems that would conflate separation of content and style
12:39
<grvpanchal>
annevk true I observed that css of user agent stylesheet (http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css) can transverse shadow DOM. Something similar could be great for grid elements
14:21
<Domenic>
annevk: a string seems to make a lot more sense as the actual value space we're working in, leaving identifiers for programming-language identifier things. Also, you need to solve http-equiv <-> httpEquiv, and I think [Reflect="http-equiv"] is nicer than [Reflect=http_equiv] with a rule that converts _ to -
14:23
<Domenic>
Hmm I guess I am wrong about - not being allowed
14:25
<Domenic>
Enumerated attributes are still really hard though
14:25
<annevk>
Domenic: because they are case-insensitive and not enums therefore?
14:26
<annevk>
Domenic: could we (ab)use an enum?
14:26
<Domenic>
Nah just hard to come up with a data model that expresses all the things that the spec does
14:26
<Domenic>
And yeah I think enums would be some component of it
14:26
<annevk>
Domenic: did you consider exposing hooks so the weird cases could be done in prose?
14:27
<annevk>
Domenic: e.g., the crossorigin funkiness
14:27
<Domenic>
Yeah, I mean, that could work
14:27
<Domenic>
Or [ReflectCORS]
14:28
<Domenic>
I think there are three tiers of them: simple 1:1 keyword:states, many:1 keywords:states (<area shape="">), and CORS settings attributes (one state has no keyword)
14:28
<Domenic>
(There are others in the second tier besides <area shape="">)
14:29
<Domenic>
Hmm maybe CORS isn't alone in being weird
14:29
<Domenic>
translate="" also has a no-keyword state
14:30
<Domenic>
I dunno, it's doable, not "hard", just a good deal harder.
14:31
<annevk>
One thing you could decide to not do is states
14:31
<annevk>
E.g., since <area shape> isn't limited to known values it doesn't really matter
14:32
<Domenic>
Yeah TimothyGu was suggesting that too
14:32
<Domenic>
I have a harder time with that since my mental picture of enumerated attributes intimately includes states. But I think you're right it could simplify things a good bit.
14:32
<annevk>
Because yeah, trying to fit a table structure in there doesn't seem great
14:33
<Domenic>
However from a code-generator point of view, if not a spec-writing point of view, you kind of want the attribute <-> state mapping to be generated automatically
14:33
<Domenic>
I guess it doesn't have to be done in IDL, but it sure would be convenient
14:33
<annevk>
Hmm, this week is clearly not the week I'm getting caught up on COOP/COEP, but I did some bits
14:34
<annevk>
I guess I'll have a go at updating tests at least for this deleted constructor idea
14:35
<annevk>
Domenic: we could still do most of that
14:35
<annevk>
Domenic: each enum value is a state, missing default is a state (unless it's an enum value) invalid default is a state (unless it's an enum value)
14:35
<annevk>
Domenic: and then in prose we switch on state and group states that are treated equivalent
14:37
<annevk>
Domenic: you'd have to refactor <area shape> (and potentially equivalent others); CORS requires some additional logic but perhaps most can be shared
14:40
<annevk>
Domenic: other alternative is to change https://heycam.github.io/webidl/#idl-record and go full on ordered maps 🙂
14:46
<Domenic>
Not quite sure how that'd work, but it's early yet :)
14:53
<annevk>
Ugh, hiding the constructor ends up affecting a lot of tests
15:06
<annevk>
HMM
15:06
<annevk>
new WebAssembly.Memory({ shared:true, initial:1, maximum:1 }).buffer.byteLength is?
15:06
<Domenic>
Didn't we decide there was no spec for that
15:07
<annevk>
65536
15:07
<annevk>
There kinda is and more importantly it does something in Chrome and Firefox
15:07
<Domenic>
O_O
15:10
<annevk>
Maybe it goes per 16 bits of bytes?
15:10
<annevk>
Seems like it
15:14
<annevk>
Domenic: not sure how curious you are, but there's https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#javascript-api-changes and https://github.com/WebAssembly/threads/blob/master/document/js-api/index.bs#L603 (and they're out-of-sync in that one says TypeError and the other RangeError; browsers do TypeError; I filed an issue on that)
15:15
<Domenic>
Ah OK, it's just the rendered version that you couldn't find
15:16
<annevk>
And yeah, the numbers are in 64KiB increments
15:18
<Domenic>
Not quite a full replacement for a SAB then, I suppose
15:18
<annevk>
Yeah, though I wasn't able to find Overview.md initially either and generally it's just super confusing how everything is organized there
15:19
<annevk>
Not really, unless you're willing to deal with largish buffers
15:51
<shu>
annevk: following up on your question yesterday about "what about deleting SAB from a subset of globals", i followed up internally and the feeling is "rather not"
15:52
<annevk>
shu: mkay, fixing tests seems less trivial in a number of cases than I had hoped
15:52
<shu>
annevk: also practically, i assume you saw the chrome release freeze? will affect COOP+COEP rollout on chrome's end
15:52
<annevk>
shu: e.g., Encoding tests rely on not having to set COOP/COEP and using the Wasm hack requires workarounds
15:53
<annevk>
shu: yeah
15:53
<shu>
annevk: wait, there are existing single-threaded tests that use SAB?
15:53
<annevk>
shu: yeah of course
15:53
<shu>
oh, like, for the pure purpose of testing if the API can work with SAB regardless of headers?
15:54
<annevk>
shu: yup or throws or whatever
15:54
<shu>
instead of changing the tests wouldn't it be easier to mock the headers in the test runner? is that possible?
15:54
<annevk>
shu: https://github.com/web-platform-tests/wpt/issues/22358 has a list of potentially affected tests (though html/ probably not so much if at all)
15:55
<annevk>
shu: not possible for .any.js tests
15:55
<annevk>
shu: and we'd also have to change them to force HTTPS in that case
15:55
<shu>
as an aside what does the .any. mean
15:56
<annevk>
shu: https://web-platform-tests.org/writing-tests/testharness.html#multi-global-tests
15:56
<shu>
ah
18:33
<annevk>
Domenic: btw, since most APIs take a view, the backing buffer being somewhat largish isn't a big deal, though ymmv
18:33
<Domenic>
Yeah that makes sense
22:38
<TabAtkins>
MikeSmith: Thanks so much for diagnosing it, I've added a note to the install instructions about it.
22:39
<TabAtkins>
I'm curious why you say using certifi would require the user to do something themselves and have sudo? I can just pick up more dependencies now, it's not a big deal.
22:39
<TabAtkins>
(Really, I guess I shoudl rewrite to use requests for more stuff; I'm already using it for some things.)