| 00:20 | <jyasskin> | TabAtkins: Any idea what happened to <xmp> in Bikeshed? https://github.com/tabatkins/bikeshed/pull/933 |
| 00:21 | <TabAtkins> | I must have accidentally stopped looking at them. Thanks for the reminder, I'll go see what's up. |
| 00:22 | <jyasskin> | Thanks! |
| 00:39 | <TabAtkins> | jyasskin: Yup, found the offending selector that only mentions <pre> and not <xmp>. Pushed fix, testing against your PR's test now. |
| 00:39 | <jyasskin> | \o/ |
| 00:39 | <TabAtkins> | And looks good. |
| 01:23 | <MikeSmith> | TabAtkins: I’m running Bikeshed on source for the Service Workers spec and noticing that formatting of Notes is getting inadvertently changed |
| 01:23 | <MikeSmith> | <p class="note" role="note"><span>Note:</span> |
| 01:24 | <MikeSmith> | <p class="note" role="note">Note: |
| 01:24 | <MikeSmith> | the span around the word “Note:” getting dropped |
| 01:24 | <TabAtkins> | That implies you're on an older version |
| 01:25 | <TabAtkins> | Pull latest from github |
| 01:30 | <MikeSmith> | hai |
| 01:30 | MikeSmith | does that now |
| 01:30 | <MikeSmith> | WARNING: Couldn't check the datafile version. Bikeshed may be unstable. |
| 01:30 | <MikeSmith> | [Errno 2] No such file or directory: u'/usr/local/lib/python2.7/site-packages/bikeshed/spec-data/readonly/version.txt' |
| 01:30 | <MikeSmith> | (but still running) |
| 01:31 | <MikeSmith> | (running bikeshed update) |
| 01:42 | <MikeSmith> | TabAtkins: thanks! got it working now |
| 04:03 | <rniwa> | Domenic: yt? |
| 04:03 | <rniwa> | annevk: yt? |
| 04:03 | <rniwa> | MikeSmith: yt? |
| 04:40 | <MikeSmith> | rniwa: I’m here |
| 04:41 | <rniwa> | MikeSmith: thanks for the response |
| 04:41 | <rniwa> | MikeSmith: it looks like a bunch of spec's are referring to ABNF: https://tools.ietf.org/html/rfc5234 |
| 04:41 | <rniwa> | MikeSmith: but they should be referring to https://www.w3.org/Notation.html instead |
| 04:41 | <rniwa> | MikeSmith: because they use <1>#<m>element notation for comma separated lists |
| 04:42 | <rniwa> | MikeSmith: which isn't defined in RFC5234 |
| 04:42 | <rniwa> | MikeSmith: alternatively, we can update those specs that use # notation to not use it |
| 04:47 | <MikeSmith> | oh wow |
| 04:47 | <MikeSmith> | thanks for catching that |
| 04:47 | <MikeSmith> | I think nobody has ever noticed that before |
| 04:48 | <rniwa> | MikeSmith: thank JoePeck on #webkit for that :) |
| 04:48 | <MikeSmith> | heh |
| 04:48 | <rniwa> | MikeSmith: he's really good at catching these thigns |
| 04:48 | <MikeSmith> | OK will thank him too |
| 04:48 | <MikeSmith> | yeah, attention to detail |
| 04:48 | <MikeSmith> | I notice that from his wpt tests as well |
| 04:49 | <MikeSmith> | anyway I guess there is some mailing list we should send a general “change your references” announcement to |
| 04:49 | <rniwa> | MikeSmith: he works on Web Inspector and he's implementing resource timing right now |
| 04:49 | <MikeSmith> | ah |
| 04:49 | <MikeSmith> | yeah I know he works on Web Inspector |
| 04:49 | <MikeSmith> | didn’t know he was working on resource timing |
| 04:50 | <MikeSmith> | but I guess we also should raise issues for each spec we notice that uses it |
| 04:50 | <rniwa> | MikeSmith: yeah probably |
| 04:50 | <MikeSmith> | IMHO the best way to deal with is, Don’t use any form of BNF in a Web API spec to begin |
| 04:50 | <MikeSmith> | they are OK for protocol specs maybe |
| 04:51 | <rniwa> | MikeSmith: I think BNF is useful for defining syntax |
| 04:51 | <MikeSmith> | in some cases |
| 04:51 | <MikeSmith> | but in a lot, not |
| 04:51 | <MikeSmith> | not if you want to specify error handling |
| 04:51 | <rniwa> | MikeSmith: I think fetch & resource timing are both defining the format for HTTP headers so it makes a lot of sense there |
| 04:51 | <MikeSmith> | OK |
| 04:51 | <MikeSmith> | so that makes more sense |
| 04:51 | <MikeSmith> | in that context |
| 04:52 | <MikeSmith> | anyway I got to step out for a bit now |
| 04:52 | <MikeSmith> | back in ~30 minutes |
| 04:53 | <rniwa> | ok, thanks |
| 05:21 | MikeSmith | has just now been chatting with JoePeck on w3c #testing about other stuff |
| 06:40 | <MikeSmith> | XhmikosR: at https://github.com/filamentgroup/loadCSS/issues/106#issuecomment-279619616 I guess I’m not understanding what the problem is. What is failing? |
| 06:42 | <XhmikosR> | MikeSmith: have you tried if `rel="stylesheet preload"` works currently in Chrome? |
| 06:43 | <XhmikosR> | if it works, then there's no backwards incompatibility. I don't use Chrome myself so I haven't tested that yet |
| 06:45 | <MikeSmith> | I have not tested it in Chrome no |
| 06:45 | <MikeSmith> | but if it doesn’t work then that’s a bug in Chrome |
| 06:45 | <XhmikosR> | true |
| 06:47 | <XhmikosR> | we could then just use string.includes but since that's for pretty new browsers I guess we should use indexOf |
| 06:48 | <XhmikosR> | I'll wait for Scott's reply and see how to proceed. I'll also need to test if Chrome's implementation follows the specs and works with `stylesheet preload` |
| 06:51 | <MikeSmith> | OK |
| 07:15 | <MikeSmith> | XhmikosR: https://github.com/w3c/webappsec-subresource-integrity/issues/26#issuecomment-279479814 |
| 07:16 | <MikeSmith> | well not that particular comment |
| 07:16 | <MikeSmith> | just https://github.com/w3c/webappsec-subresource-integrity/issues/26 |
| 07:21 | <XhmikosR> | MikeSmith: chrome doesn't seem to work with `stylesheet preload` |
| 07:22 | <MikeSmith> | interesting |
| 07:22 | <XhmikosR> | but maybe I'm missing something so I'll wait for Scott. I tested things locally with xampp |
| 07:23 | <MikeSmith> | yoav: ⬆ |
| 07:23 | <XhmikosR> | but the polyfill doesn't seem to work either so I'm probably missing something |
| 07:24 | <XhmikosR> | link.rel.indexOf("preload") !== -1 true |
| 07:24 | <XhmikosR> | the check works fine |
| 07:25 | <annevk> | rniwa: I thought HTTP defined some ABNF extensions, but I should prolly clarify that I use them |
| 07:25 | <rniwa> | annevk: maybe. |
| 07:26 | <rniwa> | annevk: I think clarifying the reference would be nice |
| 07:37 | <annevk> | Yeah |
| 07:39 | <yoav> | MikeSmith: yo! |
| 07:40 | <zcorpan> | tobie: annevk: <http://www.w3.org/mid/e1060665-17fb-cc4a-aace-49503df5f228⊙wo>; 🎉 |
| 07:42 | <yoav> | XhmikosR: So `<link href=foo rel="stylesheet preload" as=style>` doesn't work in current Chrome impl? |
| 07:42 | <yoav> | Not sure what you want it to do tbh, but it should work (in a sense that a resource should be loaded, fetched and applied as a style) |
| 07:42 | <XhmikosR> | yoav: from a quick test it doesn't seem so |
| 07:43 | <XhmikosR> | yoav: let me paste the test file, you will need php |
| 07:43 | <yoav> | XhmikosR: Can you file a bug with a test case and send it my way? |
| 07:43 | <XhmikosR> | (not my tests) |
| 07:43 | <XhmikosR> | if we verify it doesn't work sure :) |
| 07:43 | <yoav> | cool |
| 07:43 | <XhmikosR> | would be nice if it didn't require php |
| 07:43 | <XhmikosR> | but Scott's test is using it |
| 07:44 | <XhmikosR> | let me fork his repo so that things are public |
| 07:46 | <XhmikosR> | (freaking tabs for indentation :P) |
| 07:47 | <zcorpan> | XhmikosR: seems to work over here... http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4885 (network inspector shows 1 fetch; if i remove `as` it shows 2 fetches) |
| 07:47 | <zcorpan> | and style is applied |
| 07:47 | <XhmikosR> | sec guys |
| 07:47 | <XhmikosR> | might be something with the polyfill |
| 07:48 | <zcorpan> | yoav: (has there been progress on not doing a fetch for <link rel=preload> without as?) |
| 07:49 | <yoav> | zcorpan: I'm half-way through PRs to get that done (got distracted by travel and shiny objects...) |
| 07:49 | <XhmikosR> | https://github.com/XhmikosR/loadCSS/blob/master/test/preload.html |
| 07:49 | <zcorpan> | yoav: cool |
| 07:50 | <yoav> | XhmikosR: `<link rel="stylesheet preload" href="slow.css.php" as="style">` will be a blocking style |
| 07:50 | <yoav> | which I think is counter to what you're trying to do |
| 07:50 | <XhmikosR> | hmm |
| 07:51 | <XhmikosR> | I see it's blocking |
| 07:51 | <zcorpan> | https://github.com/filamentgroup/loadCSS the README suggests using rel="preload" sans stylesheet |
| 07:51 | <XhmikosR> | the problem is we can't use integrity unless rel has stylesheet, or I misunderstood the issue? |
| 07:51 | <zcorpan> | and then i guess the script adds stylesheet |
| 07:51 | <XhmikosR> | zcorpan: I changed the check |
| 07:52 | <XhmikosR> | https://github.com/XhmikosR/loadCSS/commit/98c3137ff7811616eec4bb5d993eb5486a09c85f?w=1#diff-68b76c559168de2db8358863b8199f94R22 |
| 07:52 | <yoav> | you currently cannot use preload with integrity |
| 07:52 | <yoav> | adding a rel=style won't help you with that |
| 07:52 | <XhmikosR> | ah I see |
| 07:52 | <XhmikosR> | that is what I'm trying to solve |
| 07:53 | <zcorpan> | that's interesting. i guess we should make that work |
| 07:53 | <yoav> | we definitely should |
| 07:53 | <zcorpan> | mkwst_: ^ |
| 07:53 | <yoav> | https://github.com/w3c/webappsec-subresource-integrity/issues/26 |
| 07:53 | <yoav> | zcorpan: current options are: |
| 07:54 | <yoav> | 1) add an `integrity` attribute to `<link rel=preload>` |
| 07:54 | <yoav> | 2) Jump through various implementation hoops that will enable to reuse preloaded resources and perform the integrity check at reuse time |
| 07:55 | <yoav> | (as well as letting script preloads through even if `require-sri-for-script` is present) |
| 07:56 | <XhmikosR> | I was just looking at the polyfill since I'm a FF user but since Chrome doesn't work we are currently out of luck |
| 07:56 | <yoav> | I guess that 2) is the "right" way to solve it, assuming implementation is feasible (I don't own SRI impl so not sure how complex that would be) |
| 07:56 | <yoav> | XhmikosR: sorry! :/ |
| 07:56 | <zcorpan> | i was thinking: 1.a) allow (and honor) integrity for <link rel=preload as=style> and the other as values where integrity applies, but not where it doesn't |
| 07:57 | <XhmikosR> | this makes sense ^^ |
| 07:57 | <yoav> | zcorpan: yeah, but isn't that just throwing the burden on devs rather than solving it internally? |
| 07:58 | <zcorpan> | yoav: the burden being having to use integrity attribute on their preload link? |
| 07:59 | <zcorpan> | maybe 2 has better developer ergonomics |
| 07:59 | <yoav> | yeah |
| 07:59 | <yoav> | that's what I'm thinking |
| 07:59 | <zcorpan> | but with the loadCSS pattern it doesn't really matter since it uses the same <link> and just appends " stylesheet" to rel when it's ready |
| 08:00 | <yoav> | true |
| 08:01 | <yoav> | I'll try to ping jww and see if he has an opinion on how complex integrity checks on existing resources would be |
| 08:01 | <zcorpan> | so i think it should at least be *allowed* to specify integrity="" for rel=preload. how we then deal with it in implementation is not something i can have an informed opinion on |
| 08:05 | <XhmikosR> | irrelevant but if something happens to GitHub we are screwed with almost everything hosted on it :/ |
| 08:05 | <XhmikosR> | (noticed Python moved to GH too) |
| 08:08 | <yoav> | zcorpan: and if integrity on preload mismatches and integrity on the reusing element does? |
| 08:08 | <yoav> | we don't use the resource? |
| 08:12 | <yoav> | zcorpan: unless you have a use-case that would require applying the integrity check on both the preloaded resource and the reusing element... |
| 08:13 | <annevk> | yoav: if it mismatches for the preload it simply wouldn't end up in the preload cache since you got back a network error from Fetch |
| 08:13 | <annevk> | yoav: this is all fairly simple and would fall out of properly defining preload... |
| 08:13 | <annevk> | so please start looking at that, rather than all the things around it |
| 08:13 | <yoav> | does Fetch buffer the resource before returning it? |
| 08:14 | <annevk> | yoav: it does if you add integrity, yes |
| 08:14 | <yoav> | ok |
| 08:16 | <yoav> | annevk: fwiw, this is not about defining preload, but about defining the concept of "memory cache" |
| 08:17 | <yoav> | which I agree we need to define, but may be a long(ish) term project |
| 08:18 | <yoav> | Browsers currently disagree on behavior in various ways, so I suspect defining it will take time |
| 08:18 | <annevk> | for non-Chrome it's basically about defining preload |
| 08:18 | <annevk> | if this is used in other places, it might be worth tackling those too, but I'm not sure we should tightly couple them |
| 08:19 | <yoav> | WebKit has similar behavior to Chrome in that respect |
| 08:19 | <annevk> | Okay, but I don't see why you and igrigorik keep postponing it, since it's obvious that there's many many issues coming out of it not being defined |
| 08:19 | <annevk> | And it's been like that for at least a year or so |
| 08:21 | <yoav> | annevk: I really want to define it, but need to figure out a way to scope it down, as I don't have the bandwidth to take it on as a huge project |
| 08:28 | <annevk> | yoav: how complicated is that code? |
| 08:29 | <annevk> | yoav: presumably it takes a URL and returns an ongoing fetch or some such? |
| 08:29 | <annevk> | yoav: and I guess fetch() and XHR bypass it? |
| 08:30 | <annevk> | yoav: and preload lets things stay in longer or some such? so there's some kind of max timeout |
| 08:30 | <annevk> | yoav: it's probably somewhat involved to test it |
| 08:30 | <yoav> | annevk: it's fairly complex (we're currently cleaning it up) |
| 08:31 | <yoav> | It takes in a URL, gets a past resource from memoryCache and then runs it through a large set of conditions in order to see if it can be reused or not |
| 08:32 | <annevk> | it can't just be a resource since <script src=x><script src=x> |
| 08:32 | <yoav> | WebKit has a similar set of conditions (not necessarily identical, but very close) |
| 08:32 | <annevk> | well, <script async src=x></script><script async src=x></script>, if that ends up with one fetch, it's not a resource that's returned |
| 08:32 | <yoav> | Resource is the internal representation of a fetch (which may be in flight) |
| 08:32 | <annevk> | right |
| 08:33 | <annevk> | it doesn't sound like an awfully big project to add that kind of "fetch cache" |
| 08:33 | <yoav> | so writing down what happens in Blink/WebKit during those checks is probably doable |
| 08:34 | <yoav> | but I'm not familiar with Firefox's code in that area (and have no visibility into Edge) |
| 08:36 | <yoav> | and I suspect each one of those checks will also require a (much needed but lengthy) discussion of "do we really need that?" |
| 08:38 | <yoav> | annevk: I can probably start tackling that next week or the week after that, and see how it goes |
| 08:38 | <yoav> | starting by documenting the existing implementations |
| 08:38 | <yoav> | which will probably require feedback from Mozilla folks |
| 08:39 | <annevk> | Yeah I think having a description of Chrome/WebKit's model would be good as reference |
| 08:39 | <annevk> | And then we can figure out if others want to implement that too |
| 08:39 | <annevk> | For non-preload purposes |
| 08:39 | <annevk> | And we can figure out if the Chrome/WebKit model has holes with respect to CSP and such |
| 08:39 | <yoav> | yeah |
| 08:40 | <yoav> | I suspect it won't, as it tends to err on the side of "reload the resource" |
| 08:40 | <annevk> | mkwst_ probably audited the code |
| 08:40 | <annevk> | I hope so anyway |
| 08:40 | <yoav> | oh yeah |
| 09:17 | <annevk> | Can someone look at https://travis-ci.org/w3c/web-platform-tests/builds/201282365 and tell me what is going wrong? jgraham? |
| 09:43 | <JakeA> | annevk: all I'm getting internally about the HTML outline is "we think it might break sites" but no evidence as yet |
| 09:43 | <JakeA> | annevk: anything from Moz? |
| 09:43 | <annevk> | JakeA: basically lack of time |
| 09:44 | <JakeA> | annevk: kinda sad that browsers did all of the bits except the a11y bit |
| 09:44 | <JakeA> | I guess that's nothing new |
| 09:44 | <annevk> | JakeA: the breaking site thing seems super weird to me |
| 09:44 | <annevk> | JakeA: we rolled out this feature somewhat poorly |
| 09:44 | <JakeA> | annevk: I mean, it'll change the outline of some sites, but I don't know if it'd be "bad" |
| 09:44 | <annevk> | JakeA: everyone was keen on getting some new HTML elements, without doing all the work (e.g., as of yet no CSS selectors either that make it easy to style heading levels) |
| 09:45 | <JakeA> | annevk: right! And that's what's happening on that w3c thread. Everyone's super excited about the prospect of a ****new tag**** |
| 09:46 | <annevk> | JakeA: yeah, new features are shiny, fixing infrastructure is not |
| 09:46 | <annevk> | JakeA: which reminds me, browsers still haven't removed appcache... |
| 09:46 | <JakeA> | *siiiiigh* |
| 09:47 | <JakeA> | annevk: there's a vague worry internally that it's being used by intranets, but again, not seen any evidence |
| 09:47 | <annevk> | JakeA: can't they do the long term removal for intranets? |
| 09:47 | <annevk> | JakeA: with some kind of flag for enterprises |
| 09:47 | <annevk> | JakeA: and just let that flag exist for 1.5 years |
| 09:48 | <annevk> | JakeA: isn't that how showModalDialog got removed? |
| 09:48 | <JakeA> | annevk: yeah, that seems fair |
| 09:48 | <annevk> | JakeA: it's long, but it's better than just letting the code rot and be a source of vulnerabilities |
| 10:16 | <JakeA> | annevk: I'm not sure what else I need to do to get https://github.com/w3c/web-platform-tests/pull/4518 merged. Travis is barfing, but it isn't clear on what, or if it's related to the PR |
| 10:17 | <annevk> | JakeA: it seems the results for Chrome are unstable? |
| 10:18 | <annevk> | JakeA: I second the problem with Travis though, the output is not great |
| 10:20 | <JakeA> | annevk: yeah, I can't figure out if it's specific to my tests |
| 10:23 | <jgraham> | JakeA: That seems pretty clear from the GitHub comment? Chrome timed out on 2 runs out of 8, so the tests are unstable and can't yet land |
| 10:23 | <jgraham> | annevk: It looks like for some reason travis thought that branch contained hundreds of commits |
| 10:23 | <jgraham> | I'm not sure why |
| 10:23 | <JakeA> | maybe because I rebased |
| 10:24 | <JakeA> | jgraham: ah, I didn't spot the relevant part in the wall of text |
| 10:25 | <zcorpan> | Domenic: "I wonder if we can do it purely through CSS (I doubt it)." - was this intended to trigger a knee-jerk on my part to fix it just to prove you wrong? 🤔😁 |
| 10:25 | <annevk> | jgraham: I think what's going on is that he's trying to merge into the MicrosoftEdge branch rather than master |
| 10:25 | <jgraham> | JakeA: Anything you suggest to make it more obvious? It's at the top in bold. <blink> doesn't work these days… |
| 10:26 | <jgraham> | annevk: Oh, that could be it |
| 10:26 | <annevk> | jgraham: your comment tipped me off somehow, even though I had seen it trying to apply hundreds of commits |
| 10:28 | <jgraham> | annevk: We can probably make that work in the bot, but I don't know why you would do that in general |
| 10:28 | <JakeA> | jgraham: :P I guess fold all the passes into a click-to-reveal thing. The "everything's ok" parts of the messages are huge compared to the "here's the actual problem" |
| 10:28 | <jgraham> | I hope Microsoft haven't got the idea that they should put all their commits in a MicrosoftEdge branch |
| 10:28 | <jgraham> | JakeA: Hmm, does nested <details> work? Could try it |
| 10:29 | <JakeA> | jgraham: I dunno :( |
| 10:29 | <JakeA> | jgraham: in this case the unstable tests are nothing to do with my PR. Should it block me from merging? |
| 10:30 | <annevk> | jgraham: I'm hoping it was just a mistake, we'll hear tomorrow hopefully |
| 10:30 | <Ms2ger> | JakeA, is it the rebase or the test-helpers.sub.js change? |
| 10:31 | <annevk> | jgraham: nested works |
| 10:31 | <MikeSmith> | annevk: if I got anything wrong at https://stackoverflow.com/questions/42222937/using-fetch-api-to-post-xml/42223732#42223732 lemme know or comment/answer there when you got time |
| 10:32 | <JakeA> | Ms2ger: hmm, maybe, I'm not sure how it works |
| 10:33 | <Ms2ger> | I think it's accurately detecting that your change affected all the things |
| 10:34 | <annevk> | MikeSmith: seems accurate enough |
| 10:34 | <annevk> | MikeSmith: I suspect he doesn't like CORS and thought fetch() would give a way out |
| 10:34 | <Ms2ger> | JakeA, I guess I can merge |
| 10:35 | <JakeA> | Ms2ger: I can't see how that change could make other tests unstable, but browsers have surprised me before |
| 10:36 | <Ms2ger> | JakeA, it probably just made the checker run a test it hadn't before |
| 10:39 | <JakeA> | Thanks for merging! |
| 10:42 | <MikeSmith> | annevk: thanksーand yeah I have no clue what he might actually be trying to do. hmm but yeah I guess he saw mode: no-cors and thought that meant no CORS restrictions |
| 10:42 | <MikeSmith> | I wonder now how often other people might think that |
| 10:42 | <JakeA> | it isn't the first time I've seen it |
| 10:43 | <annevk> | naming :-( |
| 10:43 | <JakeA> | Seen a few people think it's a "security? Pfft, no thanks" switch |
| 10:43 | <annevk> | hah |
| 10:44 | <MikeSmith> | I guess we should have some better simple documentation (at MDN) that clearly explains what "no-cors" really means. There doesn’t actually see to be something like that at MDN yet |
| 10:45 | <JakeA> | Fetch is poorly understood by developers |
| 10:45 | <JakeA> | I can't say I understood it well before service worker |
| 10:45 | <annevk> | Presumably understanding was worse before it was written down |
| 10:45 | <JakeA> | yeah |
| 10:46 | <annevk> | There used to be no answer to what happens for redirects to <script> element fetches |
| 10:47 | <MikeSmith> | yeah and IMHO it’s not really the job of specs to make things clear to developers. That’s what MDN etc are much better suited for |
| 10:47 | <MikeSmith> | I like the Fetch spec the way it is |
| 10:48 | <MikeSmith> | because it’s like playing a kind of puzzle game 😆 |
| 10:48 | <JakeA> | :D |
| 10:48 | <MikeSmith> | ...where you have follow clues all over the place to figure things out |
| 10:48 | <MikeSmith> | heh |
| 10:48 | <JakeA> | There's probably an article in "how fetch works" |
| 10:48 | <MikeSmith> | yeah |
| 10:49 | <JakeA> | Not many developers know there's such thing as a CORS request. Many think it's just part of the response. |
| 10:49 | <MikeSmith> | oh |
| 10:50 | <MikeSmith> | ah yeah they don’t understand the browsers enforce the cross-origin request restrictions |
| 10:50 | <JakeA> | (at some point we need to get range requests into the spec) |
| 10:51 | <MikeSmith> | anyway seriously I think the Fetch spec is good example of the right way to write a spec for implementors, for getting the requirements defined clearly, without digressions stuffed amidst it all |
| 10:53 | <MikeSmith> | in contrast I think I’m becoming less and less fond of how the HTML spec intermingles UA requirements with a lot of informational stuff for authors/web-devs |
| 10:53 | <MikeSmith> | though I think it’s possible to put both in the same spec well if they are more clearly delineated |
| 10:53 | <MikeSmith> | more like what the URL spec does |
| 10:57 | <annevk> | MikeSmith: URL was modeled after HTML's syntax section |
| 10:57 | <annevk> | MikeSmith: that section of HTML doesn't cause much confusion (though there is some I suppose), but the remainder of the standard doesn't have the clear distinction |
| 11:30 | <annevk> | JakeA: what about https://github.com/whatwg/fetch/pull/435#discussion_r92863905 |
| 11:33 | <annevk> | JakeA: that's the only thing left as far as I can tell apart from a minor thing I just spotted that I can fix when merging |
| 11:37 | <JakeA> | annevk: ah yes, will remove that bit now |
| 11:38 | <annevk> | I looked around a bit and couldn't find another standard that uses the skip flag, other than Service Workers that is |
| 11:38 | <annevk> | So hopefully we don't break anyone |
| 11:39 | <JakeA> | happy to make PRs for them if we find any |
| 11:39 | <annevk> | sweet, seems unlikely though |
| 11:52 | <jgraham> | JakeA, annevk: PRs up for both your issues. Dunno if they work yet though |
| 11:52 | <JakeA> | \o/ |
| 11:52 | <JakeA> | cheers! |
| 12:33 | <Ms2ger> | What's up with Steve Faulkner suddenly hating the w3c? |
| 12:42 | <zcorpan> | The annoying warning doesn't work well with narrow viewports (it overflows upwards) |
| 12:44 | <annevk> | Snapshot warning? |
| 12:45 | <annevk> | Also breaks dfn.js when collapsed |
| 12:45 | <annevk> | Ms2ger: did he quit w3c/html? |
| 12:46 | <Ms2ger> | Dunno, he's whining about drm on twitter |
| 12:47 | <annevk> | I saw that |
| 12:47 | <annevk> | Whenever things go negative for W3C just blame the members |
| 12:48 | <annevk> | But don't let the members near anything positive, that was all W3C |
| 12:48 | <annevk> | Such a silly refrain |
| 12:55 | <annevk> | JakeA: just need a commit message now, I usually do one between ``` and ``` as a new comment |
| 12:55 | <annevk> | JakeA: should indicate the issues fixed, tests and a summary at the top as title |
| 13:01 | <JakeA> | done! |
| 13:11 | <annevk> | Alright, we can now modify whatwg.org through GitHub |
| 13:12 | <annevk> | Setup seems to work |
| 13:40 | Ms2ger | wonders how accurate the address element on the front page is |
| 13:41 | <gsnedders> | Ms2ger: front page of what? |
| 13:41 | <Ms2ger> | whatwg.org |
| 13:44 | <annevk> | Ms2ger: contents are being changed |
| 13:45 | <annevk> | Ms2ger: mostly to direct to whatwg/meta or Hixie |
| 13:45 | <annevk> | Ms2ger: instead of the mailing list |
| 13:45 | <annevk> | Ms2ger: but the frontpage in general has some problems with out-of-date links, if anyone has ideas for an overhaul that doesn't really require us to link to nine things that'd be great |
| 13:46 | <xfq> | Related: https://github.com/whatwg/whatwg.org/issues/13 |
| 14:03 | <annevk> | And fixed |
| 14:10 | <annevk> | zcorpan: oh lol, it's actually called "annoying warning" |
| 14:10 | <annevk> | zcorpan: in the markup |
| 14:11 | <zcorpan> | annevk: yep |
| 14:11 | <zcorpan> | annevk: good to keep the right expectations for anyone touching the code :-) |
| 14:11 | <annevk> | zcorpan: changes LGTM |
| 14:12 | <annevk> | zcorpan: is the markup/style documented standalone someplace? It seems we could use it on whatwg.org for a number of things |
| 14:14 | <zcorpan> | annevk: i don't follow the question |
| 14:14 | <annevk> | zcorpan: if it's easy to reuse annoying warning elsewhere |
| 14:17 | <zcorpan> | annevk: ah. i guess we can reuse it... mostly a matter of moving the CSS out of bikeshed.css I think, maybe into a new annoying-warning.css |
| 14:17 | <annevk> | zcorpan: script is embedded in the markup then? |
| 14:17 | <MikeSmith> | wanderview: wondering if you have implemented <link rel=serviceworker> support |
| 14:18 | <zcorpan> | annevk: i don't think there's any script, it's just a <details> |
| 14:18 | <annevk> | zcorpan: oh, with fancy styling, cool |
| 14:18 | <wanderview> | MikeSmith: I don't think so |
| 14:19 | <MikeSmith> | ok |
| 14:19 | <wanderview> | MikeSmith: https://bugzilla.mozilla.org/show_bug.cgi?id=1243404 |
| 14:19 | MikeSmith | looks |
| 14:19 | <MikeSmith> | wanderview: thank you |
| 14:19 | <wanderview> | the header was added for foreign fetch support and we've been putting off working on that feature |
| 14:20 | <MikeSmith> | ah |
| 14:27 | <annevk> | Thanks wanderview for filing the Gecko bug |
| 14:27 | <annevk> | Re https://github.com/whatwg/fetch/issues/303 |
| 14:27 | <wanderview> | np... I haven't been as good at filing those bugs lately |
| 14:27 | <annevk> | JakeA: perhaps you can update that issue with the Chrome bug as well? |
| 14:28 | <annevk> | wanderview: I'm trying to take over that task for any new changes, but I forgot about this one since I didn't write the PR |
| 14:31 | <JakeA> | Done! |
| 14:36 | <annevk> | JakeA: FWIW, in general for each PR we now require tests and also impl bugs, but I tend to forget to ask for the latter |
| 14:37 | <JakeA> | Noted for future. Cheers! |
| 16:27 | <XhmikosR> | @MikeSmith: can you reply on the loadCSS issue? I don't know the names of the guys here |
| 16:28 | <MikeSmith> | XhmikosR: yes I will |
| 16:28 | <XhmikosR> | unfortunately for subresource we need `stylesheet preload` but then preload breaks if I understood correctly |
| 16:30 | <XhmikosR> | thanks |
| 16:32 | <MikeSmith> | yup |
| 16:46 | <gsnedders> | is it still the case that web fonts start to load when the browser finds the first use of it? |
| 17:13 | <Domenic> | MikeSmith: I do think the things you said in IRC would be good as a reply to the DTD email. They were appropriately diplomatic but also pointing out that it's not the direction we're focused on, for good reasons. |
| 17:13 | <Domenic> | zcorpan: I guess I really meant getting it so that *only* the "X" button closes, not the whole `<summary>`. |
| 17:14 | <MikeSmith> | Domenic: OK I will make time to reply to them then |
| 18:32 | <TabAtkins> | gsnedders: I believe so, yes. |
| 18:50 | <annevk> | Domenic: having a larger target area seems fine? |
| 18:56 | <Domenic> | annevk: yeah, just to clarify what I meant by probably impossible with CSS |
| 18:58 | <annevk> | Ah |
| 19:04 | <jyasskin> | What's the best way to put an ascii BufferSource literal into a spec example? So far I've got Uint8Array.from("climb a mountain", c=>c.charCodeAt(0)) |
| 19:17 | <annevk> | jyasskin: use TextEncoder? |
| 19:18 | <jyasskin> | annevk: Good point. I'd ruled it out when I thought I needed to base64-decode the string, but I don't actually need to do that. Thanks. |