freenode :: #whatwg

14 Feb 2017
00:20jyasskinTabAtkins: Any idea what happened to <xmp> in Bikeshed?
00:21TabAtkinsI must have accidentally stopped looking at them. Thanks for the reminder, I&#39;ll go see what&#39;s up.
00:39TabAtkinsjyasskin: Yup, found the offending selector that only mentions <pre> and not <xmp>. Pushed fix, testing against your PR&#39;s test now.
00:39TabAtkinsAnd looks good.
01:23MikeSmithTabAtkins: Im running Bikeshed on source for the Service Workers spec and noticing that formatting of Notes is getting inadvertently changed
01:23MikeSmith<p class=&quot;note&quot; role=&quot;note&quot;><span>Note:</span>
01:24MikeSmith<p class=&quot;note&quot; role=&quot;note&quot;>Note:
01:24MikeSmiththe span around the word Note: getting dropped
01:24TabAtkinsThat implies you&#39;re on an older version
01:25TabAtkinsPull latest from github
01:30* MikeSmith does that now
01:30MikeSmithWARNING: Couldn&#39;t check the datafile version. Bikeshed may be unstable.
01:30MikeSmith[Errno 2] No such file or directory: u&#39;/usr/local/lib/python2.7/site-packages/bikeshed/spec-data/readonly/version.txt&#39;
01:30MikeSmith(but still running)
01:31MikeSmith(running bikeshed update)
01:42MikeSmithTabAtkins: thanks! got it working now
04:03rniwaDomenic: yt?
04:03rniwaannevk: yt?
04:03rniwaMikeSmith: yt?
04:40MikeSmithrniwa: Im here
04:41rniwaMikeSmith: thanks for the response
04:41rniwaMikeSmith: it looks like a bunch of spec&#39;s are referring to ABNF:
04:41rniwaMikeSmith: but they should be referring to instead
04:41rniwaMikeSmith: because they use <1>#<m>element notation for comma separated lists
04:42rniwaMikeSmith: which isn&#39;t defined in RFC5234
04:42rniwaMikeSmith: alternatively, we can update those specs that use # notation to not use it
04:47MikeSmithoh wow
04:47MikeSmiththanks for catching that
04:47MikeSmithI think nobody has ever noticed that before
04:48rniwaMikeSmith: thank JoePeck on #webkit for that :)
04:48rniwaMikeSmith: he&#39;s really good at catching these thigns
04:48MikeSmithOK will thank him too
04:48MikeSmithyeah, attention to detail
04:48MikeSmithI notice that from his wpt tests as well
04:49MikeSmithanyway I guess there is some mailing list we should send a general change your references announcement to
04:49rniwaMikeSmith: he works on Web Inspector and he&#39;s implementing resource timing right now
04:49MikeSmithyeah I know he works on Web Inspector
04:49MikeSmithdidnt know he was working on resource timing
04:50MikeSmithbut I guess we also should raise issues for each spec we notice that uses it
04:50rniwaMikeSmith: yeah probably
04:50MikeSmithIMHO the best way to deal with is, Dont use any form of BNF in a Web API spec to begin
04:50MikeSmiththey are OK for protocol specs maybe
04:51rniwaMikeSmith: I think BNF is useful for defining syntax
04:51MikeSmithin some cases
04:51MikeSmithbut in a lot, not
04:51MikeSmithnot if you want to specify error handling
04:51rniwaMikeSmith: I think fetch & resource timing are both defining the format for HTTP headers so it makes a lot of sense there
04:51MikeSmithso that makes more sense
04:51MikeSmithin that context
04:52MikeSmithanyway I got to step out for a bit now
04:52MikeSmithback in ~30 minutes
04:53rniwaok, thanks
05:21* MikeSmith has just now been chatting with JoePeck on w3c #testing about other stuff
06:40MikeSmithXhmikosR: at I guess Im not understanding what the problem is. What is failing?
06:42XhmikosRMikeSmith: have you tried if `rel=&quot;stylesheet preload&quot;` works currently in Chrome?
06:43XhmikosRif it works, then there&#39;s no backwards incompatibility. I don&#39;t use Chrome myself so I haven&#39;t tested that yet
06:45MikeSmithI have not tested it in Chrome no
06:45MikeSmithbut if it doesnt work then thats a bug in Chrome
06:47XhmikosRwe could then just use string.includes but since that&#39;s for pretty new browsers I guess we should use indexOf
06:48XhmikosRI&#39;ll wait for Scott&#39;s reply and see how to proceed. I&#39;ll also need to test if Chrome&#39;s implementation follows the specs and works with `stylesheet preload`
07:16MikeSmithwell not that particular comment
07:21XhmikosRMikeSmith: chrome doesn&#39;t seem to work with `stylesheet preload`
07:22XhmikosRbut maybe I&#39;m missing something so I&#39;ll wait for Scott. I tested things locally with xampp
07:23XhmikosRbut the polyfill doesn&#39;t seem to work either so I&#39;m probably missing something
07:24XhmikosRlink.rel.indexOf(&quot;preload&quot;) !== -1 true
07:24XhmikosRthe check works fine
07:25annevkrniwa: I thought HTTP defined some ABNF extensions, but I should prolly clarify that I use them
07:25rniwaannevk: maybe.
07:26rniwaannevk: I think clarifying the reference would be nice
07:39yoavMikeSmith: yo!
07:40zcorpantobie: annevk: <>
07:42yoavXhmikosR: So `<link href=foo rel=&quot;stylesheet preload&quot; as=style>` doesn&#39;t work in current Chrome impl?
07:42yoavNot 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:42XhmikosRyoav: from a quick test it doesn&#39;t seem so
07:43XhmikosRyoav: let me paste the test file, you will need php
07:43yoavXhmikosR: Can you file a bug with a test case and send it my way?
07:43XhmikosR(not my tests)
07:43XhmikosRif we verify it doesn&#39;t work sure :)
07:43XhmikosRwould be nice if it didn&#39;t require php
07:43XhmikosRbut Scott&#39;s test is using it
07:44XhmikosRlet me fork his repo so that things are public
07:46XhmikosR(freaking tabs for indentation :P)
07:47zcorpanXhmikosR: seems to work over here... (network inspector shows 1 fetch; if i remove `as` it shows 2 fetches)
07:47zcorpanand style is applied
07:47XhmikosRsec guys
07:47XhmikosRmight be something with the polyfill
07:48zcorpanyoav: (has there been progress on not doing a fetch for <link rel=preload> without as?)
07:49yoavzcorpan: I&#39;m half-way through PRs to get that done (got distracted by travel and shiny objects...)
07:49zcorpanyoav: cool
07:50yoavXhmikosR: `<link rel=&quot;stylesheet preload&quot; href=&quot;slow.css.php&quot; as=&quot;style&quot;>` will be a blocking style
07:50yoavwhich I think is counter to what you&#39;re trying to do
07:51XhmikosRI see it&#39;s blocking
07:51zcorpan the README suggests using rel=&quot;preload&quot; sans stylesheet
07:51XhmikosRthe problem is we can&#39;t use integrity unless rel has stylesheet, or I misunderstood the issue?
07:51zcorpanand then i guess the script adds stylesheet
07:51XhmikosRzcorpan: I changed the check
07:52yoavyou currently cannot use preload with integrity
07:52yoavadding a rel=style won&#39;t help you with that
07:52XhmikosRah I see
07:52XhmikosRthat is what I&#39;m trying to solve
07:53zcorpanthat&#39;s interesting. i guess we should make that work
07:53yoavwe definitely should
07:53zcorpanmkwst_: ^
07:53yoavzcorpan: current options are:
07:54yoav1) add an `integrity` attribute to `<link rel=preload>`
07:54yoav2) Jump through various implementation hoops that will enable to reuse preloaded resources and perform the integrity check at reuse time
07:55yoav(as well as letting script preloads through even if `require-sri-for-script` is present)
07:56XhmikosRI was just looking at the polyfill since I&#39;m a FF user but since Chrome doesn&#39;t work we are currently out of luck
07:56yoavI guess that 2) is the &quot;right&quot; way to solve it, assuming implementation is feasible (I don&#39;t own SRI impl so not sure how complex that would be)
07:56yoavXhmikosR: sorry! :/
07:56zcorpani 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&#39;t
07:57XhmikosRthis makes sense ^^
07:57yoavzcorpan: yeah, but isn&#39;t that just throwing the burden on devs rather than solving it internally?
07:58zcorpanyoav: the burden being having to use integrity attribute on their preload link?
07:59zcorpanmaybe 2 has better developer ergonomics
07:59yoavthat&#39;s what I&#39;m thinking
07:59zcorpanbut with the loadCSS pattern it doesn&#39;t really matter since it uses the same <link> and just appends &quot; stylesheet&quot; to rel when it&#39;s ready
08:01yoavI&#39;ll try to ping jww and see if he has an opinion on how complex integrity checks on existing resources would be
08:01zcorpanso i think it should at least be *allowed* to specify integrity=&quot;&quot; for rel=preload. how we then deal with it in implementation is not something i can have an informed opinion on
08:05XhmikosRirrelevant but if something happens to GitHub we are screwed with almost everything hosted on it :/
08:05XhmikosR(noticed Python moved to GH too)
08:08yoavzcorpan: and if integrity on preload mismatches and integrity on the reusing element does?
08:08yoavwe don&#39;t use the resource?
08:12yoavzcorpan: unless you have a use-case that would require applying the integrity check on both the preloaded resource and the reusing element...
08:13annevkyoav: if it mismatches for the preload it simply wouldn&#39;t end up in the preload cache since you got back a network error from Fetch
08:13annevkyoav: this is all fairly simple and would fall out of properly defining preload...
08:13annevkso please start looking at that, rather than all the things around it
08:13yoavdoes Fetch buffer the resource before returning it?
08:14annevkyoav: it does if you add integrity, yes
08:16yoavannevk: fwiw, this is not about defining preload, but about defining the concept of &quot;memory cache&quot;
08:17yoavwhich I agree we need to define, but may be a long(ish) term project
08:18yoavBrowsers currently disagree on behavior in various ways, so I suspect defining it will take time
08:18annevkfor non-Chrome it&#39;s basically about defining preload
08:18annevkif this is used in other places, it might be worth tackling those too, but I&#39;m not sure we should tightly couple them
08:19yoavWebKit has similar behavior to Chrome in that respect
08:19annevkOkay, but I don&#39;t see why you and igrigorik keep postponing it, since it&#39;s obvious that there&#39;s many many issues coming out of it not being defined
08:19annevkAnd it&#39;s been like that for at least a year or so
08:21yoavannevk: I really want to define it, but need to figure out a way to scope it down, as I don&#39;t have the bandwidth to take it on as a huge project
08:28annevkyoav: how complicated is that code?
08:29annevkyoav: presumably it takes a URL and returns an ongoing fetch or some such?
08:29annevkyoav: and I guess fetch() and XHR bypass it?
08:30annevkyoav: and preload lets things stay in longer or some such? so there&#39;s some kind of max timeout
08:30annevkyoav: it&#39;s probably somewhat involved to test it
08:30yoavannevk: it&#39;s fairly complex (we&#39;re currently cleaning it up)
08:31yoavIt 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:32annevkit can&#39;t just be a resource since <script src=x><script src=x>
08:32yoavWebKit has a similar set of conditions (not necessarily identical, but very close)
08:32annevkwell, <script async src=x></script><script async src=x></script>, if that ends up with one fetch, it&#39;s not a resource that&#39;s returned
08:32yoavResource is the internal representation of a fetch (which may be in flight)
08:33annevkit doesn&#39;t sound like an awfully big project to add that kind of &quot;fetch cache&quot;
08:33yoavso writing down what happens in Blink/WebKit during those checks is probably doable
08:34yoavbut I&#39;m not familiar with Firefox&#39;s code in that area (and have no visibility into Edge)
08:36yoavand I suspect each one of those checks will also require a (much needed but lengthy) discussion of &quot;do we really need that?&quot;
08:38yoavannevk: I can probably start tackling that next week or the week after that, and see how it goes
08:38yoavstarting by documenting the existing implementations
08:38yoavwhich will probably require feedback from Mozilla folks
08:39annevkYeah I think having a description of Chrome/WebKit&#39;s model would be good as reference
08:39annevkAnd then we can figure out if others want to implement that too
08:39annevkFor non-preload purposes
08:39annevkAnd we can figure out if the Chrome/WebKit model has holes with respect to CSP and such
08:40yoavI suspect it won&#39;t, as it tends to err on the side of &quot;reload the resource&quot;
08:40annevkmkwst_ probably audited the code
08:40annevkI hope so anyway
08:40yoavoh yeah
09:17annevkCan someone look at and tell me what is going wrong? jgraham?
09:43JakeAannevk: all I&#39;m getting internally about the HTML outline is &quot;we think it might break sites&quot; but no evidence as yet
09:43JakeAannevk: anything from Moz?
09:43annevkJakeA: basically lack of time
09:44JakeAannevk: kinda sad that browsers did all of the bits except the a11y bit
09:44JakeAI guess that&#39;s nothing new
09:44annevkJakeA: the breaking site thing seems super weird to me
09:44annevkJakeA: we rolled out this feature somewhat poorly
09:44JakeAannevk: I mean, it&#39;ll change the outline of some sites, but I don&#39;t know if it&#39;d be &quot;bad&quot;
09:44annevkJakeA: 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:45JakeAannevk: right! And that&#39;s what&#39;s happening on that w3c thread. Everyone&#39;s super excited about the prospect of a ****new tag****
09:46annevkJakeA: yeah, new features are shiny, fixing infrastructure is not
09:46annevkJakeA: which reminds me, browsers still haven&#39;t removed appcache...
09:47JakeAannevk: there&#39;s a vague worry internally that it&#39;s being used by intranets, but again, not seen any evidence
09:47annevkJakeA: can&#39;t they do the long term removal for intranets?
09:47annevkJakeA: with some kind of flag for enterprises
09:47annevkJakeA: and just let that flag exist for 1.5 years
09:48annevkJakeA: isn&#39;t that how showModalDialog got removed?
09:48JakeAannevk: yeah, that seems fair
09:48annevkJakeA: it&#39;s long, but it&#39;s better than just letting the code rot and be a source of vulnerabilities
10:16JakeAannevk: I&#39;m not sure what else I need to do to get merged. Travis is barfing, but it isn&#39;t clear on what, or if it&#39;s related to the PR
10:17annevkJakeA: it seems the results for Chrome are unstable?
10:18annevkJakeA: I second the problem with Travis though, the output is not great
10:20JakeAannevk: yeah, I can&#39;t figure out if it&#39;s specific to my tests
10:23jgrahamJakeA: That seems pretty clear from the GitHub comment? Chrome timed out on 2 runs out of 8, so the tests are unstable and can&#39;t yet land
10:23jgrahamannevk: It looks like for some reason travis thought that branch contained hundreds of commits
10:23jgrahamI&#39;m not sure why
10:23JakeAmaybe because I rebased
10:24JakeAjgraham: ah, I didn&#39;t spot the relevant part in the wall of text
10:25zcorpanDomenic: &quot;I wonder if we can do it purely through CSS (I doubt it).&quot; - was this intended to trigger a knee-jerk on my part to fix it just to prove you wrong?
10:25annevkjgraham: I think what&#39;s going on is that he&#39;s trying to merge into the MicrosoftEdge branch rather than master
10:25jgrahamJakeA: Anything you suggest to make it more obvious? It&#39;s at the top in bold. <blink> doesn&#39;t work these days
10:26jgrahamannevk: Oh, that could be it
10:26annevkjgraham: your comment tipped me off somehow, even though I had seen it trying to apply hundreds of commits
10:28jgrahamannevk: We can probably make that work in the bot, but I don&#39;t know why you would do that in general
10:28JakeAjgraham: :P I guess fold all the passes into a click-to-reveal thing. The &quot;everything&#39;s ok&quot; parts of the messages are huge compared to the &quot;here&#39;s the actual problem&quot;
10:28jgrahamI hope Microsoft haven&#39;t got the idea that they should put all their commits in a MicrosoftEdge branch
10:28jgrahamJakeA: Hmm, does nested <details> work? Could try it
10:29JakeAjgraham: I dunno :(
10:29JakeAjgraham: in this case the unstable tests are nothing to do with my PR. Should it block me from merging?
10:30annevkjgraham: I&#39;m hoping it was just a mistake, we&#39;ll hear tomorrow hopefully
10:30Ms2gerJakeA, is it the rebase or the test-helpers.sub.js change?
10:31annevkjgraham: nested works
10:31MikeSmithannevk: if I got anything wrong at lemme know or comment/answer there when you got time
10:32JakeAMs2ger: hmm, maybe, I&#39;m not sure how it works
10:33Ms2gerI think it&#39;s accurately detecting that your change affected all the things
10:34annevkMikeSmith: seems accurate enough
10:34annevkMikeSmith: I suspect he doesn&#39;t like CORS and thought fetch() would give a way out
10:34Ms2gerJakeA, I guess I can merge
10:35JakeAMs2ger: I can&#39;t see how that change could make other tests unstable, but browsers have surprised me before
10:36Ms2gerJakeA, it probably just made the checker run a test it hadn&#39;t before
10:39JakeAThanks for merging!
10:42MikeSmithannevk: thanksand 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:42MikeSmithI wonder now how often other people might think that
10:42JakeAit isn&#39;t the first time I&#39;ve seen it
10:43annevknaming :-(
10:43JakeASeen a few people think it&#39;s a &quot;security? Pfft, no thanks&quot; switch
10:44MikeSmithI guess we should have some better simple documentation (at MDN) that clearly explains what &quot;no-cors&quot; really means. There doesnt actually see to be something like that at MDN yet
10:45JakeAFetch is poorly understood by developers
10:45JakeAI can&#39;t say I understood it well before service worker
10:45annevkPresumably understanding was worse before it was written down
10:46annevkThere used to be no answer to what happens for redirects to <script> element fetches
10:47MikeSmithyeah and IMHO its not really the job of specs to make things clear to developers. Thats what MDN etc are much better suited for
10:47MikeSmithI like the Fetch spec the way it is
10:48MikeSmithbecause its like playing a kind of puzzle game
10:48MikeSmith...where you have follow clues all over the place to figure things out
10:48JakeAThere&#39;s probably an article in &quot;how fetch works&quot;
10:49JakeANot many developers know there&#39;s such thing as a CORS request. Many think it&#39;s just part of the response.
10:50MikeSmithah yeah they dont understand the browsers enforce the cross-origin request restrictions
10:50JakeA(at some point we need to get range requests into the spec)
10:51MikeSmithanyway 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:53MikeSmithin contrast I think Im becoming less and less fond of how the HTML spec intermingles UA requirements with a lot of informational stuff for authors/web-devs
10:53MikeSmiththough I think its possible to put both in the same spec well if they are more clearly delineated
10:53MikeSmithmore like what the URL spec does
10:57annevkMikeSmith: URL was modeled after HTML&#39;s syntax section
10:57annevkMikeSmith: that section of HTML doesn&#39;t cause much confusion (though there is some I suppose), but the remainder of the standard doesn&#39;t have the clear distinction
11:30annevkJakeA: what about
11:33annevkJakeA: that&#39;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:37JakeAannevk: ah yes, will remove that bit now
11:38annevkI looked around a bit and couldn&#39;t find another standard that uses the skip flag, other than Service Workers that is
11:38annevkSo hopefully we don&#39;t break anyone
11:39JakeAhappy to make PRs for them if we find any
11:39annevksweet, seems unlikely though
11:52jgrahamJakeA, annevk: PRs up for both your issues. Dunno if they work yet though
12:33Ms2gerWhat&#39;s up with Steve Faulkner suddenly hating the w3c?
12:42zcorpanThe annoying warning doesn&#39;t work well with narrow viewports (it overflows upwards)
12:44annevkSnapshot warning?
12:45annevkAlso breaks dfn.js when collapsed
12:45annevkMs2ger: did he quit w3c/html?
12:46Ms2gerDunno, he&#39;s whining about drm on twitter
12:47annevkI saw that
12:47annevkWhenever things go negative for W3C just blame the members
12:48annevkBut don&#39;t let the members near anything positive, that was all W3C
12:48annevkSuch a silly refrain
12:55annevkJakeA: just need a commit message now, I usually do one between ``` and ``` as a new comment
12:55annevkJakeA: should indicate the issues fixed, tests and a summary at the top as title
13:11annevkAlright, we can now modify through GitHub
13:12annevkSetup seems to work
13:40* Ms2ger wonders how accurate the address element on the front page is
13:41gsneddersMs2ger: front page of what?
13:44annevkMs2ger: contents are being changed
13:45annevkMs2ger: mostly to direct to whatwg/meta or Hixie
13:45annevkMs2ger: instead of the mailing list
13:45annevkMs2ger: but the frontpage in general has some problems with out-of-date links, if anyone has ideas for an overhaul that doesn&#39;t really require us to link to nine things that&#39;d be great
14:03annevkAnd fixed
14:10annevkzcorpan: oh lol, it&#39;s actually called &quot;annoying warning&quot;
14:10annevkzcorpan: in the markup
14:11zcorpanannevk: yep
14:11zcorpanannevk: good to keep the right expectations for anyone touching the code :-)
14:11annevkzcorpan: changes LGTM
14:12annevkzcorpan: is the markup/style documented standalone someplace? It seems we could use it on for a number of things
14:14zcorpanannevk: i don&#39;t follow the question
14:14annevkzcorpan: if it&#39;s easy to reuse annoying warning elsewhere
14:17zcorpanannevk: 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:17annevkzcorpan: script is embedded in the markup then?
14:17MikeSmithwanderview: wondering if you have implemented <link rel=serviceworker> support
14:18zcorpanannevk: i don&#39;t think there&#39;s any script, it&#39;s just a <details>
14:18annevkzcorpan: oh, with fancy styling, cool
14:18wanderviewMikeSmith: I don&#39;t think so
14:19* MikeSmith looks
14:19MikeSmithwanderview: thank you
14:19wanderviewthe header was added for foreign fetch support and we&#39;ve been putting off working on that feature
14:27annevkThanks wanderview for filing the Gecko bug
14:27wanderviewnp... I haven&#39;t been as good at filing those bugs lately
14:27annevkJakeA: perhaps you can update that issue with the Chrome bug as well?
14:28annevkwanderview: I&#39;m trying to take over that task for any new changes, but I forgot about this one since I didn&#39;t write the PR
14:36annevkJakeA: 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:37JakeANoted for future. Cheers!
16:27XhmikosR@MikeSmith: can you reply on the loadCSS issue? I don&#39;t know the names of the guys here
16:28MikeSmithXhmikosR: yes I will
16:28XhmikosRunfortunately for subresource we need `stylesheet preload` but then preload breaks if I understood correctly
16:46gsneddersis it still the case that web fonts start to load when the browser finds the first use of it?
17:13DomenicMikeSmith: 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&#39;s not the direction we&#39;re focused on, for good reasons.
17:13Domeniczcorpan: I guess I really meant getting it so that *only* the &quot;X&quot; button closes, not the whole `<summary>`.
17:14MikeSmithDomenic: OK I will make time to reply to them then
18:32TabAtkinsgsnedders: I believe so, yes.
18:50annevkDomenic: having a larger target area seems fine?
18:56Domenicannevk: yeah, just to clarify what I meant by probably impossible with CSS
19:04jyasskinWhat&#39;s the best way to put an ascii BufferSource literal into a spec example? So far I&#39;ve got Uint8Array.from(&quot;climb a mountain&quot;, c=>c.charCodeAt(0))
19:17annevkjyasskin: use TextEncoder?
19:18jyasskinannevk: Good point. I&#39;d ruled it out when I thought I needed to base64-decode the string, but I don&#39;t actually need to do that. Thanks.
15 Feb 2017
No messages
Last message: 7 days and 4 hours ago