5
Replies
Any solution that depends on hacking generated code is probably a bad solution. The HTML/JS docs that Animate publishes are intended to be treated as a black box, like SWFs were in the old days. If you need modifications to a page, you should be programming the pages themselves to be dynamic, loading whatever changes they need to make from an external text or XML file.
Thanks ClayUUID for your response, and in general, I agree with you, that any solution that depends on hacking generated code is probably a bad solution.
The issue here is that without changing the generated code, the product is useless to me. Also, it's not exactly the same "black box" as a .SWF file. It's HTML and JS, which are by nature open and not at all "black box" languages.
The progression from Macromedia Flash to Adobe Animate today is an amazing progression. I know, because I programmed in Flash (and every Swish version!), and now today I'm using Animate.
In the time era when Flash got started, there was more room for proprietary companies, and the standards were much less defined, and still very much under revolutionary development, from a software development point of view.
Today, the standards are very well defined by the W3C, and so for the end result to end up as two simple .HTML and .JS files is absolutely astonishing; to think how the original feel and intent and functionality of Flash has been preserved, but now it exists in such a light and adaptable framework such as what Adobe has turned it into.
For it to be *so* good, but have this one *big* hiccup right at the end of the whole production process is really kind of funny, but definitely slowing to the overall creative process, and it indicates to me that Animate is not used very often for final product results that fit inside of a div on a web page, but probably almost exclusively for producing a video file, or material that gets loaded and refined in After Effects or something.
The big hiccup is that the end animation cannot sit easily inside of any given div on a webpage, and respect its parent div as a parent container according to the DOM.
The solution is, as mentioned earlier, to change and remove and add some code to the JavaScript and HTML that comes out when you press the "publish" buttin within Animate.
For me, it is easy because I made a small .PHP / .JS script to handle this for me, but it is a surprise that this exists in software made by Adobe.
..
For anyone wondering why *not* to use iframes, you can do a simple online search yourself to find out why, but mainly for me, it's security and data management needs. If I'm not using iframes, everything works exactly like it's supposed to work, from a technical, web development point of view. When iframes are a part of the recipe, there are caveats to everything, and so very often, things do not work the way they are expected to work, or how they are supposed to work.
For someone making a simple brochure-style website for your own enjoyment, it's probably not a big deal if a few thousand people see it and you use iframes, but when creating websites and content for paying customers, and when setting up online environments for people who trust you to build something that is robust and according to industry standards, using iframes won't cut it in the long run, because they are high-maintenance and high-risk.
Aside from the technical and security considerations, there's a whole argument to be made that says that iframes destroy SEO ratings and utterly confuse the search robots and make them behave unpredictably and most of the time, poorly for the person who is hoping for better SEO.
Here is just one article I found when I typed in the phrase "iframe still used," where they mention that even Google recommends against using iframes:
https://www.ostraining.com/blog/webdesign/against-using-iframes/
AdChoices