| 00:42 | <innovati> | <div hello:world></div> Am I correct in thinking that HTML doesn't support the hello: namespace thing here? Is it defined how this should be parsed, or do we know what should happen? |
| 00:46 | <MikeSmith> | innovati: per-spec it’s parsed as an attribute with the literal name hello:world and an empty value |
| 00:46 | <MikeSmith> | there’s nothing special about the colon in the attribute name |
| 00:46 | <innovati> | If this was XML instead, it would be a namespace and an attribute name separately? |
| 00:47 | <MikeSmith> | I dunno about XML, don’t remember |
| 00:47 | <innovati> | thanks so much @MikeSmith <3 |
| 03:52 | <annevk> | innovati: parse error, use data:text/xml, to try |
| 12:04 | <annevk> | littledan: I guess I'm a bit out-of-my-depth, but that kind of coding style doesn't sound great for window agents |
| 12:04 | <littledan> | annevk: Yeah, I agree |
| 12:05 | <littledan> | sorry if my comment was ambiguous. I'm all for restricting this to, roughly, the [[CanBlock]] set |
| 12:05 | <annevk> | littledan: it might be okay for audio worklets, but padenot suggested they can make those close to or actually GC-free so might not need this either |
| 12:05 | <littledan> | I don't know if it should be the same bit or if we might come to some kind of agent where they differ |
| 12:05 | <littledan> | maybe it's fine to use the same bit for now |
| 12:05 | <annevk> | I guess that's really a thing TC39 should have settled |
| 12:06 | <annevk> | Or is there more to do than set a boolean for HTML? |
| 12:06 | <littledan> | well, we decided that different hosts can settle this differently, since not everyone even uses an event loop style |
| 12:06 | <annevk> | You'll at least have as much of a loop as needed for promises presumably |
| 12:06 | <littledan> | editorially we decided to go for the most parsimonious thing, that it's just "normative optional"--hosts can already resolve that, as they do for Intl and Annex B |
| 12:07 | <annevk> | But isn't that the same as an agent flag? |
| 12:07 | <annevk> | Or can we make this different per global if we wanted to? |
| 12:07 | <littledan> | right, ultimately these are all different ways of talking about the same thing |
| 12:08 | <annevk> | Again, I think it would help if TC39 was a bit more opionated and didn't leave all the work to hosts |
| 12:09 | <annevk> | Or maybe not opinionated, but doing a bit more legwork on reasonable tradeoffs for hosts |
| 12:22 | <littledan> | Well, maybe this thread we're having in HTML now can lead to recommendations that we can bring back to the committee, to consider refining the "normative optional" wording and proposing something more specific |
| 14:39 | <Domenic> | I tend to disagree with annevk, and am in favor of expansive powers for hosts in general :) |
| 14:45 | <annevk> | You think the current setup is good? |
| 14:49 | <Domenic> | Yeah |
| 14:49 | <Domenic> | Giving hosts the ability to choose how to expose things like SharedArrayBuffer or cleanupSome() is nice |
| 14:52 | <annevk> | Sure, but there's no concrete API for doing that atm |
| 14:52 | <annevk> | E.g., our current SharedArrayBuffer thing assumes it's defined by default |
| 14:52 | <Domenic> | I'd rather hosts be able to say things like "expose X" and "don't expose Y" at their leisure than require that they only have control over a proscribed set of things ES takes the time to expose an API for. |
| 14:53 | <Domenic> | I don't think there's anything in the current setup that makes it ambiguous what to implement, so I don't see what requiring more formal channels would buy us. |
| 14:54 | <Domenic> | (It would just reduce the freedom of host specs.) |
| 14:55 | <annevk> | You can have exactly the same level of freedom without the ambiguity |
| 14:55 | <Domenic> | What ambiguity? |
| 14:56 | <Domenic> | What two different ways to read the current HTML + ES spec combination are there? |
| 16:01 | <shu> | i'm also not sure something to the level of host hook rigor is needed for normative optional things in ecma262 |
| 16:02 | <annevk> | Domenic: how is it clear that it's required that the implementation exposes the SharedArrayBuffer constructor? |
| 16:02 | <shu> | ecma262 needs to be exact in what is normative optional (e.g. the data property on the global object), but i'm also confused by the confusion |
| 16:03 | <Domenic> | annevk: because HTML says it must? |
| 16:03 | <annevk> | It does? |
| 16:04 | <annevk> | Anyway, maybe someone else can work on that as none of this makes much sense to me |
| 16:04 | <Domenic> | I mean, I'd assumed that's what your PR did |
| 16:04 | <Domenic> | If not, then it should |
| 16:13 | <annevk> | If someone could suggest the relevant language or add it to that PR that'd be appreciated |
| 16:13 | <annevk> | I asked in that TC39 issue and didn't really get a clear answer |
| 16:14 | <annevk> | The current PR simply deletes SAB and assumes it's there |
| 16:19 | <Domenic> | Happy to work on that |
| 16:20 | <annevk> | Thanks! |
| 16:32 | <annevk> | Domenic: https://github.com/w3c/aria/issues/1239 fyi |
| 18:36 | <TimothyGu> | TabAtkins: your parse-css is kept up to date, right? |
| 18:37 | <TabAtkins> | Uh, overall yes. I should make sure I haven't missed any updates in the last few months. |
| 18:37 | <TabAtkins> | I know it doesn't have the new entry-point function I added last week. |
| 18:37 | <TimothyGu> | Cool. I was about to write something similar before I thought to Google |
| 18:38 | <TimothyGu> | I’d be happy to look it over and do any updates |
| 18:39 | <TabAtkins> | yes, looking at both the spec and project histories, it should be up-to-date |
| 18:42 | <TimothyGu> | Great |