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.
Related
I'm trying to create a gallery for a mobile site where I have different stylesheets for different sized devices. Within these stylesheets I have several classes which simply set a background url property to each image I want in the gallery.
Only one of these will be displayed at a time. And I will be cycling through the classes using Javascript to display them in a slideshow type presentation.
I am wondering is this method more bandwidth efficient than having all the images as individual img tags within the DOM? By setting these url properties do they get downloaded to the user's browser when they first load the site or are they only downloaded when the class gets set on a div in the DOM?
Simply I am trying to avoid having to download all the different images to the user's device at once. If you know any alternate methods which are better for this sort of thing I am also interested.
You are right, When you set the image backround, the image will only be downloaded if it is used, By this I mean, used as a style on some dom element.
Alternatively, you could 'change' the background-image css property using javascript. This way, you don't even have the image url in your CSS.
If bandwidth is your biggest concern, I would urge you to have a look at the inspector in webkit browsers like Chrome or safari, or with firebug on Firefox to see the 'network' tab, there you have a clear overview of what is loaded, how ( what order ) and how to optimize things. You can also make some stupid mistakes clear like downloading multiple times the same library from different locations and so.
If you just declare the class in css it shouldn't download anything before it is set. however it is a round question and the answer could take a lot of different shapes.
So I would say that yes it is a good way to do it, and it should be more bandwidth efficient (if you don't know that all the images will be loaded eventually anyhow, since you will typically have asynchronous image-loading either way it shouldn't matter much. I guess that if you only load one image initially the other images (i.e. the mentioned img tags) will not interfere making the load a bit more smooth?).
I find it to be a cleaner solution at least if you aren't sure which images will be viewed (which is likely to believe) to use your css-approach. also it's easier to maintain and provide a better design.
That you will be using javascript indicate that you are also doing the client side. And that give you control to choose what to do which is great :)
One alternative could be to have a local cache of the images as well, but that really depends on the problem at hand, if you will have different images and no real possibility to know in advance which images you will need (and perhaps not even how many of them?) then I think that the cleanest way is the way you purpose.
i.e. set up (or dynamically create) css-classes for images and handle all the logic in javascript.
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.
i have a image that i don't want it drag-able or selectable so that no drag to other places on the page. how is that done?
If you want your visitors/users to see the resource on your page there is no way to stop them downloading it or saving it.
Possible options:
You can use JavaScript to prevent the context-menu popping up on right-click (related article: http://javascript.about.com/library/blnoright.htm).
You can cover the image with a transparent .png or .gif so that clicking on the image simple returns the transparent image.
But if the user can see the image on the webpage then it's already on their computer.
In reality this is far harder than you may think it will be, I assume you don't want people stealing your images which is a fair enough thing but just remember all the different ways in which someone can get an image from a web site. Your can catch the right click event and stop them at least doing that, but they can always just take a screenshot and save that instead. This is a slippery slope and it always ends the same way, if they really want to steal it, they're going to.
Since the image is just a binary data, and all the data is written on client PC's, for displaying reason it's up to th euser what they'll do with the data. There's no way you can prevent them from saving the picture displayed on a website.
All you might do is make it a little bit harder, by blocking right clicking on image, (displaying alert on right click, or something like this). But if the user really wants to save the picture they will do this anyway.
Why should you do it?
I can suggest a javascript that will able it: http://www.brownielocks.com/stopcopying.html
But every one, even with little experience can view the source and copy it. and even if you block them from viewing the source, they can use wireshark and get the picture directly. Even if you use flash to show the picture one can screen-capture the screen and retrieve the picture.
Put a watermark on the picture and use http://www.tineye.com/ from time to time and search for your picture. If you find others that use your picture - sue them. It is the most effective way.
It is impossible to prevent someone to store an image (or other resources) on their computer as others already have mentioned.
But another trick to make it harder (impossible for inexperienced people I guess) is to use CSS and background images:
<div style='background: url("myimage.gif");'></div>
The image is now on the background of the <div> block and cannot be dragged or right clicked in order to save it.
Using some coding knowledge it is possible to ind out the myimage.gif part, which can be added after the base URL in order download the image and save it. For example if the HTML page is at http://www.example.com/mypage.html the image could be found at http://www.example.com/myimage.gif
As I mentioned it is still possible to save the image, but for inexperienced people it is a lot harder.
Note: In this example the image is just put in the HTML tag, but with proper use of a CSS file, it is even harder to find for inexperienced people.
You cannot prevent a user from saving something from the web to his PC. The nearest thing that comes to my mind is the -moz-user-select CSS property... https://developer.mozilla.org/en/CSS/-moz-user-select
This javascript snippet does exactly what OP asks:
document.addEventListener("dragstart", preventDrag);
function preventDrag(event) {
event.preventDefault();
}
Can you explain to me, at a very high level, what I would need to build an image carousel for the web, please. You can use data structures and general computer science terminology - but nothing language specific.
E.g:
Store all the images in an array or linked list
When the carousel is loaded, resize the displayed images as X% window size
When the next button is pressed, imageA moves to a hidden html element.
Et cetera.
I hope that makes sense.
Thanks.
You don't want anything language specific but you want to know about carousels on the web and you've tagged this with 'html' and 'css' so I'm going to assume that I can talk about HTML and CSS but I'll try to keep it high level.
If we ignore Flash, then you're left with HTML + CSS + Javascript. The common way to do this is to arrange the images or their thumbnails (don't resize via HTML - its doesn't look good and can increase your page load time) in HTML elements that are themselves contained in one or more layers of wrapping elements. So the whole set of images strung together might be wider than the viewing window. CSS is used to manage their exact layout and to keep them from overflowing the viewing window. When I say window, I just mean the portion of the page in which you want the carousel to appear. Then Javascript is used to change the CSS properties of one of the HTML elements that is wrapping the images, causing it to scroll or shift position.
With HTML5, you have more options, but the above is the way things have usually been done until now.
Finally, if you are going to actually implement this, there are a number of scripts available that will probably meet your needs, but if not I highly recommend using a Javascript framework like JQuery - it will make things much, much easier.
If you want to build it by yourself, one straightforward way would be to have a master div and all the images in it, lined up horizontally. Have the overflow set to hidden on the master div. Then use javascript and set scrollLeft as the user clicks the next, previous buttons.
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.