| 08:03 | <annevk> | zcorpan_: what's the difference? |
| 08:04 | <zcorpan_> | annevk: difference between what? |
| 08:05 | <annevk> | zcorpan_: speculative fetches and parsing |
| 08:06 | <zcorpan_> | annevk: so speculative fetches can happen both from speculative parser and non-speculative parser |
| 08:08 | <zcorpan_> | annevk: with normal parsing, the tree builder decides to speculatively fetch e.g. a stylesheet when it processes the "link" token. the parser batches DOM insertions so the element can be inserted to the DOM at some later time |
| 08:09 | <zcorpan_> | (and scripts have opportunity to modify the DOM in between) |
| 08:11 | <zcorpan_> | from what I can tell, that's the case that's relevant for https://github.com/privacycg/proposals/issues/19 -- not speculative fetches from speculative parser |
| 08:12 | <annevk> | Is the main difference that the speculative parser can be confused by document.write()? Though maybe the real parser can be confused by script too if it moved the node to a document that doesn't fetch? |
| 08:16 | <zcorpan_> | if by confused you mean that a speculative fetch turns out to be invalid, then yeah the normal parser can't be confused by document.write because ... there's no speculative parsing :) but indeed, a script can insert a CSP meta or move or remove a parent element after the normal parser started a speculative fetch |
| 08:20 | <zcorpan_> | othermaciej also mentioned predictive speculative fetches, which wouldn't come from either parser but happen as part of navigation or so |
| 08:25 | <annevk> | Thanks, to get back to the earlier questions, I think we should define when fetches can happen (and what "security context" they happen in) and how they get de-duplicated with "actual" fetches later |
| 08:45 | <zcorpan_> | :+1: |
| 08:58 | <MikeSmith> | annevk: FYI, I raised https://github.com/tabatkins/bikeshed/issues/1763 proposing that Bikeshed output have “This section is non-normative” text the way the HTML spec does. |
| 08:59 | <annevk> | MikeSmith: sounds cool |
| 08:59 | <MikeSmith> | from looking at the Bikeshed source, I think adding class=non-normative to any element will cause Bikeshed to consider that element and descendants to be non-normative |
| 09:00 | <MikeSmith> | but I don’t know if we are using sections in our Bikeshed specs |
| 09:00 | <MikeSmith> | if not, then maybe Bikeshed would need to support it through comments, as we do with the HTML spec |
| 09:00 | <MikeSmith> | <!-- NON-NORMATIVE SECTION --> |
| 09:01 | <annevk> | MikeSmith: we do not have sections currently, but we maybe should at least for algorithms as it adds some useful reading tools |
| 09:01 | <annevk> | such as highlighting variables |
| 09:01 | <MikeSmith> | hmm yeah |
| 09:02 | <MikeSmith> | well for now maybe if we just added class=non-normative to the headings in the spec sources |
| 09:03 | <MikeSmith> | and then the Bikeshed behavior would be to emit a “This section is non-normative” paragraph after any such heading |
| 09:03 | <MikeSmith> | ...if that doesn’t sound too hacky |
| 09:04 | <MikeSmith> | that way at least we wouldn’t need to add explit section wrappers just to get this, and I wouldn’t need to implement the <!-- NON-NORMATIVE SECTION --> comment thing in Bikeshed |
| 09:05 | <MikeSmith> | to me, that <!-- NON-NORMATIVE SECTION --> comment thing seems much more like a hack than just putting some class on the headings |
| 09:12 | <annevk> | MikeSmith: yeah that seems fine |
| 15:48 | <Domenic> | Actual <section> wrappers would also allow position: sticky headings; see https://github.com/whatwg/whatwg.org/issues/320 |
| 15:48 | <Domenic> | Also maybe Bikeshed/Wattsi could translate <h1> into <hN> based on section depth |
| 15:48 | <Domenic> | To make authoring a bit nicer. |