Not so much a feature request but


(Jonathan Luna) #1

I love hype. and love what it pushes out to browser. but honestly i not the hugest fan of what it puts out on the code side. maybe its because I’m such a novice developer but personally i will hype would at some point evolve to more css driven vs java. …


(Jonathan Deutsch) #2

Thanks, this is a common request. Hype’s feature set far exceeds what is possible via CSS3 Animations so it needs to be driven by JavaScript.

Also see my rant in a post from a while ago:

…but I actually do have a rant on nice code output! Human-readable code is one of those mixed bags… it is very hard to produce something all humans would want to read (many will complain one way or another based on the developer’s choices), and if humans aren’t writing/editing it, then it loses a lot of its purpose. Further, if humans are editing it, then it is assumed that the app needs to be able to read it back in, which is exceedingly difficult in the face of human error and ambiguous specs! With Hype’s output, my philosophy was that this is a feature people think they want, but in reality don’t use. They’re mostly concerned with the result. On the whole, I think this has held up. It is like iPhone’s non-replaceable batteries - a lot more people complain that you can’t replace the battery than would ever actually replace a battery.


(Jonathan Luna) #3

still it would be nice to have the ability to output the basic styles to css and have more complex operations output as js. on a slightly different note. What are the advantages of adding html widgets to my document vs editing the elements actual inner html. I feel it have more control over interaction as well as styling from directly editing element vs widget.


(Jonathan Deutsch) #4

I agree, but for cross-browser support we basically need to drive everything dynamically. The DOM and styles we generate in IE looks very different than the DOM and styles in other browsers, for example.

This is a good question. The HTML Widget is backed by an iframe, which means it will have longer load times and be much more isolated from your document. In general, I’d only use this when you are using code from other sources (like a twitter tweet feed widget for example). 3rd party JavaScript will have a higher success rate in this environment as it is not being added via setting the innerHTML.

Other than that, for your own purposes I’d always use editing inner html of standard elements. It can take code, and can better integrate for items like forms. This will get integrated as a div in the DOM of your document.

In the early (1.0) days of Hype, there was no HTML Widget element. I think we might have gotten overzealous with that feature and people probably use it more than they should. I might think about adding a “Empty Div” element or better label on the iframe.


(Jonathan Luna) #5

I think many people would appreciate that change plus it would be more html5 friends since iframes are no longer supported. Thanks for sharing the knowedge and sharing the history. :+1:t4:


(Jonathan Deutsch) #6

What do you mean by iframes are no longer supported?


(Jonathan Luna) #7

As a standard in html5. Iframe are considered as former standard given hype being a fwrd thinking product I feel it’s best to take that factor into consideration in future updates