| 01:23 | <babaca> | https://skidson.online/ Best AQW Private server AQW Is a free to play browser mmorpg you can play with your friends join us now! Join our discord below: https://discord.gg/ZAebPzpsbR |
| 07:39 | <zcorpan> |
|
| 09:04 | <sideshowbarker> | anybody know why CSS background-clip: text has not been added/upstreamed to https://drafts.csswg.org/css-backgrounds/#background-clip |
| 09:05 | <sideshowbarker> | https://compat.spec.whatwg.org/#the-webkit-background-clip-property has text allowed |
| 09:05 | <sideshowbarker> | and UAs apparently support that for background-clip |
| 09:07 | <sideshowbarker> | …but https://drafts.csswg.org/css-backgrounds/#background-clip only allows <box>#, which resolves to border-box | padding-box | content-box — while the compat spec allows border-box | padding-box | content-box | text |
| 09:12 | <sideshowbarker> | well |
| 09:12 | <sideshowbarker> | basically same question for https://compat.spec.whatwg.org/#touch-action |
| 09:16 | <sideshowbarker> | further in that case, I wonder in general how much a great idea it is for non-CSS specs to be defining CSS features to begin with |
| 09:17 | <sideshowbarker> | because in that case, the Compat spec is basically patching something in the Pointer Events spec, which is defining something that instead rightly ought to be defined in whatever appropriate a CSS spec |
| 09:27 | <annevk> | sideshowbarker: the idea is that Compat ends up integrated into the actual specs, but I don't think there's active triaging to ensure that it happens |
| 09:51 | <sideshowbarker> | annevk: OK but I guess there’s also some ambiguity about features in the Compat spec — because some of the features are things that we don’t really plan to integrate into other specs, right? |
| 09:52 | <Ms2ger 💉💉> | "we" is doing heavy lifting there :) |
| 09:52 | <sideshowbarker> | heh |
| 09:52 | <sideshowbarker> | anyway, I mean, it seems like some Compat features are features that we really don’t want developers using |
| 09:52 | <Ms2ger 💉💉> | Sure, but that hasn't stopped us from putting such features in HTML, say |
| 09:53 | <sideshowbarker> | sure |
| 09:53 | <sideshowbarker> | but for MDN at least, I think for the most part we avoid documenting stuff in the Compat spec, on the assumption that we don’t want to encourage developers to use those features |
| 09:55 | <sideshowbarker> | for example, looking back at the background-clip: text browser-compat data now, at https://developer.mozilla.org/en-US/docs/Web/CSS/background-clip#browser_compatibility, I see it’s poorly supported anyway |
| 09:57 | <sideshowbarker> | and I’m guessing that browser projects may not be very interested in improving support for it — and that’s maybe the same reason it’s not already gotten uplifted to the CSS Backgrounds spec |
| 10:00 | <Ms2ger 💉💉> | I'm confident in MDN's ability to figure this out even at a smaller than "whole spec" granularity :) |
| 10:00 | <Ms2ger 💉💉> | Anyway, I'm not going to do any work on this, so crickets |
| 10:01 | <Ms2ger 💉💉> | (Available for consulting if you want to change that, rates available on request) |
| 11:48 | <annevk> | sideshowbarker: I don't like that strategy. It's what JavaScript has used (separate "bad stuff" into an appendix) and HTML as well to some extent and it leads to misunderstandings and hard to comprehend processing models. |
| 11:49 | <annevk> | sideshowbarker: especially for simple things it seems much more straightforward if it's in the "base" standard and clearly marked as "historical" or some such. |
| 12:03 | <sideshowbarker> | annevk: I am happy with that as long as, however it’s marked, it’s with something that clearly conveys to web developers: “don’t use this” |
| 12:03 | <sideshowbarker> | …but we have cases now where the specs aren’t making that clear to developers |
| 12:03 | <sideshowbarker> | one example is: most the NavigatorID members |
| 12:04 | <sideshowbarker> | there’s nothing in that HTML spec that clearly signals to developers that that should not be trying to do anything useful with those |
| 12:06 | <sideshowbarker> | and another case is in the DOM spec spec where for some things, the only indication about them being different from anything else is a // historical comment in an IDL block |
| 12:06 | <sideshowbarker> | …which is not the clearest signal for developers, since we don’t really want them needing to ever read the IDL anyway |
| 12:38 | <annevk> | Well, // historical isn't included in "for web developer blocks" |
| 12:38 | <annevk> | NavigatorID seems like a very complex example |
| 12:39 | <annevk> | I think it's fair to say that we lack some consistency in specifications when it comes to developer-facing instructions. I think for APIs the idea has been that we cover everything in domintro blocks (and leave out what shouldn't be done), but that hasn't been consistently done. |
| 12:45 | <annevk> | TabAtkins: do Andreu Botella (he/they)'s observations help? Request's client is an environment settings object and used for defaulting of certain things. For CSS this would typically be the one associated with the document ultimately responsible for the request. Now CSS is complex and does some things differently so you might need to set certain things yourself, such as the referrer field. Also, you no longer have to go in parallel or queue a task, you can pass your callbacks to fetch and it'll do all that for you. |
| 12:46 | <annevk> | TabAtkins: also, to be clear, I still have your GitHub request in my backlog, but haven't managed to get to it yet. |
| 14:55 | <bakkot> | sideshowbarker: I don't like that strategy. It's what JavaScript has used (separate "bad stuff" into an appendix) and HTML as well to some extent and it leads to misunderstandings and hard to comprehend processing models. |
| 15:02 | <annevk> | Domenic: what do you think about doing a Twitter poll for overloading Promise<T> with functions? Also, now that I write that, I wonder what should happen if the function doesn't return a promise. There's a choice there between throwing and passing it on to resolve. |
| 15:47 | <Domenic> | sideshowbarker: annevk: in my opinion specs are not a good place to make recommendations on what developers should or should not use, except in cases where we're actively trying to remove something from the platform (like appcache, alert(), etc.). It's a total judgment call whether document.charset or document.characterSet is more correct, or node.appendChild() vs. node.append(), or compat spec stuff, or NavigatorID. |
| 15:47 | <Domenic> | MDN might be a reasonable place to make such judgments, but it shouldn't rely on specs being authoritative about anything in that regard. It needs to make its own decisions as to what APIs it supports developers using. |
| 15:48 | <Domenic> | annevk: Twitter poll seems reasonable. If it doesn't return a promise I think passing it on to resolve makes more sense. |
| 16:24 | <annevk> | Domenic: so you think not having domintro for document.all is bad? |
| 16:36 | <Domenic> | annevk: heh, fair. I guess that would be consistent with my position since we don't have plans to remove document.all. I dunno, maybe I have an exception for things that are just too weird and broken, like document.all/embed/object? |
| 16:37 | <Domenic> | But like, whether or not you use webkit-prefixed CSS stuff seems like a style choice, as long as it's well-specified and works in all browsers (like many such CSS constructs do these days). |
| 16:52 | <annevk> | I guess, but surfacing them also adds noise and complexity for those consuming the information. Why should I have to read about webkitMatchesSelector if matches will do just fine? |
| 17:01 | <jgraham> | Historically HTML in particular has given a lot of attention to what authors ought to do seperate to what works (the entire concept of a "valid" document). So it's very understandable that people would expect it to continue doing so, and that they take lack of negative indicators as implicit endorsement. |
| 17:02 | <miketayl_r> |
are you reading this on MDN? or in the DOM spec? |
| 17:03 | <jgraham> | I also tend to agree that specs in general are a pretty poor place to set authoring norms since authors shouldn't be expected to read specs as a matter of course. |
| 17:06 | <miketayl_r> | i think that second note is more useful on MDN |
| 17:06 | <miketayl_r> | (but i don't think that it's harmful in a spec) |
| 19:47 | <miketayl_r> | jgraham: where is the right place to talk about WPT? is there a testing matrix channel now? or still on IRC? |
| 19:56 | <aja> | https://matrix.to/#/#wpt:matrix.org |
| 20:01 | <miketayl_r> | nice, thanks aja |