As a developer, I would expect to create my own image element in ActionScript code and reference the appropriate URL based on where the file was copied. I wouldn't want the compiler to add an <img> to my HTML template. It would feel too much like magic and probably wouldn't be configurable enough to be useful.
-- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Tue, Jan 7, 2020 at 9:51 AM Alex Harui <aha...@adobe.com.invalid> wrote: > > > On 1/7/20, 9:33 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > On Jan 7, 2020, at 7:28 PM, Alex Harui <aha...@adobe.com.INVALID> > wrote: > > > > I would think any of these files need to be loaded by some other > code. They can't just sit in the output folder. > > True, but this problem is smaller for image files which can simply be > referenced in the app (the src in an HTML app). As long as the relative > path is predictable, this issue is manageable. > > I might just be too nit-picky, but I think even an image needs a > HTMLElement in the DOM. So any class that wants to have an image copied > into the output folder needs to either run code to insert an <img> tag in > the DOM or have the post-process somehow know to add an <img> tag into the > output .html file and since the position of <img> tags really matter > specifying position in the annotation would be painful, IMO, so I would > expect class code to insert the img tag. > > Order of loading CSS and JS matter as well, but hopefully it will match > class initialization order so we don't have to define order in the > annotation. > > Class code is generally required because Royale does not put an initial > DOM of HTMLElements in the output html file. All HTMLElements are added to > the DOM by code (or by inject_html, but not in any particular order). > Teaching the compiler to construct an initial DOM and have the class code > find the DOM elements (I think JQuery sort of worked this way) would > require a different component set and two initialization paths in the > components ("find the element", and "add the element") so Basic does not > try to support that. Some other component set could, but because we want > to encourage dynamic, state-based UX I'm not clear there would be > significant advantages. In Alina/Pashmina's app, for example, the initial > DOM would just be a login screen. > > -Alex > >
