| 06:10 | <howdoi> | is there a stage-4 proposal list? |
| 06:29 | <annevk> | KevinMarks_: why should it call out ETag? |
| 07:10 | <KevinMarks> | Well, conditional get applies to both etag and last modified |
| 07:11 | <annevk> | KevinMarks: the conditional request logic is mostly based on request headers |
| 07:11 | <annevk> | KevinMarks: the only reason Last-Modified is mentioned is because that header is safelisted for CORS |
| 07:12 | <annevk> | KevinMarks: not entirely sure why ETag isn't, but I'm not sure it matters much |
| 09:14 | <zcorpan> | Ms2ger: do you have an opinion on https://github.com/whatwg/html/pull/1449#issuecomment-228803521 ? |
| 09:15 | <zcorpan> | since there is machinery already for reflecting enumerated attributes for both impl and testing i don't think making this case-sensitive is necessarily simpler to implement and test |
| 09:19 | <annevk> | zcorpan: stepping on the value space seems a bigger problem |
| 09:20 | <annevk> | zcorpan: and the long term confusion that causes, e.g., with HTTP methods |
| 09:22 | <zcorpan> | annevk: yeah i agree that that is a problem |
| 10:01 | <kochi> | zcorpan: quick question: related to the recent change of offsetParent to unclosed node |
| 10:03 | <kochi> | zcorpan: if we traverse up the layout tree and find a fixed position element, which is "closed" to the context object, and if it end up that the nearest unclosed one is <body> |
| 10:04 | <kochi> | zcorpan: then it should return null, not <body>, right? |
| 10:07 | <kochi> | hmm, https://github.com/w3c/csswg-drafts/issues/159 has some follow-up question. |
| 10:11 | kochi | is reading the thread |
| 10:35 | <zcorpan> | kochi: possibly the spec is not yet what we want it to be. i also don't understand shadow dom well enough yet to be able to say what does and doesn't make sense :-) |
| 11:38 | <kochi> | zcorpan: I'm not a frontend engineer so I'm not sure whether the offsetParent usages of what @platosha put in the thread is popular in the wild or not, but my gut feeling is that the spec still needs some tweaks. |
| 11:45 | <zcorpan> | kochi: ok. happy to tweak the spec as necessary |
| 11:47 | <kochi> | zcorpan: the problem is that what is the expected answer for web developers :) |
| 11:47 | <zcorpan> | yeah |
| 12:17 | <Ms2ger> | > we can remove the "gone async" concept |
| 12:17 | <Ms2ger> | \o/ |
| 12:17 | <annevk> | Actually making the patch is the hard part |
| 12:17 | <annevk> | Well, maybe thinking it all through is too |
| 12:18 | <annevk> | Since I keep hitting new things |
| 12:19 | <kochi> | zcorpan: I posted comments on the thread. In "the nearest ancestor unclosed element", does "ancestor" mean box tree based one? (I'm not familiar with CSS terminology yet) |
| 12:19 | <kochi> | if so, an element with fixed position does not have an ancestor, right? |
| 12:21 | <zcorpan> | kochi: i think the walk is supposed to be on the DOM tree per spec |
| 12:23 | <kochi> | oh, then returning document.body for the case sounds correct, if we follow the spec strictly. |
| 12:25 | <zcorpan> | nox: SimonSapin: what about calc(10% - 10px) ? (which quirk?) |
| 12:26 | <nox> | zcorpan: Line height calculation quirk. |
| 12:26 | <SimonSapin> | zcorpan: https://quirks.spec.whatwg.org/#the-line-height-calculation-quirk " |
| 12:26 | <SimonSapin> | The border-right-width, border-left-width, padding-right and padding-left properties have a used value of zero. |
| 12:26 | <SimonSapin> | " |
| 12:26 | <nox> | This is 0 if containing block is 100px wide. |
| 12:26 | <nox> | But should that trigger the quirk? |
| 12:27 | <zcorpan> | i suppose so, per the current spec :-) but i'm happy to disable the quirk when calc() is used |
| 12:27 | <SimonSapin> | nox: we should (by which I mean do you wanna?) write test cases and see what other impls do |
| 12:28 | <nox> | zcorpan: I think we could just say "have a computed value that is definitely zero", if current browsers don't trigger quirk in such a case. |
| 12:28 | <nox> | SimonSapin: We should indeed. I may do it when I'm done with my webrender stuff. |
| 12:28 | <Ms2ger> | As long as "is definitely zero" is well-defined |
| 12:29 | <nox> | Ms2ger: Yes of course. |
| 12:29 | <SimonSapin> | s/definitely zero/0px or 0%/ |
| 12:29 | <zcorpan> | http://w3c-test.org/quirks-mode/percentage-height-calculation.html has tests for this quirk but they do not match the current spec, they match a previous version of the spec. i had to change the spec to make <body> fill the viewport |
| 12:29 | zcorpan | bbiab |
| 12:30 | <nox> | SimonSapin: Fair enough. |
| 13:55 | <zcorpan> | SimonSapin: the line-height calculation quirk should maybe take writing modes into account |
| 14:20 | <SimonSapin> | zcorpan: maybe... if impls do |
| 14:21 | <SimonSapin> | If impls need to change I'd rather remove the quirk than make it nicer |
| 14:49 | <zcorpan> | SimonSapin: i think these two quirks are ones that can't be removed. note they are also present in limited-quirks which is probably a bigger set of pages than those that are in quirks mode |
| 14:57 | <Ms2ger> | SimonSapin, we're talking about this because even Servo hit webcompat issues from not implementing the quirk, right? |
| 15:36 | <Domenic> | mathiasbynens: did you ever propose some way to get the length of a JS string in code points? |
| 16:20 | <mathiasbynens> | Domenic: no actual proposal, but I may have started an es-discuss thread about it |
| 16:20 | <Domenic> | seems more useful than .at() ;P |
| 16:20 | <mathiasbynens> | Domenic: agreed |
| 16:20 | <mathiasbynens> | Domenic: https://esdiscuss.org/topic/how-to-count-the-number-of-symbols-in-a-string |
| 16:21 | <mathiasbynens> | (…and `codePointAt`, hah!) |
| 16:22 | <mathiasbynens> | Domenic: really depends on the use case though — some systems count code points, others grapheme clusters |
| 16:22 | <Domenic> | right yeah |
| 16:22 | <Domenic> | I guess I was mostly thinking about this HTML issue https://github.com/whatwg/html/issues/1467 |
| 16:22 | <mathiasbynens> | the latter is probably more useful in general, but then again the “new” ES2015 APIs all deal with code points |
| 16:23 | <Domenic> | If we changed textarea[maxlength] to validate code point length then having something in the JS API you could compare it to would make sense |
| 16:23 | <mathiasbynens> | I see |
| 16:23 | <Domenic> | [...string].length lol |
| 16:23 | <mathiasbynens> | well, there’s always [...string].length |
| 16:23 | <mathiasbynens> | GMTA |
| 16:23 | <Domenic> | probably shorter than anything we come up with |
| 16:24 | <Domenic> | https://esdiscuss.org/topic/how-to-count-the-number-of-symbols-in-a-string#content-11 is fairly compelling too |
| 16:26 | <mathiasbynens> | yeah |
| 16:32 | <zcorpan> | Domenic: thx for reviewing as="". will check again later tonight or tomorrow. :-) |
| 16:32 | <Domenic> | :) |
| 16:56 | <SimonSapin> | zcorpan: Ms2ger: yeah, the removing bit is just wishful thinking. It's for the writing mode sensitivity we should write test cases |
| 17:19 | <annevk> | https://github.com/whatwg/html/commit/b063361829de68dc0907ecc0764e2582c105cf05 has some of the navigate restructuring I'm planning < Manishearth |
| 17:20 | <annevk> | Needs a lot of polish still |
| 17:20 | <annevk> | And even that is just a rather minor step of a whole lot of changes that are needed 😕 |
| 19:06 | <wanderview> | Domenic: is step 9.b.i of ReadableByteStreamControllerEnqueue() correct? https://streams.spec.whatwg.org/#readable-byte-stream-controller-enqueue |
| 19:06 | <wanderview> | Domenic: seems like it should be asserting its a default reader and not that the reader is unlocked? |
| 19:08 | <Domenic> | wanderview: so it is definitely a default reader; an assert might help. now trying to figure out if the assertion of it being unlocked is false... |
| 19:08 | <wanderview> | Domenic: the style in other places has been to assert the default reader there |
| 19:08 | <wanderview> | other places in the streams spec |
| 19:09 | <Domenic> | wanderview: no, I think it's correct. there are 3 cases: default reader, byob reader, no reader |
| 19:09 | <wanderview> | Domenic: like step 6.a of https://streams.spec.whatwg.org/#readable-byte-stream-controller-commit-pull-into-descriptor |
| 19:09 | <Domenic> | wanderview: step 8 => default reader. 9a => byob reader. 9b => no reader |
| 19:09 | <wanderview> | Domenic: oh, I see... ok... thanks! |
| 19:09 | <Domenic> | I think there should be some de-indenting and maybe an additional assert |
| 19:09 | <Domenic> | I will do a clarifying PR |
| 19:15 | <wanderview> | Domenic: what is the purpose of the SameRealmTransfer in ReadableByteStreamControllerEnqueue? I thought we were trying to avoid copying the buffer |
| 19:16 | <Domenic> | wanderview: transfer, not copy! |
| 19:16 | <wanderview> | Domenic: where else is this concept used? |
| 19:16 | <Domenic> | wanderview: in HTML a bunch |
| 19:17 | <Domenic> | wanderview: postMessage |
| 19:17 | <wanderview> | hmm |
| 19:17 | <wanderview> | Domenic: the whole goal here is to make the original thing that script has a hold of detached? |
| 19:18 | <Domenic> | wanderview: exactly, yeah |
| 19:18 | <Domenic> | https://blog.domenic.me/reading-from-files/ kind of goes over it, in a more abstract setting |
| 19:19 | <wanderview> | ok, thanks |
| 19:19 | wanderview | leaves a big TODO comment there for now. |
| 19:19 | <Domenic> | ^_^ |
| 19:21 | <wanderview> | Domenic: the js engine guys pointed me to a serialize/deserialize thing... but I don't think thats what we want here |
| 19:21 | <wanderview> | since thats a copy |
| 19:21 | <Domenic> | agree |
| 19:21 | <Domenic> | this should probably be pretty simple; Mozilla's lth was leading the charge on an ArrayBuffer.transfer method proposal |
| 19:22 | <Domenic> | I guess it's in nightlies https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer/transfer |
| 19:22 | <Domenic> | Ah that wasn't lth though |
| 19:22 | <wanderview> | Domenic: this is only needed for ArrayBuffers in streams spec? |
| 19:23 | <Domenic> | wanderview: in the streams spec, only ArrayBuffers are transferred, if that's what you're asking |
| 19:23 | <wanderview> | yes |
| 19:49 | <wanderview> | Domenic: should step 8.b here say "set ready" instead of "let ready"? since ready was already declared further up |
| 19:49 | <wanderview> | https://streams.spec.whatwg.org/#readable-byte-stream-controller-fill-pull-into-descriptor-from-queue |
| 19:49 | <Domenic> | wanderview: yep |
| 19:52 | <wanderview> | Domenic: want me to write an issue or do you have time to just fix it? |
| 19:52 | <Domenic> | wanderview: fixed :) |
| 19:53 | <wanderview> | thanks |