WHATWG Wiki - User contributions [en]

Talk:Validator.nu Web Service Interface

2008-06-18T00:58:29Z

KornelLesinski: implementation feedback

== Implementation feedback ==
Just for fun I've added sort-of compatible interface to the [http://hcard.geekhood.net hCard Validator].

My Suggestions:

* id field for messages, that uniquely identifies each problem (e.g "unknown-attribute"). This may allow clients to ignore certain warnings and accurately aggregate error statistics even if error message contains variable data or simply wording changes.
* if message contains variable data (e.g. "'div' not allowed in 'span'"), the data could be additionally given in a separate array (["div","span"]), to allow clients to localize messages using id + arguments.
* combinations of error types and subtypes are weird. It could be orthogonal severity {fatal|error|warning|info} and type {document|i/o|unsupported}, this way you could e.g. warn about i/o problems (like downgrading of https to http).
* message_html field to allow formatted messages (messages may contain code fragments, abbreviations or links and I'd like to display these nicely to the user)
* field for additional, more verbose message or hint how to fix the problem (html formatted too)
* field for url to the relevant part of the specification
* possibility to specify non-line-oriented error location (in my implementation I don't track line numbers, but I could generate XPath path to the element)
* parse tree might contain code property which is just an XML serialisation of DOM (this is good enough for spotting misinterpreted markup)
* field or naming scheme for implementation-specific data?

Link Hashes

2007-08-31T08:03:02Z

KornelLesinski: Undo revision 2486 by Special:Contributions/Usome (User talk:Usome)

Many download sites, especially for software download, give hashes or digests for the file they distribute so that users can check the validity of the files once they've downloaded it. The process for verifying the hash however isn't straightforward.

== Problem Description ==
A lot of software download pages already give you MD5 or SHA-1 digests values to check the validity of the downloaded file. Checking the file ensure that the downloaded file is same as the author of the page wanted to give you. Corrupted or tampered files can be detected that way.

The problem is that there is no way to automate that verification process. To automate this process, a browser would need to extract the hash associated with the link on the original page.

=== Current Usage ===
Some links to software download pages featuring hashes:
* Apple: [http://www.apple.com/support/downloads/securityupdate20060061039client.html Security Update 2006-006]
* [http://www.php.net/downloads.php PHP Downloads]
* Apache: [http://httpd.apache.org/download.cgi HTTP Server]

Other examples can be found on the [http://microformats.org/wiki/hash-examples#Who_offers_MD5.2FSHA-1_checksums_with_software hash examples] page on the Microformat wiki.

=== Benefits ===
Easier discoverability of tampered files which could come from a mirror server being hacked.

== Proposed Solutions ==

=== hash attribute ===
A hash attribute could contain a md5 checksum of the target file. If the hash of the downloaded file does not match the one from the link, the file is deleted or quarantined and the user is alerted of a potential security risk.

<pre>
<a href="..." hash="b3187253c1667fac7d20bb762ad53967">
</pre>

==== Processing Model ====
When the link is clicked, the browser keeps the hash in memory to compare it with the it hashes from the downloaded file. Once the file is downloaded, the the computed hash is compared against the expected hash.

:"To be completed: what to do about non-download links, like links to other pages, when they have a hash?"

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

=== Hash Microformat ===
The hash microformat provides a way to associate hash values with links:

<pre>
<span class="download">
<a rel="bookmark" href="...">Download OpenOffice.org
<span class="checksum md5">e0d123e5f316bef78bfdf5a008837577</span>
</a>
</span>
</pre>

The microformat is better described on the [http://microformats.org/wiki/hash-examples hash-examples] page.

==== Processing Model ====
When a link is clicked, the browser check if it corresponds to the microformat (''details to be added''). If it is the hash value is extracted and, once the file is downloaded, the computed hash for the file is compared against the expected hash. Browsers should keep the initial hash value across redirections, if any. This only applies to files downloaded to the disk.

:"Could the syntax be extended so that fragment identifiers could cohabit with fingerprints?"

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

The microformat markup is heavier that it needs to be. It also force page authors to put the hash visible inside the link, or to apply specific stylesheets to hide it on visual browsers.

=== Link Fingerprint ===
Append a digest for the file in the fragment identifier of the URL. The browser can then check the validity of the file when it downloads it.

<pre>
http://example.com/file#!md5!b3187253c1667fac7d20bb762ad53967
</pre>

The [http://www.gerv.net/security/link-fingerprints/ Link Fingerprints article] by Gervase Markham gives more details.

==== Processing Model ====
When the link is clicked, the browser check if the URL contains a hash. If the URL contains a hash, once the file is downloaded the computed hash is compared against the expected hash. Browsers should keep the initial hash value across redirections, if any. This only applies to files downloaded to the disk.

:"Could the syntax be extended so that fragment identifiers could cohabit with fingerprints?"

==== Limitations ====
Work only for downloaded files; fragment identifiers are used in other ways for regular pages and PDF files opened in the browser with a plugin.

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

=== Content-MD5 HTTP Header ===
It has been suggested to use the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 Content-MD5] HTTP header. A tampered file on a hacked server is very likely to get its digest updated accordingly however.

== Mailing List References ==
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007833.html Re: hash attribute] -- Tom Pike, Wed Nov 8 05:21:22 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Ian Hickson, Wed Nov 8 08:28:19 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007857.html Re: hash attribute] -- Gervase Markham, Thu Nov 9 09:23:32 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Michel Fortin, Tue Nov 14 08:53:43 PST 2006

[[Category:Feature Request]]

Drag'n'Drop Uploads

2007-05-02T13:47:37Z

KornelLesinski:

=== The problem ===
Web applications cannot accept files from user's machine as easily and intuitively as native OS applications - users can't drop images from desktop right into documents edited in WYSIWYG editors, on-line file browsers, asset management interfaces of CMSes.

Although browsers could allow <input type=file> controls to accept dropped files, drop zone would have to be limited to small area occupied by the control. This is not how applications usually work - they don't have area exclusively for dropping files, but entire window or regular UI controls react to dropped files.

There's nothing inherently wrong with having <input type=file> with file browser, some users may even prefer this type of UI, but depending on type of application/user preference such UI may feel inefficient and unintuitive.

=== Use cases ===
* Dropping image from local machine (desktop, file explorer/finder window, another application) into WYSIWYG (contentEditable) editor to have image uploaded to server and inserted into edited document right under cursor - just like you can with office suites.
* Dropping image into textarea that uses BBcode or Wiki syntax to have image uploaded and appropriate image embedding syntax automatically inserted.
* Adding attachments in a webmail
* Web-based file browser/asset management interface
* Drag'n'drop customization of images in page templates, forum avatars, etc.

== Proposed solution ==

=== The basic concept ===

A universal IDREF attribute that would connect particular element in document (''drop zone'') with a <code><input type=file></code> control.

<input type=file id=''uploader''>
<div dropped-files=''uploader''>drop your files here!</div>

In the above example, files is dropped into <code><div></code> would be "redirected" to the <code><input></code> element. <code><input></code> can use <code>max</code> attribute to allow multiple files to be dropped at once.

Drop zone doesn't have to be <div>:

<textarea dropped-files=''uploader''>write post and drop images to have [img]url[/img] added automagically!</textarea>

Algorithm also allows dropping files directly into <code><input></code>, without requiring any additional code.

<input type=file title="drop files here!">

Drop zones can be nested (deepest-nested takes precedence). For ease of implementation and compatibility with HTML4 documents, <code><form></code> can act as a drop zone (with least precedence).

=== The process ===

==== Finding related <input type=file> ====

These steps are supposed to allow dropping files directly into <code><input></code>, or into a designated drop zone. As a fallback a <code><form></code> can be assumed to be a drop zone.

When user drops file(s) into the document:

# Take element on which file(s) were dropped (''drop target'') - usually it will be target of <code>mouseup</code> event.
# If the element is <code><input type=file></code> '''proceed to the next section.'''
# If the element does not have <code>dropped-files</code> attribute, check its parent. Continue checking ancestors until the attribute is found or there are no more parent elements.
# If element with <code>dropped-files</code> attribute was found:
## Find element referenced by <code>dropped-files</code> attribute
## Verify that referenced element it's an <code><input type=file></code>
## If above conditions are met '''proceed to the next section.'''
## Otherwise ignore dropped files or perform browser's default action and abort these steps.
# Start again from the ''drop target''
# If the element is not <code><form></code>, check its parent. Continue checking ancestors until <code><form></code> is found or there are no more parent elements.
# If <code><form></code> is found:
## Find first <code><input type=file></code> that belongs to that form
## If element can be found, '''proceed to the next section.'''
# Otherwise ignore dropped files or perform browser's default action.

(this algorithm can be optimized to walk up the DOM tree only once)

==== The next section ====

# Synchronously fire <code>filesdropped</code> event on ''drop target''
# If <code>filesdropped</code> event was cancelled, ignore dropped files and abort these steps.
# Set value of <code><input></code> just as if files were chosen using regular method (including setting multiple files if <code>max</code> attribute permits) and fire <code>change</code> event on <code><input></code>.

=== Security ===

Dropping is limited to one DOM tree (does not cross frames). Scripts still can't set value of <input type=file>.

The only new risk is that script may know exactly when user has chosen a file and may start uploading it immediately (IIRC currently major browsers don't trigger <code>change</code> event on file controls).

Browsers which used to open files dropped into document area will probably have to ask user for confirmation when first file is dropped to prevent websites from stealing files from users unaware of the new feature.

=== Open Issues ===

==== Filesdropped Event ====
* It should reference relevant <code><input></code>
* Provide some information about dropped file(s) (file name, mime type, size?)
* If possible, provide information about exact place where event occurred (using <code>Range</code> object for WYSIWYG?)

==== Other issues ====
* How would script mark areas where files can't be dropped (temporarily/conditionally) allowing browser to dynamically change cursor? Is script fiddling with CSS cursor property and canceling <code>filesdropped</code> event enough?
* Since the solution requires form and <code><input></code> element, backwards compatibility can be maintained. The problem is script may rely on files being set via drag'n'drop and may not act properly when user uses file control directly.
* Many elements could reference single <code><input></code>. Is this desirable? Disallowing that might help backwards compatibility (it would be more likely that authors prepare separate <form>s pre-filled with necessary data), OTOH it would be easier for authors to have single uploader for multiple items on the page.
* Would it be possible to have previews of images and documents available prior upload? Import into <code><canvas></code> without upload?
* Should the form be submitted asynchronously and automatically? It would allow browser to save user's time by uploading immediately and in the background. There would be possibility of uploading multiple files at the same time (alternatively they could be queued/batched).
* If upload is async, script would have to receive information from the server once upload finishes (WYSIWYG editors would need to put placeholder in the document while file uploads and replace it with the real thing afterwards). Currently it can be hacked via <code><from replace=values></code> and hidden input element or <code><from target=hidden_iframe></code> and cross-frame scripts.

== Related implementations ==

IE supports [http://msdn2.microsoft.com/en-us/library/ms537658.aspx dataTransfer] object which can be used for handling drag'n'drop and clipboard copying of text and URLs. This interface could be reused+extended for files.

Drag'n'Drop Uploads

2007-04-26T20:39:47Z

KornelLesinski: /* The basic concept */

Drag'n'Drop Uploads

2007-04-26T20:24:38Z

KornelLesinski: /* Open Issues */

=== The problem ===
Web applications cannot accept files from user's machine as easily and intuitively as native OS applications - users can't drop images from desktop right into documents edited in WYSIWYG editors, on-line file browsers, asset management interfaces of CMSes.

Although browsers could allow <input type=file> controls to accept dropped files, drop zone would have to be limited to small area occupied by the control. This is not how applications usually work - they don't have area exclusively for dropping files, but entire window or regular UI controls react to dropped files.

There's nothing inherently wrong with having <input type=file> with file browser, some users may even prefer this type of UI, but depending on type of application/user preference such UI may feel inefficient and unintuitive.

=== Use cases ===
* Dropping image from local machine (desktop, file explorer/finder window, another application) into WYSIWYG (contentEditable) editor to have image uploaded to server and inserted into edited document right under cursor - just like you can with office suites.
* Dropping image into textarea that uses BBcode or Wiki syntax to have image uploaded and appropriate image embedding syntax automatically inserted.
* Adding attachments in a webmail
* Web-based file browser/asset management interface
* Drag'n'drop customization of images in page templates, forum avatars, etc.

== Proposed solution ==

=== The basic concept ===

A universal IDREF attribute that would connect particular element in document with a <code><input type=file></code> control.

<input type=file id=''uploader''>
<div dropped-files=''uploader''>drop your files here!</div>

In the above example, when file is dropped onto <div>, browser would "redirect" the file to <code><input></code> element. <code><input></code> can use <code>max</code> attribute to allow multiple files to be dropped at once.

'''Note:''' alternative approach would be to use DOM event triggered when a file is dropped. That could be much more flexible, but probably would require giving JS method for passing file information from event object to chosen <code><input></code> element - with complexity of DOM events and inherent insecurity of JS prototypes it could be too difficult to implement securely. With IDREF browser can keep full control and have process of setting <code><input type=file></code> hardcoded.

=== The process ===

==== Finding related <input type=file> ====

These steps are supposed to allow dropping files directly into <code><input></code>, or into a designated drop zone. As a fallback a <code><form></code> can be assumed to be a drop zone.

When user drops file(s) into the document:

# Take element on which file(s) were dropped (''drop target'') - usually it will be target of <code>mouseup</code> event.
# If the element is <code><input type=file></code> '''proceed to the next section.'''
# If the element does not have <code>dropped-files</code> attribute, check its parent. Continue checking ancestors until the attribute is found or there are no more parent elements.
# If element with <code>dropped-files</code> attribute was found:
## Find element referenced by <code>dropped-files</code> attribute
## Verify that referenced element it's an <code><input type=file></code>
## If above conditions are met '''proceed to the next section.'''
## Otherwise ignore dropped files or perform browser's default action and abort these steps.
# Start again from the ''drop target''
# If the element is not <code><form></code>, check its parent. Continue checking ancestors until <code><form></code> is found or there are no more parent elements.
# If <code><form></code> is found:
## Find first <code><input type=file></code> that belongs to that form
## If element can be found, '''proceed to the next section.'''
# Otherwise ignore dropped files or perform browser's default action.

(this algorithm can be optimized to walk up the DOM tree only once)

==== The next section ====

# Synchronously fire <code>filesdropped</code> event on ''drop target''
# If <code>filesdropped</code> event was cancelled, ignore dropped files and abort these steps.
# Set value of <code><input></code> just as if files were chosen using regular method (including setting multiple files if <code>max</code> attribute permits) and fire <code>change</code> event on <code><input></code>.

=== Security ===

Dropping is limited to one DOM tree (does not cross frames). Scripts still can't set value of <input type=file>.

The only new risk is that script may know exactly when user has chosen a file and may start uploading it immediately (IIRC currently major browsers don't trigger <code>change</code> event on file controls).

Browsers which used to open files dropped into document area will probably have to ask user for confirmation when first file is dropped to prevent websites from stealing files from users unaware of the new feature.

=== Open Issues ===

==== Filesdropped Event ====
* It should reference relevant <code><input></code>
* Provide some information about dropped file(s) (file name, mime type, size?)
* If possible, provide information about exact place where event occurred (using <code>Range</code> object for WYSIWYG?)

==== Other issues ====
* How would script mark areas where files can't be dropped (temporarily/conditionally) allowing browser to dynamically change cursor? Is script fiddling with CSS cursor property and canceling <code>filesdropped</code> event enough?
* Since the solution requires form and <code><input></code> element, backwards compatibility can be maintained. The problem is script may rely on files being set via drag'n'drop and may not act properly when user uses file control directly.
* Many elements could reference single <code><input></code>. Is this desirable? Disallowing that might help backwards compatibility (it would be more likely that authors prepare separate <form>s pre-filled with necessary data), OTOH it would be easier for authors to have single uploader for multiple items on the page.
* Would it be possible to have previews of images and documents available prior upload? Import into <code><canvas></code> without upload?
* Should the form be submitted asynchronously and automatically? It would allow browser to save user's time by uploading immediately and in the background. There would be possibility of uploading multiple files at the same time (alternatively they could be queued/batched).
* If upload is async, script would have to receive information from the server once upload finishes (WYSIWYG editors would need to put placeholder in the document while file uploads and replace it with the real thing afterwards). Currently it can be hacked via <code><from replace=values></code> and hidden input element or <code><from target=hidden_iframe></code> and cross-frame scripts.

Drag'n'Drop Uploads

2007-04-26T20:04:35Z

KornelLesinski: /* The process */

=== The problem ===
Web applications cannot accept files from user's machine as easily and intuitively as native OS applications - users can't drop images from desktop right into documents edited in WYSIWYG editors, on-line file browsers, asset management interfaces of CMSes.

Although browsers could allow <input type=file> controls to accept dropped files, drop zone would have to be limited to small area occupied by the control. This is not how applications usually work - they don't have area exclusively for dropping files, but entire window or regular UI controls react to dropped files.

There's nothing inherently wrong with having <input type=file> with file browser, some users may even prefer this type of UI, but depending on type of application/user preference such UI may feel inefficient and unintuitive.

=== Use cases ===
* Dropping image from local machine (desktop, file explorer/finder window, another application) into WYSIWYG (contentEditable) editor to have image uploaded to server and inserted into edited document right under cursor - just like you can with office suites.
* Dropping image into textarea that uses BBcode or Wiki syntax to have image uploaded and appropriate image embedding syntax automatically inserted.
* Adding attachments in a webmail
* Web-based file browser/asset management interface
* Drag'n'drop customization of images in page templates, forum avatars, etc.

== Proposed solution ==

=== The basic concept ===

A universal IDREF attribute that would connect particular element in document with a <code><input type=file></code> control.

<input type=file id=''uploader''>
<div dropped-files=''uploader''>drop your files here!</div>

In the above example, when file is dropped onto <div>, browser would "redirect" the file to <code><input></code> element. <code><input></code> can use <code>max</code> attribute to allow multiple files to be dropped at once.

'''Note:''' alternative approach would be to use DOM event triggered when a file is dropped. That could be much more flexible, but probably would require giving JS method for passing file information from event object to chosen <code><input></code> element - with complexity of DOM events and inherent insecurity of JS prototypes it could be too difficult to implement securely. With IDREF browser can keep full control and have process of setting <code><input type=file></code> hardcoded.

=== The process ===

==== Finding related <input type=file> ====

These steps are supposed to allow dropping files directly into <code><input></code>, or into a designated drop zone. As a fallback a <code><form></code> can be assumed to be a drop zone.

When user drops file(s) into the document:

# Take element on which file(s) were dropped (''drop target'') - usually it will be target of <code>mouseup</code> event.
# If the element is <code><input type=file></code> '''proceed to the next section.'''
# If the element does not have <code>dropped-files</code> attribute, check its parent. Continue checking ancestors until the attribute is found or there are no more parent elements.
# If element with <code>dropped-files</code> attribute was found:
## Find element referenced by <code>dropped-files</code> attribute
## Verify that referenced element it's an <code><input type=file></code>
## If above conditions are met '''proceed to the next section.'''
## Otherwise ignore dropped files or perform browser's default action and abort these steps.
# Start again from the ''drop target''
# If the element is not <code><form></code>, check its parent. Continue checking ancestors until <code><form></code> is found or there are no more parent elements.
# If <code><form></code> is found:
## Find first <code><input type=file></code> that belongs to that form
## If element can be found, '''proceed to the next section.'''
# Otherwise ignore dropped files or perform browser's default action.

(this algorithm can be optimized to walk up the DOM tree only once)

==== The next section ====

# Synchronously fire <code>filesdropped</code> event on ''drop target''
# If <code>filesdropped</code> event was cancelled, ignore dropped files and abort these steps.
# Set value of <code><input></code> just as if files were chosen using regular method (including setting multiple files if <code>max</code> attribute permits) and fire <code>change</code> event on <code><input></code>.

=== Open Issues ===
What's the best way to get information about dropped files and where event has occurred? It will be needed for inserting markup into WYSIWYG/textarea.

How would script mark areas where files can't be dropped (temporarily/conditionally) allowing browser to dynamically change cursor? Is script fiddling with CSS cursor property (and clearing value of <input>) enough?

Since the solution requires form and <code><input></code> element, backwards compatibility can be maintained. The problem is script may rely on files being set via drag'n'drop and may not act properly when user uses file control directly.

Many elements could reference single <code><input></code>. Is this desirable? Disallowing that might help backwards compatibility (it would be more likely that there were separate <form>s pre-filled with necessary data), OTOH it would be easier for authors to have single uploader for multiple items on the page.

Would it be possible to have previews of images and documents available prior upload? Import into <code><canvas></code> without upload?

Should the form be submitted asynchronously and automatically? It would allow browser to save user's time by uploading immediately and in the background. There would be possibility of uploading multiple files at the same time (alternatively they could be queued/batched).

If upload is async, script would have to receive information from the server once upload finishes (WYSIWYG editors would need to put placeholder in the document while file uploads and replace it with the real thing afterwards). Currently it can be hacked via <code><from replace=values></code> and hidden input element or <code><from target=hidden_iframe></code> and cross-frame scripts.

Drag'n'Drop Uploads

2007-04-25T23:04:12Z

KornelLesinski: New page: === The problem === Web applications cannot accept files from user's machine as easily and intuitively as native OS applications - users can't drop images from desktop right into documents...

=== The problem ===
Web applications cannot accept files from user's machine as easily and intuitively as native OS applications - users can't drop images from desktop right into documents edited in WYSIWYG editors, on-line file browsers, asset management interfaces of CMSes.

Although browsers could allow <input type=file> controls to accept dropped files, drop zone would have to be limited to small area occupied by the control. This is not how applications usually work - they don't have area exclusively for dropping files, but entire window or regular UI controls react to dropped files.

There's nothing inherently wrong with having <input type=file> with file browser, some users may even prefer this type of UI, but depending on type of application/user preference such UI may feel inefficient and unintuitive.

=== Use cases ===
* Dropping image from local machine (desktop, file explorer/finder window, another application) into WYSIWYG (contentEditable) editor to have image uploaded to server and inserted into edited document right under cursor - just like you can with office suites.
* Dropping image into textarea that uses BBcode or Wiki syntax to have image uploaded and appropriate image embedding syntax automatically inserted.
* Adding attachments in a webmail
* Web-based file browser/asset management interface
* Drag'n'drop customization of images in page templates, forum avatars, etc.

== Proposed solution ==

=== The basic concept ===

A universal IDREF attribute that would connect particular element in document with a <code><input type=file></code> control.

<input type=file id=''uploader''>
<div dropped-files=''uploader''>drop your files here!</div>

In the above example, when file is dropped onto <div>, browser would "redirect" the file to <code><input></code> element. <code><input></code> can use <code>max</code> attribute to allow multiple files to be dropped at once.

'''Note:''' alternative approach would be to use DOM event triggered when a file is dropped. That could be much more flexible, but probably would require giving JS method for passing file information from event object to chosen <code><input></code> element - with complexity of DOM events and inherent insecurity of JS prototypes it could be too difficult to implement securely. With IDREF browser can keep full control and have process of setting <code><input type=file></code> hardcoded.

=== The process ===

When user drops file(s) into the document:

# Take element on which file(s) were dropped (that's target of <code>mouseup</code> event)
# If the element does not have <code>dropped-files</code> attribute, check its parent. Continue checking ancestors until the attribute is found or there are no more parent elements.
# If no ancestor with <code>dropped-files</code> was found, ignore dropped files or perform browser's default action and abort these steps.
# Find element referenced by <code>dropped-files</code> attribute and verify it's <code><input type=file></code>. If this element can't be found or is not a file input, ignore dropped files or perform browser's default action and abort these steps.
# Set value of <input> just as if files were chosen using regular method (including setting multiple files if <code>max</code> attribute permits)
# ?? Fire <code>change</code> event (<code>formchange</code>? <code>filesdropped</code>?) [ on which element? <code><input></code> or drop target? how would one find where files were dropped? (Range object with position within related textarea/contentEditable would be useful) ]
# ?? Should the form be submitted automatically? For example form could be submitted asynchronously unless script objects to it using <code>preventDefault/stopPropagation</code> of <code>filesdropped</code> event

=== Open Issues ===
What's the best way to get information about dropped files and where event has occurred? It will be needed for inserting markup into WYSIWYG/textarea.

How would script mark areas where files can't be dropped (temporarily/conditionally) allowing browser to dynamically change cursor? Is script fiddling with CSS cursor property (and clearing value of <input>) enough?

Since the solution requires form and <code><input></code> element, backwards compatibility can be maintained. The problem is script may rely on files being set via drag'n'drop and may not act properly when user uses file control directly.

Many elements could reference single <code><input></code>. Is this desirable? Disallowing that might help backwards compatibility (it would be more likely that there were separate <form>s pre-filled with necessary data), OTOH it would be easier for authors to have single uploader for multiple items on the page.

Would it be possible to have previews of images and documents available prior upload? Import into <code><canvas></code> without upload?

Should the form be submitted asynchronously and automatically? It would allow browser to save user's time by uploading immediately and in the background. There would be possibility of uploading multiple files at the same time (alternatively they could be queued/batched).

If upload is async, script would have to receive information from the server once upload finishes (WYSIWYG editors would need to put placeholder in the document while file uploads and replace it with the real thing afterwards). Currently it can be hacked via <code><from replace=values></code> and hidden input element or <code><from target=hidden_iframe></code> and cross-frame scripts.

Feature Proposals

2007-04-25T20:34:22Z

KornelLesinski: /* Document Markup */

This document contains a list of the problems for which feature requests have been made. Linked problem pages contain the document of the problem and their relevant solutions. Obviously, we want to keep HTML as simple as possible. That means not everyone will get what they want. Having good documentation for the problems at hand will help all of us work out what is most important.

== Guidelines ==

Before proposing a feature, please read [http://blog.whatwg.org/proposing-features Proposing features]. If you want to add a feature request, start by copying the [[Problem Solving]] template page onto a new page and fill out as much information as you can.

You don't have to provide detailed answers for everything straight away. The most important information to provide at first is the problem description. Once we have detailed descriptions, use cases and an understanding of the limitations with existing markup, we can then begin to discuss the best way in which to address the problems and work out more of the more technical details.

== Document Markup ==
* [[Dialogue]]
* [[Annotation]]
* [[Footnotes]]
* [[Sidenotes]]
* [[Image Caption]]
* [[Inline Math]]
* [[Layout tables]]
* [[Drag'n'Drop Uploads]]

== DOM Scripting ==
* [[Text in Canvas]]

== Security ==
* [[Link Hashes]]
* [[Digital Signatures]]

== Other ==

This list of features needs to be sorted out. They've come from all the [http://del.icio.us/lachlan.hunt/WHATWG feedback provided on blogs] over the past few weeks.

* Don't render quotation marks around <code>q</code> elements.
* Make form validation easier
** <code>required</code> attribute
** <code>maxlength</code> attribute for textarea
** <code>pattern</code> attribute
** <code>min</code>
** <code>max</code>
* New Form Controls
** Search fields
** Combo boxes
** Date/Time
** E-mail
** Int
** Long
** Unsigned
** Float
** Number
** Currency
** URL
* WYSIWIG Editor (<code>contentEditable</code>)
* Placeholder attribute
* Captions for images
* Bring back the <code>start</code> and <code>value</code> attributes for ordered lists.
* Bring back the <code>menu</code> element
* Require XHTML-link syntax for HTML
* Caption/label/list header for lists
* Include the <code>role</code> attribute.
* Allow <code>href</code> on all elements
* Make it easier to mark up blocks of code
* Allow block level elements inside paragraphs
* “a tag that could hold "bad grammar" and not have any effect on the validation (sort of like a document.write from JavaScript) and would terminate all unclosed items at the end of the element (like TDs tend to do).”
* <code>blink</code>!
* Fix the <code>object</code> element.
* Unify <code>img</code>, <code>object</code>, </code>embed</code> and <code>iframe</code> into a single element
* Headers and footers
* A mechanism to include content from an external source (e.g. <code>include</code>, perhaps like XInclude)
* A <code>corner</code> element (presumably for making rounded corners)
* Markup for advertisements
* Easier column layouts
* A <code>foot</code> element for containing scripts at the bottom of the page, or something to help deal with cross-browser load events.
* Key Generation/Certificate management (The <code>keygen</code> element)

Talk:Link Hashes

2007-04-24T09:59:39Z

KornelLesinski: Metalink?

==== Link Fingerprint ====

Just a note to say that while this is certainly out of scope for HTML, it's nonetheless a good solution, and mentioning it there, with enough details, can serve of a justification to not include other proposed solutions in the spec. --[[User:Michel Fortin|Michel Fortin]] 09:56, 17 November 2006 (PST)

== Metalink? ==

http://www.metalinker.org/

Metalinks can contain hashes (in several, extensible, formats) and also other information, like target platform, language and list of mirrors.

Maybe instead of specyfing only hashes in HTML, we should encourage adoption of metalink?

[[User:KornelLesinski|KornelLesinski]] 09:59, 24 April 2007 (UTC)

Talk:Layout tables

2007-04-24T09:25:32Z

KornelLesinski: New page: Most of the difficulty with CSS is caused by incomplete IE's implementation (notably lack of <code>display:table-cell</code>). Specyfing even more advanced table-like constructs won't impr...

Most of the difficulty with CSS is caused by incomplete IE's implementation (notably lack of <code>display:table-cell</code>). Specyfing even more advanced table-like constructs won't improve IE6's implementation a bit.

And of course there's no reason to tie this layout to particular element names, so this proposal belongs to CSS and is out of scope of HTML.