| 09:23 | <MikeSmith> | annevk: FYI https://stackoverflow.com/questions/55914486/issue-making-range-requests-in-some-browsers |
| 09:42 | <MikeSmith> | annevk: also https://stackoverflow.com/questions/55913537/does-server-302-redirect-take-precedence-over-other-xhr-callbacks |
| 09:50 | <annevk> | MikeSmith: answered second, first has an adequate answer |
| 09:51 | <MikeSmith> | thanks |
| 13:09 | <annevk> | A) "Let X be 1 if Y, or 2 otherwise." B) "Let X be 1 if Y, and 2 otherwise." |
| 13:09 | <annevk> | MikeSmith: gsnedders: jgraham: ^^ |
| 13:09 | <annevk> | please vote |
| 13:18 | <gsnedders> | annevk: B, I think. Though I think both are grammatical. |
| 13:20 | <annevk> | gsnedders: interesting, Domenic quite strongly prefers A and I was about to change things around |
| 13:20 | <gsnedders> | I don't really have a particularly storng preference. |
| 13:21 | <annevk> | It's very hard to find some kind of reference for it too |
| 13:26 | <Ms2ger> | Whatever you do, put it in infra.s.w.o |
| 13:32 | <annevk> | Yeah, I might make it a Twitter poll after all, kinda curious |
| 13:37 | <annevk> | https://twitter.com/annevk/status/1123219698198482944 |
| 13:38 | <gsnedders> | annevk: the iWeb corpus has way more hits for 'and false|true otherwise' than 'or false|true otherwise' |
| 13:39 | <annevk> | gsnedders: iWeb? |
| 13:39 | <annevk> | Domenic: ^^ |
| 13:40 | <gsnedders> | annevk: it's the largest corpora at https://www.english-corpora.org nowadays |
| 13:41 | <annevk> | padenot suggests "Let V be true if C, false otherwise" |
| 13:42 | <nox> | "Let V be C coerced as a boolean" |
| 13:42 | nox | hides. |
| 14:00 | <innovati_> | Hi! Is there any particular reason why parsed CSS and the CSSOM don't use DOM as a standard? Is there anything preventing building a DOM interface to parsed CSS stylesheets and rules? |
| 14:03 | <Domenic> | innovati_: CSS is not composed of elements, attributes, comments, CDATA sections, and text nodes, so it wouldn't be a very good fit. |
| 14:04 | <innovati_> | it's a tree structure of stylesheet lists, stylesheets that have properties and content, and css rules that have properties and content |
| 14:04 | <Domenic> | Yep, that's very different. |
| 14:05 | <Domenic> | (Also I don't think the stylesheet lists are a tree.) |
| 14:05 | <Domenic> | (They're a list.) |
| 14:05 | <innovati_> | I've been experimenting with converting CSSOM -> DOM and it does seem useful to get at it and access it that way, I guess I just didn't understand why it wasn't more like that already |
| 14:05 | <innovati_> | well you have 1 document.styleSheets just like you have 1 document.documentElement, and all other content is a child of that. Tree structure. |
| 14:06 | <Domenic> | You can always convert arbitrary data structures into other arbitrary data structures. If the converted-to data structure is flexible enough, then you can do so in a structure-preserving way, so that any arbitrary data can be put in that data structure. But that doesn't mean the converted-to data structure is the most useful one. |
| 14:07 | <innovati_> | After looking at them both I'm at a loss to understand why DOM can't work for it I guess? |
| 14:07 | <Domenic> | The thing that makes document.documentElement interesting, and part of a tree structure, is that it's an _element_. Its children are of the same type as it. document.styleSheets is a list (CSSStyleSheetList IIRC), but its children are stylesheets (CSSStyleSheet IIRC). Quite different. |
| 14:07 | <Domenic> | DOM can work for anything, is my point. It just doesn't work well. |
| 14:07 | <innovati_> | yes there are a few different types of things in CSSOM, but those can be represented by different types of nodes |
| 14:08 | <Domenic> | Yes, but for example, I could represent x76 assembly as a DOM tree. Or I could represent a dog as a DOM tree. You can come up with mappings from anything to a DOM tree. It's just not very useful. |
| 14:08 | <Domenic> | As long as you're flexible and say "oh, each part of the dog is just a type of DOM node", then you can easily map. |
| 14:09 | <innovati_> | What is it about DOM that makes it not work well for parsed CSS objects? It seems beneficial enough to bother converting CSSOM -> DOM to get at it with better tools. There are already a lot more DOM-capable tools than CSSOM-capable tools out there, I'm wondering why CSS needs its own separate Object Model and can't re-use the DOM standard, or why DOM can't be adapted to handle things like CSS while keeping it all standardized |
| 14:10 | <Domenic> | Well, DOM is very specific: one document, which contains 0-1 DOCTYPEs, 0-n processing instructions, and 1 element. That element contains children, which are elements, comments, text nodes. Elements have attributes and children; other node types do not. |
| 14:10 | <Domenic> | If something doesn't meet that exact structure, then it's not a good fit for the DOM. |
| 14:10 | <Domenic> | CSS has a very different structure: no tree, just a flat list of rules. |
| 14:11 | <Domenic> | There is no counterpart to "element" which can be infinitely nested |
| 14:11 | <Domenic> | CSS also has special rules like @media, etc., which can have one single level of nesting of other types of things inside them. There's nothing like that in DOM land. |
| 14:11 | <Domenic> | There's no text nodes; there's only rules and declarations |
| 14:11 | <Domenic> | There's no attributes. |
| 14:11 | <Domenic> | There's namespaces, but they work differently. |
| 14:12 | <Domenic> | It's best to come up with a data structure (CSSOM) which captures all these CSS-specific structures and constraints. |
| 14:12 | <Domenic> | That's all I have time for for now :). Hope it helps. |
| 14:13 | <innovati_> | there's a stylesheet list with stylesheet objects. There are properties on these stylesheet objects that seem like they could be attributes. Inside the stylesheets there are CSS rules that also have properties |
| 14:13 | <innovati_> | some CSS rules can contain other CSS rules, like @media, but it's not limited to a depth of 1 |
| 14:13 | <innovati_> | it's a true tree structure |
| 14:13 | <innovati_> | rules can contain rules can contain rules, etc |
| 14:14 | <innovati_> | I wonder how native selector nesting will be represented in CSSOM, maybe things are about to get a lot more nested |
| 14:21 | <annevk> | innovati_: if you can rewrite the existing CSS stuff on top https://dom.spec.whatwg.org/#concept-tree and reduce complexity I think that'd demonstrate that there might be something there |
| 14:21 | <annevk> | innovati_: when we're talking about more concrete objects though it makes a lot less sense to me |
| 14:22 | <annevk> | innovati_: but there is something to be said for generic operations on trees to work on both, similar to how Array operations work on typed arrays and such, to some extent |
| 14:23 | <innovati_> | This is rough - it only supports 3 CSS rule types, but it converts CSSOM to a data structure (MicroXML) which can easily be converted into DOM. Once you have it in DOM suddenly you can inspect that structure in dev tools, JS has a bajillion built-in methods for analyzing and even working with DOM that it lacks for CSSOM: https://codepen.io/tomhodgins/pen/wZNVYo |
| 14:25 | <innovati_> | I've been doing a lot of experiments with parsing and I was thinking the other day - what if that AST you parse stuff to was DOM instead of just something custom. Is that a step up from arrays and objects in JS? You get a standardized set of tools to work with it, and if you did that every time, I imagine you'd have a lot more interoperability between tools |
| 14:25 | <innovati_> | If DOM isn't that standard or isn't flexible enough, maybe it's worth there being something that can represent tree structures of data with a standard set of operations on them for that purpose instead |
| 14:26 | <annevk> | I suppose one could have a @@treewalker protocol similar to @@iterator, but I'm not sure what that would be like and for which things it would work and how |
| 14:30 | <gsnedders> | what ordering would it even use? |
| 14:31 | <annevk> | gsnedders: as long as they all use concept-tree as underlying primitive that's defined right there |
| 14:33 | <innovati_> | I have a function I use sometimes when I want to touch every rule in the tree and operate on it with a JS callback function: https://github.com/tomhodgins/cssomtools/blob/master/index.js#L20&L40 is that the sort of thing you're talking about? |
| 14:33 | <innovati_> | it has to be a recursive solution to get infinitely nested rules |
| 14:33 | <innovati_> | well, not infinite but deeply nested |
| 14:41 | <annevk> | yes (but you left) |
| 14:56 | <innovati> | hmm I guess I'll read more of the DOM spec and keep digging :D Are there other good resources for learning DOM apart from the spec itself? |
| 15:34 | <annevk> | littledan: I'm not seeing ClearKeptObjects defined anymore? |
| 16:05 | <littledan> | annevk: It's defined in https://github.com/tc39/proposal-weakrefs/pull/86/files#diff-d9d881ee65a07bfc860db6062acc5e68R162 |
| 16:06 | <littledan> | and used in https://github.com/whatwg/html/pull/4571/files#diff-36cd38f49b9afa08222c0dc9ebfe35ebR89634 |
| 16:19 | <annevk> | littledan: ah had not looked at PRs |
| 16:21 | <Domenic> | annevk: do you remember why it's AbortSignal? signal for fetch? Instead of just using undefined to mean not present? |
| 16:21 | <annevk> | Domenic: Request#signal iirc |
| 16:21 | <Domenic> | Hmm I see |
| 16:22 | <annevk> | Domenic: if there’s an interface and dictionary you run into that quickly unfortunately |
| 16:23 | <annevk> | Domenic: interface could return undefined I suppose, but might also be confusing, esp. given long tradition to not do that |
| 16:23 | <Domenic> | Yeah. Just means that the pattern is going to spread to other APIs I think. |
| 16:26 | <annevk> | Domenic: if passing the interface as dictionary makes sense that seems okay |
| 18:11 | <Soni> | can we get any sort of process for submitting feature requests? |
| 18:11 | <Soni> | https://discourse.wicg.io/t/meta-tag-for-protocol-handlers-default/3525 |
| 18:13 | <Soni> | hm... |
| 18:14 | <Soni> | wait let me try something |