| 00:23 | <jugglinmike> | Is there a syntactic convention for enum values? |
| 00:35 | <jugglinmike> | It looks like they're indistinguishable from strings https://webidl.spec.whatwg.org/#idl-enums |
| 06:45 | <hacknorris> | π» |
| 08:35 | <annevk> | jugglinmike: they are, but also: https://w3ctag.github.io/design-principles/#casing-rules |
| 08:35 | <annevk> | (perhaps we should enforce those casing rules in IDL) |
| 08:44 | <hacknorris> | But im back with same question as yesterday? |
| 08:46 | <foolip> | hacknorris: It sounds like you're asking for more of https://w3c.github.io/csswg-drafts/css-values-5/#attr-notation to be supported? |
| 09:21 | <hacknorris> | sort of too but also for a way to imitiate img tag with only css |
| 09:22 | <hacknorris> | And making ot automated for different image sizes |
| 09:24 | <hacknorris> | Image source |
| 09:24 | <hacknorris> | Containers source |
| 09:25 | <hacknorris> | App-container > app-box > app-icon |
| 09:45 | <foolip> | hacknorris: I'm not sure that I understand, but WHATWG doesn't maintain CSS, if it's one or more new CSS features you'd like to suggest, https://github.com/w3c/csswg-drafts/issues is the place for that. Although just filing an issue and waiting will probably be a bad first experience, https://www.w3.org/Style/CSS/current-work#contribute might be a better place to start. |
| 09:47 | <hacknorris> | But attr() url property is documented? |
| 09:47 | <hacknorris> | just not used |
| 10:02 | <hacknorris> | And i'd like to know if there is any other way to convert custom tag to embed/img |
| 10:03 | <foolip> | It's only partially implemented, in particular using it for URLs isn't supported and a topic of security discussion, see https://github.com/w3c/csswg-drafts/issues/5092 |
| 10:05 | <foolip> | hacknorris: assuming you want something that works today, can you use a framework with a template system, to generate the complex markup from much simpler inputs? |
| 10:14 | <hacknorris> | Mhm |
| 10:15 | <hacknorris> | Dtd? |
| 10:37 | <hacknorris> | It's only partially implemented, in particular using it for URLs isn't supported and a topic of security discussion, see https://github.com/w3c/csswg-drafts/issues/5092 |
| 11:34 | <lpfreelance> | Hello, I've been playing around with the File System Access API. I experimented with it and found it may lack of a functionality. As I'm new to the WHATWG / specification world I'd rather ask here before submitting anything on the repository (https://github.com/whatwg/fs). When retrieving a FileSystemHandle (either a file or a directory) from IndexedDB storage, there is currently no direct way to test if an entry exists on user's device. While trying (on Chrome at least), you need to call a method (like May I suggest to add a new method on the FileSystemHandle interface, something like Btw, what difference is there between specification of WICG and WHATWG? I don't see which one would be more suited to eventually post my issue. |
| 11:52 | <Domenic> | In general such methods are bad, for all file system APIs, because they create TOCTTOU errors. https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use |
| 11:53 | <Domenic> | It's better to do the thing you want to do, and if it fails, handle the error, instead of checking if what you want to do is possible, then trying to do it (which might still fail) |
| 11:54 | <Domenic> | See also https://nodejs.org/api/fs.html#fsaccesspath-mode-callback for a different ecosystem's documentation of the problem |
| 11:58 | <arai> | Can there be an attribute's getter steps which has side effect? or is it prohibited? I'm wondering if we can assume all DOM-related getters (represented by attribute in WebIDL) can be considered side-effect free. the context is https://bugzilla.mozilla.org/show_bug.cgi?id=1806598 , where we're trying to figure out the list of side-effect free native functions in getters |
| 12:10 | <lpfreelance> | Well thank you for the definition of TOCTTOU ! I understand, it makes sense and I didn't have this edge-case in mind, hence the `FileSystemSyncAccessHandle` interface with an exclusive lock, I guess. I'll look into the documentation, many thanks and good day π |
| 12:14 | <annevk> | arai: what kind of side effects are you concerned about? A lot of them are so-called "lazy" getters, so they'd end up allocating objects when first invoked |
| 12:16 | <annevk> | arai: we generally want x.getter === x.getter to be true, but that is sometimes violated as well (e.g., input.valueAsDate) |
| 12:17 | <arai> | good point. let me think |
| 12:18 | <annevk> | arai: https://github.com/whatwg/webidl/issues/212 last comment there might be of interest |
| 12:22 | <arai> | returning different value for each access is fine for out case. lazy getter is somewhat problematic if it can modify internal state of objects too much (let me think what "too much" is...) |
| 12:25 | <arai> | hm, let me explain the context a bit more. the context is eager evaluation in the developer tools console, where the value of the given JS codelet is evaluated before user hits Enter. and we want to check if given native function can be called there |
| 12:31 | <arai> | so allocating objects and storing the result in the cache should be fine |
| 12:41 | <arai> | possible problematic case is that x.something_else returns different value between before/after calling x.getter |
| 12:47 | <lpfreelance> | In general such methods are bad, for all file system APIs, because they create TOCTTOU errors. https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use After thinking about it. Could such method be implemented with a documentation alike to the one in Node.js to inform end-user? e.g. I retrieve a file from storage, I don't know if it exists, I need to save data in it. But doing so requires me to run long computation / algorithm to prepare data before writing it in the file. In such case, wouldn't it be preferable to be able to test if the file exists before running computation / algorithm? And indeed, still handle edge-case and test for any error when actually writing in the file. What do you think? |
| 12:56 | <annevk> | lpfreelance: getting a handle shouldn't really require any computation? |
| 12:58 | <arai> | to my understanding, the extended attributes mentioned in https://github.com/whatwg/webidl/issues/212 are about the restriction on the return value across multiple calls. and I think that's slightly different about our concern in the eager evaluation case, where the focus is "whether calling the getter is visible to remaining code" |
| 13:02 | <lpfreelance> | annevk: I mean preparing data to write in the file/handle. Code flow currently:
With
|
| 13:07 | <lpfreelance> | 2. Prepare data, is where it requires computation. |
| 13:19 | <Noam Rosenthal> | Hmm I see that we only perform the microtask checkpoint for regular tasks, but not during "update the rendering". This would mean that microtasks queued inside requestAnimationFrame/ResizeObserver callbacks would only be triggered as part of the next task. This is not how implementations work... am I missing something? |
| 13:31 | <zcorpan> | i'm going to start using |
| 14:02 | <annevk> | Noam Rosenthal: there's also some kind of cleanup |
| 14:02 | <annevk> | Noam Rosenthal: Jake Archibald prolly knows off the top |
| 14:09 | <Jake Archibald> | Noam Rosenthal: there's a microtask checkpoint after calling a callback |
| 14:10 | <Jake Archibald> | Whether it's in a task or the render steps |
| 14:11 | <Jake Archibald> | So, `Promise.resolve().then(callback)` if you run this in a raf callback, `callback` will be called as soon as the JS stack empties |
| 14:14 | <Jake Archibald> | https://html.spec.whatwg.org/multipage/webappapis.html#clean-up-after-running-script |
| 14:15 | <Noam Rosenthal> | thanks Jake Archibald , that explains it! |
| 14:19 | <annevk> | ah right, it's the same thing non-JS dispatched events use |
| 14:19 | <annevk> | summarized as "is there still JS on the stack?" |
| 15:12 | <annevk> | arai: I can't immediately think of a getter that is quite that bad and I certainly wouldn't mind experiments in trying to enforce it |
| 15:16 | <annevk> | lpfreelance: somewhat fair, although what you really want I think is to tack a lock on the file so you're relatively sure your eventual write won't fail either. Taking https://whatwg.org/faq#adding-new-features into account filing an issue against whatwg/fs and asking for thoughts seems like a good next step to me. |
| 15:56 | <lpfreelance> | annevk: In such case indeed, to tack a lock on the file could be ideal. It might also be useful with a directory entry. Alright, I will also check for any related issues before filling one. Thanks for your feedback! |
| 16:04 | <annevk> | lpfreelance: btw, the difference with the WICG draft is that the WHATWG spec defines the fundamentals only; the WICG draft builds on that and adds end user file system access, but there's no agreement that that should be exposed across browsers |
| 17:53 | <arai> | arai: I can't immediately think of a getter that is quite that bad and I certainly wouldn't mind experiments in trying to enforce it |
| 19:13 | <hacknorris> | holy offtopic |
| 19:56 | <mztea9281> | Thatβs us @david |
| 20:07 | <hacknorris> | which david, guy, i dont even know what tf you talk about π |