RESOLUTION: We think we want strict subsets - events is a subset of caret is a subset of typing which is a subset of true.

[johanneswilm]

instead of different modules, different versions of cE will be in a hierarchical relationship to oneanother.

[fredck]

Isn't it what we call "dependencies" when we use "modules".

I still think that "modules" is a more appropriate term, especially considering that in the future true maybe a combination of several different modules.

Additionally, it would be better to use modern terminology. "Module" and "dependency" are well accepted terms.

In other words: The true module depends on the typing module (maybe later on others as well), which depends on the caret module, which depends on the events module. When I enable one of them, dependencies are as well enabled, naturally.

[johanneswilm]

@fredck : The resolution is that they should not be different modules, but rather four different levels:

lowest: events, second: caret, third: typing, fourth: true.

After much back and fourth, we decided to now start out by specifying the typing level, but the other three levels will also be mentioned in the spec. I don't think there is any problem with dividing the remaining three up into even more levels at a later stage, when the TF starts speccing those.

[johanneswilm]

This change mostly came as a request by browser makers, and we (the JS devs) didn't really have any good reason to be against it.

[fredck]

That's pretty fine for me... it makes sense... I'm just talking about terminology. Calling them "modules" with "dependencies" will give the very same results with a clear terminology that is open for future developments.

[johanneswilm]

I see what you are saying. In terminology we will try to stay as close to W3C terminology as possible. That way, I think, we can get as fast as possible through the standardization system and obtain the greatest amount of attraction by browser makers. I do not yet know what those terms are in the case of these subsets of oneanother (I will look at other specs), but using the term "module" at least gives me the idea that you can have module "A" and module "B" independently, and not that they are in a hierarchical relation to oneanother.

If in a later version of the spec, we change our mind and decide that the different "modes" do not have to be in a hierarchical relation to oneanother, I don't think that will be any problem, especially as long as we are talking of still unspecified "modes" that have not yet been shipped in browsers.

Btw, if it turns out that the standard term for such hierarchical modes is "modules", then this discussion is redundant. :)

[fredck]

Note that "modules" definitely allows for "A" and "B". Exactly because of this extra benefit I'm proposing to use this term. Because we don't know how it will look like in the future and maybe we'll go the way of having a one-to-many hierarchy instead of a one-to-one.

I'm not insisting on this. I'm just adding a POV. This is my last comment here and I'm fine with any direction it takes.

[johanneswilm]

Added to relevant spec