Thanks for the replies. For #4, I mean that when I hit the "tab" key, it doesn't insert a tab, but rather acts as forms normally do... focus moves to the next element on the page, which happens to be something different than the text editor I was working with.
Oh, I see. We'll have to think about that. Since HTML doesn't have the concept of tabstops or dynamic tab positions, this may not work very well in the context of an online WYSIWYG editor.
In the context of word processors, tabbing in a list usually indents and in a table cell usually moves to the next cell so we would probably adopt those for predictability.
What happens outside of that I'm not sure what would be the best. We can probably implement anything and we can also offer configurable options as well. That said, we'll probably have a recommended default based on what we think is best.
Comments
Thanks for the replies. For #4, I mean that when I hit the "tab" key, it doesn't insert a tab, but rather acts as forms normally do... focus moves to the next element on the page, which happens to be something different than the text editor I was working with.
Oh, I see. We'll have to think about that. Since HTML doesn't have the concept of tabstops or dynamic tab positions, this may not work very well in the context of an online WYSIWYG editor.
In the context of word processors, tabbing in a list usually indents and in a table cell usually moves to the next cell so we would probably adopt those for predictability.
What happens outside of that I'm not sure what would be the best. We can probably implement anything and we can also offer configurable options as well. That said, we'll probably have a recommended default based on what we think is best.
TheSunny