The document discusses the history and limitations of buttons and other controls in HTML. It notes that buttons used to be designed differently, then skinning was introduced to change their appearance, but this led to increased development costs. The specifications for HTML5 buttons and other controls have lagged behind needs, failing to introduce features like date pickers, sliders, or new layout options. As a result, web developers have had to resort to workarounds like custom buttons using images and JavaScript. The document argues it may be better to use frameworks other than HTML for building applications, as HTML is best suited for text and Canvas may only be suitable for graphics like video.

1. Buttons A small unit of Input+Functionality+Design That turns out to be pretty important to get right...

2. How Buttons used to be designed...

3. Then it all became Cheesy(We began to use Mice rather than Keyboards...)

4. These Buttons are all an illusion, of course...

5. That code is still down thereunder the hood, even in Windows7

6. And then Skinning came in Vogue...(circa 2000?) Unintuitive interfaces (a lot of them just reacted to hotspots, and didn’t take the time to implement alternate images for mouse over, clicked, selected, etc... A good attempt...but spotty results...

7. So the OS’s implemented it... First some Linux branch used skinning... Then Apple copied them... Then MS followed suit... ... but sometimes copying just doesn’t come off as well as you thought it should have... Dev costs shot through the roof: win controls got chromed, custom ones didn’t, etc. In addition 16, 32, 48 px icons was only a stopgap

8. Skinning... explains how the HTML <Input type=“Button”...> Got 15 years of extra game time, while not improving Styling, Functionality, or Behavior.

9. The (payed for) Web waits for no one... Web developers tired of waiting... So now we ‘make’ buttons out of: images + Anchor Tags + AJAX, JScript to short circuit the spec’s HREF functionality... and replace it with custom functionality... More images for Hover, Clicked, effects... Creative, yes...but adds up to lots of added dev and QA testing time, swearing, and costs. In addition: we’re not using the Specs.Why? Because the specs are not keeping up to the times.

10. It’s all going to get better, right? Nothing addressing this in the HTML 5 specs. Admittedly, could be added before 2022, which is when HTML5 is due. Yup. 2022.

11. In 2022 you’ll be 12 years older...

12. An exaggeration?A little HTML History...(Historically, Too Much LagTime) When Dinosaurs roamed: SGML 1989: Tim Berners-Lee/Cauillau develop HTML in CERN’s basement. That was Cool. Unfortunately, right after that: IETF meetings, blah, blah, blah, bickering: everything slows down 1992: HTML 2.2 1995: HTML 3.0 proposed, but dies on the vine. 3.2 was unofficial....“included extensions to control stylistic aspects of documents, contrary to the "belief [of the academic engineering community] that such things as text color, background texture, font size and font face were definitely outside the scope of a language when their only intent was to specify how a document would be organized.“ 1997: HTML 4.0 1999: HTML 4.1 2000: XHTML 1.0 2001: XHTML 1.1 2008: HTML 5 (18 years later!) proposed as a working draft

13. Late, but still, CANVAS is coming, right?Get real. Reality is HTML5 Canvas is...graphically challenged... HTML 5 Specs for the famous Canvas look more paltry than Silverlight version 1.0 (and really miles behind Silverlight 4.0 features)

14. The problems are not limited to Buttons... Or Controls: No AutoComplete combo, etc. <Input type=“StillNoDateControlAfter18Years”.../> <input type=“NoSliderEither”.../> No new controls being added (Grid, Trees, TreeGrids, Accordion, etc) Or layout: No opacity, no zoom, no rotation... No drop shadow, no blur, no reflection... And woohooo -- you can have Tables...or CSS pretending to be Tables...but you can’t go further (circular, triangle, perspective). Or distribution architecture: Spare parts flying in close formation (No packaging, no versioning system). A slew of languages/ frameworks (Jack of all trades, master of none). No unit testing of whole swaths of functionality (Unit Tests of Jscript?!?) Not keeping up with the Jones (iPhone, Android, Mobile 7, TV ads...) Wow. We can have Video. Just not in a format anybody uses yet... No solution to dealing with different hardware specs Multiple DPI’s (higher and higher resolutions) Hence Icons now are 16x16,32x32,64x64...before they woke up...

15. Developers are creative... It’s just that it’s maybe not the best use of their intellects to solve artificial problems...

16. If things are broken...Let’s rethink things...

17. I really did mean anything...

18. I really did mean anything...

19. Or a totally new Button...Same Functionality. Just Done my way...

20. 20 XAML: UI EventsTriggering StoryboardsAgControl62.xaml One use for UI Events is to Launch or Stop Storyboards of Animations. Again, Storyboards are defined as Resources Dictionary Items So we know how to get at them (with their keyName) And re-Type them to a StoryBoard And Begin() them!

21. So what’s the answer?Horses for Courses. HTML is fantastic for Text. That’s what it was designed for... Canvas...in 2022... will be great. If you are doing movies, it will be very useful. If doing apps though, use something appropriate: better framework, better patterns, better controls, etc.