| 07:38 | <annevk> | Domenic: ensuring the map has the correct thing for element-references requires duplicating most of reflect for element-references, no? |
| 07:39 | <annevk> | It's not just a single concept after all |
| 07:40 | <annevk> | Also, I think that we should try to update the ARIA attributes that only allow a couple strings to be enumerated attributes (this indeed doesn't address the problem with how invalid values map to AT, but it might help with it, pending further updates to accname) |
| 07:47 | <annevk> | Domenic: overall it seems somewhat reasonable to attempt to stick the element-references in the map directly, but I think we still need most of my setup if we actually want to improve ARIA attributes overall (which WebKit wants to try at least) |
| 07:48 | <Domenic> | Domenic: ensuring the map has the correct thing for element-references requires duplicating most of reflect for element-references, no? |
| 07:48 | <Domenic> | Agreed it would be nice if ARIA attributes were enumerated. |
| 07:49 | <annevk> | Domenic: why do we not need the difference between explicitly set attr-element and attr-associated element for ElementInternals? |
| 07:49 | <Domenic> | attr-associated = explicitly set + whatever's going on with the string-valued content attribute |
| 07:49 | <Domenic> | There is no string-valued content attribute for ElementInternals |
| 07:50 | <Domenic> | I guess attr-associated also has some shadow root censoring stuff |
| 07:50 | <Domenic> | I don't think I ever understood that |
| 07:52 | <annevk> | That's why the explicitly set thing can be a weak reference, so if you lose access to the shadow tree the element is in and you that reference wasn't allowed anyway you can collect things |
| 07:53 | <annevk> | And the collecting isn't observable |
| 07:54 | <Domenic> | I guess it just seems weird we're censoring access to something the developer explicitly already had access to and set themselves, but I've never understood the encapsulation invariants attempted here, so shrug |
| 07:56 | <annevk> | Domenic: we're getting a bit astray here, but there's two reasons for that: 1) avoiding accidental dependency by other scripts on the exact layout of the shadow tree 2) forcing developers to think through encapsulation and come up with a better design such that the shadow tree can be redesigned independent from the outside world |
| 08:00 | <annevk> | Domenic: btw, I was hoping reflect callers would continue to do the same thing. So we'd only restructure reflect itself and how ARIA/ElementInternals interact with it. |
| 08:05 | <Domenic> | Yeah, this just doesn't seem like reflection to me |
| 08:05 | <Domenic> | It's only one-directional, and it can be much simpler. |
| 08:05 | <Domenic> | We can factor out the shadow DOM hiding stuff and use that, I guess, but we don't need all of (some generalized version of) reflect |
| 08:14 | <annevk> | Domenic: why is it only one-directional? Note that I want this to work for numeric and enumerated attributes as well. |
| 08:15 | <Domenic> | You just need to go number => string. You don't need to go string => number. |
| 08:15 | <annevk> | Domenic: why not? How would the getter work? |
| 08:16 | <Domenic> | It would return the number value stored in the map |
| 08:16 | <Domenic> | String conversion is only needed for getting values from the map to the AT |
| 08:16 | <Domenic> | We never need to get values from the AT to the map |
| 08:16 | <annevk> | Domenic: so you're saying we'd just need string -> number? |
| 08:16 | <Domenic> | Store numbers in the map |
| 08:16 | <Domenic> | Turn them into strings when you give them to the AT, like in my comment |
| 08:16 | <Domenic> | Return the numbers from the map in the getter |
| 08:17 | <annevk> | Oh, but that actually makes accname harder to write as now it needs special logic for the map version. |
| 08:19 | <Domenic> | Does it? I thought accname would use the string-or-element returning getTheCurrent(X, element) I outlined... I'll go look at the accname PR that's in progress |
| 08:19 | <Domenic> | It looks like that would work for accname |
| 08:20 | <Domenic> | They would only ever encounter a list of elements actually, which simplifies their spec a good bit |
| 08:21 | <annevk> | Domenic: I still don't really see how this makes it easy to define a new IDL enumerated attribute for instance |
| 08:22 | <Domenic> | I think it makes it automatic? |
| 08:22 | <Domenic> | You state what ARIA content attribute it maps to |
| 08:22 | <Domenic> | Then you're done |
| 08:23 | <Domenic> | Oh sorry, the operative word was "enumerated" |
| 08:23 | <annevk> | Domenic: but I'd want the behavior where the getter only returns canonical values and such |
| 08:23 | <annevk> | Domenic: or if you have a constrained numeric field it throws the correct exception, similar to how it does that for element reflection |
| 08:24 | <Domenic> | I think that is simpler with this framework because, unlike with reflect where the DOM can be mutated to contain arbitrary invalid values, the AT cannot be mutated in that way |
| 08:24 | <Domenic> | You need the setter to constrain the incoming values but once the value is the map, the getter remains trivial |
| 08:24 | <Domenic> | (for ElementInternals) |
| 08:24 | <annevk> | So you'd define special behavior for each setter where? |
| 08:25 | <Domenic> | You'd do it generically in "Similarly, on setting, it must perform the following steps:" |
| 08:25 | <annevk> | Wouldn't it be easier if they could just rely on reflect for new attribute additions to ARIA? |
| 08:26 | <annevk> | And not have to design for both elements and ElementInternals separately? |
| 08:26 | <Domenic> | I really don't think it would! Reflect is super-complicated and fragile due to the DOM interactions! |
| 08:26 | <Domenic> | It is not a good tool for the simple ElementInternals <-> AT interactions. |
| 08:27 | <annevk> | It's not a tool for ElementInternals <> AT. It's a tool for defining how the attributes on ElementInternals work. |
| 08:27 | <Domenic> | But the attributes on ElementInternals are for interacting directly with the AT, not for interacting with the DOM |
| 08:27 | <Domenic> | The attributes on Element are for interacting with the DOM |
| 08:28 | <annevk> | I don't see it that way. They're at a lower level, but they still need the same filtering/conversion. |
| 08:29 | <Domenic> | They do not need the same filtering/conversion. Because the DOM can be mutated arbitrary by getAttribute/setAttribute, but the AT's values cannot be mutated. |
| 08:29 | <Domenic> | "Reflect" is a verb that is specifically meant to communicate a two-way relationship. ElementInternals -> AT is actually just a one-way relationship! |
| 08:30 | <annevk> | The reflect is between the IDL attribute and the value in the map, and the map is then mapped to AT in the same way other ARIA attribute values are. |
| 08:30 | <Domenic> | OK, if you want to do it that way then sure. But the map doesn't get mutated either. There is no getAttribute/setAttribute for the map. |
| 08:31 | <Domenic> | So no filtering or conversion is needed for the IDL attribute -> value in map direction. |
| 08:32 | <annevk> | I agree that there is some redundancy in this setup, but overall it seems easier to define new attributes if you only have to think about reflect semantics and not about reflect and setter steps that end up matching what reflect does. |
| 08:34 | <annevk> | What I worry about is that if we use custom setter steps we end up with the ElementInternals API behaving differently. I would worry about that with me doing it, but also as others eventually define new attributes and have to figure that out. |
| 08:35 | <annevk> | I guess it might still be unavoidable though if some attribute cannot use reflect. Hopefully they put out the Bat-Signal for that. |
| 08:47 | <annevk> | Domenic: thanks for talking it through! I'm doing HTTP stuff next week, but I hope to start work on Nov 7. We'll see how much yak shaving I get into I suppose. :-) |
| 08:47 | <Domenic> | Sounds good! :) |