| 04:30 | <annevk> | oliverdunk: you won't get a response with type "cors" if the request didn't ask for CORS |
| 04:36 | <annevk> | MikeSmith: https://travis-ci.org/whatwg/encoding/builds/547664070 is still failing so we can't publish the RD for Encoding |
| 04:36 | <annevk> | MikeSmith: maybe it's taking to long? |
| 04:37 | <MikeSmith> | annevk: it takes ~8 minutes to run |
| 04:37 | <MikeSmith> | annevk: I just restarted it |
| 04:38 | <annevk> | MikeSmith: hmm yeah, given that it fails 10min in I guess it's not the time |
| 04:38 | <MikeSmith> | I see it timed out after 10 minutes |
| 04:38 | <annevk> | MikeSmith: I did a restart once already fwiw |
| 04:38 | <MikeSmith> | ah OK |
| 04:38 | <MikeSmith> | https://www.w3.org/2019/06/12-w3m-minutes.html#item05 |
| 04:39 | <MikeSmith> | Decision: Signing the Consortia letter to DoC |
| 04:39 | <MikeSmith> | https://lists.w3.org/Archives/Team/w3mreq/2019Jun/att-0053/01-part |
| 04:49 | <MikeSmith> | oofs |
| 04:49 | <MikeSmith> | sorrt |
| 07:12 | <MikeSmith> | annevk: so I can “fix” the Encoding build issue by making the checker emit that name of every filename it checks |
| 07:13 | <MikeSmith> | that way there will be continuous log output while it’s checking, and we won’t his the Travis no-log-output-for-more-than-10-minutes timeout |
| 07:19 | <MikeSmith> | annevk: that also has the advantage of making it not look like the build is hanging, when in fact it’s actually running the HTML checker but just on a really large number of files (as is the case with the Encoding standard) |
| 07:45 | <MikeSmith> | actually the reason that checking the Encoding files takes so long isn’t just due to there being so many files to check (66 files), it’s also that 30+ of the files are bigger than 4MB |
| 07:58 | <MikeSmith> | annevk: https://github.com/whatwg/whatwg.org/pull/259 will fix the Encoding build-timeout issue |
| 08:32 | <Domenic> | MikeSmith: approved |
| 08:33 | <Domenic> | These kinds of things were why I was wondering whether maybe we should not check the encoding tables. But I guess it's still a good thing to do. |
| 09:57 | <MikeSmith> | Domenic: yeah but the changes are general improvements that we’re better off with anyway, so I guess it’s a net win |
| 10:18 | <MikeSmith> | Domenic: hmm well take a look at the current log output at https://travis-ci.org/whatwg/encoding/builds/547664070 |
| 10:19 | <MikeSmith> | are there multiple subdirectories there under encoding.spec.whatwg.org/commit-snapshots/ ? |
| 10:19 | <MikeSmith> | or just one? |
| 10:20 | <MikeSmith> | if there are subdirectories there for all previous snapshots.. that’s gonna take a while |
| 10:23 | <Domenic> | There should only be one per build |
| 10:24 | <MikeSmith> | OK |
| 10:27 | <MikeSmith> | OK, green |
| 10:27 | <MikeSmith> | https://travis-ci.org/whatwg/encoding/builds/547664070 |
| 10:27 | <MikeSmith> | > Ran for 11 min 39 sec |
| 10:27 | <Domenic> | Woohoo! |
| 10:27 | <MikeSmith> | yeah :) |
| 10:28 | <MikeSmith> | so another reason it takes so long is that it’s essentionally checking all the files 3 times |
| 10:29 | <MikeSmith> | once in encoding.spec.whatwg.org/commit-snapshots/753f0d461b3a1f04d0f8355052a5491e2629799e, once in encoding.spec.whatwg.org/review-drafts/2019-06, and once in the root encoding.spec.whatwg.org/ |
| 10:30 | <MikeSmith> | each run takes about 3 minutes and checks ~180MB of files, 66 files total |
| 10:30 | <MikeSmith> | so it’s checking more than .5GB of HTML source in total |
| 10:31 | <MikeSmith> | so it takes on average about 2.7 seconds to check each doc |
| 10:32 | <Domenic> | Not so bad :) |
| 10:33 | <MikeSmith> | well actually for normal-sized docs, it takes only a few hundred milliseconds |
| 10:34 | <MikeSmith> | but in the case of Encoding, it’s heavily weighted by the fact that almost half the docs are 4MB+ |
| 10:34 | <MikeSmith> | anyway, I think we now have everything fixed as far as getting the review drafts built |
| 11:01 | <Domenic> | Yeah, a wild review draft has appeared! https://encoding.spec.whatwg.org/review-drafts/2019-06/ |
| 11:01 | <Domenic> | Thanks for all your help :D |
| 11:01 | <annevk> | \o/ |
| 11:05 | <Domenic> | https://travis-ci.org/whatwg/html/builds/548150617#L927 wattt svg <rect>s and <foreignObject>s need their width/height set as content attributes? CSS seems like it should work fine... |
| 11:06 | <Domenic> | MikeSmith: I know it's getting late but IMO https://github.com/whatwg/html/pull/4713/files#diff-36cd38f49b9afa08222c0dc9ebfe35ebR88225 should be valid SVG. But it fails the build. I couldn't find any requirements in https://www.w3.org/TR/SVG2/shapes.html#RectElement to support the validator error. |
| 11:07 | <MikeSmith> | Domenic: looking now |
| 11:07 | <MikeSmith> | it might actually be because the SVG WG changed the spec |
| 11:07 | <Domenic> | Hmmmm |
| 11:07 | <MikeSmith> | https://www.w3.org/TR/SVG2/Overview.html is from 04 October 2018 |
| 11:08 | <MikeSmith> | I know they made other changes that relaxed previous restrictions |
| 11:08 | <Domenic> | https://www.w3.org/TR/SVG11/shapes.html#RectElement seems pretty similar |
| 11:10 | MikeSmith | looks there too |
| 11:16 | <MikeSmith> | Domenic: OK, yeah, the #REQUIRED restriction was in https://www.w3.org/TR/2003/REC-SVG11-20030114/shapes.html#RectElement |
| 11:16 | <Domenic> | Oh fascinating |
| 11:17 | <Domenic> | DTDs with requirements imposed via comments. (Or is the # syntax not comments?) |
| 11:18 | <MikeSmith> | Domenic: I don’t actually remember how it was done for DTDs |
| 11:18 | <MikeSmith> | kinda glad I don’t remember :p |
| 11:19 | <MikeSmith> | anyway, as far as I can see, the current spec doesn’t define any attributes as required |
| 11:19 | <MikeSmith> | which seems like maybe it’s an oversight |
| 11:19 | <Domenic> | I dunno, given how (almost?) everything can be set via CSS, it kind of makes sense to me. |
| 11:20 | <MikeSmith> | well I see the prose of the original spec never defined anything as required either |
| 11:20 | <MikeSmith> | it was only indicated with that #REQUIRED thing in the DTD |
| 11:21 | <MikeSmith> | sigh, I really don’t want to bash other groups’ work but this is really really annoying |
| 11:22 | <MikeSmith> | I mean it’s now completely ambiguous whether they actually intend for no attributes to be required, or whether they just didn’t bother to carry any of the restrictions over |
| 11:22 | <Domenic> | True :-/ |
| 11:23 | <MikeSmith> | OK, anyway, in the checker schema I can un-require the problem attributes |
| 11:23 | <MikeSmith> | I need to do this for foreignObject too, I think (becuase we are getting errors for that too) |
| 11:23 | <Domenic> | I can also add them to all the code I guess, just feels redundant given I could instead do it in CSS |
| 11:23 | <MikeSmith> | will do that right now and push a new checker build |
| 11:24 | <MikeSmith> | nah, easier to change the checker |
| 11:24 | <Domenic> | <3 |
| 11:26 | <Domenic> | Oh, wait |
| 11:26 | <Domenic> | Firefox does not seem to like setting width and height via CSS |
| 11:30 | <Domenic> | MikeSmith: yeah, cancel that checker update, those errors prevented me from writing code that doesn't work in Firefox. Which means we have a separate interop issue, but meh... |
| 11:31 | <MikeSmith> | Domenic: ah OK |
| 11:35 | <Domenic> | Now I can show you all my beautiful diagram https://whatpr.org/html/4713/webappapis.html#module-script-fetching-diagram |
| 11:35 | <Domenic> | (actually Hiroshige's, but I did the SVG conversion) |
| 11:39 | MikeSmith | looks |
| 11:39 | <MikeSmith> | Domenic: very ... utilitarian |
| 11:40 | <Domenic> | lol |
| 11:40 | <MikeSmith> | I believe this style is called “brutalism” |
| 11:40 | <Domenic> | hahahaha |
| 11:48 | <Domenic> | I suppose we could borrow some styles from https://html.spec.whatwg.org/multipage/parsing.html#overview-of-the-parsing-model |
| 12:11 | <MikeSmith> | Domenic: so by the way, we actually have existing tests that would fail if I made that SVG schema change |
| 12:11 | <MikeSmith> | https://github.com/web-platform-tests/wpt/blob/master/conformance-checkers/html-svg/struct-dom-19-f-novalid.html |
| 12:12 | <MikeSmith> | and https://github.com/web-platform-tests/wpt/blob/master/conformance-checkers/html-svg/struct-dom-17-f-novalid.html |
| 12:13 | <MikeSmith> | so even if I had merged the schema change, I would have had to change those tests — because the checker build fails if any tests fail |
| 12:17 | <Domenic> | Always good to have test coverage :) |
| 12:17 | <MikeSmith> | yeah |
| 12:17 | <MikeSmith> | especially if the tests came from a 3rd-party contributor, which those are |
| 12:28 | <annevk> | Anyone here familiar with https://www.w3.org/TR/trace-context/? |
| 12:28 | <annevk> | Is this a web application protocol not intended to be natively implemented in browsers? |
| 12:29 | <annevk> | "A simplistic regex-based implementation can be found in the test folder. This implementation has 100% compliance to the test suite." not browsers then |
| 12:33 | <MikeSmith> | annevk: I can doublecheck with plh (it’s his group) but as far as what I know about it, it’s not intended to be natively implemented in browsers |
| 12:36 | <annevk> | MikeSmith: someone filed https://github.com/whatwg/fetch/issues/911 |
| 12:42 | MikeSmith | looks |
| 14:16 | <MikeSmith> | annevk: so, nowhere in the issue description at https://github.com/whatwg/fetch/issues/911 does the OP provide any explanation of any problem specific to exchanging “distributed trace contexts” that is caused by the CORS preflight |
| 14:17 | <MikeSmith> | the two items described in the “this poses two challenges for observability providers” part are general problems/costs of the preflight for any case at all |
| 14:17 | <annevk> | MikeSmith: yeah, true |
| 14:18 | <annevk> | MikeSmith: might be worth asking about |
| 14:19 | <MikeSmith> | well the two things that OP lists are, 1) The preflight request increases the latency for the original HTTP request and 2) Unless the server… is modified to respond appropriately to the preflight request the request would fail |
| 14:20 | <MikeSmith> | as far as the second point, the server system already must be modified to do something with the `traceparent` and `tracestate` request headers |
| 14:22 | <MikeSmith> | so it’s not clear why an admin of such a server system would not also be able to CORS-enable the server system, or why it would be any more trouble to do so |
| 14:22 | <MikeSmith> | annevk: anyway, I will add a comment there |
| 14:30 | <oliverdunk> | annevk: did you see my last message last night? |
| 14:31 | <annevk> | oliverdunk: I replied, no? See the logs |
| 14:35 | <oliverdunk> | Missed that somehow, thanks. Wouldn't it be set to cors by the otherwise of 4.1 step 5? |
| 14:38 | <annevk> | oliverdunk: oh if we’re talking fetch(), yes |
| 14:40 | <oliverdunk> | Cool. So for detecting a redirect with fetch(), everything sounds alright? |
| 14:41 | <annevk> | oliverdunk: I think so, but it’s been a while and have not looked at all steps |
| 14:42 | <oliverdunk> | No worries, I appreciate your help :) |