| 02:42 | <MikeSmith> | Firefox tail in Firefox logo seems to have gotten more firey recently |
| 07:12 | <zcorpan> | annevk: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=29083 |
| 07:13 | <annevk> | cool |
| 07:18 | <zcorpan> | https://codereview.chromium.org/1154373005/ looks like good news |
| 07:23 | <MikeSmith> | zcorpan: except, it seems there haven't been any movement in that review in 2 months |
| 07:26 | <zcorpan> | MikeSmith: it's committed, no? |
| 07:32 | <Ms2ger> | Is it? That review tool is awful at actually communicating anything to the uninitiated |
| 07:34 | <MikeSmith> | oh yeah maybe I just missed the fact that it was committed |
| 07:35 | <MikeSmith> | but also, what Ms2ger said |
| 07:36 | <MikeSmith> | anyway, it's good news for sure |
| 07:36 | MikeSmith | didn't mean to be the wet blanket |
| 07:46 | <jgraham> | Well the review tool does seem to put (Closed) in the title and the last comment is from the commit bot, so I think that aspect could be less clear. I have never heard anyone say they actually like that review tools though. At least not anyone who used another review tool. |
| 07:49 | <jgraham> | OTOH we are still getting requests rom Chromium engineers to make tests work over file:// so something is clearly wrong still |
| 07:53 | <annevk> | jgraham: it seems those engineers are not informed about Chromium moving to a stricter origin policy for file URLs |
| 07:55 | <jgraham> | Well I think a lot of their tests rely on the current behaviour, so GLWT, I guess |
| 07:56 | <jgraham> | But my concern was more that no one has communicated how to run tests using wptserve or, better yet, constructed a coherent system where all wpt tests are run in the same way |
| 08:15 | MikeSmith | discovers https://developer.mozilla.org/en-US/docs/Template:SpecName and finds that it looks pretty thorough and up to date |
| 08:18 | <zcorpan> | MikeSmith: except for CORS :-) |
| 08:18 | <annevk> | and all the links lacking HTTPS |
| 08:19 | <annevk> | and "DOM4" |
| 08:22 | <jgraham> | annevk: It's a wiki? :) |
| 08:23 | <annevk> | jgraham: can't 386 all the things |
| 08:24 | <hober> | but we *can* complain about all the things |
| 08:26 | <annevk> | hober: or memeify |
| 08:29 | <MikeSmith> | ok, I put together a MDN article on Subresource Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity |
| 08:30 | <MikeSmith> | and I already spent far more time on it than I should have, so anybody else feel free to "improve" it |
| 08:30 | <annevk> | MikeSmith: you haven't defined fetch(url, {integrity: ...}) it seems |
| 08:31 | <annevk> | MikeSmith: might want to mention it in #mdn on Mozilla's IRC |
| 08:31 | <MikeSmith> | yeah will send a heads-up there |
| 08:37 | <tantek> | nicely done MikeSmith |
| 08:41 | <MikeSmith> | annevk: so has that whole "Modifications to Fetch" monkey-patch in the SRI spec be superseded by it actually having been folded into the Fetch spec now? |
| 08:41 | <MikeSmith> | tantek: thanks |
| 08:42 | <annevk> | MikeSmith: there's an open PR that removes it |
| 08:42 | <annevk> | MikeSmith: Fetch already has it included |
| 08:42 | <MikeSmith> | ah ok |
| 08:53 | annevk | could use some help on https://github.com/whatwg/url/issues/62#issuecomment-134530442 |
| 08:54 | <annevk> | with* |
| 09:03 | <MikeSmith> | annevk: btw https://w3c.github.io/webappsec/specs/subresourceintegrity/#does-varresponsevar-match-varmetadatalistvar |
| 09:03 | <annevk> | MikeSmith: seems broken? |
| 09:03 | <MikeSmith> | ...is a link to the SRI spec that I found in the Fetch spec |
| 09:04 | <annevk> | MikeSmith: oh, I guess they changed links then, pretty sure I tested it |
| 09:04 | <MikeSmith> | annevk: yeah seems like a Bikeshed problem |
| 09:04 | <MikeSmith> | ah ok |
| 09:04 | <MikeSmith> | the "varresponsevar" part looks wrong though |
| 09:05 | <MikeSmith> | like, <var> markup crept into the anchor |
| 09:05 | <TabAtkins> | That's... not a Bikeshed spec. |
| 09:05 | <annevk> | yeah, they have something weird |
| 09:06 | <annevk> | ReSpec with markdown |
| 09:06 | <MikeSmith> | oh .. |
| 09:06 | <MikeSmith> | well they seem to have fixed it https://w3c.github.io/webappsec/specs/subresourceintegrity/#does-response-match-metadatalist |
| 09:07 | <annevk> | Fix deployed |
| 09:12 | <nox> | What's the status on css-selectors-4? |
| 09:12 | <nox> | Is the terminology in it mostly viable? |
| 09:13 | <TabAtkins> | Drop the "css-". It's cleaner. |
| 09:13 | <TabAtkins> | And yes. |
| 09:13 | <TabAtkins> | What terminology are you looking for specifically? |
| 09:13 | <annevk> | and the -4 |
| 09:13 | <TabAtkins> | Well, the spec's name is selectors-4 |
| 09:14 | <TabAtkins> | Sorry, selectors4 |
| 09:14 | <annevk> | :-/ |
| 09:14 | <Ms2ger> | No, it's "selectors" :) |
| 09:14 | <TabAtkins> | No it's becky |
| 09:20 | <zcorpan> | Hixie: can you look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=28796 pls? |
| 09:24 | <philipj> | zcorpan: har du tid? |
| 09:25 | <zcorpan> | philipj: ja |
| 09:26 | <jgraham> | Ska alla prata Svenska nu? |
| 09:27 | <zcorpan> | japp |
| 09:28 | <Ms2ger> | Njet |
| 09:31 | <annevk> | zcorpan: see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=29061 |
| 09:31 | <annevk> | zcorpan: it's a bit more complicated due to DOMTokenList |
| 09:34 | <zcorpan> | annevk: thx. we have relList so values can be feature-checked with that api without the case-folding idea |
| 09:35 | <annevk> | zcorpan: yeah, both sandbox and this seem to require the same thing |
| 09:53 | <nox> | TabAtkins: Compound selectors, complex selectors, are these names going to stay? |
| 09:54 | <nox> | The terminology in selectors3 was confusing. |
| 09:58 | <TabAtkins> | Yeah, that terminology is solid. |
| 10:03 | <hallvors> | annevk: in https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send step 4, will an implementation never handle input that is *neither* Document nor BodyInit ? |
| 10:03 | <annevk> | hallvors: IDL will stringify it |
| 10:03 | <nox> | TabAtkins: Cool, thanks. |
| 10:03 | <hallvors> | annevk: OK, thx |
| 10:14 | <hallvors> | Is "Content-Type: charset=UTF-8" a valid content-type header? |
| 10:15 | <annevk> | hallvors: yes |
| 10:15 | <annevk> | hallvors: oh wait, no it isn't |
| 10:15 | <annevk> | hallvors: I read text/plain; in there somehow |
| 10:26 | <hallvors> | OK.. so the test expects such headers to be sent as they are set because it doesn't have a proper charset attribute to rewrite.. Did I get that right? |
| 10:27 | <hallvors> | (Trying to annotate the test file a bit - this is rather obscure stuff) |
| 10:28 | <annevk> | hallvors: yeah, I guess if it can't parse the Content-Type header it should leave it alone |
| 10:29 | <annevk> | hallvors: right, the XHR spec contains a "valid MIME type" check |
| 10:30 | <hallvors> | yes - I think the tests are up-to-date and match the spec carefully, it's just that they are not commented so it's hard to figure out the actual logic ;) |
| 10:30 | <hallvors> | I'll have you review the PR in a moment.. |
| 10:31 | <hallvors> | should be an easy review :) |
| 11:01 | <annevk> | Anyone have any novel URL security concerns? https://www.w3.org/Bugs/Public/show_bug.cgi?id=27642#c2 |
| 11:07 | <MikeSmith> | annevk: maybe something about data URLs? |
| 12:37 | <jgraham> | SimonSapin: http://log.csswg.org/irc.w3.org/css/2015-08-25/#e581689 seems like it's the route of maximum complexity |
| 12:37 | <jgraham> | in the long run |
| 12:39 | <SimonSapin> | jgraham: does this happen that often? |
| 12:39 | <jgraham> | SimonSapin: I don't know |
| 12:40 | <SimonSapin> | what would be a better way to deal with this? |
| 12:41 | <SimonSapin> | (I want strong arguments if I’m gonna re-open this topic) |
| 12:41 | <jgraham> | Not making backwards-incompatible changes? Not allowing implementations to optionally support older versions of the spec? |
| 12:41 | <jgraham> | I mean I don't think these will be winning arguments in CSS-land |
| 12:44 | <jgraham> | Anyway, if this doesn't happen very often I guess it's not a huge concern, but the current setup seems to either require implementations to (potentially) compare both refs on each test run, which is unnecessarily slow, or have additional metadata about which ref they expect to match, which is unmaintainable |
| 12:44 | <jgraham> | wptrunner will do the former fwiw |
| 12:45 | <astearns> | jgraham: I don't think the intent is to allow implementations to optionally support older versions |
| 12:45 | <jgraham> | If that's not the intent why wouldn't you just update the tests to require the new behaviour? |
| 12:45 | <astearns> | in addition to changing the old test to allow either result, a new test for the new result should be added to a new test suite |
| 12:46 | <jgraham> | Literally the entire CSS levels system seems to be designed around that concept |
| 12:47 | <astearns> | a 2.1 implementation will pass with the old behavior, and a new implementation will pass the old test *and* the new test |
| 12:47 | <Ms2ger> | There's no such thing as "a 2.1 implementation" |
| 12:49 | <astearns> | the initial suggestion was to remove the old test and add a new test to the level 3 test suite. fantasai countered with allowing both results in the old test |
| 12:51 | <Ms2ger> | So what's the plan for testing css-color-4? Spreading tests around in css21/, css-color-3/, css-color/4? |
| 12:51 | <Ms2ger> | -4* |
| 12:52 | <zcorpan> | css/color/ ? |
| 12:53 | <Ms2ger> | No, that would make sense |
| 12:53 | <zcorpan> | right, sorry |
| 12:54 | <Ms2ger> | Does css still require repo-wide unique file names? |
| 12:55 | <jgraham> | Yes |
| 12:56 | <hallvors> | annevk: quickie for you :) https://critic.hoppipolla.co.uk/r/5750 |
| 12:59 | <annevk> | TabAtkins: why does <a spec=html for=/>origin</a> still get confused with an <dfn>origin</dfn> in a document that is not HTML? |
| 12:59 | <annevk> | TabAtkins: why do I even need for=/ to make that work? |
| 12:59 | <TabAtkins> | ...interesting |
| 13:01 | <annevk> | hallvors: r+ |
| 13:02 | <hallvors> | annevk: thanks |
| 13:02 | <annevk> | TabAtkins: also, "unicode serialisation of an origin" from HTML appears not to be indexed |
| 13:03 | <SimonSapin> | sorry annevk http://w3cmemes.tumblr.com/post/127554590107/lazy-college-senior-csswg-continues-to-not-go |
| 13:03 | <annevk> | TabAtkins: also, many terms in DOM that are used elsewhere lack export... I guess that's the reason I cannot use them elsewhere... |
| 13:03 | <annevk> | SimonSapin: not a very interesting resolution |
| 13:04 | <annevk> | "Nobody has done work." "Let's decide to continue to not do work." |
| 13:04 | <annevk> | Film at 11 |
| 13:06 | <TabAtkins> | annevk: To be fair, I gave the explicit reason of "to annoy Anne" |
| 13:06 | <annevk> | TabAtkins: meh |
| 13:07 | <annevk> | TabAtkins: so apparently <a spec=html for=/> ends up pointing to https://html.spec.whatwg.org/multipage/infrastructure.html#concept-url-origin |
| 13:07 | <annevk> | TabAtkins: so it's not quite where I need it to end up |
| 13:08 | <TabAtkins> | annevk: HTML defines two indistinguishable "origin" terms. |
| 13:08 | <TabAtkins> | Bikeshed, unfortunately, has no way to distinguish between indistinguishable definitions, which is why it throws a fatal error if you try to define such. |
| 13:08 | <TabAtkins> | `bikeshed refs --text="origin" --type="dfn"` |
| 13:11 | <annevk> | TabAtkins: so they only way to reference all of HTML from Bikeshed is to use an anchors block? Which won't show up in the terms defined by this specification block... |
| 13:12 | <TabAtkins> | HTML's definitions aren't exported, and they're marked up shittily in the first place (which is why we're not exporting them by default; they'd stomp all over everything) |
| 13:13 | <TabAtkins> | Well, they're not marked up at all, and so Shepherd can't do much inference for them. |
| 13:13 | <TabAtkins> | Their markup isn't shitty for the purpose it was originally intended. |
| 13:13 | <annevk> | The same is true for DOM which you converted... |
| 13:13 | <TabAtkins> | Yes, I *converted* DOM. |
| 13:13 | <annevk> | And forgot to add export et al |
| 13:14 | <TabAtkins> | Oh, yeah, sure. Want me to fix all that? |
| 13:14 | <TabAtkins> | (I often forget. I've struggled for some time to figure out a non-annoying way to get Bikeshed to let you know you should export things.) |
| 13:14 | <annevk> | I dunno, I'd prefer you fix some of the other lingering issues I guess |
| 13:14 | <TabAtkins> | Working on those. |
| 13:15 | <TabAtkins> | It does suck that HTML is hard to ref. :/ |
| 13:15 | <TabAtkins> | Don't know what else I can do, tho - there is literally no way to distinguish between the two "origin" terms besides their url. |
| 13:16 | <annevk> | I guess the scraper for HTML could use the IDs |
| 13:17 | <annevk> | Or we could attempt to change the markup for HTML in some way to accommodate the scraper |
| 13:19 | <TabAtkins> | The latter would be the best, but it's a big job. |
| 13:19 | <TabAtkins> | We don't need a full conversion or anything, tho, just add some decent markup to the dfns. |
| 13:20 | <TabAtkins> | Like for origin, export both and put for=url on one and for=http on the other, or something. |
| 13:20 | <TabAtkins> | or give it lt="http origin" |
| 13:21 | <annevk> | it's not really HTTP, but I'm not sure what it would be otherwise either |
| 13:21 | <annevk> | it's sort of the definition of the core security concept of the web |
| 13:22 | <TabAtkins> | Sure, I was just going off of the IDs. |
| 13:23 | <annevk> | Oh, I guess that might be the Origin header |
| 13:23 | <annevk> | for=http would make sense there I suppose |
| 13:27 | <TabAtkins> | Ah yeah, I was thinking of adding a "header" definition category. Mike West asked for it. |
| 13:28 | <annevk> | makes sense |
| 13:28 | <annevk> | TabAtkins: I've established host, hostsyntax, url, and urlsyntax categories btw |
| 13:28 | <TabAtkins> | Hm? |
| 13:29 | <annevk> | for=urlsyntax and such |
| 13:29 | <annevk> | but maybe you meant something else |
| 13:29 | <TabAtkins> | Yeah, I meant type=header |
| 13:29 | <TabAtkins> | <dfn header>Origin</dfn>, that kind of thing |
| 13:30 | <TabAtkins> | So they're not "dfn" type terms. |
| 13:30 | <annevk> | aw |
| 13:31 | <TabAtkins> | Jeez, HTML has *three* "origin" dfns. |
| 13:32 | <annevk> | right |
| 13:32 | <TabAtkins> | #concept-url-origin, #http-origin, and #origin-2 |
| 13:32 | <TabAtkins> | wtf |
| 13:32 | <annevk> | also https://html.spec.whatwg.org/multipage/browsers.html#origin |
| 13:32 | <annevk> | oh, that's the heading |
| 13:33 | <TabAtkins> | #origin-2 is the definition you want for the core "origin" concept. |
| 13:33 | <annevk> | yeah |
| 13:36 | <TabAtkins> | annevk: Do you have the ability to fix HTML? We can at least spot-fix things as we go. Any time you need to put an HTML term in an anchors block, we can fix it in the spec. |
| 13:51 | <beverloo> | annevk, back from holiday, I'll be picking up the PR today. Sorry I didn't get to it before I left! |
| 13:57 | <annevk> | beverloo: no rush! |
| 13:58 | <zcorpan> | annevk: what's the status of URL comparison? came up for the context of @document rule |
| 13:58 | <annevk> | zcorpan: https://url.spec.whatwg.org/#url-equivalence no API yet |
| 13:58 | <annevk> | zcorpan: if you have specific use cases, I recommend filing issues |
| 13:59 | <zcorpan> | ty |
| 14:00 | <zcorpan> | annevk: looks like some spaces are missing, is that in the source or bikeshed's fault? |
| 14:02 | <annevk> | zcorpan: looks like TabAtkins' new serializer's fault :-/ |
| 14:02 | <TabAtkins> | Sorry, iterating back towards success here. Almost done! |
| 14:06 | <TabAtkins> | Working on that specific issue right now, since I noticed it in another spec. |
| 14:06 | <TabAtkins> | I know exactly what's causing it, but I'm trying to fix it without regressing in certain other matters. |
| 15:08 | <Domenic> | annevk: in https://github.com/whatwg/url/issues/62#issuecomment-134530442 do <a>/<area> have non-relative flags? |
| 15:22 | <Domenic> | TabAtkins: I am really concerned by Bikeshed's lack of regression tests... You fix things now, but we have no guarantee they stay fixed :( |
| 15:23 | <Domenic> | I guess we can start checking out specific bikeshed revisions and using those to build the spec on ci |
| 15:23 | <Domenic> | and only upgrade periodically |
| 15:31 | <TabAtkins> | Domenic: Yeah, I (a) need to start producing tagged revisions, and (b) greatly increase my test suite. |
| 15:33 | <TabAtkins> | Sucks having to be a grown-up about this now. ;_; |
| 15:35 | <darobin> | TabAtkins: welcome to my world :-p |
| 15:54 | <annevk> | Domenic: non-relative flag is a property of a URL, blob URLs would typically have it set |
| 16:00 | <Domenic> | annevk: OK, then I don't understand which URL the reset algorithm is consulting the non-relative flag of |
| 16:02 | <Domenic> | JakeA: if anyone asks about progress events in fetch, I made a thing. https://gist.github.com/domenic/95e689d0be5e24fb08ec |
| 16:02 | <nox> | Domenic: s/URL/url/ |
| 16:02 | <nox> | It looks into the url set in set the input. |
| 16:03 | <Domenic> | nox: in the new scheme there is no set the input |
| 16:03 | <nox> | Domenic: Sorry, I can't hear you from the late train. |
| 16:08 | <JakeA> | Domenic: ohh, cheers |
| 16:11 | <annevk> | Domenic: the internal url |
| 16:12 | <Domenic> | annevk: I see |
| 16:13 | <Domenic> | I think maybe inlining reset into each algorithm would be clearer tbh. |
| 16:19 | <annevk> | Domenic: that's a lot of duplication |
| 16:19 | <annevk> | Domenic: the main question I have though is whether it would make sense to separate out Location setters |
| 16:19 | <annevk> | Domenic: those are so different from all the other setters that it doesn't really make sense to handle them in a single algorithm |
| 16:19 | <Domenic> | annevk: it's one line: if internal url's non-relative flag is not set, let internal url = parse URL using get the base / get the input |
| 16:20 | <Domenic> | annevk: separating them out seems very reasonable. |
| 16:20 | <Domenic> | annevk: I was anticipating three separate interface definitions |
| 16:20 | <annevk> | Domenic: I see |
| 16:21 | <annevk> | Domenic: I was kind of hoping to keep them together |
| 16:21 | <Domenic> | i think it's much clearer separate... they act on different "this" types |
| 16:25 | <annevk> | Domenic: yeah, but it's a lot of redundancy and a new source for bugs |
| 16:26 | <annevk> | hmm |
| 16:26 | <Domenic> | I see basically zero redundancy... they're just different functions |
| 16:26 | <Domenic> | Think about the implementation |
| 16:26 | <annevk> | yes I have :-) |
| 16:26 | <Domenic> | No implementation is going to implement this as one class with each algorithm having a three-way switch statement |
| 16:26 | <Domenic> | They'll have three separate classes |
| 16:26 | <annevk> | most of these algorithms don't need a three-way switch |
| 16:27 | <annevk> | e.g., other getter can be shared across all pretty easily |
| 16:27 | <annevk> | by just making reset conditional on "get the input" as well |
| 16:27 | <Domenic> | But that kind of conditional is not fun |
| 16:27 | <Domenic> | Prefer polymorphism over branching |
| 16:28 | <Domenic> | https://sourcemaking.com/refactoring/replace-conditional-with-polymorphism |
| 16:28 | <Domenic> | having a "reset" step that is meaningless 2/3 of the time is not great |
| 16:29 | <Domenic> | hard to follow the resulting algorithm |
| 16:37 | <annevk> | Domenic: so I guess what you'd argue for is that we define them separately in URL and HTML |
| 16:37 | <annevk> | Domenic: share them between <a> and <area> |
| 16:37 | <annevk> | Domenic: put the members directly on URL.prototype |
| 16:38 | <annevk> | (well, that already happens, just through a different technique) |
| 16:38 | <annevk> | Domenic: I guess we could do that, it's a bit of duplication, but nothing too bad I suppose |
| 16:38 | <Domenic> | annevk: yeah, that sounds right. |
| 16:38 | <annevk> | I was kind of hoping we could make these properties more consistent by defining them in a single place, but so far I failed at that, so... |
| 16:40 | <Domenic> | I just think what we've learned is that they're irreducibly different |
| 16:45 | <annevk> | Getters for Location/WorkerLocation/URL could still be shared somehow, but IDL doesn't let you define getters and setters separately |
| 17:47 | <gsnedders> | is bugs.webkit.org really slow for anyone else? |
| 17:52 | <jgraham> | gsnedders: Well they're slow to fix the bugs, so… </rimshot> |
| 17:55 | <gsnedders> | well yes, I am getting annoyed by a bug first reported in 2008, and still UNCONFIRMED |
| 17:56 | <gsnedders> | https://bugs.webkit.org/show_bug.cgi?id=18954 specifically |
| 17:58 | <annevk> | gsnedders: loads fine here |
| 22:21 | <nox> | "table[border] { border-style: outset; } /* only if border is not equivalent to zero */" |
| 22:21 | <nox> | Can't that be expressed properly with selectors4's :not() and :has()? |
| 22:23 | <nox> | Mmmh, I guess attribute selectors aren't powerful enough. |