Re: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest

[Jonas Sicking]

On Wed, Mar 20, 2013 at 2:31 PM, Anne van Kesteren  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

[whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use

[Boris Zbarsky]

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.


This then follows with a non-normative note:

   Note: In the case of HTTP, the referrer IDL attribute will match the
   Referer (sic) header that was sent when fetching the current page.

In cases when the hostname is non-ASCII, the Referer header will have it 
encoded in punycode.  The question is what should happen for 
document.referrer.  Right now, I see the following behavior:


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.


No idea what IE does.

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.


-Boris

Re: [whatwg] Hide placeholder on input controls on focus

[Kit Grose]

On 20/03/2013, at 8:18 PM, Markus Ernst wrote:

> Am 20.03.2013 02:20 schrieb Kit Grose:
>> In almost every case the placeholder remains visible until the user has 
>> begun typing, as I strongly believe it ought to be remain in the 
>> specification, since it provides the contextual hint for as long as possible.
> Do you refer to author implementations via scripting? As in Opera and IE 10, 
> the placeholder gets hidden when the field is focused; thus, regarding 
> browser implementations, the "almost every case" refers to Firefox, Chrome, 
> and some versions of Safari.

As Rafał noted, I was referring to the behaviour of the application chrome 
itself (e.g. its built-in address bar), not its implementation of the HTML5 
placeholder attribute.


On 21/03/2013, at 8:54 AM, Roger Hågensen wrote:

> On 2013-03-20 10:18, Markus Ernst wrote:
>> The problem is that some users do not even start to type when they see text 
>> in the field they focused. Thus I strongly believe that some visible hint at 
>> the _focusing_ moment would be helpful for these users. If the Opera and IE 
>> behaviour of totally hiding the placeholder is considered as suboptimal, the 
>> placeholder could be blurred, made semi-transparent or whatever; but I am 
>> sure that something should happen when the control gets focus, and not only 
>> when the user starts typing.
> 
> Have it dim/vanish at not just onfocus but onmouseover as well? (and TAB, but 
> that should be the same as onfocus usually)
> I agree that this would be beneficial.
> 
> Here is an example: (go to http://htmledit.squarefree.com/ or someplace 
> similar or save it locally as .html and test it that way)
…snip…
> So maybe a placeholder opacity of 0.5 on hover, and opacity of 0.0 on focus 
> would be a suitable browser default. (web authors should still be able to 
> style the behavior like I just did)


This behaviour still makes it effectively impossible to use placeholders in 
combination with autofocus, which I think is unnecessary.


On 20/03/2013, at 8:18 PM, Markus Ernst wrote:

> The current implementations of Firefox and Chrome seem to imply selectable 
> content at least to some users, as Tim and myself reported in this thread. 
> Both show the placeholder in a lighter color than the input text; this does 
> not seem to fully solve the issue, maybe because many web designers color 
> text in form fields anyway.

I can say I've never observed this issue myself in usability testing, but I'm 
not willing to outright discount the possibility that it's a real issue. Does 
anyone have any empirical evidence/test results that show the issue of users 
trying to select text is more prevalent than the issue of users forgetting what 
the placeholder said once it's been hidden, especially while using the HTML5 
placeholder attribute?

As I said previously, I predict that these issues would be sorted out simply by 
the widespread adoption of the placeholder attribute (and therefore the 
standardisation of its behaviour). Simulating placeholders has been variously 
done by dynamically setting the input to have the placeholder as its value—with 
or without dynamically styling the content differently—or by positioning an 
actual label element over the field. In both cases, the implementation effort 
required to make the field retain its placeholder but not be selectable in 
Javascript is higher than to simply blank the value on focus and restore it on 
blur if the field is left empty. As people transition to the placeholder 
attribute, the variation in the implementations by different page authors will 
be removed and UAs should be able to standardise the behaviour to match their 
own application UI.

Here's a discussion on the usability of each option, with a few different 
references: 
http://ux.stackexchange.com/questions/21299/removing-placeholder-text-on-focus


> The problem is that some users do not even start to type when they see text 
> in the field they focused. Thus I strongly believe that some visible hint at 
> the _focusing_ moment would be helpful for these users. If the Opera and IE 
> behaviour of totally hiding the placeholder is considered as suboptimal, the 
> placeholder could be blurred, made semi-transparent or whatever; but I am 
> sure that something should happen when the control gets focus, and not only 
> when the user starts typing.

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 

Re: [whatwg] URL standard: Query string parsing; host parsing

[poccil14]

After rechecking the URI specification in RFC3986 I want to withdraw my 
question on query
string parsing.  Apparently I relied on the older RFC2396 syntax of URIs 
(through the java.net.URI
documentation) and naively assumed that the parsing of query strings in URIs 
remained unchanged.
Accordingly, the query string question is withdrawn.  However, I still have a 
question about
host parsing.  For convenience, I repeat that question here:

-- Host parsing and Unicode characters --

Rule 2 of the host parser says "Let host be the result of running utf-8's 
decoder on the percent decoding of input."  But the percent decoding algorithm 
only works on ASCII strings, and has undefined behavior on Unicode strings.  
This may preclude the use of Unicode characters in host names, especially in 
IDNA, which probably isn't the intent.  Accordingly, should this rule and/or 
the percent decoding algorithm be redefined to allow Unicode characters here? 
(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.)

Re: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest

[Nils Dagsson Moskopp]

Anne van Kesteren  schrieb am Wed, 20 Mar 2013
17:31:14 -0400:

> If you do an XMLHttpRequest from a document hosted at
> /superlonghashkeythatactsasauthenticationtoken you probably do not
> want to expose the Referer header.

A GET request should be idempotent, so what would be the problem? If
subsequent access changes the state of the resource, that seems broken.

> Now 1) this document should be
> hosted over https so this is less likely to be a concern given actual
> implementations of Referer over https and b) for same-origin requests
> this matters less (if at all), it still seems better if anonymous is
> anonymous.

I'd suggest using HMACs instead of hashes for signed action URLs. Right?

-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] Hide placeholder on input controls on focus

[Roger Hågensen]

On 2013-03-20 10:18, Markus Ernst wrote:
The problem is that some users do not even start to type when they see 
text in the field they focused. Thus I strongly believe that some 
visible hint at the _focusing_ moment would be helpful for these 
users. If the Opera and IE behaviour of totally hiding the placeholder 
is considered as suboptimal, the placeholder could be blurred, made 
semi-transparent or whatever; but I am sure that something should 
happen when the control gets focus, and not only when the user starts 
typing.


Have it dim/vanish at not just onfocus but onmouseover as well? (and 
TAB, but that should be the same as onfocus usually)

I agree that this would be beneficial.

Here is an example: (go to http://htmledit.squarefree.com/ or someplace 
similar or save it locally as .html and test it that way)



/** css start */

input::-webkit-input-placeholder
{ /* WebKit browsers */
color: red;
}

input:hover::-webkit-input-placeholder
{ /* WebKit browsers */
opacity:0.5;
text-align:right;
}

input:focus::-webkit-input-placeholder
{ /* WebKit browsers */
opacity:0.0;
}

input:placeholder
{ /* future standard!? */
color: red;
}

input:placeholder:hover
{ /* future standard!? */
opacity:0.5;
text-align:right;
}

input:focus:placeholder
{ /* future standard!? */
opacity:0.0;
}

/** css end */








I only did webkit! (and what I assume will be the standard?)
Reason I did not add any css for IE 10 or Firefox 19 is that they fail 
(at least I could not easily get this to work in those browsers), Chrome 
25 handles this just fine.
Other than me playing around a little with the right align to visually 
move the placeholder text "out of the way", I assume this is how you 
would like it to look/behave Markus?


So maybe a placeholder opacity of 0.5 on hover, and opacity of 0.0 on 
focus would be a suitable browser default. (web authors should still be 
able to style the behavior like I just did)


--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/

Re: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest

[Anne van Kesteren]

On Wed, Mar 20, 2013 at 12:54 PM, Jonas Sicking  wrote:
> On Tue, Mar 19, 2013 at 8:08 PM, Anne van Kesteren  wrote:
>> Not if the referring URL was a capability, which I think might have
>> been the point.
>
> I don't understand what that means. Could you explain?

If you do an XMLHttpRequest from a document hosted at
/superlonghashkeythatactsasauthenticationtoken you probably do not
want to expose the Referer header. Now 1) this document should be
hosted over https so this is less likely to be a concern given actual
implementations of Referer over https and b) for same-origin requests
this matters less (if at all), it still seems better if anonymous is
anonymous.


> 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? What about 407?


-- 
http://annevankesteren.nl/

Re: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest

[Jonas Sicking]

On Tue, Mar 19, 2013 at 8:08 PM, Anne van Kesteren  wrote:
> On Tue, Mar 19, 2013 at 6:30 PM, Jonas Sicking  wrote:
>> I don't think that that is a particularly convincing argument since there is
>> no confused deputy problem here, and if a website is making security
>> decisions based on referrer headers even when there are no other identifying
>> signals, then that website is a lost cause.
>
> Not if the referring URL was a capability, which I think might have
> been the point.

I don't understand what that means. Could you explain?

>> In other words, I see no new attack vectors being introduced, but I do see
>> additional value, if we keep the referrer.
>
> You do know there are efforts to making Referer obsolete within
> Mozilla so to leak less information about the user?

My argument isn't to force having a referrer here. My argument is to
follow the same policies for referrer as for other requests.

I don't think keeping the referrer anonymous XHR requests is going to
materially change the ability to adjust these policies in general.

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.

/ Jonas

Re: [whatwg] [html][webcomponents]: Link element in body?

[Brian Kardell]

On Wed, Mar 20, 2013 at 11:16 AM, Boris Zbarsky  wrote:
> On 3/20/13 6:27 AM, Benjamin Stürmer wrote:
>>
>> I've been thinking about this exact thing for the last few weeks,
>> because I have a use case in which it would be beneficial to use an
>> in-body  to include CSS files, especially if  could be
>> updated to support the "scoped" attribute with the same behavior as in
>> 

Re: [whatwg] [html][webcomponents]: Link element in body?

[Boris Zbarsky]

On 3/20/13 6:27 AM, Benjamin Stürmer wrote:

I've been thinking about this exact thing for the last few weeks,
because I have a use case in which it would be beneficial to use an
in-body  to include CSS files, especially if  could be
updated to support the "scoped" attribute with the same behavior as in

[whatwg] [html][webcomponents]: Link element in body?

[Benjamin Stürmer]

> On 3/19/13 11:18 AM, Brian Kardell wrote:
> > Section 4.2.4 of the HTML Standard[1] contains a note:
> > "Note: If the rel attribute is used, the element is restricted to the
> > head element. When used with the itemprop attribute, the element can
> > be used both in the head element and in the body of the page, subject
> > to the constraints of the microdata model."
>
> That's an authoring requirement, like pretty much everything to do with
> element content models.
>
> As in, if you have a  without itemprop but with rel inside 
> your HTML validator will complain at you (and chances are your page will
> end up with FOUC and whatnot, which is why this is not something the
> spec makes valid).
(My first post to the list. Hi there! Please let me know if I violate
any conventions I haven't picked up on while lurking.)

I've been thinking about this exact thing for the last few weeks,
because I have a use case in which it would be beneficial to use an
in-body  to include CSS files, especially if  could be
updated to support the "scoped" attribute with the same behavior as in

Re: [whatwg] Hide placeholder on input controls on focus

[Rafał Miłecki]

2013/3/20 Markus Ernst :
> Am 20.03.2013 02:20 schrieb Kit Grose:
>>
>> In almost every case the placeholder remains visible until the user has
>> begun typing, as I strongly believe it ought to be remain in the
>> specification, since it provides the contextual hint for as long as
>> possible.
>
> Do you refer to author implementations via scripting? As in Opera and IE 10,
> the placeholder gets hidden when the field is focused; thus, regarding
> browser implementations, the "almost every case" refers to Firefox, Chrome,
> and some versions of Safari.

Opera is not consistent with this behavior
1) On webpages is hides placeholder on focus
2) In it's UI it hides placeholder on start of typing (address bar,
search engine, speed dial)

If user can write address (in the UI) despite placeholder being
displayed during focus, I find it weird, the same can be confusing on
a web page :|

-- 
Rafał

Re: [whatwg] Hide placeholder on input controls on focus

[Markus Ernst]

Am 20.03.2013 02:20 schrieb Kit Grose:

In almost every case the placeholder remains visible until the user has begun 
typing, as I strongly believe it ought to be remain in the specification, since 
it provides the contextual hint for as long as possible.
Do you refer to author implementations via scripting? As in Opera and IE 
10, the placeholder gets hidden when the field is focused; thus, 
regarding browser implementations, the "almost every case" refers to 
Firefox, Chrome, and some versions of Safari.



That it has historically been implemented in a way that implies selectable content is, I 
believe, chiefly due to the lack of support for a "right" way to do this (which 
has led many developers to implement the placeholder text simply by setting the field's 
value to the placeholder text as the simplest implementation).
The current implementations of Firefox and Chrome seem to imply 
selectable content at least to some users, as Tim and myself reported in 
this thread. Both show the placeholder in a lighter color than the input 
text; this does not seem to fully solve the issue, maybe because many 
web designers color text in form fields anyway.


The problem is that some users do not even start to type when they see 
text in the field they focused. Thus I strongly believe that some 
visible hint at the _focusing_ moment would be helpful for these users. 
If the Opera and IE behaviour of totally hiding the placeholder is 
considered as suboptimal, the placeholder could be blurred, made 
semi-transparent or whatever; but I am sure that something should happen 
when the control gets focus, and not only when the user starts typing.

Re: [whatwg] Hide placeholder on input controls on focus

[Rimantas Liubertas]

On 2013 m. March 20 d., Wednesday at 03:20, Kit Grose wrote: 
> In almost every case the placeholder remains visible until the user has begun 
> typing, as I strongly believe it ought to be remain in the specification, 
> since it provides the contextual hint for as long as possible.

Agreed. In this case it also shows-up again if user deletes everything typed 
in, so you get reminded that the field is for without leaving it.

Regards,
Rimantas