| 07:39 | <annevk> | I think if we want some kind of API-like thing though whereby we pass along the data there to service workers or even actual servers, I think we'd want that isolated in some way from the built-ins. Either by using custom: blah or indeed reserving _-prefixed identifiers for web developers. |
| 09:37 | <svensauleau> | Note that the prefix X- was commonly used for HTTP headers and is deprecated now: https://www.rfc-editor.org/rfc/rfc6648. |
| 09:54 | <annevk> | Yeah, though HTTP headers not having this kind of distinction has resulted in all kinds of block and safelists in browsers |
| 09:54 | <annevk> | And X- got deprecated because it was a (bad) convention that often resulted in two headers or a weird name we were stuck with, not an API entry point as _ would be |
| 11:08 | <littledan> | Yeah I guess I was replacing x- with data- in my head |
| 11:11 | <littledan> | “Contains _” (or -) seems like a practical convention IMO. I think we want to do something like, our the “namespace” in there too, so it’s like turbopack_foo |
| 11:11 | <littledan> | Though if someone wants to do _foo nothing would stop them |
| 11:12 | <svensauleau> | assert { turbopack: { foo: 'bar' } } is effectively namespacing and feels more practical to me |
| 11:19 | <littledan> | I agree that this serves the name spacing purpose, but could you explain more about why you prefer it? |
| 11:19 | <littledan> | What makes it more practical? |
| 11:23 | <svensauleau> | It doesn't require parsing a _/X- delimiter |
| 11:24 | <svensauleau> | A bundler/tool can pass the entire attributes object to the corresponding tool, implementation-wise it feels easier. |
| 12:15 | <littledan> | Oh, I don’t think anyone would parse it, it would just be a convention |
| 12:16 | <littledan> | Otoh the nested structures would require a grammar change that we haven’t done yet |