So I have 2 questions for the awesome leaders, programmers, and html experts of this community. I have a comic in which I've been using flash files to make my pages come to life but I've realized that mobile browsers do not supports this.However, I have come across HTML5 which seems to be a solution for having animations and sounds be played within a comic. Therefore, my questions are:
1) Is it possible to convert our html to html5 for our webcomics?
2) If so, are there resources out there to learn how to do this?
I want to keep the same formatting, but just change comic pages to html5 code snippets.
Basically, the thing that HTML5 uses instead of Flash, is called Canvas.
Your flash animations need to be converted into something that can be run on Canvas. Now, I don't know what you're using to make your flash videos, but most animation tools that support flash have added ways to convert projects to be Canvas compatible.
They kinda have to, since support of Flash is being dropped.
Oh wow, this is really cool, I may have to sub I mean
So Robotwin gave one answer to your question, but here's another angle: the visuals you've got here could be done with CSS3's @keyframes rule, which tends to be more performant (your mobile viewers will thank you) and better supported (ditto). I'm actually working on a CSS3-based animation program for my own purposes, which I can toss your way when it's done.
No matter how you render your visuals, the audio's going to be a problem: HTML5 has a tag for it, but CF doesn't allow uploads of audio files. Unless we can convince Kyo to change that (I don't think he wants to), you'll have to either host your audio elsewhere and hotlink it, or... use Flash for it, which kind of defeats the purpose of not using Flash.
I think iframing HTML5 things is how a lot of game sites handle it. I know for Kongregate, I used to have to upload to dropbox or awardspace, then provide a link for them to iframe from.
No idea how well / if iframes could be snuck onto a comicfury page, though. I'm pretty sure, say, an author's note section doesn't support that kind of html, but it could possibly be done by editing the code behind each page you need to have iframes for. Just throwin it out there.
There's really no need for an iframe here. They're typically used on sites like Kongregate to sandbox your code (otherwise, nothing stops someone uploading a game that also makes AJAX calls to perform actions as the currently logged-in account).
If that's all a blah blah technical mess, the tl;dr is that iframes in this context are a security measure that you don't need to worry about.
Thanks for the suggestions everyone! I've got some ideas how I want to do it now. The last thing to figure out would be the audio.
It would be great if I could just host it on Comicfury, but if I host it somewhere else would it still be possible to embed the audio on my site?
So I've managed to find a program to create simple animation tweens and some basic user interaction. Furthermore, it can be exported directly as HTML.
For those of you interested, it's called Wick
@Kyo I have a questions for you.
I have found an HMTL5 file that contains user input to progress a scene. When the custom HTML code is uploaded as a comic page, the user input no longer works.
original file: Example 1
uploaded to website: Example 2
Is there a reason that user input does not work when uploaded as custom embedded HTML?
it might be something about your layout HTML that's interfering with it. from glancing through the source code, the embed code appears identical as the one on the separate file, but of course it also contains other stuff to make your layout work, which your generator thingy output may not like. The simple fix around this would be to just embed that extra file in an iframe with the correct dimensions, that should probably work
On my machine (64-bit Firefox 64.0 on Windows 7), your first link completely fails to render anything at all, while the latter renders the ghost properly but, yes, fails to respond to user input. I'm going to attach some debugging functions in the inspector. Wish me luck.
Okay, okay, so it turns out the initial diagnosis was incorrect. User input isn't being ignored at all. What's actually happening is that... the script assumes the canvas's upper-left corner is the upper-left corner of the viewport, which isn't the case cos your layout puts it in the center. Input events work; it just thinks the cursor is somewhere else entirely.