| 01:01 | <Domenic> | HTML spec local build question: is there a way to make it fail on HTML parsing issues? I often get success on local build and then a failure on PR preview build (e.g. missing end-tags) This is a regression since the Rust build tools since they autocorrect bad tags. Jeremy Roman might have ideas. Ideally the Rust parser we're using would have a validating mode, but I'm not sure it does... Filing a tracking issue on html-build would be helpful. |
| 01:02 | <Domenic> | Domenic: minor [SecureContext] mess: https://github.com/w3c/webref/issues/1142#issuecomment-1930188979. Thoughts? |
| 06:37 | <Noam Rosenthal> |
|
| 09:53 | <hsivonen> | annevk: Not sure what to think of the lab9.be link at the bottom on https://util.unicode.org/UnicodeJsps/idna.jsp . The page says that Firefox resolves the link, but Firefox no longer does (because Firefox calls into ICU4C on a per-label basis and has incorrect special-case code for CJK characters that normalize to period). That is, Firefox, Chrome, and Safari mutually consistently fail to implement the spec. This raises the question if we should change the specs or the browsers. I can see arguments both ways. |
| 10:09 | <hsivonen> | I'm on track to writing code that would make the link resolve in Firefox again. Making it not resolve takes its own kind of special effort. |
| 10:13 | <mathiasbynens> | looks like we had some data loss here https://blog.whatwg.org/implementation-progress-on-the-html5-ruby-element |
| 10:17 | <mathiasbynens> | the “???” in the examples are real U+003F QUESTION MARK characters instead of the intended non-ASCII characters |
| 10:17 | <mathiasbynens> | https://web.archive.org/web/20120522110923/https://blog.whatwg.org/implementation-progress-on-the-html5-ruby-element is what it used to be |
| 10:36 | <annevk> | hsivonen: that should not resolve I think. Not sure what U+2490 gets mapped to though. |
| 10:38 | <hsivonen> | hsivonen: that should not resolve I think. Not sure what U+2490 gets mapped to though. |
| 10:39 | <hsivonen> | Well, at least I do also find actual bugs: https://unicode-org.atlassian.net/browse/ICU-22658 |
| 19:01 | <TabAtkins> | All right, https://github.com/w3c/htmldiff-ui/pull/10 filed |
| 19:09 | <akaster> | Does that fix help at all with <https://github.com/whatwg/html/issues/10072>;? 🙏 |
| 19:25 | <TabAtkins> | Does that fix help at all with <https://github.com/whatwg/html/issues/10072>;? 🙏 |
| 20:50 | <sefeng> | Domenic: I have another case for sequential focus which I am not sure which behaviour is correct. https://jsfiddle.net/qyuc0otf/ If you focus the first input and then press <TAB>, firefox moves the focus to the "second" input, Chrome and Safari moves to the <area> element |
| 21:05 | <sefeng> | I think we should do DOM orders here, so that's what Chrome and Safari do. |