I want to have a html file with javascript. Then I want to have some images in this file. I want to send this html file to my friends (per e-mail). I want them to see my html file with images but I do not want to send them all files with all images. It would be nice to send them just one file.
I also do not want to have images on a web-server.
I also do not want to send them an archive with all the files (since they then need to open this archive).
Do I want to much or it's possible to do what I want?
ADDED
I do not want my friends to see the html file in a mail-client. I want to send a file as an attachment. So, they can save it and then open with a browser.
Yes, it is possible:
# HTML
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA................." />
# CSS
background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA.................)
File source is encoded using Base64 algorithm that allows easily represent binary data as normal text.
Find out more on wikipedia: Data URI scheme.
Depending on whether the mail client supports it, you could in theory use the data URI scheme, like so:
<img src="data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
vr4MkhoXe0rZigAAAABJRU5ErkJggg==" alt="Red dot" />
Again, the support is mail client dependent. Some might not support it at all. Some might truncate after a X amount of bytes. Etcetera. As far as I know there aren't many of them. Further I don't see another ways to inline images in HTML like that. Until the support is widespread, your best bet is really to send the images along as an attachment.
Update as per the OP's update: well, most of the modern webbrowsers supports it. The aforementioned Wikipedia link even mentions them in detail.
Data URIs are currently supported by the following web browsers:
Gecko-based, such as Firefox, XeroBank, Camino, Fennec and K-Meleon
Konqueror, via KDE's KIO slaves input/output system
Opera (including devices such as the Nintendo DSi or Wii)
WebKit-based, such as Safari (including on iPhones), Android's browser, Epiphany and Midori (WebKit is a derivative of Konqueror's KHTML engine, but Mac OS X does not share the KIO architecture so the implementations are different), as well as Webkit/Chromium-based, such as Chrome and Iron
Internet Explorer 8: Microsoft has limited its support to certain "non-navigable" content for security reasons, including concerns that JavaScript embedded in a data URI may not be interpretable by script filters such as those used by web-based email clients. Data URIs must be smaller than 32 KiB.
Note that IE8 truncates the string after 32KB. So, as long as the images aren't that large, you could use the data URI scheme for IE8 users. It's not supported on IE7 and lower.
I am not aware of a way to accomplish what you're after with 100% certainty it will work.
Is there a way to forgo the images? Perhaps an ascii representation instead? (something like this http://www.text-image.com/)
The archive would be the only "single file" option that I'm aware of.
You cant execute javascript from a mail client. You can inline the images, but you will need a library because doing it by hand is non-trivial.
You should just send them a link.
Why don't you just link the images with relative paths, and bundle them in a folder with the html file and send it archived and compressed (zip or tarball, depending on preference)?
If you just want to send one file, just zip it using your favorite compression program.
You should never, under any circumstances, send email whose body is HTML. Send plain text mail with the images as MIME attachments, or better yet, put the images on a website (I hear Flickr is quite good ;-) and send them URLs.
I'm going to say it again, because it needs to be said more often: email must be plain text.
Related
I'm writing a web page that has a HTML <object> in it, like
<object [...]>Your browser does not support this.</object>
On all my machines I only have up-to-date browsers installed and don't want to clutter my machines with old browsers (this is actually not easily possible in most cases without depending on third-party-software and/or doing hours of configuration tweaking).
I know of pages like https://www.browserstack.com/ that let you render websites, but this is rather time consuming when I frequently need to check loads of small changes. And honestly I actually don't want to give my data to external companies just for a simple rendering.
How can I easily check how my page would look on old browsers?
Just found it out. The content between the <object></object> tags is not only triggered in unsupporting browsers, but also when the data attribute holds an invalid target (like an unavailable file).
So, to test how it looks on unsupporting browsers, one can simply set the data-attribute to something unavailable. But keep in mind that the webdesigner then also has to define a more meaningful message than just "Your browser does not support SVG", but also has to consider that the object to display is simply missing (for example in a dynamic setting of the data attribute via PHP, like data=<?php echo getFile(); ?> when the function returns something undefined).
I have a form to select images for a gallery, and I want to allow user to select only jpg,gif and png image formats.
And now, for testing, I change extension of a image to .bmp like "image1.bmp", and when I click in my input file to select a image, this "image1.bmp" is hidden, but If I select "show all files", this "image1.bmp" appears, and I can select this "image1.bmp" and send this image in my form. And Im inserting this image with this format on database.
This is normal using accept="image/gif, image/jpg, image/jpeg, image/png"??
Because what I wanted is to block all formats that are not gif,jpg or png.
I have this input file:
<input type="file" name="img[]" multiple="multiple" accept="image/gif, image/jpg, image/jpeg, image/png" />
This is common browser behavior. Browsers that support the accept attribute use it to create an initial file filter, but they do not prevent the user from changing or removing the filter and thereby selecting and submitting any file they like. The purpose of the attribute is to help users select files of appropriate types.
What browsers should do is less clear. HTML 4.01 says that the accept attribute “specifies a comma-separated list of content types that a server processing this form will handle correctly. User agents may use this information to filter out non-conforming files when prompting a user to select files to be sent to the server”. The reference to server-side processing may be misleading. The attribute affects client-side (browser) behavior only. The intent is to say that the attribute value should be written according to what file type(s) are expected from the user; it is more or less self-evident that the server-side form handler should be written so that it is capable of handling the specified type(s).
HTML5 LC is more verbose. It says that the attribute “may be specified to provide user agents with a hint of what file types will be accepted”. It then describes how it could be used by a browser to provide an adequate user interface. It also says: “User agents should prevent the user from selecting files that are not accepted by one (or more) of these tokens.” This might be sensible, but browsers do not actually do that. Even if they did, the attribute would not constitute a security measure of any kind (because a user could edit the form, or write a form of his own, or use a browser that ignores the accept attribute). Its purpose is to protect a normal user from making mistakes, like submitting a file of a type that will be rejected by the server-side handler.
(Browsers interpret the accept attribute value in rather simple way. They work on filename extensions, so if you name a GIF file, or a plain text file, or a binary program file so that its name ends with .png, they will treat it as a PNG image file, instead of inspecting the content of the file. The .bmp extension is problematic, since it commonly means Windows Bitmap, for which there is no registered MIME type; browsers may treat the nonstandard notation image/bmp as corresponding to .bmp.)
You cannot block sending of files. What you can do is to deal with files properly server-side, and there you should not of course rely on filename extensions but detect the types from the file content.
Clearly if you click "show all" can obviously see other files.
Your question is not quite hide or show, but filter at the time of upload, you have two solutions:
1) SERVER-SIDE:
With php (just an example) and regExp:
if (preg_match('#^image\/(png|)$#', $_FILES[$i]['img']['type']) === false) {
echo 'Invalid extension!';
} else {
//Save file
}
2) CLIENTE-SIDE:
With javascript use determinater lib:
https://github.com/rnicholus/determinater
Changing the extension does not change the mimetype of the file. Do the same test with an actual BMP file.
The accept attribute is not widely accepted. Chrome and IE10+ support it. If you're using anything else, like Firefox, Safari, or Opera, it won't work. You can read more here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input
This means that like Guilherme suggested, you'll need a client side or server side check. I'd suggest both. Client site will immediately tell an unsuspecting user, while the server side will help filter malicious users. However, beware, there is some debate on how MIME type detection isn't exactly reliable. You can Google around if you want to find out more about that.
Either with a headless browser, google filesytem API, or some other way.
This question says you can, but not how.
Converting d3.js SVG code to a standalone program -- any suggestions?
google groups has more hints, but no examples.
I've spent a bunch of time playing with the node-canvas example, as well as the phantomJS svg example. I can't figure out how to make them play together. Apparently in Linux, the x-windows Javascript rendering engine isn't very good anyway.
My API reading list of JavaScript, d3.js, SVG, CSS, and other HTML stuff is already mountainous - all I want to do is save a .svg image that I generate with d3.js.
Help, please.
This will neither be easy nor overtly complicated. Main reason being is that a web browser alone cannot save an SVG file from a DOM rendering, unless it's Chrome version 12.
Thing is that an SVG image is just a plain text file with a bunch of rendering instructions. The solution you point to basically says you would have to do this server side. Though they suggest node.js, you can do this in any server-side language you'd like.
Trick is to take your JavaScript/HTML interface, make it either keep track of all objects you create, or otherwise be able to serialize all of them, and then send that data (ex: via ajax) to a server-side program which would reconstitute that to an SVG file and offer it to be downloaded.
The challenge is that both your programs (client-side, javascript and server-side: php/etc.) will more or less have to re-implement SVG specifications to make this work and have common understanding as to how you serialized it for the transmission. There are virtually no stock components that do this for you.
There are some examples of using node().parentNode.innerHTML with 64B encoding, but I couldn't figure out how to use it.
https://groups.google.com/forum/?fromgroups#!topic/d3-js/aQSWnEDFxIc
The easiest solution I've found so far is FileSaver.js demo here:
http://eligrey.com/demos/FileSaver.js/
It uses the HTML5 filesaver interface.
I came across this today, I've not tried it but perhaps someone will find it useful:
https://github.com/d3-node/d3-node
const D3Node = require('d3-node')
const d3n = new D3Node() // initializes D3 with container element
d3n.createSVG(10,20).append('g') // create SVG w/ 'g' tag and width/height
d3n.svgString() // output: <svg width=10 height=20 xmlns="http://www.w3.org/2000/svg"><g></g></svg>
How can i limit my form to only accept jpeg files? Now it shows all files.
<input name="image" type="file" />
And are there any javascript method to show progress?
There is an accept attribute in the input tag, but it's not supported by all browsers. Here's an example:
<input type="file" name="image" id="image" accept="image/jpeg" />
It could be your first check, but your main check must be on the server when accepting the file.
How can i limit my form to only accept jpeg files
Mostly, you can't. You have to check at the server (which you need to do anyway, even if you can check at the client; you can never trust client-side validation, of anything). But things are improving. There is the new File API from the W3C coming down-the-pike, which you could use on browsers that support it (Mostly Firefox, at the moment; it was a Mozilla initiative), just for a better user experience for those with modern browsers.
Edit And Gert G points out that here's the accept attribute that can give a hint to the browser, which is nice for browsers that support it.
And are there any javascript method to show progress?
Not directly, no. It's sometimes possible to show progress indirectly, by using a timed series of ajax requests alongside the upload and having the server tell you how much it had received so far, but it's fraught with difficulty and probably not worth the bother.
This is another area where the file API could help, although you might find you introduced a fair bit of latency in the process: Basically, you could read a chunk of the file locally, send that to the server via ajax, update progress, read and send the next chunk, etc.
There are, of course, Flash uploaders like SWFUpload that show progress and such, if you want to use something proprietary (but incredibly widespread). (Flash, I mean.)
There is no pure html way to show certain file types, and there is no easy javascript way either.
I use a package called FancyUpload: http://digitarald.de/project/fancyupload/ which handles this part for me. Also, it will show the download progress bar as you've asked.
I should mention that the uploader I posted needs you to include a javascript framework called MooTools. There are other similar uploaders available if you prefer jQuery (such as uploadify) or another framework.
Please, make sure that you also check on the server side.
This can't be done in plain HTML/Javascript, but there are several Flash-based components that can do this - e.g. Uploadify comes to mind.
If you can live with this limitation, there's plenty of questions about this (with good answers) here on SO.
You can use <input name="image" type="file" accept="image/jpeg"> to limit the users choice. But you still need to check the file type in the server.
You can obviously not display progress without starting the upload, so you should be first looking for a server side api that keep the client updated on the state of the upload. As for javascirpt progress bars every javascript library has one e.g. jquery progress bar
Is it possible to create data URI's in GWT?
I want to inject a byte array image as an actual image using a data URI.
You should checkout ClientBundle in GWT's trunk. It will create data urls automatically for browsers that support them and fallbacks for that other browser: http://code.google.com/p/google-web-toolkit/wiki/ClientBundle
The feature won't ship until GWT 2.0, but it's in heavy use now.
Yes. It is completely possible to do this. I'd done it for an application until I realized IE6 doesn't handle binary data streams this way. You can do it in several ways. For the purposes of my example, I'm already assuming that you've converted the byte array to a string somewhere, and that it is properly encoded and of the proper type for your data URI. I'm also assuming you know the basic format (or can find it) of your chosen data scheme.
I've taken these examples from the Wikipedia article on data URI scheme.
The first is to just use raw HTML to make the image reference as you normally would and have it inserted into the page.
HTML html = new HTML("<img src=\"data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
vr4MkhoXe0rZigAAAABJRU5ErkJggg==\" alt=\"Red dot\">");
You can also just use an image. (Which should produce roughly the same output HTML/JS.)
Image image = new Image("data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
vr4MkhoXe0rZigAAAABJRU5ErkJggg==");
This allows you to use the full power of the Image abstraction on top of your loaded image.
I'm still thinking that you may want to expand on this solution and use GWT's deferred binding mechanism to deal with browsers that do not support data URIs. (IE6,IE7)