Re: [whatwg] Fetch: crossorigin=anonymous and XMLHttpRequest
On Wed, Mar 20, 2013 at 2:31 PM, Anne van Kesteren ann...@annevk.nl wrote: That said, allowing both anonymous and non-anonymous requests to do xhr.setRequestHeader(referer, ) might be a good idea. I.e. being able to set it explicitly to the empty string. Okay. Does anonymous also mean not handling 401 by prompting the user? I think so yes. What about 407? The fact that there's a proxy that the user needs to log in to should never be exposed to the platform I would think. Nor should the platform be able to affect how the user interacts with such a proxy. / Jonas
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On Wed, Mar 20, 2013 at 10:46 PM, Boris Zbarsky bzbar...@mit.edu wrote: The question is whether it's more important for document.referrer to match the HTTP header (so the note will actually be true) or location.href and .URL... Well, and the other question is what .URL and location.href should return, since clearly we don't exactly have interop there. My ongoing assumption has been that we want to serialize to punycode always in the API as the Unicode form is very much a UI decision and we do not want to leak that detail to web developers. (We do at some point want to expose an API to convert one to the other, irrespective of UI considerations.) -- http://annevankesteren.nl/
Re: [whatwg] URL standard: Query string parsing; host parsing
On Wed, Mar 20, 2013 at 7:52 PM, pocci...@gmail.com wrote: Accordingly, should this rule and/or the percent decoding algorithm be redefined to allow Unicode characters here? The host parser is only given Unicode input where the string has code points in the range U+ to U+007F. (A related question is whether the URL standard should just go ahead and adopt Unicode Technical Standard 46 for IDNA, but that issue need not be answered now.) http://annevankesteren.nl/2012/11/idna-hell -- http://annevankesteren.nl/
Re: [whatwg] Hide placeholder on input controls on focus
From: k...@iqmultimedia.com.au To: resca...@emsai.net; derer...@gmx.ch Date: Thu, 21 Mar 2013 01:18:26 + CC: whatwg@lists.whatwg.org Subject: Re: [whatwg] Hide placeholder on input controls on focus I'm skeptical that this is genuinely a significant issue with users, chiefly because I've never really seen any page authors feel the need to implement anything like this, and because as stated earlier Safari, Firefox and Chrome all use non-hiding placeholders in various places in their browser chrome without any sort of special treatment on focus. Surprisingly, the only example I could find of a developer doing something both on focus *and* once the user starts typing is Opera in its address bar and search field, which behaves as you describe; the placeholder text goes lighter on focus. Nevertheless, the _only_ browser I can find which actively removes its placeholder text on focus is IE 8 (in its search field). I can't believe that there needs to be a different implementation for fields in the browser's own chrome as for in-page form fields. Just as an added data-point (that I only noticed today) - Windows 7's placeholder implementation in the Start menu and Explorer's search box: - The text is displayed in grey *and* italic *and* with a space at the start. - Focusing the input box with tab/Control-E or autofocus when opening the Start menu does *not* hide the placeholder. - Typing hides the placeholder and clearing to empty re-shows it. - Control-A or clicking in the textbox hides the placeholder. This to me seems like a very interesting compromise between the two observed behaviours in browsers - autofocus does not prevent the user seeing the placeholder but any attempt to interact with it (by typing, mouse clicking or control-a) removes it. I would be interested in why this behaviour was not adopted in IE10's input[placeholder] implementation. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
Date: Wed, 20 Mar 2013 22:46:15 -0400 From: bzbar...@mit.edu To: wha...@whatwg.org Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use 1) Gecko shows exactly the string we put on the wire in document.referrer (punycode and all). document.URL and document.location.href show the non-ASCII chars in some cases. 2) WebKit (or at least Chrome) seems to return punycode for all three of these. 3) Opera seems to return non-ASCII chars for all three of these, at least in some cases. IE 10 shows the non-ASCII chars in all three in the cases I've tried just now. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] Hide placeholder on input controls on focus
Am 21.03.2013 12:10 schrieb James Ross: Just as an added data-point (that I only noticed today) - Windows 7's placeholder implementation in the Start menu and Explorer's search box: - Focusing the input box with tab/Control-E or autofocus when opening the Start menu does *not* hide the placeholder. - Control-A or clicking in the textbox hides the placeholder. I was not aware of the possibility to distinguish between clicking in a textbox and other ways to focus it. This behaviour seems to be very user-friendly to me.
Re: [whatwg] URL standard: Query string parsing; host parsing
I see, the IDNA issue is still unsettled. So do you have advice for how implementers should parse and validate domain names in the meantime? Should the implementation convert domain names to punycode, validate their length, or any of these? On Mar 21, 2013 7:08 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Mar 20, 2013 at 7:52 PM, pocci...@gmail.com wrote: Accordingly, should this rule and/or the percent decoding algorithm be redefined to allow Unicode characters here? The host parser is only given Unicode input where the string has code points in the range U+ to U+007F. (A related question is whether the URL standard should just go ahead and adopt Unicode Technical Standard 46 for IDNA, but that issue need not be answered now.) http://annevankesteren.nl/2012/11/idna-hell -- http://annevankesteren.nl/
Re: [whatwg] URL standard: Query string parsing; host parsing
On Thu, Mar 21, 2013 at 10:00 AM, Peter Occil pocci...@gmail.com wrote: I see, the IDNA issue is still unsettled. So do you have advice for how implementers should parse and validate domain names in the meantime? Should the implementation convert domain names to punycode, validate their length, or any of these? As far as I can tell the most prominent implementations still implement IDNA2003. In fact, with Rebel Opera gone, all browsers do IDNA2003. So maybe we should standardize on that. The problem with standardizing on that of course is that it runs counter to registrar policies :-( -- http://annevankesteren.nl/
Re: [whatwg] Hide placeholder on input controls on focus
Just as an added data-point (that I only noticed today) - Windows 7's placeholder implementation in the Start menu and Explorer's search box: - Focusing the input box with tab/Control-E or autofocus when opening the Start menu does *not* hide the placeholder. - Control-A or clicking in the textbox hides the placeholder. I was not aware of the possibility to distinguish between clicking in a textbox and other ways to focus it. This behaviour seems to be very user-friendly to me. I think this is a neat feature in the Windows Start Menu, but I think it's a bad idea to distinguish between the two sources of focus in the case of a placeholder text. If I have an on-load handler that focuses a different element depending on some logic (for example, autoselect the first empty field in a form), that behavior would then result in a different appearance than if I set the autofocus attribute, even though the page's behavior would be identical from the user's perspective. Other than that, though, the formatting used in the Windows Start Bar and several other places already mentioned by others -- light grey and italicized -- seems like the best option to me. I'd also be in favor of giving placeholder text opacity on focus, though italicizing the text seems like a sufficiently strong signal that that might not be necessary. I have anecdotal evidence of user confusion both from placeholders vanishing on focus and from placeholder text looking the same as input text. The first was when some of my users got confused by an app I built before I realized that IE was hiding placeholders on focus. The second was me, testing the same app -- I know how placeholders work, but I kept instinctively trying to highlight the text because it exactly matched the formatting of actual values. ~ Benjamin
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On Wed, 20 Mar 2013, Boris Zbarsky wrote: The spec for document.referrer says: The referrer attribute must return the document's referrer. The document's referrer is not really defined anywhere in a useful way that I can find. Yikes, I apparently forgot to fill that in. Sorry about that. Try now. I'll leave your e-mail in my pile to make sure I deal with the remaining issues you mentioned, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On 3/21/13 2:22 PM, Ian Hickson wrote: On Wed, 20 Mar 2013, Boris Zbarsky wrote: The document's referrer is not really defined anywhere in a useful way that I can find. Yikes, I apparently forgot to fill that in. Sorry about that. Try now. Much better, thanks. I haven't dug through the resulting thing to figure out what it does with IDN, so far... -Boris
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On 3/21/13 7:01 AM, Anne van Kesteren wrote: On Wed, Mar 20, 2013 at 10:46 PM, Boris Zbarsky bzbar...@mit.edu wrote: My ongoing assumption has been that we want to serialize to punycode always in the API Hmm. That _does_ suck if you want to show location stuff to the user, though (though a proposed ACE-to-Unicode API would somewhat help, if you remember to use it). as the Unicode form is very much a UI decision and we do not want to leak that detail to web developers. You mean the decision as to when exactly to use the Unicode and when to use ACE? In what way is it a UI decision (apart from browser URL bars having anti-phishing logic that falls back to ACE when they detect weird chars in the URI)? (We do at some point want to expose an API to convert one to the other, irrespective of UI considerations.) Agreed, but that doesn't help answer the question of what authors should get in the DOM. Or put another way, it seems like we should be trying to use IRIs until we can't for some reason, and I see no a priori reason that location.href can't be an IRI... -Boris
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On Thu, Mar 21, 2013 at 2:33 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/21/13 7:01 AM, Anne van Kesteren wrote: as the Unicode form is very much a UI decision and we do not want to leak that detail to web developers. You mean the decision as to when exactly to use the Unicode and when to use ACE? In what way is it a UI decision (apart from browser URL bars having anti-phishing logic that falls back to ACE when they detect weird chars in the URI)? E.g. Chrome only shows Unicode if they have indication (prolly locale) that the end-user will understand it and will use ACE otherwise. I do not want that kind of logic to leak through developer-exposed APIs. That's madness. See http://wiki.whatwg.org/wiki/URL#UI for links to more details. Or put another way, it seems like we should be trying to use IRIs until we can't for some reason, and I see no a priori reason that location.href can't be an IRI... If we can define until we can't I would be okay with that. Otherwise it seems safer to always use punycode and delegate the problem. -- http://annevankesteren.nl/
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On 3/21/13 2:40 PM, Anne van Kesteren wrote: You mean the decision as to when exactly to use the Unicode and when to use ACE? In what way is it a UI decision (apart from browser URL bars having anti-phishing logic that falls back to ACE when they detect weird chars in the URI)? E.g. Chrome only shows Unicode if they have indication (prolly locale) that the end-user will understand it and will use ACE otherwise. You mean shows Unicode in their url bar? Firefox does something similar. I agree that's a UI decision that should have nothing to do with what location.href shows. I do not want that kind of logic to leak through developer-exposed APIs. That's madness. Agreed. If we can define until we can't I would be okay with that. OK, makes sense. -Boris
Re: [whatwg] Hide placeholder on input controls on focus
On 2013-03-21 14:02, Markus Ernst wrote: Am 21.03.2013 12:10 schrieb James Ross: Just as an added data-point (that I only noticed today) - Windows 7's placeholder implementation in the Start menu and Explorer's search box: - Focusing the input box with tab/Control-E or autofocus when opening the Start menu does *not* hide the placeholder. - Control-A or clicking in the textbox hides the placeholder. I was not aware of the possibility to distinguish between clicking in a textbox and other ways to focus it. This behaviour seems to be very user-friendly to me. As far as I know there are hover, focus, and modified (are there others?). The events varies whether it's in a browser (and which browser) and which OS (and which GUI API). Ideally a browser chrome should follow the OS styleguide to provide a consistent OS user experience. And with HTML5 stuff should behave consistently in all HTML5 supporting browsers. But that's just my opinion on where the line should be drawn. There are after all things like the context menu stuff that crosses the GUI boundaries. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] Hide placeholder on input controls on focus
On 22/03/2013, at 6:20 AM, Roger Hågensen wrote: Ideally a browser chrome should follow the OS styleguide to provide a consistent OS user experience. And with HTML5 stuff should behave consistently in all HTML5 supporting browsers. I disagree that all HTML5 supporting browsers should (necessarily) behave consistently, especially coupled with the implication that it should do so even in violation of the OS's conventions. UAs should implement all interactive controls in the way that is most consistent with user expectations. Surely it's better for users that their browser behaves consistently with the other apps on their own system than it is for browsers to behave consistently across a variety of platforms. I don't believe the specification should dictate any visual style for placeholders, nor any specific behaviour for hiding the placeholder. In that way, I support the current phrasing of the specification which cedes that decision to implementors. This provides each implementor the latitude to implement the placeholder behaviour in a way that is consistent with the platform it's running on, as they (presumably) currently do for their browser chrome. Kit Grose User Experience + Tech Director, iQmultimedia
