| 01:51 | <Alex.hsu> | annevk: I don't hate maintainers because I'm a maintainer myself I know how hard it is to maintain, but I was amazed when I saw some questions on the MDN forums that were not answered a year ago |
| 02:14 | <sideshowbarker> | annevk: I don't hate maintainers because I'm a maintainer myself |
| 02:19 | <Alex.hsu> | If by "MDN forums", you mean https://discourse.mozilla.org, then I'm not sure how many of the maintainers actually read that. I definitely don't. But I do read (and often triage) every single issue posted to https://github.com/mdn/content/issues minutes or at most a few hours after they are posted. So I'd personally recommend you ignore the Discourse instance and just post to that GitHub issue tracker instead What I just discussed is MDN Issues My post :https://github.com/mdn/browser-compat-data/issues/15096 |
| 02:27 | <sideshowbarker> | Ah, well with BCD issues you're likely to get a response more quickly if you just go ahead and raise a PR with a patch for the relevant JSON data file |
| 02:29 | <sideshowbarker> | In this case your patch would add a note to the Android Chrome browser compat data for type=time input element |
| 02:30 | <sideshowbarker> | https://github.com/mdn/browser-compat-data/blob/main/html/elements/input/time.json#L14 |
| 02:48 | <Alex.hsu> | Ah, well with BCD issues you're likely to get a response more quickly if you just go ahead and raise a PR with a patch for the relevant JSON data file HTML only |
| 04:14 | <sideshowbarker> | I'm using the official way, without any JS effects |
| 05:21 | <Alex.hsu> | I follow this. I added an input type='time' to html, which should be displayed on android as the same as the official document https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time |
| 17:31 | <Domenic> | annevk: not sure what the latest is on ORB/CORB but it looks like a WebKit contributor wants to implement CORB per the current Fetch spec: https://lists.webkit.org/pipermail/webkit-dev/2022-March/032161.html . Might be worth chiming in with the status. |
| 19:11 | <annevk> | Domenic: thanks, yeah I guess I'll write an email tomorrow |
| 19:32 | <annevk> | Domenic: so Chris and TabAtkins were working on auto-sizing of nested documents at some point. Whatever that ends up being should maybe be able to explain embed/object? |
| 19:33 | <annevk> | Also note that farre discovered numerous weird issues in Chromium while working on making Firefox use nested documents for embed/object... We'll file bugs. |
| 19:33 | <Domenic> | Kind of... auto-resizing ended up being able to cause infinite loops, so we cut it? https://github.com/domenic/cooperatively-sized-iframes#but-what-about-auto-resizing |
| 19:33 | <Domenic> | But, how does it work for object, I wonder. |
| 19:34 | <annevk> | Well for the specific case of images you cannot get loops as they have intrinsic height/width/ratio (or at least one of those, iirc) |
| 19:34 | <Domenic> | SVG can change its own intrinsic height/width I believe |
| 19:35 | <annevk> | Yeah, though that's not a loop per se |
| 19:37 | <Domenic> | I think it could be... gonna try to create one and see what happens. |
| 19:41 | <annevk> | I mean, you could create a loop with a script I suppose, but I'm not sure that counts 🙂 |
| 19:43 | <Domenic> | Right. I guess the missing ingredient is that SVGs don't have a mode where their "viewport width" is set based on the contents of the SVG. (E.g. in HTML, a very long string of text with no spaces will cause a viewport width greater than the window width. In SVG you will be capped at whatever the width="" attribute is set to.) |
| 19:43 | <annevk> | And I guess embed/object work across origin as well currently, but that could be a special privilege |
| 19:44 | <annevk> | Right, or you don't have a width attribute at all, but then you need an aspect ratio I think |
| 20:12 | <Domenic> | I think... if you use viewBox="0 0 200 200", position: fixed; bottom: 0; puts you at 200 pixels, even if you're actually 1080 pixels tall?? |
| 20:14 | <Domenic> | No, not quite |