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
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
2013/3/20 Markus Ernst derer...@gmx.ch:
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
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
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 link to include CSS files, especially if link could be
updated to support the scoped attribute with the same
On Wed, Mar 20, 2013 at 11:16 AM, Boris Zbarsky bzbar...@mit.edu 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 link to include CSS files,
On Tue, Mar 19, 2013 at 8:08 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Mar 19, 2013 at 6:30 PM, Jonas Sicking jo...@sicking.cc 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
On Wed, Mar 20, 2013 at 12:54 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Mar 19, 2013 at 8:08 PM, Anne van Kesteren ann...@annevk.nl 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
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
Anne van Kesteren ann...@annevk.nl 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
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.
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
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
13 matches
Mail list logo
