00:24
<leoisverycool>

Apologies if this is a common question -- I searched the FAQ but I don't think I saw anything https://github.com/whatwg/html/blob/main/FAQ.md

Is there a canonical representation of the HTML spec in a machine readable-format like XML or JSON as opposed to the IDL?

For example, the spec would specify that the type on a button is an "enumerated attribute" that can take "button" "submit", etc. as opposed to the IDL, which specifies a DOM String

00:25
<leoisverycool>
Certainly I could parse https://github.com/whatwg/html/blob/main/source and while it's not "hard" it's a non-trivial task
00:27
<leoisverycool>
There are quite a few scattered efforts out there -- e.g. https://github.com/tawesoft/html5spec
00:28
<leoisverycool>
Certainly I would imagine MDN does this to prepare their documentation -- but it's not immediately clear to me how or if they do that without studying their build process a lot more
00:49
<akaster (OOO πŸ¦ƒ)>
if you want to parse source, you'd be best off using or extending wattsi https://github.com/whatwg/wattsi
01:34
<Domenic>
There is no such machine-readable format besides the source itself.
02:34
<leoisverycool>

if you want to parse source, you'd be best off using or extending wattsi https://github.com/whatwg/wattsi

That makes sense. I had a look at I am impressed it is maintained and in Pascal. I agree that parsing wattsi sources (and potentially using wattsi itself) makes sense due to the useful dfntag especially. For example in the case of button, it is helpful that dfn holds context for attributes:

  <table>
   <thead>
    <tr>
     <th> Keyword
     <th> State
     <th> Brief description
   <tbody>
    <tr>
     <td><dfn attr-value for="button/type"><code
     data-x="attr-button-type-submit">submit</code></dfn>
     <td><span data-x="attr-button-type-submit-state">Submit Button</span>
     <td>Submits the form.
    <tr>
     <td><dfn attr-value for="button/type"><code data-x="attr-button-type-reset">reset</code></dfn>
     <td><span data-x="attr-button-type-reset-state">Reset Button</span>
     <td>Resets the form.
    <tr>
     <td><dfn attr-value for="button/type"><code
     data-x="attr-button-type-button">button</code></dfn>
     <td><span data-x="attr-button-type-button-state">Button</span>
     <td>Does nothing.
  </table>
  <table>
   <thead>
    <tr>
     <th> Keyword
     <th> State
     <th> Brief description
   <tbody>
    <tr>
     <td><dfn attr-value for="button/type"><code
     data-x="attr-button-type-submit">submit</code></dfn>
     <td><span data-x="attr-button-type-submit-state">Submit Button</span>
     <td>Submits the form.
    <tr>
     <td><dfn attr-value for="button/type"><code data-x="attr-button-type-reset">reset</code></dfn>
     <td><span data-x="attr-button-type-reset-state">Reset Button</span>
     <td>Resets the form.
    <tr>
     <td><dfn attr-value for="button/type"><code
     data-x="attr-button-type-button">button</code></dfn>
     <td><span data-x="attr-button-type-button-state">Button</span>
     <td>Does nothing.
  </table>
02:36
<leoisverycool>
Although I don't have a specific suggestion in mind, are maintainers of wattsi open to contributions that would extend the language? I don't have anything specific in mind at the moment, but something that could potentially help the robustness of such a parser for subsequent updates to the standard.
02:42
<leoisverycool>
For example, I could envision a collection of tags that could be used to articulate each dom element, while retaining searchability within wattsi sources and could reduce boilerplate while enhancing parseability.
02:53
<leoisverycool>

Here is a very rough example:

<h4 split-filename="form-elements">The <dfn element><code>button</code></dfn> element</h4>

<element name="button">
  <categories>
    Flow content, Phrasing content, Interactive content, Palpable content
    Listed, Labelable, Submittable, Autocapitalize-and-autocorrect inheriting
  </categories>

  <contexts>
    Where phrasing content is expected
  </contexts>

  <content-model>
    Phrasing content, no interactive content descendant, no tabindex attribute descendant
  </content-model>

  <attributes>
    Global attributes
    disabled, form, formaction, formenctype, formmethod, formnovalidate, formtarget
    name, popovertarget, popovertargetaction, type, value
  </attributes>

  <accessibility>
    <link href="https://w3c.github.io/html-aria/#el-button">For authors</link>
    <link href="https://w3c.github.io/html-aam/#el-button">For implementers</link>
  </accessibility>
...
02:53
<leoisverycool>
I would doubt it for many reasons -- but very much appreciate your consideration.
02:54
<leoisverycool>
[this isn't quite right -- but perhaps conveys the idea]
03:41
<Domenic>
Yes, we're quite open to that. Although it'd be even better if it could be done in the new Rust pre-processor layer, which is in a more well-known language and has nice things like unit tests. I'd be ideal if eventually we moved everything from Wattsi to Rust. See this example issue for one such project (not quite what you're looking for, but gives an idea): https://github.com/whatwg/html-build/issues/293 See here for the Rust layer: https://github.com/whatwg/html-build/blob/main/src/main.rs See here for some previous discussion of machine-readable stuff: https://github.com/whatwg/wattsi/issues/146 + https://github.com/whatwg/html/issues/1246
05:35
<leoisverycool>
Thank you so much
05:36
<leoisverycool>

~Aside: is there interest in moving wattsi in over to Rust? Matching the existing spec~

Edit: re-read, looks like yes

I'd be ideal if eventually we moved everything from Wattsi to Rust.

05:39
<leoisverycool>
[oh wow, I had no idea hixie worked on this back in the day.]
06:04
<leoisverycool>
Minor patch https://github.com/whatwg/wattsi/pull/164 cc/ Domenic
13:24
<Kaiido>
Small curiosity, can a node's children ever not be "in tree order"? Asking because at least in node insert, it's asked to iterate over a DocumentFragment's children in tree order and that seemed redundant, but maybe it's not.
15:03
<Ms2ger>
No, that's just saying if you have a node with children [a, b, c], you should work on a first, then b, then c
16:08
<bkardell>
Ian Hickson: https://www.software.hixie.ch/utilities/js/live-dom-viewer/ doesn't seem to be responding (indeed your domain in general)
16:08
<bkardell>
I guess this could have been a dm, but maybe someone else knows something (like the host is generally having troubles) or can help :)
17:59
<jay.herry77>
If you’re all this payment method and you needs some cash πŸ’΅ just clink on my link and join my telegram group πŸ‘πŸ‘πŸ‘πŸ‘πŸ™πŸ™ πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡ Cashapp? Chime Apple Pay? pal? Venmo? BOA? Wells Fargo? Join my channel now Got any of these Chase? BOA? Wells Fargo? Navy federal? Capital one? Truist? Att &t? PNC? TD bank? Credit union? M&T bank? Santander bank? Northwest bank? Or any other local Bank JOIN MY CHANNEL NOW TO GET PAID!!βœ… Join the telegram channel πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡ https://t.me/+ioqje81ziAYyYTc0 https://t.me/+ioqje81ziAYyYTc0 πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘†πŸ‘† @EVERYBODY @EVERYBODY @EVERBODY @EVERYBODY
18:40
<zcorpan (OOO 22 Nov)>

How do we want to handle https://github.com/whatwg/html/pull/10557 ? It looks like the boxes in OP are ticked, but it's not clear if it's web compatible yet, and there was at least one crbug filed about <select><input> (https://issues.chromium.org/issues/379612186) cc annevk

(For https://issues.chromium.org/issues/379034733#comment6 , that should be fixed in the spec PR, but maybe not yet in chromium)

22:33
<Kaiido>
No, that's just saying if you have a node with children [a, b, c], you should work on a first, then b, then c
Ok, but given that a node's children is already an ordered set, it's thus redundant to iterate it in tree order, no? Unless its order is something else than tree order.
22:56
<Domenic>

How do we want to handle https://github.com/whatwg/html/pull/10557 ? It looks like the boxes in OP are ticked, but it's not clear if it's web compatible yet, and there was at least one crbug filed about <select><input> (https://issues.chromium.org/issues/379612186) cc annevk

(For https://issues.chromium.org/issues/379034733#comment6 , that should be fixed in the spec PR, but maybe not yet in chromium)

Maybe jarhar can give us an update on the shipping plans? Is Chromium still proceeding to ship exactly what's in the PR?

I think it might be reasonable to delay landing until it's baked in stable for a while, but we could also land and revert if it's not able to make it.