01:31
<Domenic>

Note that we have several large changes in flight: my speculation rules (large addition), jmdyck's <div algorithm> work https://github.com/whatwg/html/pull/11392, and zcorpan's reformatting https://github.com/whatwg/html/pull/11640 .

I landed speculation rules, so the other two will need a bit of rebasing.

It seems like at least zcorpan's work is easy to rebase. Maybe we should target landing jmdyck's algorithm work first, since it seems more painful to rebase?

04:43
<zcorpan>
Yes. I was thinking of running reformahtml in ci so that PRs fail if they use formatting that the script would change
05:59
<annevk>
zcorpan: can we make it work for Bikeshed too you think? Would be nice if we can apply it everywhere
06:17
<zcorpan>
I'll have a word with chatgpt 🙂
09:13
<Noam Rosenthal>
zcorpan, annevk
We would like to move HTML out-of-order streaming to stage 1 (https://github.com/whatwg/html/issues/11542)
It seems to pass the bar we've defined for stage 1 (see https://github.com/whatwg/html/issues/11542#issuecomment-3269569121)
Obviously there are still details to flesh out before it makes it in.
Any thoughts/objections?
cc foolip
09:29
<zcorpan>
Noam Rosenthal: OK with me
09:43
<annevk>
Noam Rosenthal: stage 1 seems okay. I do think the API shape will need some changes. We need to come up with a coherent story for all HTML manipulation methods going forward, including replacement for insertAdjacentHTML() and such.
09:44
<foolip>
Yeah, the API shape if definitely not stable.
10:05
<zcorpan>
specfmt --full-spec 0.18s user 0.04s system 86% cpu 0.256 total python3 reformahtml.py ../../whatwg/html/source 1.37s user 0.05s system 97% cpu 1.467 total
10:09
<zcorpan>
Is Python vs Rust perf difference important here? Contributors won't need to run it locally going forward (just once for existing PRs)
10:10
<annevk>
Adam Rice would you be interested in becoming the Streams Workstream editor? Mattias Buelens would you be okay with that as well? (Both of you will continue to be editor of the Streams Standard. This is primarily to establish who gets to handle disputes.)
10:14
<Domenic>

I think it's fine as long as these are separate tools used at will/on CI. (Like specfmt is only used at-will today.)

Eventually an ideal architecture would probably be to incorporate it into whatwg/html-build so that ./build.sh errors on formatting issues, so people can detect them locally without running CI. At that point faster would be better.

I do suspect ChatGPT could do a good job porting the Python to Rust. If you check out the recent PRs to whatwg/html-build from today, it's been helpful.

10:19
<zcorpan>
Domenic: integrating with the build step (and maybe bikeshed?) seems like a good idea. I'm wondering if we should make specfmt support a no-breaking mode and improve the output for --full-spec (e.g. right now it reformats tags in head), or continue with reformahtml to support bikeshed syntax, add tests, and then convert to rust
10:20
<Domenic>
What Bikeshed syntax were you thinking about? Our strategy so far has been to add various Bikeshed functionality to Wattsi + html-build.
10:22
<zcorpan>
I was thinking of supporting markdown. But I guess we don't use markdown for whatwg specs, and csswg prefer semantic breaks, so maybe it's not needed
10:24
<zcorpan>
DOM uses <p>-less markdown paragraphs
10:28
<Domenic>
Streams is pretty much as Markdown as it can be
10:28
<Domenic>
But yeah I'd suggest just contributing directly to the Rust parts of html-build. With AI, Rust is not so bad.
10:32
<zcorpan>
annevk wanted to be able to reformat the bikeshed specs also though
10:39
<Domenic>
Oh, I see, I totally misunderstood. That explains why you were thinking of updating specfmt, since it already supports those...
11:19
<zcorpan>
Yeah
11:20
<zcorpan>
It seems easy enough to support markdown paragraphs and lists though
11:39
<annevk>
DOM using <p>-less paragraphs seems like a mistake, but there's definitely a few WHATWG specifications leaning more heavily into Markdown these days. If we could agree on some kind of canonical format I'd happily switch to that though.
13:18
<Dominic Farolino>
What do you mean no-breaking mode?
13:19
<Dominic Farolino>
Fwiw I use specfmt all the time on bikeshed specs. It works for markdown lists and other markdown features/syntax. The Observable spec is very markdown-ey and I've used specfmt constantly throughout development
13:33
<zcorpan>
Dominic Farolino: https://github.com/whatwg/html/pull/11640
14:10
<annevk>
jmdyck: I guess if Simon's PR doesn't address the whitespace issues you found then a separate PR would be helpful, yes.
18:16
<Dominic Farolino>
OK sorry for my ignorance, are we reformatting HTML to have no line breaks then? Apologies if I missed a bunch of upstream conversation about this.
18:30
<Luke Warlow>
DOM using <p>-less paragraphs seems like a mistake, but there's definitely a few WHATWG specifications leaning more heavily into Markdown these days. If we could agree on some kind of canonical format I'd happily switch to that though.
Fwiw if we could align the formats used by the various (whatwg) specs as much as possible that would be great! It's something I run into when switching between Dom and html how the rules are different.
My two cents are that we should do away with the optional closing tags everywhere for example.
19:22
<jmdyck>
11640 is proposing no line-breaks within <p> and similar. Conversation started with zcorpan's question (in this room) on Friday, I believe.
19:52
<zcorpan>
@domfarolino:matrix.org: no worries! Yes, that's my proposal. Maybe for all whatwg specs, if editors agree. I think it will make things simpler for contributors.
19:53
<zcorpan>
@domfarolino:matrix.org: I started vibe-coding reformahtml this week as an experiment, but not married to it.