Re: [whatwg] Priority between a download and content-disposition
On Mar 17, 2013 4:46 AM, Julian Reschke julian.resc...@gmx.de wrote: On 2013-03-17 02:49, Jonas Sicking wrote: It's currently unclear what to do if a page contains markup like a href=page.txt download=A.txt if the resource at audio.wav responds with either 1) Content-Disposition: inline 2) Content-Disposition: inline; filename=B.txt 3) Content-Disposition: attachment; filename=B.txt People generally seem to have a harder time with getting header data right, than getting markup right, and so I think that in all cases we should display the save as dialog (or display equivalent download UI) and suggest the filename A.txt. I agree that people have problems getting headers right, but in all the cases above, it seems they have set the header on purpose, no? Over in [1] we immediately ran into people wanting to override an explicitly set header. So no, I don't think that is accurate. I think it is just as common to want to control a situation from markup when you are dealing with a server that is sending a header, as when dealing with a server that is not sending a header. At least if you account for the number of servers setting headers. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=676619#c117 / Jonas
Re: [whatwg] Mutation Observer arguments format
On Mar 15, 2013 6:58 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 14, 2013, at 12:49 PM, Alex Russell slightly...@google.com wrote: The old API is confusing. We can do better, so we should. I actually find the proposed syntax more confusing than the old syntax. For starters, I don't want to remember which options were types and which are not since a mutation observer that observes attributes but doesn't observe attribute old data is a different type of a mutation observer than the one that does observe old data. So while I understand some people may find the new syntax more appealing and easy to understand, I don't think it's a significant improvement over the old syntax that justifies the cost of changing the syntax at this point especially because it appears to be backward incompatible. It's not. The old option format can continue to be supported. I think most of us are open to new syntax if it's significantly better than the current syntax and is backward compatible. - R. Niwa
[whatwg] Hide placeholder on input controls on focus
Hello Whatwg On several occasions I encountered that users got confused by the placeholders on input fields. In a doodle.com survey last week, 2 out of 5 people answered me via e-mail that they were not able to fill in their names in the name field, because they tried to highlight and delete the placeholder saying Your name. Also, some months ago I had phone calls from clients who were desperate because they thought they weren't able to log into their Hotmail accounts anymore, for the same reason (I think Hotmail has made the placeholder highlightable since then). It seems that a relevant number of users do not even try to start typing as long as the placeholder text remains visible. A short browser comparison shows: - Firefox and Chrome hide the placeholder when the user starts typing - Opera and Safari hide it when the field gets focus - IE I can't test because I haven't IE 10 The Opera and Safari behaviour seems to make sense to me, while the behaviour of Firefox and Chrome causes this kind of annoying confusion. Thus I'd suggest to modify the following sentence in 4.10.7.3.10: User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string or the control is not focused (or both), e.g. by displaying it inside a blank unfocused control and hiding it otherwise. To: ...when the element's value is the empty string _and_ the control is not focused, e.g. by displaying ... Best Regards Markus Ernst
Re: [whatwg] Hide placeholder on input controls on focus
Date: Mon, 18 Mar 2013 10:31:56 +0100 From: derer...@gmx.ch To: whatwg@lists.whatwg.org Subject: [whatwg] Hide placeholder on input controls on focus A short browser comparison shows: - Firefox and Chrome hide the placeholder when the user starts typing - Opera and Safari hide it when the field gets focus IE 10 hides it when the field gets focus. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] Hide placeholder on input controls on focus
On 3/18/13 5:31 AM, Markus Ernst wrote: - Opera and Safari hide it when the field gets focus The behavior of Safari here is platform-dependent or possibly version-dependent. Safari 6 on Mac doesn't hide the placeholder until you start typing. ...when the element's value is the empty string _and_ the control is not focused, e.g. by displaying ... I believe the spec used to say this and got changed. Certainly the Gecko implementation did this and got changed. It's worth looking into why the changes were made before simply trying to revert them. -Boris
Re: [whatwg] Fetch: crossorigin=anonymous and XMLHttpRequest
On Sun, Mar 17, 2013 at 5:25 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Mar 17, 2013 at 2:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
I tried to address both by pointing to UMP which wants both a) and b).
The alternative would be to use iframe sandbox=allow-scripts which
exhibits the same behavior given the unique origin (that also blocks
Referer). I believe at least Maciej expressed interest in supporting
the UMP use case.
But *why* does UMP want this behavior? What's the use case?
I think they do not want to expose any kind of identifying information
in the request to sort of force the capability model.
In the Firefox implementation { anon:true } does for all requests what
withCredentials=false does for cross-origin requests.
I see. Is it called anon already or still mozAnon? There's an
outstanding request to rename it to anonymous as most other terms are
spelled out.
--
http://annevankesteren.nl/
Re: [whatwg] Priority between a download and content-disposition
* Jonas Sicking wrote: It's currently unclear what to do if a page contains markup like a href=page.txt download=A.txt if the resource at audio.wav responds with either 1) Content-Disposition: inline 2) Content-Disposition: inline; filename=B.txt 3) Content-Disposition: attachment; filename=B.txt People generally seem to have a harder time with getting header data right, than getting markup right, and so I think that in all cases we should display the save as dialog (or display equivalent download UI) and suggest the filename A.txt. You mention `audio.wav` but that is not part of your example. Also note that there are all manners of other things web browsers need to take in- to account when deciding on download file names, you might not want to e.g. suggest using desktop.ini, autorun.inf or prn to the user. That aside, it seems clear to me that when the linking context says to download, then that is what a browser should do, much as it would when the user manually selects a download context menu option. In contrast, when the server says filename=example.xpi then the browser should pick that name instead of allowing overrides like a href='example.xpi' download='example.zip' .. which would cause a lot of headache, especially from third parties. And allowing such overrides in same-origin scenarios seems useless and is asking for trouble (download filenames broken after moving to CDN). However I don't think we can expect people to indicate Content-Disposition: inline in order to protect resources. Nor do I think that simply using a different filename is going to meaningfully protect downloaded content. So I think a stronger UI warning is needed in this scenario. I am not sure what you are referring to here, could you elaborate? -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Priority between a download and content-disposition
On Mon, Mar 18, 2013 at 7:50 AM, Bjoern Hoehrmann derhoe...@gmx.netwrote: However I don't think we can expect people to indicate Content-Disposition: inline in order to protect resources. Nor do I think that simply using a different filename is going to meaningfully protect downloaded content. So I think a stronger UI warning is needed in this scenario. I am not sure what you are referring to here, could you elaborate? People were concerned that there might be security problems with forcing a download and/or offering a specific filename. Making a C-D: inline header override @download might alleviate that. I agree that if it's actually a problem, then this doesn't seem like a good solution. I can't recall any compelling arguments that a security issue exists, though. -- Glenn Maynard
Re: [whatwg] Priority between a download and content-disposition
I think I raised this on several other threads; in essence, countless websites permit users to upload constrained file formats, such as JPEGs or GIFs used as profile images. With content sniffing attacks, we've already seen that it's relatively trivial for attacker to make files that are both valid images, and also pretend to be some other, more dangerous file format. Because many browsers prominently display the origin of a download and it's the only security indicators users really have, I think it's harmful to permit something like: a href='http://www.facebook.com/.../user_profile_image.jpg' download='important_facebook_update.exe' In fact, given the security problems it creates and the fact that they will be difficult to fully mitigate without establishing some sort of a new 'opt-out' mechanism akin to X-Content-Type-Options (to which most of the Internet will remain oblivious), I'm not entirely sure if the value of download= (which seems dubious, TBH) justifies the risk. /mz
Re: [whatwg] Priority between a download and content-disposition
On Mon, Mar 18, 2013 at 9:30 AM, Michal Zalewski lcam...@coredump.cxwrote: I think I raised this on several other threads; in essence, countless websites permit users to upload constrained file formats, such as JPEGs or GIFs used as profile images. With content sniffing attacks, we've already seen that it's relatively trivial for attacker to make files that are both valid images, and also pretend to be some other, more dangerous file format. Because many browsers prominently display the origin of a download and it's the only security indicators users really have, I think it's harmful to permit something like: a href='http://www.facebook.com/.../user_profile_image.jpg' download='important_facebook_update.exe' Downloads are associated with the site the link is on, not the domain the resource is served from. If users click a download link and the file comes from s3.amazonaws.com, they didn't come from Amazon; they came from your page. The origin of downloads should probably not be displayed in a prominent location, since to typical users it's useless and potentially misleading; it should be hidden in something like a details button. -- Glenn Maynard
Re: [whatwg] Hide placeholder on input controls on focus
On 18 Mar 2013 at 12:27, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/18/13 5:31 AM, Markus Ernst wrote:
- Opera and Safari hide it when the field gets focus
The behavior of Safari here is platform-dependent or possibly
version-dependent. Safari 6 on Mac doesn't hide the placeholder until
you start typing.
I for one find this to be extremely irritating. Workaround I was given by some
kind person:
[placeholder]:focus::-webkit-input-placeholder
{
color: transparent;
}
--
Cheers -- Tim
Re: [whatwg] Priority between a download and content-disposition
Downloads are associated with the site the link is on, not the domain the resource is served from. If users click a download link and the file comes from s3.amazonaws.com, they didn't come from Amazon; they came from your page. I don't believe that's the case in most browser UIs. In fact, I don't think it should be. For example, if I search for something on google.com, and this takes me a page that serves Content-Disposition: attachment; filename=impotant_google_update.exe, we don't want to imply that Google endorsed that, right? /mz
Re: [whatwg] Priority between a download and content-disposition
From: lcam...@coredump.cx Date: Mon, 18 Mar 2013 10:00:40 -0700 To: gl...@zewt.org CC: wha...@whatwg.org; derhoe...@gmx.net; jo...@sicking.cc Subject: Re: [whatwg] Priority between a download and content-disposition Downloads are associated with the site the link is on, not the domain the resource is served from. If users click a download link and the file comes from s3.amazonaws.com, they didn't come from Amazon; they came from your page. I don't believe that's the case in most browser UIs. Correct; IE 10 and Firefox 19 both specifically say file filename from host of file and make no mention of the page/URL containing the link. Chrome 25 doesn't show the host at all in the primary UI but the Downloads window includes the full URL of the file, and nothing about the page containing the link. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] Hide placeholder on input controls on focus
Am 18.03.2013 13:27 schrieb Boris Zbarsky:
On 3/18/13 5:31 AM, Markus Ernst wrote:
- Opera and Safari hide it when the field gets focus
The behavior of Safari here is platform-dependent or possibly
version-dependent. Safari 6 on Mac doesn't hide the placeholder until
you start typing.
...when the element's value is the empty string _and_ the control is not
focused, e.g. by displaying ...
I believe the spec used to say this and got changed. Certainly the
Gecko implementation did this and got changed. It's worth looking into
why the changes were made before simply trying to revert them.
I had searched the list archives for placeholder before posting, but
of course I may have missed the relevant discussion. I did not search
Firefox bugs, though.
A reason for the behaviour of Firefox and Chrome may be that some user
may not have read the placeholder text before focusing the control.
Anyway, if this behavior lets some users think they can't even fill in
the form, there must be something wrong about it. Maybe some implementer
may want to include this case in their usability tests; I do not insist
in discussing it at spec level.
Am 18.03.2013 17:47 schrieb Tim Streater:
I for one find this to be extremely irritating. Workaround I was
given by some kind person:
[placeholder]:focus::-webkit-input-placeholder
{
color: transparent;
}
Yes, from an author's POV I could also imagine scripting solutions to
this case. Anyway it looks like a more general UI question to me.
Re: [whatwg] Fetch: crossorigin=anonymous and XMLHttpRequest
On Mon, Mar 18, 2013 at 5:43 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Mar 17, 2013 at 5:25 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Mar 17, 2013 at 2:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
I tried to address both by pointing to UMP which wants both a) and b).
The alternative would be to use iframe sandbox=allow-scripts which
exhibits the same behavior given the unique origin (that also blocks
Referer). I believe at least Maciej expressed interest in supporting
the UMP use case.
But *why* does UMP want this behavior? What's the use case?
I think they do not want to expose any kind of identifying information
in the request to sort of force the capability model.
By not including cookies or other login information you are already
forcing the capability model since you can't tell the connection from
one that is server-to-server.
Including the referrer header, at least by default, seems very useful
still since there is lots of infrastructure in servers which are using
those for logging purposes.
In the Firefox implementation { anon:true } does for all requests what
withCredentials=false does for cross-origin requests.
I see. Is it called anon already or still mozAnon? There's an
outstanding request to rename it to anonymous as most other terms are
spelled out.
I don't know what we're currently using off the top of my head.
/ Jonas
Re: [whatwg] Priority between a download and content-disposition
On Mon, Mar 18, 2013 at 12:00 PM, Michal Zalewski lcam...@coredump.cxwrote: Downloads are associated with the site the link is on, not the domain the resource is served from. If users click a download link and the file comes from s3.amazonaws.com, they didn't come from Amazon; they came from your page. I don't believe that's the case in most browser UIs. This is about how the Web works, not browser UIs. If I click a link on www.computerviruses.com, and it prompts me to save a file to disk, I make my decision of what to do with the file based on the context of the link I clicked. The host serving the file is irrelevant. Anybody can host a hostile file on amazonaws.com or any number of hosts which may sound safe; the endorsement of whether a file is safe comes from how and where it's linked, not where it's hosted. In fact, I don't think it should be. For example, if I search for something on google.com, and this takes me a page that serves Content-Disposition: attachment; filename=impotant_google_update.exe, we don't want to imply that Google endorsed that, right? The point isn't that browsers should have a big UI showing the page where you clicked the link. The point is that links are judged based on whether you trust the site linking the file, and whether the page endorses the link (which search results don't). -- Glenn Maynard
Re: [whatwg] Hide placeholder on input controls on focus
On Mon, Mar 18, 2013 at 12:51 PM, Markus Ernst derer...@gmx.ch wrote: A reason for the behaviour of Firefox and Chrome may be that some user may not have read the placeholder text before focusing the control. Anyway, if this behavior lets some users think they can't even fill in the form, there must be something wrong about it. I've seen browsers (or maybe pages emulating placeholder in script) that hide the placeholder text while the input field is focused. When the placeholders are labels for the inputs, it's incredibly annoying to have to focus something else in order to see the placeholder text. If placeholders are meant to be useful and not just eyecandy, they need to remain visible until the user enters something. -- Glenn Maynard
[whatwg] Media queries for multichannel audio ?
Is there anything like this ? I'd like a media element to be able to select the multi-channel version of some audio only when the device will output multiple channels and select a stereo version otherwise (rather than downmixing). This would save network bandwidth as well as providing better quality (if the custom-mixed stereo audio is likely better than the end-device down-mixed version). Seems like this would be handled in the resource selection algorithm by checking if the media attribute of the source matches the environment, but I can't find how to specific audio characteristics in a media query. …Mark
[whatwg] [CSSWG][css-counter-styles] Updated WD of CSS Counter Styles
The CSS WG has published an updated Working Draft of the CSS Counter Style Module Level 3: http://www.w3.org/TR/css-counter-styles-3/ This spec documents the existing CSS 2.1 and 2.0 counter styles in better detail, adds a handful of CJK and other list styles, and adds an @counter-style rule which allows authors to define their own counter styles. Significant changes since the last WD are listed at: http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/#changes Significant additions include: - the 'width' descriptor for, e.g. zero-filled counters http://www.w3.org/TR/css-counter-styles-3/#counter-style-width - the 'speak-as' descriptor for customizing text-to-speech http://www.w3.org/TR/css-counter-styles-3/#counter-style-speak-as - the 'disclosure-*' styles, intended to be used for the HTML details element and similar use cases http://www.w3.org/TR/css-counter-styles-3/#simple-symbolic We'd especially appreciate a review of these additions. We expect the next step to be Last Call. Please send any comments to www-st...@w3.org, and please, prefix the subject line with [css-counter-styles] (as I did on this message). For the CSS WG, ~fantasai
Re: [whatwg] Media queries for multichannel audio ?
On 03/18/2013 05:18 PM, Mark Watson wrote: Is there anything like this ? I'd like a media element to be able to select the multi-channel version of some audio only when the device will output multiple channels and select a stereo version otherwise (rather than downmixing). This would save network bandwidth as well as providing better quality (if the custom-mixed stereo audio is likely better than the end-device down-mixed version). Seems like this would be handled in the resource selection algorithm by checking if the media attribute of the source matches the environment, but I can't find how to specific audio characteristics in a media query. I don't think such a thing exists, but you could request it for Media Queries Level 4: http://dev.w3.org/csswg/mediaqueries4/ You'd want to post to www-style for that, though. ~fantasai
