3 ms·
I don't see interactivity as part of the standard. It's all static as far as I can tell. There are language-specific API's, but that defeats much of the purpose
by tabtab 7y ago
I don't see interactivity as part of the standard. It's all static as far as I can tell. There are language-specific API's, but that defeats much of the purpose of a markup language: you have to use two languages: the XML, and then the language-specific API's. Lack of state-handling is part of why HTML/DOM gui's are Rube Goldberg devices.
- giancarlostoro 7y agoI feel like RAD tooling is the best way to do UI work, it's a shame we keep going backwards on that.
- tabtab 7y agoThe problem with RAD has been that it makes the first 80% easy, but the last 20% a bear. You don't get enough control to give the customer what they really want and need. I've kicked around the idea of "staged rendering". The displayed elements are generated in stages, and one can alter the meta-data used in each stage as needed via event handlers. Thus, if you need to insert an extra CSS class into an element or even totally revamp a widget's HTML, you can by altering the appropriate stage. Earlier stages would have a draft "class" attribute for the HTML element which you can change or append to. In later stages, you can overwrite the entire HTML of that element, and the very latest stages allow you change or wipe large sections of pages, like the entire form block. Similar techniques can control SQL generation. This gives you RAD-esque automation without taking away control. The automation produces various DRAFTS which you can tweak as needed along the way. The jury is still out on my experiments. Still, we need an interactive GUI markup standard regardless.