Bit of background
I've been producing a Flash-driven webcomic for three years now, incorporating some basic animation, a synced soundtrack and zoom-drag page viewing. The recent Flash-bashing, my desire to reach iHandhelds and my preference for open versus proprietary means that I want to make the move to HTML5 techniques this year. In the long-term, I think the writing's on the wall for Adobe's product, and I'm not entirely convinced that's a bad thing.
I'm relatively comfortably with both CSS and HTML, having worked a little in web design before. However, JavaScript is a foreign country to me, and I simply wanted to get some advice as to
whether what I want to achieve can be accomplished consistently across all browsers and
what the best techniques/approaches to the problem would be.
Any advice, even general principles, are very welcome. I've already sought out several HTML5 tutorials and introductions, which lead me to believe that the canvas element will be foundational to my plan; however while all the individual problems I face have been answered by many blogposts and guides, combining the various solutions into a single entity is something I'm not currently able to figure out, as I'm not certain of the limitations of the new HTML5 tags, or of best practice.
If I'm successful in achieving what I'm after, I'm going to post the full code online with an explanation of all the elements. Webcomics might not be a huge domain, but having a resource that did this would have made my life a lot easier - hopefully it'll help someone else in a similar position.
What I'm after
Here's a diagram giving the basics of the design requirements. I'll explain the elements, and the desired extras, below.
(Perhaps the simplest way to demonstrate what I'm after would be for interested folks head over to my website and see how my comic currently works. This isn't a plug - it would simply give the quickest insight.)
At core, I'm after a viewer that will:
display text (SVG image) in a canvas element above an raster image the page's panel art
both images should be zoom-and-draggable in sync but should ideally fade in separately, with the raster image coming first, followed by the SVG image
I'm guessing that the best way to accomplish this would be to layer two canvas elements one above the other using z-index, with the SVG file in the uppermost element. These could then be nested, as in the diagram, within a div element that would carry the zoom-drag function. Is this a reasonable approach, or are there more efficient options?
The next and previous buttons are self-explanatory. Would it best to have each page (bearing in mind some will involve animation and music) on a separate page, or to have all pages within a chapter on a single page, with the buttons making them visible progressively? I imagine this would have a great impact on loading speeds.
Finally, I'd like to have the viewer capable of displaying fullscreen if the reader desires. I imagine this could be accomplished by using Javascript to make the canvas elements and their surrounding div switch between different CSS giving a px-defined size and 100% height and width. Is this a good approach? Is it possible to apply the size change to the div element only and have the canvas elements automatically follow suit, possibly by defining their size via % in CSS?
Desired extras
At various points in the comic I make use of basic animation techniques - simple movements of layered raster images across the viewing pane. This would be simple to accomplish, I imagine, using Javascript; am I correct in thinking that applying overflow:hidden to the wrapping div will prevent images larger than the viewing area from spilling outside the viewer area?
I also want to synchronise audio with some of these animations. I understand that synchronising canvas events with the audio would be the best way to do this on, permitting both to begin activity only upon page loading or next button click.
That's about everything. As said, any advice at whatever level would be greatly appreciated, even if it's 'yes' or 'no' to the various questions I've asked. At root, it would also be good to know if HTML5 is the best option for what I'm after or whether (with gritted teeth) I should stick to Flash for now and go after handhelds using Adobe AIR.
Related
I'm currently creating an interactive anatomy app for learning purposes.
I'm starting with a spine module, which contains 24 vertebrae, a pelvis, skull and spinal cord.
Each piece is a separate transparent image of the same size, and each are layered top to bottom.
This works and looks great! The problem is, it is extremely processor intensive. Adding and removing little pieces, zooming in, almost any interaction at all is VERY slow.
Is there a way to layer all of those images in a performant manner? I would like for a student to be able to remove a lamina, and have that vertebrae swap out the image. Or to zoom in on only the Lumbar vertebrae and interact there.
What approach, technology, etc should I be looking at?
https://jsfiddle.net/whetw8o5/1/
Fiddle for reference.
Fiddle contains a transition tag for height, so you can easily use a tool and modify the height of the parent #spineo tag and see how much trouble it has.
Fiddle performs better than my site because it is by itself.
I'm implementing a HTML5 game using canvas. Now I'm thinking about making all text overlays like tooltips, speechbubbles, infowindows and so on using HTML elements with position absolute over the canvas. So I can use many effects and transitions CSS3 offers.
But I'm not sure about performance. These overlays have to be added and removed frecuently (is something MMORPG like, so there will be a lot of speechbubbles and so on).
There are probably 2 questions regarding performance:
DOM traversal to add/remove. Maybe a cache can help?
HTML and CSS3 itself.
The other option is to manage these elements in the canvas itself, drawing them each frame. But maybe I have then again a performance penalty, because of the extra code, timeouts and stuff I would have to add, to achieve similar effects like in CSS3. And traversal of some data structure would be needed anyways.
Any advices, opinions, experiences?
Thanks in advance.
Consider using only one of the mentioned two technology. May be you can release that application in mobile or tablet. I think on these devices would be issues with handling both the same time. And another thing: if you stay in canvas there would be no worries about compatibility. Its not a techy but a thought-provoking answer.
The single best reason for using the DOM for UI elements in HTML5 games is event handling.
If you draw everything on canvas you will need to write your own logic to handle clicks and decide what has been clicked on, which can soon become very complex, expecialy if you have multiple layers of interface.
With DOM elements (especially when using a library like jQuery) this is trivial, and you can create a rich and interactive UI with minimal effort.
The only downside I can think of is that you may encounter browser inconsistencies, especially if using CSS3, but again jQuery will help with this.
I suppose another downside is that once you go down the DOM route, your game is always going to be a browser game, whereas if it was 100% canvas, there would always be the possibility of porting the code to another language and making it native, but I guess that would only be a downside for some people.
One way to approach this is to use a "dynamic" image map behind your canvas object. Then you can use the dom as required. Note you will need to pass the clicks on the canvas through to the image map.
As a front-end developer, I've been given a mock-up design to implement. This design features several tachograph-style icons, which have me stumped as to the best way to mark them up in HTML and CSS.
The images look like the following:
Obviously these assets represent the empty state and the full state respectively.
My issue is this: how can I mark-up these images so that I can show varying levels of completion, i.e. 10% full, 60% full etc?
Waiting in anticipation to hear your answers.
I would seriously recommend looking into the Raphael javascript library. You can knock something like this up in just a few lines of code.
See also this question: Drawing a half gauge/speedometer (JavaScript Canvas or Java Swing Example needed) where I gave an answer including a four-line code sample using Raphael, which provides an animated fuel gauge. You'll need to tweak it for your design, but even then it's only going to be a few lines of code.
The great thing about using Raphael to draw things like this is that it is fully compatible with older browsers, even IE (as far back as IE6 if you need it), without you having to do any special code to support it. It's a great little library.
Hope that helps.
Given that the image reprisents actual data and isn't purely a design mechanism, I'd mark the image up as an HTML image.
<img ... alt="10%">
If your concern is about showing portions of the image, one way you could do this would be to set the image as a background to some container and use width and height to identify the amount of the image to show.
i'm not an expert on html5 /css3, but would you not use the html5 arc command to create a mask to reveal the full state.
As you have a 270 degree rotation from empty to full, you'd just map the value as percentage of 270 to create the value of the arc that would mask the appropriate value.
I believe that there is a java script Math.PI that might help to.
When designing my homepage, I feel like the common knowledge is that it is bad to just have one big picture in the center that gives all of the content. The "right" way to do it would be to chop up the large layed out image into several small backgrounds and make the text use standard html with css background images for layout.
Is the only reason one big image is bad SEO reasons?
A search engine can't make sense of it.
A blind or otherwise visually-impaired person can't make sense of it.
Someone blocking images because he's on a mobile phone with expensive internet can't make sense of it.
There are a few reasons :-)
Also important:
Changes are not easily made to whole, pre-composited images, unless you still have access to the original layered variants. And hopefully they contain text as well, not just pixel data. (Mentioned by others before already. Credits go to pierre and Kendrick)
If you're using background images don't forget to set a text and background color too. Otherwise people not seeing any images might have a hard time deciphering your text (black on black isn't nice to read :-))
You can still use one large image as background. How the text is layed out above that is another matter entirely. In fact, chopping up the image and piecing the pieces together is painful using CSS too. In my experience it's best and easiest to leave background images unchopped and instead composite the rest of the layout above them, using other images or backgrounds if needed. This gives you a little more flexibility when changing a layout again, too.
SEO is one. Handicapped accessibility is another big one -- a screen reader can't read text within an image, typically. Page load time is another one; a user with a slow connection won't see anything useful while the image loads. Lastly, many browsers will use multiple connections to request resources such as images, so they can be loaded simultaneously. If there's just one image, only one connection can be used.
Updating will be tedious; you can also no longer rely on many benefits of CSS.
It's also bad for accessibility (screen readers, text-resizing, different monitor sizes)
It also removes your ability to easily edit text content.
I certainly wouldn't do it if you're looking for a web-developer job, but if you really don't care about the above, you won't be the first person to do it...
I see no reason at all in using imagea to represent something what can easily be achieved with HTML and CSS.
You're putting up a web site to enable communication between you and your visitors. Images and Flash prevent that.
Generally, you design a site with HTML/CSS and text. Only when you wish to add some design that cannot be expressed with standard means, then you use images. But have your site degrade gracefully for those who cannot or does not wish to see images. Let images be an addition, like an advanced version, in no case a replacement for text.
The discussion on this answer to the question "How can I use Google's new imageless button?" Has prompted this question.
Google seems to think that going imageless is good for some reason, but from the comments cited, I fail to see the advantage. Is it worth it to send dozens of lines of HTML and who knows how much CSS to render these imageless buttons, rather than simply load another image, especially when techniques like CSS sprites are available?
When would this technique be preferred? The other question asks how it can be done, but I want to know why it should be done.
Localization (it's easier to translate text than images)
Skinning/themeing (it's easier to change the look and feel with single CSS than recreate multiple images)
Accessibility (screen readers can read properly, text scaling works properly)
Performance (the CSS is shared and so is loaded once from the server)
Functionality (it's easier to expand the button with new UX elements like dropdown arrow when you don't have to change the whole picture)
Btw, the "imageless" button might as well contain an image inside the visual template. This approach is quite similar to XAML's approach to templating and styling the visual tree.
I think in this specific case I can only see the advantage that the buttons can be programatically generated. If you don't know what your button will say it's probably easy to make this way than generating it using somekind of image library generator.
Also changing one CSS can make you change the look-and-feel of all buttons at once. Using image buttons you'll need to update everyone and each of images.
Isn't this done because the height of the button may vary (for example the text size)?
The page load is smoother as no images have to be loaded and will appear later than the rest
The button text is also readable in the case somebody cannot read/view images, yet you have the graphical look. (building a graphical button with images in the traditional way around real text is as complicated HTML as this method)
As they mentioned in their blog, these buttons are skinnable without creating and storing custom images.
Basically, you get all the advantages of plain text buttons over custom imaging, while still having a nice, skinnable graphical look.