Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
Samuel Santos wrote: I don't think this is a valid argument since you can change it anyway [1]. [1] http://www.quirksmode.org/dom/inputfile.html I should note that some consider this a (low priority, low severity) security bug that should just be fixed (e.g. by disallowing opacity styling on file inputs or some such). -Boris
Re: [whatwg] Some media element details
On Mon, 14 Jan 2008, Antti Koivisto wrote: Some comments about the media elements: 3.14.9.4. Loading the media resource The user agent must then set the begun flag to true and fire a progress event called begin at the media element. The progress event draft calls this event loadstart (and occasionally start, that spec is not very consistent). No matter which name is chosen, it would be nice if it was same everywhere. Fixed. 3.14.9.7. Playing the media resource It is not entirely clear from descriptions of play() and pause() if the timeupdate, ratechange, play and paused events should all be fired asynchronously, though I assume that is the idea. Fixed. It would be nice to have a read-only attribute (called playing for example) that would be true when the element is actively playing. Knowing if the playback is progressing is necessary for implementing basic playback UIs with JS. It is clumsy and not very obvious that you need to do var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY to get this information. What's the use case? When a media element is removed from a Document, the user agent must act as if the pause() method had been invoked. Calling pause() will invoke load() in case the network state is EMPTY. This seems like wrong thing to do on remove. The above should be modified to invoke pause() only if the network state is greater than EMPTY. Fixed. It might also be good to explicitly state that exceptions are ignored. Which exceptions? 3.14.9.8. Seeking 3. If currentLoop is equal to the value of playCount, let... Should be equal to the value of playCount - 1. Fixed. As soon as the user agent has established whether or not the media data for the new playback position is available, and, if it is, decoded enough data to play back that position, the seeking DOM attribute must be set to false. There is no event of any kind associated with seeking attribute becoming false which makes it difficult to react to changes in seeking state. It might be a good idea to fire a timeupdate here. I've added 'seeking' and 'seeked' events. ... notwithstanding the looping attributes (i.e. the effective start and effective end, etc, don't affect the seeking attribute). Should be don't affect the seekable attribute. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some video questions
On Sun, 27 Jan 2008, Charles wrote: The video element supports width and height. Does this include the additional area needed (if necessary) by the controls? It strikes me that it shouldn't, since it would be odd for the video width and height to change when non-video decorators are shown/hidden. I don't see a standard controls height and width, which is fine, but will there be read-only attributes for the width, height and position for controls? The spec currently doesn't say. I've added an issue marker regarding this, but basically the rendering section will define this, based on implementation experience. On Mon, 28 Jan 2008, Charles wrote: If users do show the video element's controls, are the plug-in's native controls shown? No, the user agent is expected to provide its own controls, and not expose the embedding framework's controls. If that's the case, is the expectation that authors will need to temporarily hide controls (or make sure they're already hidden) before getting its height? The videoHeight attribute can be used to determine the actual native height of the video content. I have omitted a great deal of the remainder of this specification as it did not contain actionable feedback on the specification as far as I could tell. Please let me know if I missed something. On Tue, 29 Jan 2008, Charles wrote: For example: YouTube embeds SWF files. Shouldn't that be a video element from a semantic POV? If so, that seems to imply a requirement for the video element to be extendable with plug-ins. video would be appropriate for embedding the FLV files used by Flash players, but to embed the SWF files, the embed element is better suited. On Tue, 29 Jan 2008, Charles wrote: So, my questions remain. What I'm hearing is that (1) video will only be a cross-browser, cross-platform solution for exactly one format -- that freely implementable and royalty free combination of container and compressed video and audio formats -- and that (2) from a design perspective video transport controls may be any size (or no size at all if the browser vendor prefers overlays), requiring designers to roll their own if they need controls to be a predictable size. Correct, except that it's at least one format, not exactly one format. On Tue, 29 Jan 2008, Charles wrote: James wrote: Are you looking for a way for plugins, rather than the browser itself, to handle video? Yes, with the brower handling handles precendence and event routing, etc. Really not terribly different than plug-ins today, but semantically meaningful, straightforward, simple and consistent. I don't really understand what that would look like. It isn't what video is currently intended to be, though. On Tue, 29 Jan 2008, Charles wrote: Are Adobe/Microsoft going to be update their Flash/Silverlight browser plug-ins in order to be first-class video handlers in Safari on Mac and Windows? On Tue, 29 Jan 2008, Charles wrote: The question is not about what Adobe or Microsoft may or may not do. The question is about whether Safari (not to single out one browser) is going to (a) allow 3rd-party browser plug-ins to create support for more formats (b) using the video element (c) on the Safari platform. Yes, the WebKit implementation (Safari implementation) of video will allow people to provide new codecs to handle new formats. Here's a precise scenario: A user creates an HTML5 page, and of course uses the video element to embed their Windows Media content. They're rude, and could care less about Mac or Linux support. Will Safari provide an API that allows Microsoft to support this scenario [...] Yes, the Windows Safari browser would just use DirectShow to render the videos, and DirectShow allows Microsoft to register a new codec to handle the Windows Media content. On Thu, 31 Jan 2008, Christoph P�per wrote: Ian, |object| currently has special handling for images, shouldn't videos be dealt with similarily (i.e. not create a nested browsing context)? Since we're introducing video, I don't see much reason to go out of our way and support video in object as well. It would just make things even more complicated. Also |type=image| (or 'video') should be enough, without slash and subtype, but I've raised that before. I imagine I'll get to that feedback when I process the object element feedback then. :-) On Thu, 31 Jan 2008, Charles wrote: Imagine the QuickTime plug-in being able to register itself with IE's brower as a handler for video types that IE otherwise wouldn't handle. That seems like a very desirable thing, but the more we talk the more it seems outside the scope of what HTML5 can solve. The QuickTime framework can register itself as a codec in DirectShow, which would then work in IE. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
On May 14, 2008, at 9:55 AM, Křištof Želechovski wrote: I do not feel like having the file submission control styled and customized in any way; submitting a file poses a serious security and privacy risk so I would not like to see this control disguised as something else. Just like an alert window title, it should have a consistent look for all applications. The WebKit file input control would, I think, be safe to style because it does not have a text field to type into, so no matter what it looks like the user has to actively choose a file from the file open dialog after clicking on it. The designs of most other browsers would be vulnerable to disguising it as something else though, if the user can be tricked into typing a file path. Regards, Maciej Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Samuel Santos Sent: Wednesday, May 14, 2008 6:38 PM To: WHATWG; HTMLWG Subject: Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface This issue seems to be a very recurring and still unsolved problem when dealing with Web internationalization / multi-language Web Apps. I would like to suggest this to be reviewed with an editor comment please. Additionally, it's important if we could decorate separately the file path text field and the browse button using CSS. Best reagards, Samuel Santos
Re: [whatwg] iframe width/height
On Sat, 7 Apr 2007, Henri Sivonen wrote: Shouldn't iframe keep its width and height attributes just like the other embedded content elements? Documents don't have intrinsic dimensions, and the user's default font size is likely to vary from user to usr. How would you know what height and width to give? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe width/height
On May 15, 2008, at 12:57, Ian Hickson wrote: On Sat, 7 Apr 2007, Henri Sivonen wrote: Shouldn't iframe keep its width and height attributes just like the other embedded content elements? Documents don't have intrinsic dimensions, and the user's default font size is likely to vary from user to usr. How would you know what height and width to give? You give it the dimensions of an industry-standard ad banner size. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] [html5] window.print() undefined
On Mon, 18 Jul 2005, Dimitri Glazkov wrote: What do you guys think about this -- and this is just theoresizing and hypothizing :) Print representation, if defined, should probably not be viewed as the byproduct of the screen presentation. For instance, if script modified DOM properties in the screen presentation, these changes should not affect the print presentation, and vise versa. How is this accomplished? I've been thinking about DOM sandboxing idea lately, and it seems interesting, but I haven't have time to cook up anything delicious quite yet. So, here's the half-baked version: DOM Sanboxing Markup is serialized content that comes over the wire. DOM is an object representation of markup. This representation can be (and routinely is in Web apps) modified to something else. This would've been perfectly hunky-dory if the modifier of the DOM was the only player in the game. However, with the advent of the GreaseMonkey era, the rules a-changing. Now, instead of one UA, you have multiple UAs (let's call them UA-plets) of various degrees of completeness and importance, custom to each client, all operating inside of one big UA called the modern Web browser. This has certain unexpected and hard-to-regulate effects. How do you make sure that the semantics of DOM tree have not been messed with, so that a UA-plet that relies on semantics could still get its turn at the original markup? So, here's proposition minimus: store the original DOM tree and make it always accessible, regardless of what the final DOM tree will look like. It is, after all, the purest representation of data. The original DOM tree is read-only and can not be altered. Now, a proposition maxiumus: allow access to the original DOM tree AND provide facilities to create a mutable snapshot of it. This way, the UA-plets can have the cake and eat it, too: they can view DOM representation of the original markup, and also tweak it as they see necessary. This implies, of course, that printing is a UA-plet: it simply gets the original markup and either simply applies stylesheets to it or tweaks it as necessary, then sends it off to the printer. In effect, this allows the overarching UA environment (the browser) to sandbox DOM manipulation for specific purposes of each UA-plet, be that rendering for viewing, printing, or hCalendar data harvesting. Whaddayathink? This sounds overly complicated, and quite similar to what XBL2 allows. I'm not sure it's something we would want in HTML5, though. In particular I'm not really sure what problem we're trying to solve here -- that printing is inconsistent when GreaseMonkey scripts are involved isn't really a high-priority problem as far as I can tell. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5 - dialog
Ernest Cline wrote: The only synonym of dialog that is anywhere near as general seems to be discourse/. And I accidentally replied off list: Discourse is too general. In philosophy and theology a discourse can mean teaching, as in Levinas' discourse about 'the other' has made alterity a recurring theme in all modern philosophy or pentecostal theology is defined by its discourse about the charims. I would not associate discourse with a spoken list-like dialog. That would be way too narrow. Lars Gunther
Re: [whatwg] Thoughts on HTML 5 - dialog
Tab Atkins Jr. wrote: My personal favorite alternate suggestion so far has been cl. Yes, I also quite like the analogy with dl/ul/ol. But it may be confusing when using dt and dd as child elements (as in the current spec for dialog): cl dt dd ... /cl That could be resolved by introducing elements ct and cd: cl ct cd ... /cl and that I guess can be regarded as making things better OR worse depending on your focus... Best regards Mike Wilson
Re: [whatwg] Removing @rev
On 14 May 2008, at 12:11 AM, Ian Hickson wrote: On Tue, 13 May 2008, Křištof Želechovski wrote: Removing @rev is harmful for Lynx because that is how it decides who the author is. Removing rev= from the spec doesn't preclude Lynx still supporting it for legacy documents, and for new documents, rel=author is preferred and is trivially supportable given support for rev=made, so I don't think this is a particularly convincing argument. For what it's worth, I always press 'c' before going hunting for a contact address. It usually doesn't work, but that's life I guess. Ian: would it be too much to have the spec say that @rev is valid if and only if its value is made or owner? That way I can continue supporting older versions of lynx until people have updated to a version supporting rel=author I generally prefer lynx over links, w3m and such when I'm ssh'd into another machine, so I don't know much about them, but if they also support @rev then that would be more reason to keep it in with these fixed values. — Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] script charset=
On Wed, 14 May 2008 01:46:32 + (UTC)
Ian Hickson [EMAIL PROTECTED]さん wrote:
On Mon, 25 Apr 2005, Toshirou Takahashi wrote:
about 2.12. Scripting
http://whatwg.org/specs/web-apps/current-work/#the-script
interface HTMLScriptElement : HTMLElement {
attribute DOMString text;
attribute DOMString src;
attribute DOMString type;
};
Why isn't there Charset attribute ?
I've added it.
I haven't tested where UAs get their charset= information from in
detail. The spec, as defined now, makes the charset= attribute
authoritative, and if the attribute is omitted, makes document.charset the
required authoritative default. Is that what browsers do?
I can write English a little. If there is a mistake, I am sorry.
Well..
I do not know it, But, I think that probably is so.
http://www.w3.org/TR/REC-html40/charset.html#h-5.2.2
Priorities
1.An HTTP charset parameter in a Content-Type field.
2.A META declaration with http-equiv set to Content-Type and a value
set for charset.
3.The charset attribute set on an element that designates an external
resource.
The user agent may use heuristics and user settings.
But,The page becomes the storm of the error, if a browser ignores the
attribute that a person knowing charset of the js file appointed.
The Charset attribute evades an error surely on all current browsers.
In Japan, There are a lot of data assets of character codes such as Shift_JIS,
EUC
, ISO-2022-JP, UTF-8 ...
And it is not rare that they coexist on one page.
For example
meta http-equiv=content-type content=text/html; charset=UTF-8
script src=./hogelib.js charset=Shift_JIS/script
script src=./hogeJson.js charset=EUC-JP/script
body
...
It cannot solve an error by the setting of the browser by the user.
The reason is because an error is already taking place when user open up
a page.
And there are a lot of cases which cannot set Content-Type in the server
side.
By the way, I think that @charset Shift_JIS; in JS code (like CSS) is
good, but think the charset attribute to be the realistic choice that
all current browsers can avoid an error and confusion.
Thanx.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
--
Toshiro Takahashi [EMAIL PROTECTED]
高橋登史朗
http://allabout.co.jp/internet/javascript/profile/mbiopage.htm
http://jsgt.org/mt/01/
Re: [whatwg] Review of the 3.16 section and theHTMLInputElementinterface
The method to disguise a file input control as described is and should remain a dirty trick; if the user agent allows it, some add-on should detect it and offer a warning. Allowing semantic customization could be interpreted as encouragement. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Samuel Santos Sent: Thursday, May 15, 2008 1:38 AM To: Křištof Želechovski Cc: WHATWG; HTMLWG Subject: Re: [whatwg] Review of the 3.16 section and theHTMLInputElementinterface I don't think this is a valid argument since you can change it anyway [1]. [1] http://www.quirksmode.org/dom/inputfile.html Samuel 2008/5/14 Křištof Želechovski [EMAIL PROTECTED]: I do not feel like having the file submission control styled and customized in any way; submitting a file poses a serious security and privacy risk so I would not like to see this control disguised as something else. Just like an alert window title, it should have a consistent look for all applications. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Samuel Santos Sent: Wednesday, May 14, 2008 6:38 PM To: WHATWG; HTMLWG Subject: Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface This issue seems to be a very recurring and still unsolved problem when dealing with Web internationalization / multi-language Web Apps. I would like to suggest this to be reviewed with an editor comment please. Additionally, it's important if we could decorate separately the file path text field and the browse button using CSS. Best reagards, Samuel Santos -- Samuel Santos http://www.samaxes.com/
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
On Thu, May 15, 2008 at 1:23 AM, Boris Zbarsky [EMAIL PROTECTED] wrote: Samuel Santos wrote: I don't think this is a valid argument since you can change it anyway [1]. [1] http://www.quirksmode.org/dom/inputfile.html I should note that some consider this a (low priority, low severity) security bug that should just be fixed (e.g. by disallowing opacity styling on file inputs or some such). -Boris The Yahoo! UI toolkit [1] allows a developer to create a browse that looks like whatever he wants it to and can be controlled by javascript pretty much however he wants it to. Flickr uses this (you have no log in, so no link here). It also has more robust features than input type=file - the interface can have custom styles - the dialog can choose multiple files - the dialog can filter certain file types That Yahoo widget uses Flash and Javascript to make all that happen. Adobe isn't going to take this feature of Flash away (Javascript control of a file dialog) and I wouldn't expect browsers to try to block it. The W3C File Upload [2] draft allows for the something similar using plain javascript without the requirement for Flash, and there are already implementations in the wild. That's just a generic Javascript API - I can't imagine browsers trying to restrict how that looks on the page. Again, - the interface that have custom styles (anything with an onclick will do) - the dialog can choose multiple files These aren't features you're going to take away from today's users of popular web applications. Those features are here to stay. I don't see how customizing the look of the file dialog's button is a security risk. Sure, the button might say something malicious, but it still requires the user to browser his local files, choose a file, and click Open. One problem with either the Yahoo widget or the File Upload draft is that they both require Javascript to function. If you want these features to be accessible to non-Javascript enabled browsers, we'll need to include it in HTML. It would probably call for a new input type with a more specific, flexible presentation (i.e. just a button that can be styled with CSS) If Javascript is as an acceptable requirement, another problem with those solutions is that they require separate POSTs. The Yahoo uploader uses a separate request for each file. The File Upload API has functions like getDataAsHexBinary that, I guess, could put a file's data into a hidden input field, but that data still wouldn't be uploaded the same way regular input type=file is uploaded (as multipart/form-data with headers for each file, etc). It would be better for HTML to specify an accessible and clean way of styling buttons for producing file dialogs than to force Samuel Santos to use dirty CSS hacks, a proprietary tool, or an API that interfaces with HTML forms in a clunky way. [1] http://developer.yahoo.com/yui/uploader/ [2] http://www.w3.org/TR/file-upload/ -- Jon Barnett
Re: [whatwg] Removing @rev
On Thu, 15 May 2008, Nicholas Shanks wrote: For what it's worth, I always press 'c' before going hunting for a contact address. It usually doesn't work, but that's life I guess. Ian: would it be too much to have the spec say that @rev is valid if and only if its value is made or owner? That way I can continue supporting older versions of lynx until people have updated to a version supporting rel=author Well HTML5 is far from being ready, I recommend using HTML4 for now and getting Lynx to support rel=author in advance of HTML5 coming out. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Removing @rev
On Thu, 15 May 2008, Charles Iliya Krempeaux wrote: I thought the rev attribute was being added back? (Someone... I can't remember who... came on the Microformats mailing list, a while ago, and said something to that effect.) I have no plans to, evidence showed it was causing authors all kinds of problems, and had no practical benefits. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Removing @rev
Getting suport from Lynx is the easy part; the hard part is to get the supporting Lynx to all those BBS out there. This is very much different from the personal browser the user can control. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Thursday, May 15, 2008 10:02 PM To: Nicholas Shanks Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [whatwg] Removing @rev On Thu, 15 May 2008, Nicholas Shanks wrote: For what it's worth, I always press 'c' before going hunting for a contact address. It usually doesn't work, but that's life I guess. Ian: would it be too much to have the spec say that @rev is valid if and only if its value is made or owner? That way I can continue supporting older versions of lynx until people have updated to a version supporting rel=author Well HTML5 is far from being ready, I recommend using HTML4 for now and getting Lynx to support rel=author in advance of HTML5 coming out. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
Maciej Stachowiak wrote: On May 14, 2008, at 9:55 AM, Křištof Želechovski wrote: I do not feel like having the file submission control styled and customized in any way; submitting a file poses a serious security and privacy risk so I would not like to see this control disguised as something else. Just like an alert window title, it should have a consistent look for all applications. The WebKit file input control would, I think, be safe to style because it does not have a text field to type into, so no matter what it looks like the user has to actively choose a file from the file open dialog after clicking on it. The designs of most other browsers would be vulnerable to disguising it as something else though, if the user can be tricked into typing a file path. Because of this Firefox 3 does not allow typing filenames. If you click the input field it always brings up the file picker. / Jonas
Re: [whatwg] Thoughts on HTML 5 - dialog
-Original Message- From: Mike Wilson [EMAIL PROTECTED] Sent: May 15, 2008 8:02 AM To: 'WHATWG' [EMAIL PROTECTED] Subject: Re: [whatwg] Thoughts on HTML 5 - dialog Yes, I also quite like the analogy with dl/ul/ol. But it may be confusing when using dt and dd as child elements (as in the current spec for dialog): cl dt dd ... /cl That could be resolved by introducing elements ct and cd: cl ct cd ... /cl and that I guess can be regarded as making things better OR worse depending on your focus... Best regards Mike Wilson Because of the backwards compatibility using dt and dd with a new dialog element would have with most existing UA's, I'd be leery of changing the names unless additional types of child elements for dialog/ (by whatever name it gets) were added, such as an element to markup stage directions, audience response, or the like. Then, since we'd be introducing enough new stuff to break compatibility anyway: dialog/ speaker/ (what dt/ currently is) speech/ (what dd/ currently is) fx/ (a new element for stage effects, audience response etc.)
Re: [whatwg] Thoughts on HTML 5 - dialog
On Thu, May 15, 2008 at 6:20 PM, Ernest Cline [EMAIL PROTECTED] wrote: -Original Message- From: Mike Wilson [EMAIL PROTECTED] Sent: May 15, 2008 8:02 AM To: 'WHATWG' [EMAIL PROTECTED] Subject: Re: [whatwg] Thoughts on HTML 5 - dialog Yes, I also quite like the analogy with dl/ul/ol. But it may be confusing when using dt and dd as child elements (as in the current spec for dialog): cl dt dd ... /cl That could be resolved by introducing elements ct and cd: cl ct cd ... /cl and that I guess can be regarded as making things better OR worse depending on your focus... Best regards Mike Wilson Because of the backwards compatibility using dt and dd with a new dialog element would have with most existing UA's, I'd be leery of changing the names unless additional types of child elements for dialog/ (by whatever name it gets) were added, such as an element to markup stage directions, audience response, or the like. Then, since we'd be introducing enough new stuff to break compatibility anyway: dialog/ speaker/ (what dt/ currently is) speech/ (what dd/ currently is) fx/ (a new element for stage effects, audience response etc.) Yeah, I'm backing off of that position... I'm back to liking plain dialog or talk. Either sounds great to me. ~TJ
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
On Thu, May 15, 2008 at 5:04 PM, Matthew Paul Thomas [EMAIL PROTECTED] wrote: Imagine that there is a popular mobile device with a Web browser. Imagine further that this browser is widely used, despite having no support for Flash, no support for W3C File Upload, and not even any support for input type=file. I know, I know, this seems unrealistic, because those features are here to stay, but humor me here for a moment. For ease of discussion, let's call this device the iPhone. Except for the needless sarcasm - we're on the same page here. Imagine further that this iPhone has no user-visible file system. It stores music, but annoyingly, the device vendor doesn't want to let people upload songs to Web sites. What the vendor *does* want to let people do is upload photos to Web sites, so that they can use sites like Flickr or even post photos to their Weblogs from the road. So the iPhone vendor implements input type=file just for photos. Is this the iphone's behavior? (earlier you said it doesn't implement input type=file, but here you're saying it's implemented for photos) It's rendered in a Web page as three components: (1) a button for taking a new photo, (2) a button for choosing an existing photo, and (3) a thumbnail of the selected photo. There's no filename: that wouldn't make any sense, because device has no user-visible files. The interface for choosing a file isn't particularly important. It's the style/presentation of the button that triggers that interface that's in question, or being able to create your own interface to trigger that file-choosing interface. It's a security risk in those browsers where input type=file contains an editable text field, because a page could trick you into typing the pathname of a confidential file into the field, and the button would no longer warn you that it wasn't an innocent text field. In browsers (such as Firefox 3, as Jonas just mentioned) where the field is not editable, the button is safer to style -- but if you're assuming the control contains only one button, you might produce ugly results on devices where it has more. Sure, we agree that tricking a user into typing a filename is somewhat of a security risk, and browsers have mitigated that. My point was disguising the button that triggers the file-choosing dialog box (or web-page-like interface, if you will) is NOT a security issue. It's very possible to create a custom interface for triggering that dialog, but all the solutions I know of are convoluted and don't interface well with web forms. For example, if I want just a plain blue, underlined link (a la Flickr, click here to upload your photos) to trigger that browse dialog, I have to use something like Yahoo's widget or the File Upload API. Or, I have to use CSS hacks that are probably going to look silly on an iPhone. I only have a couple possible solutions in mind: - Insist that input type=file always be rendered like input type=button and therefore can be styled as such. That's not such a great solution for lots of reasons. - Insist that the HTMLInputElement.click() method in Javascript trigger the UAs file-choosing dialog. I don't know any browsers that support that, you know, for security reasons - never mind that there are two other ways to already do that with Javascript today. That would require Javascript to function, but at least it degrades more gracefully than depending on Flash or the File Upload API just to have a custom button. The HTMLInputElement would stay intact, so you don't have to code two or three separate methods of handling file uploads (see my note about separate POST requests, etc.). Plus it would be more feasible on a device like the iPhone that may not support a whole new complex API (and may never get Flash). So, is there any reason for browsers to NOT support HTMLInputElement.click() to trigger a file dialog? Is it reasonable to insist that they do? Would that solve Samuel Santos' original concern for wanting a custom, localized button that says Upload a file in his site's native language? ... If Javascript is as an acceptable requirement, another problem with those solutions is that they require separate POSTs. The Yahoo uploader uses a separate request for each file. The File Upload API has functions like getDataAsHexBinary that, I guess, could put a file's data into a hidden input field, but that data still wouldn't be uploaded the same way regular input type=file is uploaded (as multipart/form-data with headers for each file, etc). ... Web Forms 2.0 already defines min= and max= attributes for this purpose. Thanks, I hadn't seen that. input type=file max=n where n is greater than 1 would allow for mutliple files. I hadn't seen that. -- Jon Barnett
