1. TextArea features.
We all know that text areas are used as the basis for all RTF editors. So lets capitalize on it, and just go ahead and add a type attribute with the following types:
- text, ASCII, Unicode – These would all be unformatted text. The difference is that text would handle any text, ASCII would only be 7 or 8 bit ASCII characters, and Unicode would be only Unicode characters.
- MarkDown – AKA BBS formatting. MarkDown has become a highly popular way for shorthand formatted text entry. Made popular through WikiMedia and other CMS.
If this is done right, then the new API could look like most of the desktop APIs when it comes to adding formatting and features to the TextArea. Ref http://msdn.microsoft.com/en-us/library/system.windows.forms.richtextbox.aspx. Though the MS RichTextBox is not perfect, it has a rich set of API calls to do 99% of what is common to all website rich editors.
2. Element specific print context.
Some of this works in IE, but not always in other browsers. This should be a standard by now.
3. Variables in CSS.
Yes, I know that we have similar features by using LESS and SASS, but if 90% of everything I am doing is updating old CSS to support new features, then reconstructing the CSS to LESS or SASS is a burn that most clients don’t want to pay for. So I cheat and generate some of my style in the page render at the server, or I use the cheats that are built into Angular.Js.
But while I am at it, LESS has a glaring shortcoming too.
When rendering the LESS to CSS, I cannot tell the rendering engine to use a server supplied variable in rendering the LESS. I have gotten around this by creating a handler on the server that renders that variables into a new LESS file, then I have the LESS JS file render the LESS files into the proper CSS. If feels as scrappy as it sounds, but until I add injection points into either the server render, or the JS render, this is the best I have.