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
Related
I'm learning to use a payment method via SCI.
and for that I have to send a POST/GET request to The SCI.
everything is working fine. the payment goes well.
but when I open the page and inspect it, I can see The input fields of the form. (type-->hidden) then using the edit HTML I can change the amount as you can see in the image bellow
<input type="hidden" name="amount_USD" value="60" readonly>
the readonly does not do the job! how can I make HTML Code unchangeable.
or if there is any alternative way to code this in a more secure way.
You can never make client side code completely protected, because there are many tools one can use to manipulate the files. Anything from browser extensions to developer tools can do this. Code that can be modified includes HTML, CSS, and client-side JavaScript.
If your app/website relies on this type of security, it will never be completely secure.
Chrome Dev Tools is only one example of a way some could maliciously use your app. You should evaluate your security practices from the back end to front end.
There is nothing you can do to prevent the user from being able to edit the HTML on client (browser). You should implement server side validation to reject invalid data.
You can read more about it here: JavaScript: client-side vs. server-side validation
In this particular case, you could do something that rejects the amount received from client if it doesn't match on the server. Or, do not receive the amount from the client at all, if the client should not be able to change it.
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>
Let's say someone is writing a reply to an online forum on their iPhone when they lose connection.
Is it possible to use HTML5 local storage to save their submission and post it when they get connection back?
If so, how do I tell if the phone has a connection or not?
Yes you can by implementing your custom logic into the app.
To see if a connection is available you could either use navigator.onLine flag (but it seems that is not completely reliable):
Does Safari and/or WebKit implement the equivalent of window.navigator.online?
http://html5demos.com/offline
or try to load content from the internet and see if it's possible or not:
Checking online status from an iPhone web app
Could you not use JavaScript to set a variable and make it a string with the content of whatever the user puts in the box? You could use getElementById or similar to get the content from the form.
Then, store it in a "cookie". If you don't know how to do this, here is a quick run down on javascript cookies from w3: http://www.w3schools.com/js/js_cookies.asp
Then on page load you could have it load the cookie and make the value of the form equal to the variable you declared earlier.
The best approach (in the light of navigator.onLine behaving inconsistently in different browsers) would be to save whatever the user is typing to localStorage every few seconds or every few keystrokes.
If the page is reloaded again, then you can make sure to first see if there is anything stored in the localStorage key, and if so, then load that into the text box and the user can continue from where he left off.
You can also take a look at the 'going offline with web storage' section of this article http://dev.opera.com/articles/view/taking-your-web-apps-offline-web-storage-appcache-websql/
I initially set out to learn how to handle "ajax-ready file uploads"; I found, and comprehend, one of the main concepts: it's not possible as ajax, but you can submit a form with the target set to a hidden iFrame's id [1]. That seems to be generally accepted by the community and compatible with all browsers. Is that an accurate assessment?
My question is: what are the pitfalls to this approach? Because if there are none, it seems to me that every "ajax-ready post" could be done in this same fashion. Remove the file upload component and this approach versus, say, a jQuery.post() approach appear to have identical outcomes.
In all the questions and resources I've researched, I've only been able to find "solutions" for handling my initial issue. I've been unable to find any sort of "pro v. con list" or "pitfalls to this approach" anywhere regarding a form targeting an iFrame; if you know of one, please feel free to share it!
[1] HTML Example:
<form method="post" target="take_the_reload">
...
</form>
<iframe class="hide_me" id="take_the_reload" name="take_the_reload"></iframe>
Much obliged,
Beez
References: Just a couple of the resources I've used:
http://www.joshclarkson.net/blog/file-uploads-in-a-hidden-iframe-using-jquery/
Firefox form targetting an iframe is opening new tab
http://terminalapp.net/submitting-a-form-with-target-set-to-a-script-generated-iframe-on-ie/
javascript: submit form in an iframe...help
http://www.openjs.com/articles/ajax/ajax_file_upload/
When I first started AJAX (before jQuery and Prototype came along) I used to do exactly that with all my forms....just post them to a hidden Iframe. It was easy and painless.
The drawbacks of form-post:
It's not really "pure" AJAX (file uploads aside). I'm sure all the DOM manipulation in the iframe for the result is slower than just getting back a response via XHR.
The error handling is more difficult - you have to look at what the server puts in the Iframe as a result
Things are moving towards JSON-based data handling which forms alone don't do
Sometimes you want to do something "in the middle" between the form and the server such as some field mapping or including other client-side data
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.