Basically, I want to save a certain DOM element of my page as an image, and store this on a server (and also allow the user to save the image to a local disk). I reckon the only way of doing this currently is to render a canvas, which allows me to send the image data via AJAX and also make image elements in the DOM. I found a promising library for this, however my DOM element has
multiple transparent backgrounds
css 3d tranforms
And html2canvas simply fails there. Is there currently any way to neatly save an image representation of the current state of a DOM element, with all its CSS3 glory?
Browsers may never allow a DOM element to be truly rendered as it is to a canvas, because there are very serious security concerns around being able to do that.
Your best bet is html2canvas plus your own hacks. You may simply need to implement your own render code in a customised way. Multiple backgrounds should be doable with drawImage calls, and you may be able to work in css3 transforms when canvas 2D gets setTransform() (which I think is only in the next version of the spec).
In this stage of CSS3 development and crossbrowser support is this probably not possible without writing your own html2canvas extension.
You can try dig into Google Chrome bug reporter as they allow you to send current snapshot of web page. But I think it's some internal function which isn't available in JS api.
Also, I think this can be easily abused for spying on users, so don't expect any official support from browser development teams.
Related
Yesterday, I saw a tweet saying about holderJS library. When I read the usage, it says it will generate the image placeholder completely on client side. So I am wondering why in the life would I need a placeholder library?
What is the scenario in which rather than placing div of some size I would use image placeholder?
Image placeholders are generally meant for a page that is either in the process of dynamically loading a real image or the page is only partially designed and the placeholder image shows how the design will be laid out and how big the image should be even though the real image is not yet available. In this way, the HTML design can be nearly completed even though the final images are not yet available or done.
Wikipedia uses image placeholders when they know they want a particular image in a page, but are in search of an image they can use with the appropriate license.
Image placeholders are traditionally served up by a service on the web that automatically creates the placeholder images based on query parameters in a URL, but the holder.js library creates placeholder images entirely on the client (so no outside services are needed).
You can certainly achieve the same look as a placeholder with just a div with a background color and perhaps even some text in the div. But, when someone wanted to plug the final images into place, they would have the change the div tags to img tags. When using a placeholder image, all the HTML tags can be final and left as they are, only the .src values need to be plugged in to finish the design. So, placeholder images allow you to have a closer to complete version of the HTML even though the images are not yet done. It's a minor different, but one that is appreciated by some designers.
okay so i have basic skills in html, css, javascript.
im still in the learning phases but just need a little help on where to go in regards to creating a web app.
i can figure out all the code, so thats fine, i just need some pointers as to what to use where.
So basically ill have a webpage with a few simple buttons, when clicked they'll send a message to the server and the server will hold a count for each button clicked using a php script.
1) - would it be best to hold that information in a JSON file?
then from there, there'll be another webpage which will have div tags stretching 100% across the page, with an element inside it which will move across the page according to the count held on the server.
2) - what should i use to animate it moving?. would i use javascript? or css3 or something?
the front end will need to continuously update on the count held by the server.
3) - would AJAX methods be best using javascript?
any advice would be great thanks.
And one last thing.
With Javascript animating, if i wanted to animate a div moving horizontal, is the best way to do it by animating the margin size? or am i stuck in the dark days..
1: i would store it in a database, if you store it in a file make sure that you are handling writes in a safe way(multiple writes to the same file)
2:you could use javascript to animate the css properties of a html element(preferable the width)
3: Ajax would work but then you need to continuously poll the server for changes alternativly use longpoling http://en.wikipedia.org/wiki/Push_technology#Long_polling
an alternative if you only support modern browsers and your hosting company allows it is to use websockets
If you're trying to save information server side (which you seem to be), I would recommend using a database (such as MySQL).
If your animation is dependent on the value from the server, I would use javascript to animate it. Note that you will have to poll the server in order to actually get this information (lets say, every second). When you get the information, simply update the div you want to animate with the new information. I don't quite understand what you want your display to look like, so I can't really give you anything more specific here.
Yes. I would recommend using jQuery to handle your AJAX calls as it makes it much easier and deals with cross-browser weird-ities.
To your update:
One option could definately be to adjust the (left) margin size, but you could also use the relative position. It will basically push the element however many pixels in whatever position from where it would typically be displayed. So if your box is by default right along the left border, you could relatively position it 100px to the right. You can read more about position here.
I can't find an answer to this question, when the browser takes an SVG from the cache does it re-compute the xml or not, does it store the 'IMAGE' that it has already created? (How?)
I would've have thought not, but then I've noticed how fast repeated svgs load.
I've also noticed slowness on a page logo (in mobile browsers) which make me think THEY re-compute the SVG, so i've moved to PNG's (which are obviously cached) for mobile to save a lot of computational work for the low end phones.
So maybe, does the answer depend on the browser / browser type / browser settings?
*my svg's are compressed svgz's by the way
Sometimes it does and sometimes it doesn't. Most browsers go to some effort not to rerender things unless they have to. There is a buffered-rendering property in SVG 1.2 Tiny that may help if you're using Opera, other browsers try to do things automatically without requiring such hints though.
Browsers generally don't cache SVG content as a simple bitmap though. They do cache things like the absolute position and size of shapes and text with transforms applied, the css tree structure, gradients etc and then use this information they can redraw the content much more quickly than having to work it out each repaint. Such information allows browsers to copy with javascript and SMIL animation of parts of the SVG content as well as user scrolling.
What language or technology would I need to be able to create documents online? I want to be able to add text and images and move them into position, resize etc, similar to this.
And then when complete, create a PDF from them.
Sorry if this is a bit vague, I just need to know where to start researching.
You need to decide on your basic technology: Flash, Silverlight, Canvas, client-side SVG, server-side SVG or server-side bitmap. There are also commercial solutions that work with Adobe InDesign documents (and probably a host of other proprietary formats) but I'd expect those not to be cheap.
Flash/Silverlight require plugins, and are considered by some to be a dying technology - though I am sure that is disputed. Canvas is 'very HTML5' and is essentially a bitmap built/rendered on the client, but if you are ultimated rendering to PDF it may not provide the resolution you need. The same limitation affects building an image server-side too - you should probably be dealing with vector elements plus bitmaps, rather than rendering everything to pixels as you go.
That leaves SVG in my list, either on the client (see RaphaelJS) or on the server (see Inkscape). I'm doing some work with server-side SVG rendering at the moment, and it is promising; although subject to more scalability issues than client-side, it doesn't suffer from browser-compatibility issues or the limitations of browser rendering.
The biggest issue in browser SVG rendering is flowed paragraph text and text in/on a path - I am not sure how well these are implemented in modern browsers, or how much agreement there is between them. This is especially the case given that some of these require SVG1.2, and browsers (afaik) are only just settling on SVG1.1, after many years. But, if you just want to do standard blocks of text, bitmaps and vector elements, browser-based SVG should suit you fine.
The example you've given uses a server-side technology (SVG, or perhaps a commercial format) and renders to low-res PNG on the client.
In your case, once you've considered how to 'do the editing', you'll need to consider how to render to PDF, which will be done on the server. You could go low-level and use something like FPDF, use a report renderer like Jasper, or use a graphics system like GhostScript, Inkscape, Scribus, ps2pdf, svg2pdf etc.
Aside: I normally don't answer questions without obvious prior research. But, since you've indicated that you will indeed undertake this, I'm happy to help get you started.
i'm buildling a website and I want to create a translucid menu. I know that .gif image types enable transparency, but from my experience, not translucidy(anything between being transparent and opaque) - by default it seems to set the opacity to 100%, ie a solid image without any translucity/transparency.
I'm not sure if the issue is with the file type, or with how I'm exporting my menu. If it's worth anything, I'm using Fireworks to create and export my menu.
As is, I'm exporting my seperate files for my menu as .pngs, which seem to support translucent images, but I know that I'll be wanting to reduce the file size of these images soon, so is there a better alternative to getting a semi-transparent image other than using the .png file type?
Thanks,
Patrick
I'd say PNG is probably the best bet. The more modern browsers (read: not IE6) understand the 8-bit alpha channel it provides, whereas GIFs just have the transparency key.
Often these days, the bottleneck on sites isn't the size of the image (either in dimensions or in data) but rather the number of requests that it takes to load a page. More modern website designs try to pack as many images into one using techniques like CSS Spriting (woot.com, most of google). The other bottleneck is often not setting caching up correctly, forcing return visitors to reload a bunch of stuff.
You'll see google's various pages caching everything it can, and reducing the number of things a single page needs to download (combine all Javascripts into one, all CSS stylesheets into one) so that the browser is make 2 and 3 requests instead of 15-20.
I'd go with PNGs, and look into CSS sprites and caching as an alternative optimization.
See here for an example of an image sprite used on google's homepage.