| 09:05 | <ntim> | emilio: seems somewhat relevant to inert: https://drafts.csswg.org/css-contain-2/#content-visibility |
| 09:09 | <annevk> | Turns out turning pairs into tuples was more work than expected, but primarily due to yak shaving. On the flipside, header thingies get to have proper types now. |
| 10:04 | <emilio> | ntim: how is it related? |
| 10:04 | <emilio> | zcorpan: sure, happy to help out there |
| 10:05 | <zcorpan> | emilio: sweet, thanks |
| 10:07 | <annevk> | zcorpan: happy to learn you've progressed from reminiscing about SGML's SHORTTAG NO to XML 1.1 😛 |
| 10:08 | <zcorpan> | annevk: hey at least I'm not digging backwards in time! |
| 10:21 | <ntim> | emilio: |
| 10:21 | <ntim> | When an element skips its contents, the user agent must change the used value of the contain property so as to turn on layout containment, style containment, paint containment, and size containment. Further, its contents (the flat tree descendants of the element, including both text and elements, or the replaced content of a replaced element) are not painted (as if they had visibility: hidden) and do not respond to hit-testing (as if they had pointer-events: none). |
| 10:22 | <ntim> | without the visibility: hidden bit, it's very similar to inert |
| 10:22 | <ntim> | or maybe not |
| 10:23 | <emilio> | ntim: well, similar perhaps, but not related in any other way right? |
| 10:24 | <ntim> | emilio: inert mentions find in page, i would suspect content-visibility affects this as well |
| 10:27 | <ntim> | emilio: > The skipped contents must not be accessible to user-agent features, such as find-in-page, tab-order navigation, etc., nor be selectable or focusable. |
| 10:27 | <ntim> | this is for content-visibility: hidden |
| 10:27 | <ntim> | very similar to inert |
| 10:28 | <ntim> | if you remove visibility: hidden, it's basically inert |
| 10:43 | <emilio> | ntim: content-visibility has other intended semantics. The children of content-visibility: hidden do not render at all iirc |
| 10:43 | <emilio> | ntim: Plus it adds containment, and so on |
| 11:05 | <sideshowbarker> | annevk: My Firefox patch landed (thanks to emilio for reviewing and fixing it) and so now the latest Firefox Nightly has HTTP status codes in the relevant devtools console CORS errors. |
| 11:05 | <sideshowbarker> | working now on getting it into Safari too https://bugs.webkit.org/show_bug.cgi?id=231928 |
| 11:05 | <sideshowbarker> | getting it into Chrome will take quite a bit longer still |
| 11:09 | <annevk> | \o/ |
| 11:25 | <freddy> | uh, how do people run/test wattsi locally? I'm probably holding it wrong but the empty directory it wants as 2nd parameterdoes not seem empty enough for wattsi? |
| 11:30 | <freddy> | Ah. The 2nd argument is actually the third. |
| 11:32 | <annevk> | freddy: if you want to run it on HTML, you want to use https://github.com/whatwg/html-build |
| 11:34 | <freddy> | yup, I used that to find out how wattsi is run. I'm starting with a smaller (hopefully faster) invocation while prototyping https://github.com/whatwg/wattsi/issues/146 |
| 11:34 | <annevk> | freddy: okay |
| 11:54 | <annevk> | freddy: oh, you still don't have it working? Maybe sideshowbarker can help. I haven't played with wattsi in a while |
| 11:54 | <freddy> | still? You overestimate my my powers 😂 |
| 11:55 | <freddy> | I also just found the time to start. currently trying to add dumb WriteLn() here and there to find out where my code should go... (but then, all of this will be probably forgotten when I go on vacation in... 4 hours and only come back in a week :)) |
| 11:56 | <sideshowbarker> | I can make time to work on wattsi — especially if it’s blocking anybody |
| 11:57 | <freddy> | it's not blocking, directly. I think it just would be nice to have a "list of elements" that is slightly more guaranteed to be exhaustive |
| 11:57 | <annevk> | freddy: sorry, I meant getting it to run, not generating the index 🙂 |
| 11:57 | <sideshowbarker> | freddy: yeah 100% agreed |
| 11:58 | <sideshowbarker> | I think the wattsi code is pretty clear and overall pretty easy to work with |
| 11:58 | <freddy> | so, I can compile and run wattsi, but am still trying to find my way in terms of architecture and existing abstractions |
| 11:58 | <sideshowbarker> | ah yeah |
| 11:58 | <annevk> | sideshowbarker: if you're around, is https://github.com/whatwg/fetch/pull/1330 still okay to land? |
| 11:58 | <sideshowbarker> | to understand it, it helps if you try to think like Hixie 😋 |
| 11:59 | <sideshowbarker> | sideshowbarker: if you're around, is https://github.com/whatwg/fetch/pull/1330 still okay to land? |
| 11:59 | <annevk> | (I made a bunch of changes since your initial review) |
| 12:00 | <freddy> | pretty sure it's not terrible code. it's quite readable after all, but last time I was writing pascal is about 15 years ago. And I never met hixie :) |
| 12:01 | <freddy> | trying to print an element name gives me Operator is not overloaded: "AnsiString" + "TCanonicalString" (source is along the lines of Writeln('Looking at ' + CrossRefNode^.Element.LocalName); |
| 12:01 | <sideshowbarker> | yeah the Pascal syntax is kind of idiosyncratic — but in the end if you’re familiar with coding in C++ or Rust or something (as compared to Python or even Java), it’s not so different |
| 12:01 | <sideshowbarker> | trying to print an element name gives me Operator is not overloaded: "AnsiString" + "TCanonicalString" (source is along the lines of |
| 12:02 | <freddy> | .AsString 💡 |
| 12:03 | <sideshowbarker> | yeah that reminds me that even as much as I have worked on that code, every time I go back into, I kind of need to re-learn |
| 12:03 | <sideshowbarker> | the biggest gotchas in working with the wattsi code are in dealing with strings — there are places where it expects string constants, and if you try to give it a normal string there, it will compile, but you’re gonna end up with garbage in the output |
| 12:04 | <sideshowbarker> | and places where you have to deal with pointers in somewhat unexpected ways |
| 12:05 | <sideshowbarker> | yeah, when you dip in there, it can be frustrating — and time-consuming doing some trial-and-error at times |
| 12:09 | <sideshowbarker> | annevk: https://github.com/whatwg/fetch/pull/1330 looks perfect. And thanks much for toning down the guidance about 403s — much better without “encouraged”, and the added “Ultimately server developers have a lot of freedom in how they handle HTTP responses” language helps too |
| 12:31 | <freddy> | does Variant default to vDEV? (I assume not) |
| 12:36 | <annevk> | freddy: iirc it runs for each variant: https://github.com/whatwg/wattsi/blob/main/src/wattsi.pas#L2994 |
| 12:44 | <sideshowbarker> | yeah wattsi runs multiple passes, one for each output variant |
| 12:45 | <sideshowbarker> | so Variant doesn’t default but instead its value changes during each run |
| 12:49 | <freddy> | ok, makes sense. thx |