| 00:57 | <sideshowbarker> | We don’t seem to have anywhere a definition of what “transient activation” or “transient user activation” is. |
| 00:58 | <sideshowbarker> | I mean, I developer-friendly definition (vs something for implementors that’s just implied through what’s affected by the relevant spec requirements). |
| 00:59 | <sideshowbarker> | Is it possible to state in one or two sentences what “transient activation” actually means? |
| 01:00 | <sideshowbarker> | Does it mean “requires a user gesture”? Or does it mean more than that? |
| 01:05 | <sideshowbarker> | I take it that maybe it means, the entire browsing context is one that’s somehow known to have been triggered by a user gesture, and therefore for all features within that browsing context that would normally be considered to require a separate user gesture, the user gesture is considered to have already happened? |
| 01:08 | <sideshowbarker> | Does “transition activation” mean the same thing as saying the user gesture has been “propagated”? Or are those two things not synonymous (but instead there’s some more complex relation)? |
| 01:09 | <sideshowbarker> | I’m trying to read between the lines of the discussion at https://github.com/whatwg/html/issues/1903 (and other places) |
| 01:10 | <sideshowbarker> | …and https://docs.google.com/document/d/1erpl1yqJlc1pH0QvVVmi1s3WzqQLsEXTLLh6VuYp228/edit# |
| 01:14 | <sideshowbarker> | …and https://html.spec.whatwg.org/multipage/interaction.html#user-activation-gated-apis |
| 01:17 | <sideshowbarker> | context is that this has come up in recent MDN article content which uses the term “transient user activation” without us yet having defined that term anywhere in MDN (and without having any external definition to link to) |
| 01:17 | <sideshowbarker> | I guess I should wait to hear from Domenic for some guidance |
| 02:54 | <sideshowbarker> | Draft definition: https://pr7962.content.dev.mdn.mozit.cloud/en-US/docs/Glossary/Transient_activation |
| 02:54 | <sideshowbarker> | Transient activation (or "transient user activation") is a window state that indicates a user has recently pressed a button, moved a mouse, used a menu, or performed some other user interaction. |
| 02:55 | <sideshowbarker> | PR at https://github.com/mdn/content/pull/7962 |
| 07:03 | <annevk> | Domenic: no I missed that. My concern was more that a caller might want something like str.substring(0,10), but is okay with getting back shorter strings and doesn't want to truncate the length argument based on the input |
| 07:04 | <annevk> | Domenic: and similarly you might want to do str.substring(5,1), but be okay with getting back the empty string for strings that are not at least 6 long |
| 07:18 | <sideshowbarker> | https://lists.w3.org/Archives/Public/public-webappsec/2021Aug/0009.html reading Martin Thompson say that he finds some part of a spec “mind-numbingly arcane”, I no longer feel so bad for similar mind-numbness I feel when reading some specs. Kind of feel like I’m in pretty good company now… |
| 07:20 | <sideshowbarker> | this makes me think the entire navigate algorithm should ideally have a non-normative domintro box saying something meaningful for normal readers about what the algorithm does and what some key points/effects are |
| 07:21 | <sideshowbarker> | and in general, for other algorithms, across our core specs |
| 07:22 | <sideshowbarker> | …because people do read actually those algorithms and try to exfiltrate some understanding from them |
| 07:25 | <sideshowbarker> | I feel like the only people who actually have a clear understanding of the navigate algorithm are the editors who wrote it and maybe the implementors who implemented it — but I suspect even the implementors, to (re)understand it, would end up needing to go back and look at the code they wrote, rather than the prose of the spec |
| 07:28 | <sideshowbarker> | And to be clear, I’m not complaining about the quality of spec prose — just saying it’s kind of inherently going to be arcane to pretty much anybody. And so supplementing it with some kind of non-normative domintro intro or outro could help a bit for orienting readers. |
| 07:33 | <Ms2ger 💉💉> | Are there any implementors who actually implemented the navigate algorithm as written by now? :) |
| 07:34 | <sideshowbarker> | touché |
| 11:53 | <Sam Sneddon [:gsnedders]> | this makes me think the entire navigate algorithm should ideally have a non-normative domintro box saying something meaningful for normal readers about what the algorithm does and what some key points/effects are |
| 12:01 | sideshowbarker | looks |
| 12:04 | <hsivonen> | I'm a bit skeptical if https://github.com/html5lib/html5lib-tests/blob/master/tokenizer/domjs.test#L197 is worth enough having that it makes sense to expose more API surface in a parser implementation in order to pass it. |
| 12:08 | <Sam Sneddon [:gsnedders]> | What's the challenge there? Needing to know whether the source string came from endianness-unknown UTF-8/16 etc.? |
| 12:09 | <hsivonen> | What's the challenge there? Needing to know whether the source string came from endianness-unknown UTF-8/16 etc.? |
| 12:09 | <Sam Sneddon [:gsnedders]> | per spec, BOM removal is part of the decode step in Encoding, right? |
| 12:10 | <hsivonen> | per spec, BOM removal is part of the decode step in Encoding, right? |
| 12:23 | <hsivonen> | Well, I suppose there's already a de facto release of the parser from the validator-nu branch, so it's not worthwhile to try to avoid that bit of public API in the other branch. |
| 12:27 | <sideshowbarker> | hsivonen: I can’t remember for sure I’m not certain the validator-nu release of the parser is actually usable outside the context of integration with the HTML checker release |
| 12:28 | <hsivonen> | Well, anyway Driver.java is low-level anyway, so let's just get it merged. |
| 12:28 | <sideshowbarker> | and to be clear, the only release has been of the maven jar to the central repo — and even that’s never been announced |
| 12:28 | <sideshowbarker> | Well, anyway |
| 12:30 | <hsivonen> | I'm less happy about exposing the sniffing limit esp if https://github.com/whatwg/html/issues/6962 happens, but no exposing that one seems to block a whole lot of other patches. And that also seems to be in a low-level building block anyway. |
| 12:31 | <hsivonen> | master is now missing only 5 changesets from validator-nu and 2 of those are in-flight for m-c, so I'll probably merge them tomorrow. |
| 12:32 | <hsivonen> | The three patches that will be left are the hardest one (ambiguous ampersand) and the null doctype thing, which I'm inclined to say is a spec bug. |
| 12:32 | <hsivonen> | Null doctype name, that is. |
| 12:34 | <hsivonen> | Another possibility is merging the null doctype patches after ensuring the change isn't Web-visible, but it seems silly to have this kind of tokenizer-level difference from what's exposed via the DOM. |
| 12:35 | <sideshowbarker> | Yeah the ambiguous-ampersand one is a beast. But if I recall correctly I at least did finally manage to get that one passing all html5lib tests. So at least it is spec-conforming. |
| 12:37 | <hsivonen> | sideshowbarker: Note: I ended up discarding https://github.com/validator/htmlparser/commit/b50d61182d08f9da3cb69650c7f62126f812bb39 , so that's not included in "5" |
| 12:37 | <sideshowbarker> | about the null-doctype-name patch, I personally have no strong opinion or special insights on the harder questions about it — I just wrote it to get the relevant html5lib tests passing |
| 12:38 | sideshowbarker | sideshowbarker: Note: I ended up discarding https://github.com/validator/htmlparser/commit/b50d61182d08f9da3cb69650c7f62126f812bb39 , so that's not included in "5" |
| 12:39 | <sideshowbarker> | At this point, I can’t even remember the context for that one… |
| 12:40 | <hsivonen> | It was the addition I made the last time round I tried to merge a patch affecting EOF-in-template error reporting, but I solved it in a different way that's forward-compatible with Firefox perhaps becoming able to visualize EOF-triggered errors. |
| 12:40 | <sideshowbarker> | aha, yeah, recalling that template stuff |
| 12:41 | <sideshowbarker> | anyway the main end goal I had with all the open PRs/patches I wrote was that we could set up CI to run the html5lib test suite so that we could catch any regressions |
| 12:42 | <sideshowbarker> | being certain that we separately confirm we are conforming to the spec was a secondary concern for me :) because I work on faith that the html5lib tests are written to conform to the actual spec requirements |
| 12:44 | <hsivonen> | Perhaps it's the least churn for everyone if I just merge the doctype stuff and ensure that it's not Web-visible. But it would be sad if we now have so many project depending on the test suite that it's no longer worthwhile to change the spec or suite. |
| 12:44 | <sideshowbarker> | also I think for the HTML checker behavior, most (or maybe none) of these changes actually make no difference — so it’s been hard for me to feel much direct pain about any issues with them |
| 12:44 | <hsivonen> | The ones that affect Firefox View Source definitely affect the checker, too. |
| 12:45 | <sideshowbarker> | Perhaps it's the least churn for everyone if I just merge the doctype stuff and ensure that it's not Web-visible. But it would be sad if we now have so many project depending on the test suite that it's no longer worthwhile to change the spec or suite. |
| 12:46 | <sideshowbarker> | but it seems to me like there are not that many projects that are using the test suite and would definitely break / need to change their implementations |
| 12:47 | <sideshowbarker> | I mean, it seems like it’s on the order of just 6 or 7? |
| 12:47 | <hsivonen> | Not sure how many there are. |
| 12:48 | <hsivonen> | My primary concern is that leaving this oddity in could make non-browser-DOM APIs diverge from browsers in what they expose. However, probably no one care about what the non-browser API expose for doctype. |
| 12:48 | <sideshowbarker> | I think most of the non-browser implementations would not be resistant to changing their code. But it’s the browser projects that would. |
| 12:49 | <hsivonen> | Does any browser project even run the tokenizer tests? |
| 12:49 | <sideshowbarker> | However, probably no one care about what the non-browser API expose for doctype. |
| 12:49 | <hsivonen> | Firefox runs them only on the Java level. |
| 12:50 | <sideshowbarker> | Does any browser project even run the tokenizer tests? |
| 12:51 | <hsivonen> | Let's see if someone else comments here soon. I need to step away from the computer for a bit now. |
| 12:51 | <sideshowbarker> | OK |
| 17:32 | <Sam Sneddon [:gsnedders]> | Does any browser project even run the tokenizer tests? |
| 17:34 | <Sam Sneddon [:gsnedders]> | honestly I think having a longer discussion about the tokeniser tests and their value is probably worthwhile; there's no trivial path to convert them to tree construction tests (given there's no guarantee what they're testing will actually create a different tree for a slightly different sequence of tokens), but I think there's some questions about their value |
| 17:34 | <Sam Sneddon [:gsnedders]> | even just giving "here's the tokens that would be generated by the tokeniser" (without the tree constructor changing state?) for each tree construction test might be actually as valuable |
| 17:36 | <Sam Sneddon [:gsnedders]> | but of course that again means changing the tree construction test format to include them, which I know Henri has objected to before |
| 18:25 | <Domenic> | accent-color is now a thing. The only interesting form controls I could find to WHATWG-green-ify are those on https://participate.whatwg.org/agreement but then it looks weird next to the blue links... |