| 13:12 | <XhmikosR> | anyone around who has access to the https://validator.w3.org/ server? I've been getting Error 503 and timeouts for a few hours now |
| 13:17 | <XhmikosR> | /CC @MikeSmith when you are around :) |
| 13:19 | <annevk> | XhmikosR: I can reach it, FWIW |
| 13:19 | <XhmikosR> | annevk: can you post a few times successfully? |
| 13:20 | <XhmikosR> | I can also reach the site, but it fails when uploading a doc or making a POST request |
| 13:20 | <annevk> | XhmikosR: ah, I tried to validate whatwg.org |
| 13:21 | <XhmikosR> | maybe there's some kind of ongoing DDoS attack going on? |
| 13:21 | <annevk> | XhmikosR: uploading a test from wpt also works |
| 13:22 | <XhmikosR> | it seems it works now for me too, let me restart CI |
| 13:23 | <XhmikosR> | yup it seems it works now again |
| 13:23 | <XhmikosR> | minus a few cases https://github.com/MaxCDN/bootstrapcdn/pull/1457/checks?check_run_id=443612129 |
| 13:24 | <XhmikosR> | we have the issue on all other branches too so it doesn't seem to be related to an npm package, and I could also reproduce just a few minutes ago on the browser |
| 14:48 | <MikeSmith> | XhmikosR: here now |
| 14:48 | <XhmikosR> | MikeSmith: I'm still seeing the failures on CI :/ |
| 14:49 | <MikeSmith> | yeah will try to fix the server now |
| 14:49 | <XhmikosR> | thanks! |
| 14:57 | <MikeSmith> | XhmikosR: OK, should be back to normal now |
| 14:57 | <XhmikosR> | thank you! |
| 14:58 | <MikeSmith> | cheers |
| 15:53 | <smaug____> | https://html.spec.whatwg.org/#nonce-attributes |
| 15:53 | <smaug____> | trying to understand that |
| 15:53 | <smaug____> | "Elements that have a nonce content attribute" ... ok, some elements have nonce content attribute |
| 15:54 | <smaug____> | but somehow _that_ isn't exposed to CSS |
| 15:56 | <smaug____> | "extracting the value from the content attribute" means probably something |
| 15:56 | <smaug____> | but not sure what |
| 15:56 | <smaug____> | the value is extracted but is the content attribute still there? |
| 15:56 | <smaug____> | and if it is there, what is the value? |
| 15:56 | <smaug____> | annevk: do you happen to recall |
| 15:57 | <smaug____> | I'm probably missing some bits elsewhere in the spec |
| 15:58 | <smaug____> | oh, when element gets connected, then the value becomes empty string |
| 15:58 | <smaug____> | but when does the "extract" happen? |
| 16:03 | <annevk> | smaug____: seems prett clear if you read on |
| 16:04 | <annevk> | smaug____: normative requirements are further down |
| 16:04 | <smaug____> | annevk: I'm missing where the extract happens |
| 16:04 | <annevk> | > Whenever an element including HTMLOrSVGElement has its nonce attribute is set or changed, set this element's [[CryptographicNonce]] to the given value. |
| 16:04 | <smaug____> | right |
| 16:04 | <smaug____> | I understand that sets the slot |
| 16:04 | <smaug____> | but nothing says the content attribute isn't set too |
| 16:05 | <annevk> | smaug____: it is set |
| 16:05 | <smaug____> | oh |
| 16:05 | <smaug____> | but if I remove element from DOM and put it back, then value is "" |
| 16:05 | <annevk> | smaug____: so if you manipulate post tree connection you are leaking |
| 16:05 | <annevk> | Hai |
| 16:05 | <smaug____> | bizarre |
| 16:06 | <annevk> | Well, seems a tad better than hijacking setAttribute() entirely in novel ways |
| 16:07 | <smaug____> | so if parser sets the attribute, it gets cleared when element gets connected |
| 16:07 | <smaug____> | after that attribute changes aren't affected |
| 16:07 | <smaug____> | but slot gets updated |
| 16:08 | <smaug____> | and then when connecting again, attribute value is cleared |
| 16:08 | <annevk> | Sounds right |
| 16:08 | <smaug____> | super weird, but ok. Just trying to understand how one should implement this |
| 16:08 | <smaug____> | thanks |
| 16:09 | <annevk> | There should be tests for all of this |
| 16:09 | <annevk> | bz and I were involved in agreeing on these semantics iirc |
| 16:11 | <smaug____> | it might have been simpler to just always clear the nonce attribute |
| 16:12 | <annevk> | And somehow avoid a loop and create weird mutation records? |
| 16:13 | <smaug____> | hmm, which loop? |
| 16:14 | <smaug____> | MutationRecord has the old value, so it would just always have "" |
| 16:14 | <smaug____> | but anyhow, this is what it is now |
| 16:14 | <smaug____> | just a bit more difficult to implement |
| 16:23 | <annevk> | Set attribute invoking set attribute, spec doesn’t have a clear to change an attribute without side effects apart from direct manipulation |
| 16:24 | <annevk> | There’s also no real precedent for no-opping setAttribute() calls |
| 16:25 | <annevk> | But yeah, it is what it is 😊 |
| 16:25 | <smaug____> | was there precedent for changing attribute values when connecting an element to document? |
| 16:25 | <smaug____> | I guess all the options are weird |
| 16:26 | <annevk> | smaug____: <details> maybe? But yeah, weird too |
| 16:26 | <smaug____> | some kind of change to parser to set the slot, and not attribute |
| 16:26 | <smaug____> | but changing parser is scary |
| 16:27 | <annevk> | I think that ruled that out, but it’s been a while |