| 01:50 | <jugglinmike> | annevk: Thanks! I'll see if I can write something up in the next week or so |
| 15:12 | <Dominic Farolino> | Just a heads up to anyone interested: https://github.com/domfarolino/specfmt is in decent shape and works in most cases I use it for, so I'd love for people to try it out more and report bugs so we can make it even better. Please give it a shot! |
| 15:13 | <Dominic Farolino> | It's not to the point yet where we can just perfectly format full pre-existing specs, but I think it's getting there... |
| 15:16 | <Dominic Farolino> | And it also currently follows WHATWG column-limit line breaking instead of semantic line breaking, so some people hate it :) Maybe it should have 2 modes |
| 15:35 | <jgraham> | Dominic Farolino: Oh interesting. Does it try to keep named things on the same line (i.e. for things like [=long reference=] avoid linebreaks after [=long)? That's been requested on the WebDriver-BiDi spec because people were finding it hard to find/update by search when needing to consider the possibility of linebreaks, and led to a proposed lint to disallow them (but no automatic enforcement, which makes me worry about the tradeoffs). |
| 15:35 | <Dominic Farolino> | No, that would be semantic line breaking, which the tool (and WHATWG specs more generally to my knowledge) do not follow. |
| 15:36 | <jgraham> | It's not what I think of when I think of semantic linebreaking at least |
| 15:36 | <jgraham> | (I thought sematic linebreaking was about putting each clause on a seperate line, even if it's rather short, which I personally dislike) |
| 15:37 | <annevk> | Dominic Farolino: most of "my" specs break at a 100 columns but never break inside a term, e.g., Fetch (sometimes I don't catch it in review though) |
| 15:38 | <annevk> | (and I tend to not break inside tags) |
| 15:38 | <Dominic Farolino> | Perhaps I don't know what semantic line breaking is then |
| 15:38 | <Dominic Farolino> | I was going off of https://github.com/tabatkins/bikeshed/issues/662#issuecomment-1332775833, which seems to indicate that WHATWG specs all break and column length regardless of whether we're inside a term |
| 15:39 | <Dominic Farolino> | Apparently that's not the case (though in HTML it definitely seems to be the case) |
| 15:40 | <Arthur Hemery> | Completely unrelated question about response headers in a navigation redirect chain: Cross-Origin-Opener-Policy was designed to be taken into account during redirects, but as far as I can tell, the HTTP fetch step (https://fetch.spec.whatwg.org/#http-fetch, S7.2.manual) returns a response with nulled out headers (https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect). Am I missing something or is it broken? |
| 15:40 | <jgraham> | Per my understanding, semantic linebreaking is when you always break after a clause, usually a comma or a fullstop, kind of like this. The argument is it makes for cleaner diffs. But I find it's hard to read, like poetry. |
| 15:41 | <annevk> | Dominic Farolino: HTML allows a break whenever there's already whitespace (you don't get to insert additional whitespace though, such as between a start tag and the first character) |
| 15:42 | <Dominic Farolino> | Yeah, the tool wraps to what I believe is consistent with HTML (I mostly wrote the tool while working on the navigation and session history rewrite) |
| 15:42 | <annevk> | Fair, I'd love a feature that avoids breaking inside terms as that makes editing a whole lot easier (no need to regex search all the time) |
| 15:44 | <Dominic Farolino> | That does seem nice. The current tool is really simple; it doesn't do any parsing to know if you're inside a term or not etc, which is why the HTML-like formatting is easiest for it. But I do personally like not breaking inside a term. PRs welcome heh! |
| 15:44 | <Dominic Farolino> | But a while ago I was told to not do that in HTML, so I just assumed that WHATWG specs were like that more generally. Good to know that's not always the case |
| 15:50 | <jgraham> | Yeah, I think to do a really nice job you'd want to actually have some kind of parser. And since spec parsing is kind of defined as "whatever bikeshed does" (except for HTML and stuff using respec, but increasingly also those), it's not that easy to produce a high quality implementation. Although maybe it doesn't really need to be that high quality. |
| 15:54 | <annevk> | Especially given all the Markdown that's now mixed with HTML... |
| 15:55 | <jgraham> | (I wonder if one could implement on top of tree-sitter or something. I suppose the dream would be an LSP server for spec documents) |
| 16:41 | <annevk> | I aspire to not dream of specs |
| 23:29 | <sideshowbarker> | https://stackoverflow.com/questions/75024554/what-javascript-dom-algorithms-behave-differently-with-an-xmldocument-than-wit |