This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11796 - HTML5 SUGGESTIONS ------------------------------ This file contains suggestions of tags / features that can be added to HTML5. I sincerely hope that these features are added especially the file tag (<file></file>) which is the last I would write on. I hav
Summary: HTML5 SUGGESTIONS ------------------------------ This file contains suggestio...
Status: RESOLVED INVALID
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-18 23:25 UTC by contributor
Modified: 2011-08-04 05:16 UTC (History)
7 users (show)

See Also:


Attachments

Description contributor 2011-01-18 23:25:01 UTC
Specification: http://dev.w3.org/html5/spec/Overview.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#top

Comment:
HTML5 SUGGESTIONS
------------------------------
This file contains suggestions of tags / features that can be added to HTML5.
I sincerely hope that these features are added especially the file tag
(<file></file>) which is the last I would write on.

I have 4 (Four) suggestions to make

1)
Mic input type - <input type="mic" />
---------------------------------------------
will enable the browser to receive direct input from a microphone. Input is
saved in (mp3) format and
uploaded when form is submitted.
Problem it will solve : I can't think of any problem this tag will solve but I
can think of a benefit / advantage.
(Web based voice authentication). A person reads a word into Microphone and
submits it, a server side script
analyses uploaded audio file and authenticates it. This can be combined with
username and password.

2)
Cam input type - <input type="cam">
---------------------------------------------
Will enable the browser to receive direct input from web cams. This tag is not
important but if implemented
will remove browsers dependence on plugins like flash to support web cams.

3)
AJAX file uploads
-----------------------
HTML5 should officially support AJAX based file uploads. Current workarounds
exist like submiting form to an
iframe but these are just hacks. What I am saying is that the XMLHttpRequest
object should have a property like
file which is an array and the IDs of the file upload input type can be stored
in this array. When the submit method is
called, the files are uploaded.
Also, HTML5 should provide certain file upload related events - 4 events are
suggested below
a )onuploadbar - This event is raise each time a certain amount (bar) of
percentage of file is uploaded. E.g. event is
raised each time 10% of file is uploaded.
b )onuploadcomplete - This event is raised when all files are uploaded
successfully
c )onfilecomplete - For multiple file uploads, this event is raised for each
file that has been successfully uploaded
d )onuploadfailed - This event is raised if any error occurs during upload
causing the upload to fail

4)
File tag <file></file> and FILE STREAMING
--------------------------------------------------------
This is the most important suggestion. 
Currently, server side technologies exist for dynamically generating content
that can be displayed in browsers. E.g. images
The problem here is no client side technology is available to support dynamic
content generation.
For better understanding, I will start with a problem statement

PROBLEM
---------------
I have a PHP script that dynamically generates a chart in form of a GIF image.
I can point the SRC attribute of an image tag to this
PHP script but there is no standard way for the browser to handle this, so
while one browser will reject the image because it does
not recognise ".php" as an image extension, another browser will ask the user
if they want to save the file (download it).
In PHP, there is an extension called GD that can be used to dynamically
generate images at runtime, however to send this image to
the browser, the image first has to be saved to a file on the server (this has
an overhead), then an image tag is sent to the browser
with the SRC attribute set to the location of the image file. This places
restrictions on the use of dynamically generated files.
It is important to note that dynamically generated files are not only limited
to images, flash, PDF and other files can also be generated
dynamically. Currently only static files are supported.

SOLUTION
---------------
The file tag is an attempt to provide a solution to this problem.
The file tag provides a standard way for dynamically generated content to be
sent to the client directly (streamed).
Description : A file tag is a container for dynamically generated and streamed
files.
A file tag is a generic container that can host any type of file. The server
side script first sends a mime-type header to inform client
of the kind of file client should be expecting / will be receiving. Files are
displayed through the use of plugins or inbuilt browser
capabilities.
Although there are special tags to handle various file types (<img>, <audio>,
<video>), having one tag that is file type
independent and relies mostly on plugins to display files removes to necessity
to add file streaming support to each tag
that hosts files.

How It Works
I add a file tag to my HTML page and set the "SRC" to a PHP script or any
server side script. This script is called and it first sends
a mime type header followed by dynamically generated content. Browser uses
mime type to be able to display file. Browser might
have native capacity to display file or it may have a plugin installed which
it uses to display file. Where the browser does not have
a plugin installed that can display file and a native capacity to display
file, the user is informed that browser cannot display file and
is given the option of saving file to disk to open later with an appropriate
program.
Also, dynamically generated content can also be streamed inbetween the file
tag.
I.E. Instead of setting the "SRC" attribute to a server side script, the
server side script can simply echo the beginning file tag <file>,
echo the mime type header, echo the dynamically generated content and then
echo the closing tag </file> . It works either way.

The file object created from a file tag exposes certain methods and properties

- ispluginused (boolean property) : is true if a plugin is currently used to
display the contents of file tag.
- getplugin() : a method called to get a reference to plugin object if object
exposes it self to javascript.
   returns the plugin object on success and false on failure
- Load($url) : Current file content is unloaded and new content is loaded by
calling server side script pointed to by $url
- Refresh() : Reloads content from current url.

DEFINITION OF TERMS
---------------------------------
1 )Static files : are files saved on the server which are sent to the client
upon request. Static files are usually generated using
3rd party software and are then saved on the server. They are hardly changed
after being saved on the server. And a change will
require human interaction.

2 )Streamed files : are files that are generated dynamically by server side
scripts and streamed (sent) directly to the client
(browser). They are not normally saved to the server although they can be.

APPLICATION / BENEFITS
-------------------------------------
A PHP script that dynamically generates an image or PDF file can send it to
the browser in a standard way without having to save
it to disk on the server. The client will also understand and be able to
display file.
The file tag does not introduce any new file type, it is just a standard way
for the browser to receive streamed files.

PHP EXAMPLE
---------------------
<?php
$image = imagecreatefrompng("images/picture.png"); // image is fetched from
file because this is an illustration of file tag not dynamic image generation
echo "<file>";
echo "mime-type:image/png";
imagepng($image);
echo "</file>";
imagedestroy($image);
?>

OR

// image.php
<?php
$image = imagecreatefrompng("images/picture.png");
echo "mime-type:image/png";
imagepng($image);
imagedestroy($image);
?>

// image.html (part)
<file src="image.php"></file>

Posted from: 41.220.69.8
Comment 1 Tab Atkins Jr. 2011-01-19 01:21:23 UTC
#1 and #2 are already handled via the @accept attribute on <input type=file>.  You declare what type of file you'd like to accept, and the browser can then ask the user if they wish to provide a file, or use their mic/camera to create one on the fly.

#3 is already handled by XHR, and has been for a while.

For #4, <object> is already designed to accept arbitrary files, with more specialized elements (<img>, <audio>, <video>) accepting particular types of files for better handling.

Your assertion that <img src=foo.php> may not work in some browsers is false - no browser rejects images based on file extension, nor do any of them try to automatically save images referenced through <img>.  If they did, they'd have massive compatibility problems, precisely because so many images are generated by php scripts in that way.  The correct way to load an image, dynamically generated or not, is to use <img>.
Comment 2 Aryeh Gregor 2011-01-19 09:25:14 UTC
(In reply to comment #0)
> 1)
> Mic input type - <input type="mic" />
> 
> 2)
> Cam input type - <input type="cam">

These are being worked on in the form of <device>, and hypothetically sort of maybe exist in the accept="" attribute (although browsers don't implement that yet).

> I have a PHP script that dynamically generates a chart in form of a GIF image.
> I can point the SRC attribute of an image tag to this
> PHP script but there is no standard way for the browser to handle this, so

You're mistaken -- handling is both standardized and interoperably implemented.

> while one browser will reject the image because it does
> not recognise ".php" as an image extension,

No browser does this.

> another browser will ask the user
> if they want to save the file (download it).

No browser does this.  Make sure you aren't serving the image with Content-Disposition: attachment.

> In PHP, there is an extension called GD that can be used to dynamically
> generate images at runtime, however to send this image to
> the browser, the image first has to be saved to a file on the server (this has
> an overhead), then an image tag is sent to the browser
> with the SRC attribute set to the location of the image file.

No you don't.  You can serve the image directly as your HTTP response from the .php file and it will work fine.  Tons and tons of applications do this.  Thus there's no problem for your suggestion #4 to solve.
Comment 3 Ian 'Hixie' Hickson 2011-02-16 08:16:47 UTC
Can someone do me a favour and split out the issues that aren't already handled into separate bugs?
Comment 5 Michael[tm] Smith 2011-08-04 05:16:52 UTC
mass-move component to LC1