| 05:07 | <annevk> | Domenic: I suspect that’s fallout from shadow trees and that Chrome/Fx still haven’t fixed their bug but will double check later |
| 07:01 | <hsivonen> | jyasskin: thanks |
| 08:24 | <hsivonen> | https://bz.apache.org/bugzilla/show_bug.cgi?id=59311#c9 reminds me of Apache-sent text/plain for binary file vs. browsers, therefore, not treating text/plain as authoritative |
| 08:27 | annevk | sighs |
| 09:45 | zcorpan | sees https://bugs.webkit.org/show_bug.cgi?id=212069 |
| 09:45 | <zcorpan> | Does WebKit support cross-origin isolation? |
| 09:46 | <zcorpan> | https://bugs.webkit.org/show_bug.cgi?id=215407 |
| 09:51 | <annevk> | thanks zcorpan, left a comment on the first bug |
| 09:53 | <zcorpan> | 👍 |
| 10:29 | <mathiasbynens> | is it possible for the root element to somehow not take up the entire viewport (through non-default styles)? |
| 10:30 | <annevk> | mathiasbynens: I think by default it doesn't do that |
| 10:30 | <annevk> | mathiasbynens: just give it a border |
| 10:30 | <annevk> | (background and overflow might be confusing here, but they end up applying to the viewport instead when set on the root + special behavior for HTML's body element) |
| 10:33 | <mathiasbynens> | oh my this renders differently on Chrome vs. Firefox |
| 10:33 | <mathiasbynens> | data:text/html,<style>:root{border:5px solid red |
| 10:34 | <mathiasbynens> | (note: quirks mode) |
| 10:34 | <mathiasbynens> | it renders the same in standards mode thankfully |
| 10:35 | <annevk> | Not sure why Chromium and WebKit have that quirk |
| 10:35 | <mathiasbynens> | to be more precise, I'm trying to find out if there's a way for `:root { filter: ...; }` to not take effect on some part of the viewport |
| 10:37 | <annevk> | Maybe ecobos can help; filter is too new for what I know |
| 10:38 | <andreubotella> | https://quirks.spec.whatwg.org/#the-html-element-fills-the-viewport-quirk |
| 10:38 | <andreubotella> | assuming Firefox devtools' "computed" tab actually shows the computed values, the width of the html element is the actual (used) width, not auto |
| 10:43 | <annevk> | So there's a difference between getComputedStyle() and computed value and I'm not sure what DevTools does |
| 10:46 | <andreubotella> | I'm looking at wpt and there doesn't seem to be a test for that quirk |
| 10:50 | <annevk> | andreubotella: if you're interested in working on that spec I'm sure zcorpan would appreciate the help |
| 10:51 | <zcorpan> | this isn't a quirks mode thing, it's what getComputedStyle always does |
| 10:52 | <zcorpan> | https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle step 5 |
| 10:53 | <zcorpan> | -> https://drafts.csswg.org/cssom/#resolved-value |
| 10:55 | <andreubotella> | yeah, it does seem likely that the devtools "computed" tab is showing the results from getComputedStyle |
| 10:55 | <andreubotella> | that was just me trying to debug, though |
| 10:56 | <andreubotella> | <mathiasbynens> oh my this renders differently on Chrome vs. Firefox |
| 10:56 | <andreubotella> | <mathiasbynens> data:text/html,<style>:root{border:5px solid red |
| 10:57 | <zcorpan> | css/cssom/computed-style-002.html tests almost this case (getComputedStyle returning used value for 'width') |
| 10:58 | <zcorpan> | andreubotella: so firefox still doesn't implement https://quirks.spec.whatwg.org/#the-html-element-fills-the-viewport-quirk |
| 10:59 | <zcorpan> | https://bugzilla.mozilla.org/show_bug.cgi?id=1259924 |
| 11:07 | <annevk> | If Firefox DevTools use the resolved value for "computed" I wish that was called out somehow |
| 11:07 | <annevk> | Although it would be even nicer to make the specification align with the name of the public-facing API |
| 11:24 | <andreubotella> | So I think I'll write a wpt test for that quirk |
| 12:31 | <zcorpan> | andreubotella: great! http://wpt.live/quirks/ looks like there are some tests for body-fills-html |
| 12:32 | <zcorpan> | but firefox passes those, so not sure |
| 12:38 | <andreubotella> | it looks like those tests are specifically checking that the quirk *doesn't* apply in the cases that the spec excludes, and nothing's checking that it applies elsewhere |
| 12:38 | <andreubotella> | also, that's "body fills html", not "html fills viewport" |
| 12:39 | <zcorpan> | ah right |
| 12:39 | <andreubotella> | but if firefox isn't implementing that quirk, maybe it's not needed for web compat |
| 12:40 | <zcorpan> | yeeeeah, except they have web compat problems documented in the bug, and chromium and webkit aren't removing it |
| 12:40 | <zcorpan> | the spec at first sided with gecko, until they asked me to change the spec |
| 12:41 | <zcorpan> | if you can get the 4% of the web that uses quirks mode down to 0%, maybe we can drop quirks mode altogether :) |
| 12:43 | <andreubotella> | yeah, I don't think that's something I can do :D |
| 12:44 | <zcorpan> | :( :( :( |
| 13:17 | <ecobos> | mathiasbynens: `:root { filter: ... }` is special |
| 13:17 | <ecobos> | mathiasbynens: and it applies on the whole viewport, including fixed-pos elements and so on (on all browsers except FF, but we need to change that) |
| 13:18 | <mathiasbynens> | ecobos: thanks for confirming! any idea which (part of which) spec mandates this? |
| 13:20 | <ecobos> | mathiasbynens: see https://bugzilla.mozilla.org/show_bug.cgi?id=1423746 / https://github.com/w3c/fxtf-drafts/issues/11. It should really be https://drafts.fxtf.org/filter-effects/#FilterProperty (I commented on that issue a while ago to ask for that change), but it is in here: https://drafts.fxtf.org/compositing/#pagebackdrop |
| 13:20 | <ecobos> | mathiasbynens: spec could be clearer |
| 13:20 | <mathiasbynens> | ecobos: cheers! |
| 13:20 | <ecobos> | mathiasbynens: one way to get around it could be to apply an inverse filter on a given part of the page |
| 13:21 | <ecobos> | mathiasbynens: (but that only works for filters that are actually invertible) |
| 14:43 | <andreubotella> | zcorpan: looks like webkit's skipping the "auto computed value" exception for html fills viewport |
| 14:43 | <andreubotella> | s/exception/restriction |
| 14:43 | <Domenic> | (+1 to "it would be even nicer to make the specification align with the name of the public-facing API"; I made this pitch several years back but the CSSWG folks seem really attached to their computed/used/resolved hierarchy and not willing to do any renames...) |
| 14:44 | <zcorpan> | andreubotella: do you have a demo? |
| 14:44 | <andreubotella> | that tests this in particular no, but it came up in tests for body fills html |
| 14:45 | <zcorpan> | TabAtkins: ^ (re computed value) |
| 14:45 | <andreubotella> | but give me a minute |
| 14:50 | <andreubotella> | hm, turns out that's not the case |
| 14:51 | <andreubotella> | there bug is with body fills html, but it's quite an odd one |
| 14:55 | <andreubotella> | https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8657 |
| 14:56 | <andreubotella> | the body spans the whole viewport even though webkit's devtools have the html at 200x200 |
| 14:57 | <andreubotella> | then again, I'm testing this with various webkit representatives on linux because I don't have a mac around, so ymmv |
| 15:01 | ecobos | really hates that quirk |
| 15:06 | <benjamingr__> | Hey, we're ( Node.js ) considering graduating our EventTarget and AbortController from experimental to stable and would love a glance by some skilled eyes on the code to make sure it looks good ( https://github.com/nodejs/node/pull/35949 is the PR). We were unable to port the WPT (since it tests node) but we added quite a bit of coverage to it. |
| 15:06 | <benjamingr__> | Also pinging Domenic and annevk who have been very helpful in this undertaking in the past :] |
| 15:24 | <zcorpan> | andreubotella: thanks. this makes it a bit clearer: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/8658 |
| 15:24 | <zcorpan> | andreubotella: so yes, it seems webkit makes body fill the viewport, rather than filling the <html> |
| 15:25 | <zcorpan> | (the <span> is not necessary here) |
| 15:27 | <andreubotella> | zcorpan: right, I just copied from the existing tests |
| 15:46 | <annevk> | benjamingr__: nothing really comes to mind, other than wondering whether the tests you have also pass in browsers |
| 16:15 | <benjamingr__> | They all do, I usually run them in the browser console first to iterate quickly :] |
| 16:56 | <benjamingr__> | Domenic: if you don't mind - is there a specific reason event handler ordering works this way? (that is in https://github.com/nodejs/node/pull/35949#issuecomment-722496598 ) the behaviour is 1 2 3 4 and not 1 3 2 4 ? |
| 16:58 | <annevk> | benjamingr__: onmessage invokes addEventListener the first time it's called with a function that invokes the passed in function, roughly |
| 16:58 | <annevk> | benjamingr__: it falls out from how event handler attributes work, basically (defined in HTML) |
| 17:00 | <benjamingr__> | Yeah, I'm trying to figure out _why_ that's the behaviour |
| 17:00 | <benjamingr__> | That is, I assume event handlers behave this way for some reason (good or not), right? |
| 17:02 | <TimothyGu> | annevk: how much work would it be to convert Web IDL to use spec-factory? I assume spec-factory is currently only for WHATWG specs? |
| 17:03 | <annevk> | benjamingr__: I suspect it's just because that's what someone implemented back in the day |
| 17:03 | <annevk> | benjamingr__: it's not like a lot of the early web had a lot of collaborative design |
| 17:04 | <annevk> | TimothyGu: yeah, that's the case; not sure how much work it would be |
| 17:14 | <TabAtkins> | what in specific am i being pinged for? |
| 17:20 | <andreubotella> | TabAtkins: <Domenic> (+1 to "it would be even nicer to make the specification align with the name of the public-facing API"; I made this pitch several years back but the CSSWG folks seem really attached to their computed/used/resolved hierarchy and not willing to do any renames...) |
| 17:21 | <TabAtkins> | ah k. yeah, that's not happening now, it would involve changing so much verbage across so many specs; the split happened like 15 years ago |
| 17:29 | <TabAtkins> | The CSSWG at the time of the CSS2 -> CSS2.1 development made a bunch of "no, it's the children that are wrong"-type mistake |
| 18:01 | <Domenic> | What's that site with COEP/COOP/CORP stats? Something like isolation.policy, but not... |
| 18:01 | <benjamingr__> | annevk: got it :D |
| 18:03 | <benjamingr__> | By the way, two more questions I am unsure about a) are we allowed to expose a static utility to get the event listeners of an event target (kind of like `getEventListeners` in chrome)? b) are we allowed to warn (to stderr) if the number of listeners is above a certain threshold? |
| 18:03 | <Domenic> | benjamingr__: no new methods not in the spec... I'm not aware of Chrome having such a nonstandard method. |
| 18:04 | <annevk> | warn seems fine (assuming in the console) |
| 18:04 | <Domenic> | benjamingr__: console is generally up to the implementation. We do try to standardize some warnings, but a lot remain browser-specific, and that's fine, since (on the web) it's not observable |
| 18:05 | <Domenic> | benjamingr__: I guess you are referring to the method that only exists when you have the console open in Chrome? As long as it's not on the EventTarget interface itself, then it's fair game, yeah. |
| 18:05 | <benjamingr__> | Domenic: I mean something like a `utils.getEventListeners(eventTarget)` and not a `eventTarget.getEventListeners` |
| 18:05 | <Domenic> | Ah yeah, then that'd be fine |
| 18:05 | <benjamingr__> | Ah, thanks, people have been asking for that for inspecting targets |
| 18:05 | <Domenic> | People have been asking for it in the spec too, but we're a bit stuck between the encapsulation folks and others... |
| 18:06 | <Domenic> | https://github.com/whatwg/dom/issues/412 |
| 18:06 | <benjamingr__> | Interesting, thanks |
| 18:25 | <croraf> | Does the fetch standard also define how img and script html tags fetch the resources? |
| 18:25 | <annevk> | croraf: HTML does, but it uses fetch to do so |
| 18:26 | <croraf> | So the HTML standard says "fetch standard should be used for fetching"? |
| 18:28 | <annevk> | croraf: a lil more, but effectively that |
| 18:28 | <croraf> | annevk, thanks |
| 18:29 | <andreubotella> | croraf: standards do have access to some fields of the request that aren't available from the javascript fetch API, if that's something you care about |
| 18:31 | <annevk> | Ah yeah, although we haven't really updated HTML yet to poke at the internal response for <img> and <script> |
| 18:31 | <croraf> | andreubotella, I just meant in general, if the HTML spec in the tags for fetching resources requires the use of resource fetching aligned with the fetch standard. |
| 18:32 | <andreubotella> | annevk: <script> does poke at the internal response, it's <link> that doesn't |
| 18:32 | <croraf> | That is, it requries the underlying fetching is aligned with the fetch standard |
| 18:33 | <andreubotella> | I'll write a PR for that, but it looks like <link rel="icon"> won't be testable (https://github.com/whatwg/html/issues/6122) |
| 18:36 | <croraf> | andreubotella, "That is, HTML requires the underlying fetching for the tags is done using the fetch standard" Is this quote of mine correct? |
| 18:36 | <andreubotella> | yeah |
| 18:40 | <croraf> | Thanks. My next question is regarding the fetch JS API. It has the options argument, which defines headers['content-type'] property, and a body property. |
| 18:41 | <croraf> | Now, these two must be aligned, kind of. |
| 18:44 | <andreubotella> | croraf: So, depending on what JS object you pass as the body, you might get a default content-type automatically, but you can override it by setting the header explicitly |
| 18:44 | <andreubotella> | For example, a URLSearchParams object will get you Content-Type: application/x-www-form-urlencoded |
| 18:44 | <andreubotella> | I think that's part of the JS API, not the main fetch infrastructure |
| 18:46 | <croraf> | But the fetch standard also defines the JS API. It says that in the Preface: "The Fetch Standard also defines the fetch() JavaScript API" |
| 18:47 | <andreubotella> | sure, but the fetch infrastructure is defined at the spec level, not in terms of JS |
| 18:47 | <andreubotella> | thus why specs can use things JS doesn't have access to |
| 18:50 | <croraf> | I understand that the spec can access more things. My question is in the other direction. That is, where can I read how are header["content-type"] and body coordinated? |
| 18:51 | <andreubotella> | https://fetch.spec.whatwg.org/#dom-request step 37, and https://fetch.spec.whatwg.org/#concept-bodyinit-extract |
| 18:52 | <andreubotella> | as you can see, if you explicitly set the content-type header, your header wins |
| 19:00 | <croraf> | OK. And if there is no content-type header it is set by this "body extraction"? |
| 19:00 | <croraf> | andreubotella, |
| 19:01 | <andreubotella> | step 37 in the new Request algorithm starts with "If init["body"] exists and is non-null" |
| 19:02 | <andreubotella> | my bad, I misread |
| 19:02 | <andreubotella> | that's right |
| 19:04 | <croraf> | What is init["body"] is that just the value of the "body" property? |
| 19:05 | <andreubotella> | basically yeah |
| 19:07 | <croraf> | So if it is an object of ReadableStream type the extraction proceeds normally, and if it is not it will try to "cast" the body to ReadableStream? |
| 19:09 | <andreubotella> | I think this is relatively recent, so not all browsers will support a stream as the body, but yeah |
| 19:10 | <croraf> | I'm talking about 1. in https://fetch.spec.whatwg.org/#concept-bodyinit-extract |
| 19:10 | <croraf> | It is not clear to me what will be done if body is a plain JS object, or just a string, or a number... |
| 19:10 | <andreubotella> | that's where the "basically yeah" I gave above breaks down |
| 19:11 | <croraf> | Seems like JS object, a string, or number will have to be converted to the ReadableStream. |
| 19:11 | <croraf> | Oh, OK. So in which step is that handled? |
| 19:12 | <croraf> | Somewhere prior to step 37 in https://fetch.spec.whatwg.org/#dom-request ? |
| 19:12 | <andreubotella> | RequestInit's `body` takes the `BodyInit?` ("nullable BodyInit") WebIDL type |
| 19:13 | <andreubotella> | WebIDL handles the rest of JS objects, casting them to a string I suspect |
| 19:13 | <Mek> | step 1 creates a new ReadableStream, step 5 defines an "action" depending on the type of the body, and step 6 runs the action to enqueue data into the stream |
| 19:16 | <croraf> | Mek, but how does ReadableStream get created from a string, a plain JS object, or a number? |
| 19:17 | <Mek> | a string ends up in the "scalar value string" branch, which defines "action" as utf-8 encoding the string. |
| 19:17 | <Mek> | Step 6 then enqueues a Uint8Array containing that encoding to the stream that was created |
| 19:17 | <Mek> | and indeed, webidl will tostring anything that doesn't match any of the types in BodyInit |
| 19:18 | <andreubotella> | Since WebIDL handles the conversions before the params to the JS function ever get to spec-land, the "extract" algorithm won't ever have any type that isn't part of the BodyInit union |
| 19:20 | <croraf> | I think I see now. But the step 1 is confusing me very much |
| 19:21 | <croraf> | But this is kind of irrelevant because 5 is switching on an object, not on the stream. |
| 19:21 | <andreubotella> | Step 1 doesn't do any conversion, it just creates a new ReadableStream if the body wasn't one already |
| 19:21 | <andreubotella> | Step 5 then sets "action", which in step 6.1 populates the stream |
| 19:22 | <croraf> | Oh, so 1 will take the body if it is a ReadableStream, otherwise will create an empty ReadableStream (irrespective of the content of the body)? |
| 19:22 | <andreubotella> | right |
| 19:22 | <croraf> | I see. |
| 19:25 | <croraf> | And you did conclude that when entering here, the object is necesarily one of the types in the switch (5)? |
| 19:25 | <croraf> | here = https://fetch.spec.whatwg.org/#concept-bodyinit-extract |
| 19:27 | <andreubotella> | Since RequestInit's `body` is of type BodyInit?, init["body"] on the spec-land definition for new Request() is either missing (~= undefined), null, or one of the types in BodyInit |
| 19:28 | <andreubotella> | And the condition to step 37 is "if init["body"] exists and is non-null" |
| 19:30 | <croraf> | cool |
| 19:31 | <croraf> | So if it is a string Content-Type is set to text/plain;charset=UTF-8 |
| 19:32 | <croraf> | If it is URLSearchParams to application/x-www-form-urlencoded;charset=UTF-8`. |
| 19:33 | <croraf> | FormData to multipart/form-data, and the only other option that sets the Content-Type is the Blob |
| 19:34 | <croraf> | If it is of type ReadableStream, BufferSource or byte sequence, seems like Content-Type will be extracted as null. |
| 19:35 | <andreubotella> | which gets filtered out by new Request's step 37.4 |
| 19:36 | <croraf> | No, 37.4 has nothing to do with what I said. |
| 19:37 | <andreubotella> | "if Content-Type is non-null" |
| 19:37 | <croraf> | 37.4 non-null, as you said before, deals with the explicit Content-Type property value |
| 19:37 | <Bakkot> | does anyone happen to have a state machine diagram for XHR lying around? |
| 19:37 | <croraf> | Oh, sorry, indeed, 37.4 also deals with the extraction |
| 19:37 | <croraf> | that is done in 37.3 |
| 19:44 | <croraf> | Is init['body'] of type BodyInit? |
| 19:45 | <croraf> | I mean it can also be null, anything else? |
| 19:56 | <andreubotella> | croraf: WebIDL dictionary fields that don't have the "required" keyword will let you set the value to undefined in JS-land |
| 19:56 | <andreubotella> | the spec-level language for this is: init["body"] is missing, or init["body"] does not exist |
| 20:24 | <Domenic> | Bakkot: that is such a reasonable ask, but sadly I don't know of one. I'm surprised Google image search doesn't seem to have one either. |
| 20:38 | <croraf> | andreubotella, my point was more about the options handled in the switch not present in the interface: the byte sequence, and the scalar value string (which has a similar but not identical item in the interface at USVString) |
| 20:42 | <Domenic> | scalar value string === USVString |
| 20:43 | <Domenic> | byte sequence might be leftover; I can't find any callers that pass a byte sequence |
| 20:47 | <croraf> | Domenic, you think that byte sequence can perhaps be removed from the switch (5)? |
| 20:48 | <Domenic> | croraf: correct |
| 20:48 | <croraf> | And about scalar value string, why is it named differently than USVString? |
| 20:48 | <annevk> | I think we added that recently for something |
| 20:50 | <annevk> | Yeah you requested byte sequence Domenic 😊 |
| 20:50 | <annevk> | https://github.com/whatwg/fetch/issues/1073 |
| 20:50 | <Domenic> | nice... |
| 20:51 | <Domenic> | Oh, I see, I missed all the call sites of "safely extract" |
| 20:52 | <Domenic> | So yeah it definitely has uses |
| 20:52 | <Domenic> | (just not ones that appear from the fetch() API) |
| 20:53 | <croraf> | OK. What about "scalar value string", can it be replaced with USVString in the switch (5)? |
| 20:53 | <croraf> | And perhaps remove "scalar value string" completely from https://infra.spec.whatwg.org/#scalar-value-string |
| 20:56 | <Domenic> | We prefer the term "scalar value string" |
| 20:57 | <Domenic> | The fact that IDL uses WordsSmushedTogether instead of words like normal means there's a slight mismatch, but it's OK. |
| 20:57 | <croraf> | 1 word instead of 3 is more concise, and more clear visually that a "specific type" is meant. |
| 20:58 | <croraf> | Doesn't matter, but the "inconsistency" might be slightly confusing. |