Open chong-z opened 7 years ago
As you mention, this issue was up at the F2F. The proposal, which as you state came from @garykac, was to either prefix all those remaining inputtypes that didn't have a prefix or to create two levels: supertypes and subtypes. We didn't have a clear conclusion for which one of the two we would pick, but noone seemed opposed to the idea that we should do one of the two. I added the prefixes now, but was prepared to switch it all to a super/sub type model if that ended up being the final conclusion.
I personally don't care for which one of the three options that are now on the table we pick. I don't think "looks weird" is a good argument, but I also agree that there are likely not many "shortcuts" JS developers can take by checking for prefixes or supertypes. They'll spend quite a bit of time developing on top of this anyway, so they will have the time to distinguish the inputtypes for most purposes. An exception may be insert paragraph and insert linebreak. Some editors may choose to treat these two the same way so having a prefix or supertype may help them.
Prefixing could also have the purpose to group them more easily together. Either to understand the spec or by having different subfunctions for inserting, deleting, history or formatting. But again - the time saved by this is minor.
Given that the strongest opinions on this matter both seem to have their origin in Google, and not that many others have expressed much of an opinion on this matter, maybe you guys could come up with a common proposal and then present to the rest of us?
I don't think "looks weird" is a good argument
Sorry for the confusion, the argument should be:
format
and history
doesn't provide additional useful information, so we shouldn't do it.But yes it won't mean a lot for JS, so If we are prefixing
@garykac @ojanvafai WDYT?
We have a bunch of commands that fall into obvious categories, and we kinda-sorta use prefixes for some of them (deleteXxx and insertXxx).
This implies that there is some structure there (the categories). If the commands do fall into categories, then it would be silly to ignore that structure and dump them all into an unorganized bag of commands.
A developer that wants to write code to filter out all formatting commands shouldn't have to enumerate each and every formatting command (which will break if we add more commands).
if prefix(type) == format
is a lot better than
if type == bold or type == italic or type == underline or type == strikethrough ...
And having a list with common prefixes also makes the list easier to read since related items are all grouped together rather than scattered throughout the list of commands.
The argument that it doesn't provide additional useful information is not valid. It does provide additional information: the category. While we may happen to know that "bold" is implicitly a "format"ing command, this fact is not obvious to the code unless we make it explicit, and exposing the category to the code is the point of having the prefix.
Without these explicit categories, many devs are going to end up creating tables for these categories:
formattingCommands = ['bold', 'italic', ...];
and it's very easy to imagine people wanting to write code like the following:
if prefix(type) == 'history'
undoManager.command(type, data);
else if prefix(type) == 'format'
// Ignore all format commands
else if ...
...
else
log('unknown command: ' + type);
The key is that it's easy for us to choose sensible names now. It'll be harder to fix the names later. We can address this categorization-problem either by (1) ignoring it, (2) having type/subtype attributes (probably overkill), or (3) using a common prefix for the categories. The latter option is much easier to do.
It seems better to expose two separate enums in that case: category and command. You might have different kind of groupings going forward after all.
Issue Background
Recent commit https://github.com/w3c/input-events/commit/28b3edf74f08de898c3ce6b79be621dfe3e18cc3 adds prefixes to all
inputType
, e.g.The original point of adding prefixes came from TPAC 2016: https://www.w3.org/2016/09/22-webapps-minutes.html#item04 @garykac
Original Naming style
Actually those prefixes look weird to me, and I'm not sure how useful "catch all events" would be.
The original style is
DOMAction+Source/MoreDetails
, andBy/From
means 'indirect outcome'. e.g.insert*
anddelete*
because they can be handled using similar logic (if JS doesn't care about sources, etc).insertFromSpeech
later, it should just work with existinginsert
logicinputType
because they have to be handled individuallyformat
orhistory
doesn't provide useful information, JS still need to make a list of supportedinputType
, andpreventDefault()/Let go
on othersProposal
We could do something about
transpose
,undo
andredo
, but should leave otherinputType
standalone. (As well asbackColor
,createLink
,fontName
, andfontColor
proposed here https://github.com/w3c/input-events/issues/32#issuecomment-248762122)transpose
:insertTranspose
orinsertFromTranspose
could work, but I'm not sure about semantics...undo
andredo
: We need to make it clear it's only about DOM modification, e.g.undoModification
,modificationFromUndo
, see https://github.com/w3c/input-events/issues/21