| 00:04 | <TabAtkins> | Domenic: That globals email was super-helpful, thanks! This answers some questions that were recently raised for some Houdini specs. |
| 02:07 | <Domenic> | \o/ |
| 04:19 | <jdp> | hey all. does the url spec (https://url.spec.whatwg.org/) apply to all urls across all schemes? i'm asking cuz i'm unsure if postgres' strategy for specifying unix domain sockets in postgres:// urls is invalid |
| 04:20 | <jdp> | postgres percent-encodes the domain socket's path and places it in the host section of the postgres url, but according to https://url.spec.whatwg.org/#host-parsing that would be invalid, because %2F decodes to / and that would cause a syntax violation |
| 04:23 | <jdp> | for reference, toward bottom of the section: https://www.postgresql.org/docs/current/static/libpq-connect.html#AEN42532 |
| 04:38 | <annevk> | jdp: yeah, it is for all URLs |
| 04:39 | <jdp> | annevk: cool thanks |
| 06:32 | <kochi> | annevk: do you know which timezone smaug's in? |
| 06:33 | <annevk> | kochi: UTC+02:00 |
| 06:33 | <annevk> | kochi: aka Eastern European Time Zone |
| 06:33 | <annevk> | kochi: having said that, he doesn't exactly keep office hours is my impression |
| 06:34 | <kochi> | I was told that he could be in PST, so... |
| 06:35 | <kochi> | unless he's travelling, my assumption was right :) |
| 08:19 | <nox> | Specs down? |
| 08:20 | <nox> | Can't load https://quirks.spec.whatwg.org here. |
| 08:21 | <nox> | Never mind, was just slow. |
| 08:24 | <nox> | annevk: Next time someone ask about postgresql socket URLs, |
| 08:24 | <nox> | annevk: feel free to refer them to https://github.com/servo/rust-url/issues/26#issuecomment-200900094. |
| 08:25 | <zcorpan> | http://www.downforeveryoneorjustme.com/html.spec.whatwg.org :-( |
| 08:26 | <zcorpan> | Hixie_: ^ |
| 08:27 | <nox> | "In quirks mode and limited-quirks mode, for a block container element whose content is composed of inline-level elements, the element’s line-height must be ignored for the purpose of calculating the minimal height of line boxes within the element." |
| 08:27 | <nox> | So the line-height isn't ignored if the block container contains something that isn't inline, right? |
| 08:45 | <zcorpan> | nox: ...right. or this quirk is only intended to override CSS's requirements for that particular case. it could be that CSS already specifies that line-height is ignored for some other situation |
| 08:46 | <zcorpan> | nox: which case are you interested in? |
| 08:47 | <nox> | zcorpan: The line-height for a table cell. |
| 08:47 | <nox> | zcorpan: Trying to fix the HN top bar in Servo. |
| 08:51 | <zcorpan> | nox: hmmm, i think a table cell is also a block container. https://drafts.csswg.org/css2/visuren.html#block-container-element |
| 08:52 | <nox> | Yes it is, my question was about the kind of content. :) |
| 08:55 | <zcorpan> | ok, yeah, only block containers that establish an inline formatting context (i.e. only contain inlines). but if a block container has mixed inline and block you get an anonymous block to wrap the inlines, and i suppose the quirk should apply to the anonymous block? |
| 08:58 | <zcorpan> | nox: is the problem with the image? https://quirks.spec.whatwg.org/#the-line-height-calculation-quirk is also closely related |
| 09:01 | <nox> | zcorpan: Yes it's the logo. |
| 09:01 | <nox> | zcorpan: https://github.com/servo/servo/issues/11821 |
| 09:02 | <zcorpan> | ok i think you need to implement those two quirks to get that working correctly. it seems chromium passes all the tests for the two quirks |
| 09:31 | <zcorpan> | hmmm doesn't httparchive include page rank anymore? |
| 09:55 | <zcorpan> | nox: https://gist.githubusercontent.com/zcorpan/1c2fd8b55133c0e6f4892243c87b2d0a/raw/dcb7707d46379337eb719f39ac506db50530c72b/quirks_doctypes_2016_06_01.md all quirks mode urls in httparchive (sorted by their doctype) |
| 09:57 | <zcorpan> | https://gist.github.com/zcorpan/1c2fd8b55133c0e6f4892243c87b2d0a for the html version but it seems to be cut off for me, i guess github thought it was too long |
| 10:18 | mathiasbynens | was just about to mention that |
| 11:59 | <Ms2ger> | TabAtkins, still not sure you fixed https://github.com/w3c/csswg-drafts/issues/85 |
| 12:02 | <Ms2ger> | Who the hell is Mostafa Shahdadi and why are they messing with random w3c bugs? |
| 12:15 | <MikeSmith> | Ms2ger: just a spammer? |
| 12:16 | <MikeSmith> | I'm not at my pc now to check |
| 12:21 | <MikeSmith> | disabled the account |
| 12:33 | <annevk> | JakeA: data:text/html,<object data="http://example.com/gofish">I am fallback</object> and https://bugzilla.mozilla.org/show_bug.cgi?id=1003797#c20 might be of interest |
| 12:33 | <annevk> | JakeA: with two requests you can figure out 2xx |
| 12:34 | <annevk> | JakeA: given that, we could consider opening up response.ok, though I'm a little wary still |
| 12:36 | <JakeA> | annevk: struggling to figure out why it needs two requests. Why isn't <object> fallback enough? |
| 12:37 | <annevk> | JakeA: how do you tell network error from 404? |
| 12:37 | <annevk> | JakeA: maybe nobody cares about that distinction |
| 12:38 | <JakeA> | annevk: ahh, yeah. response.ok would expose the difference |
| 12:38 | <annevk> | JakeA: "My statement above is wrong, determining 2xx requires one request, telling non-2xx and network errors apart requires two." is a comment I'll add there |
| 12:39 | <annevk> | JakeA: indeed |
| 12:44 | <annevk> | <embed src=http://test:test/ onerror=w(1) onload=w(2)></embed> gives 2 in Chrome, nothing in Firefox |
| 12:44 | <JakeA> | annevk: btw, been thinking about the path to range requests & service worker. Was thinking of adding an algorithm to fetch that asserts if a given partial response is ok to use. Something in the form assertPartialResponse(response, typeAllowed) (but as an algorithm rather than API), where typeAllowed is "any", "visible" (not opaque) or a url the response |
| 12:44 | <JakeA> | must come from. It throws if not allowed, otherwise returns the next value for typeAllowed |
| 12:45 | <JakeA> | annevk: so assertPartialResponse(corsResponse, "any") returns "cors" |
| 12:45 | <JakeA> | assertPartialResponse(opaqueResponse, "any") returns the response url |
| 12:46 | <annevk> | the return value seems strange? |
| 12:46 | <annevk> | I'm not entirely sure what this does based on this description |
| 12:47 | <JakeA> | annevk: the problem is the calling API needs to be responsible for maintaining some state, since only it knows what the response is being used for |
| 12:48 | <JakeA> | Eg for a video, returning ranges from multiple cors urls is cool. Using a single no-cors url is cool. Using multiple no-cors urls is not cool. Mixing cors & no-cors is not cool. |
| 12:48 | <JakeA> | But if the video changes src, or resets somehow, we're back to the start in terms of how responses are processed |
| 12:49 | <annevk> | Does <video> today do "no-cors" and multiple range requests? |
| 12:49 | <JakeA> | yes |
| 12:50 | <annevk> | Right, that's what I thought too, not sure anyone thought through the implications of just doing that, but... |
| 12:50 | <annevk> | But also, what <video> can request is restricted. It can only ever be "no-cors" or "cors" I think |
| 12:51 | <annevk> | But you're probably getting at something else and I'm not there yet |
| 12:53 | <JakeA> | If a <video> is making no-cors requests, we need to make sure the response is either all cors responses, or no-cors responses from the same url |
| 12:54 | <JakeA> | It probably doesn't matter tons for <video>, but I want to avoid being able to return a single response that wraps opaque data in "exposeThis(` and "`)" and executes it as JS |
| 12:58 | <JakeA> | I think I need to write something up in more detail. The intent is to give APIs a way to ensure that partial responses for something that's going to be treated as a single unit don't allow parts to be opaque unless they're all from the same url |
| 13:03 | <annevk> | JakeA: I guess we also need to figure out how to make partial requests |
| 13:04 | <JakeA> | annevk: works with the fetch API today by just setting headers |
| 13:04 | <annevk> | JakeA: currently that would result in CORS preflight if you enabled CORS |
| 13:04 | <JakeA> | annevk: ah, yeah, that |
| 13:04 | <zcorpan> | LINK ERROR: No 'idl' refs found for 'supports()' with for='CSS'. |
| 13:04 | <zcorpan> | LINK ERROR: No 'method' refs found for 'supports(property, value)'. |
| 13:04 | <zcorpan> | TabAtkins: ^ |
| 13:05 | <JakeA> | annevk: and in both Chrome and Firefox we silently drop the range header if it's no-cors, which is a bug |
| 13:06 | <annevk> | I'm surprised this kind of thing is never escalated but stays under the wraps for so long |
| 13:08 | <JakeA> | annevk: oh wait, I missed a lot of important details there. We drop the header in the case of event.respondWith(fetch(event.request)) in a service worker |
| 13:08 | <JakeA> | I think it's because at some point the request gets recreated and the non-safe headers get dropped |
| 13:25 | <annevk> | fetch() does that |
| 13:25 | <annevk> | No good ideas here |
| 13:30 | <JakeA> | annevk: when this came up with client hint headers we discussed the idea of a header entry being "blessed" somehow. So if it's "ua added" it isn't filtered |
| 13:33 | <annevk> | JakeA: yeah, but UA getting a same origin bypass is… Ship sailed I guess, but still |
| 13:34 | <annevk> | JakeA: seems complex to get correct too |
| 13:49 | <annevk> | JakeA: I think we should more carefully study a concept of "passthrough" |
| 13:50 | <annevk> | JakeA: where if the request is not modified, we just pass it on to the network or cache API, without altering the headers that were already okay'd be the API in some way (however wrong we may think that is) |
| 13:51 | <JakeA> | annevk: in which cases is it wrong? |
| 13:51 | <JakeA> | Marking an immutable header object as passthrough seems fine |
| 13:51 | <annevk> | JakeA: it's arguably wrong for UAs to add Range, DNT, etc. as servers might not expect those headers coming from UAs |
| 13:52 | <annevk> | JakeA: for developers we require a CORS preflight, for UAs we just do, that's a weird security policy |
| 13:52 | <JakeA> | annevk: in this case range predates CORS right? |
| 13:52 | <annevk> | I don't think so |
| 13:52 | <annevk> | CORS is from 2006, <video> was first proposed in 2007 |
| 13:53 | <JakeA> | but download resuming? |
| 13:53 | <annevk> | DNT is definitely post-CORS |
| 13:53 | <JakeA> | (I'm assuming download resuming used range headers) |
| 13:53 | <annevk> | JakeA: not sure, perhaps |
| 14:47 | <wanderview> | annevk: JakeA: I still don't buy that its fetch() removing the range header because its unsafe... it should hit the init path that just copies the headers without going through append algorithm |
| 14:47 | wanderview | kind of misses being on European time so he doesn't have to read backscrolll first thing... |
| 14:48 | <wanderview> | step 8 of new Request says "header list is a copy of request's header list"... so I think that should avoid stripping the range header |
| 14:49 | <JakeA> | Yeah, that's right |
| 14:49 | <JakeA> | hmm |
| 14:49 | <annevk> | Ah yeah, I already do passthrough |
| 14:50 | <JakeA> | It's `init` that goes through the filtering |
| 14:50 | <ondras> | hmmh, Safari has issues with CORS with HTTP redirects |
| 14:50 | <ondras> | is this known/workaroundable? |
| 14:51 | <annevk> | wanderview: doesn't step 31 overwrite the headers either way? |
| 14:51 | <annevk> | ondras: all browsers do, to some extent |
| 14:51 | <wanderview> | annevk: ah, crap... yea |
| 14:51 | <annevk> | ondras: the main fix is submitting tests to web-platform-tests |
| 14:52 | <ondras> | annevk: well my particular use case -- cross-origin request with one HTTP redirect -- works in other browsers |
| 14:52 | <ondras> | Safari *seems* to try (does preflight for the redirected GET) |
| 14:53 | <wanderview> | annevk: JakeA: yea... and we do it just like the spec... that will remove the range headers https://dxr.mozilla.org/mozilla-central/source/dom/fetch/Request.cpp#502 |
| 14:53 | <annevk> | JakeA: wanderview: so yeah, if we want to fix stuff like that we should reconsider proper passthrough requests :/ |
| 14:53 | <ondras> | but even if I respond properly to this unnecessary preflight, it fails |
| 14:53 | <wanderview> | annevk: if we just set the guard after the fill it would be fine I think... but maybe unsafe for other cases |
| 14:53 | <annevk> | ondras: what makes it unneeded? |
| 14:54 | <ondras> | annevk: it is a GET with no custom headers |
| 14:54 | <annevk> | wanderview: I don't think we want to allow modifying the request aspects while keeping the headers |
| 14:54 | <ondras> | annevk: I am not aware of other browsers doing a preflight |
| 14:54 | <annevk> | wanderview: either nothing changes per whatever policy the API decided things were safe, or we apply the policy we know is safe |
| 14:55 | <annevk> | ondras: I see, I recommend filing bugs and maybe writing tests |
| 14:56 | <ondras> | annevk: I would love to speak to some Apple engineer first to rule out the possibility of me doing something completely wrong, but I suppose those are hard to come by? |
| 14:58 | <annevk> | ondras: a little bit, I think if you've done your homework and tested in other browsers you're generally good for a bug report |
| 15:00 | <ondras> | annevk: "To access Apple Bug Reporter, sign in with the Apple ID associated with your developer account." <-- this is the preferred way? |
| 15:00 | <annevk> | ondras: use https://bugs.webkit.org/enter_bug.cgi?product=WebKit |
| 15:00 | <ondras> | annevk: okay, thanks a lot |
| 15:01 | <annevk> | ondras: oh, and if you haven't, test in Safari Technology Preview |
| 15:01 | <ondras> | annevk: will try, thanks |
| 15:49 | <wanderview> | does anyone implement as= for <link rel=preload> now? https://github.com/whatwg/html/pull/1418#issuecomment-227481256 |
| 16:00 | <MikeSmith> | wanderview: I thought Chrome does but have not tested |
| 16:00 | <MikeSmith> | yoav would know |
| 16:00 | <MikeSmith> | or igrigorik_ |
| 16:05 | <wanderview> | thanks |
| 16:23 | smaug____ | wonders what would it take to convince blink folks to remove .chrome |
| 16:55 | <annevk> | hayato: is anyone from your team planning on adding the relatedTarget stuff to the event dispatch algorithm? |
| 16:55 | <annevk> | hayato: or is the idea that I take that on? |
| 16:56 | <annevk> | hayato: I should probably go through the remaining shadow tree issues again I suppose, got a little distracted with navigation |
| 17:51 | <TabAtkins> | Ms2ger: What do you think isn't fixed about it? (Preferably, comment in the bug.) |
| 17:54 | <Domenic> | I still find it confusing that "static" in CSS selectors means "from JavaScript" and "dynamic" means "from CSS stylesheets". I usually think of JS code as much more dynamic than CSS stylesheets. |
| 17:55 | <TabAtkins> | JS code evaluates selectors against what is, at the timescales we're dealing with, a static DOM, while stylesheets are 99% evaluated against a DOM in the process of being built or mutating. |
| 17:55 | <annevk> | "static" and "live" might match DOM terminology better |
| 17:56 | <TabAtkins> | The words carry the right semantics at least, insofar as "static" is considered cheaper or capable of handling more expensive operations than "dynamic" stuff is. |
| 19:37 | <Domenic> | Yeah not saying it's wrong, or even that it's necessarily confusing to most, but it's confusing to me. I see "we should put this in the static profile" and my gut reaction is "great, then I can use it in my static CSS stylesheets!" |
| 20:03 | <Mek> | TabAtkins: any idea why with latest bikeshed I lose about 50% of the references in the service worker spec? |
| 20:03 | <Mek> | TabAtkins: as in the list of specs in the "Normative References" section and in the "Terms defined by reference" sections are missing about half the specs with latest bikeshed... |
| 20:07 | <Mek> | TabAtkins: bisecting blames https://github.com/tabatkins/bikeshed/commit/b77fe40776dedaf83b23b77a952a1599c29ac398, before that commit all the references are there, after it half are missing |
| 20:08 | <TabAtkins> | Mek: Point me to your spec? |
| 20:08 | <Mek> | TabAtkins: https://github.com/slightlyoff/ServiceWorker/blob/master/spec/service_worker/index.bs |
| 20:08 | <Mek> | https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html is what some old bikeshed version generated, with latest bikeshed half the references are missing |
| 21:42 | <Mek> | TabAtkins: should I file a bug for the broken references? |
| 21:43 | <TabAtkins> | Nah, got it. Got distracted by some other things, but fixing it now. |
| 21:43 | <Mek> | okay, thanks |