On Sat, 03 Apr 2010 17:23:39 +0300, Greg Brown gkbr...@mac.com wrote:
OK, that makes sense. Thanks for the info.
However, a extra readonly attribute float height to the TextMetrics
interface should be fairly trivial to implement for browser vendors and
would greatly help web developers
On Thu, 21 Jan 2010, NARUSE, Yui wrote:
In 4.10.19.4 URL-encoded form data, The
application/x-www-form-urlencoded encoding algorithm,
it says:
For each character in the entry's name and value, apply the following
subsubsteps:
If the character isn't in the range U+0020, U+002A,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ian Hickson i...@hixie.ch wrote:
On Mon, 5 Apr 2010, Swampert wrote:
In your HTML5 draft standard, the default value for type attribute in
script element is text/javascript. While according to RFC 4329, the
MIME type text/javascript is
Sorry for misunderstanding your original suggestion.
On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas nza...@yahoo-inc.comwrote:
I certainly can't argue against a focus on JS crypto. :) What I'd like to
do is eliminate what I believe will be a repeated pattern for developers in
the future. It
On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson i...@hixie.ch wrote:
Well you currently can do this by using the onbeforeprint and onafterprint
hooks, though that's not exactly pretty. Hopefully it will also be
possible with media-specific CSS, though that depends on how details
ends up working in
On Apr 5, 2010, at 1:04 PM, David Flanagan wrote:
Perry Smith wrote:
On Apr 3, 2010, at 11:58 PM, David Flanagan wrote:
Perry Smith wrote:
HTMLCollection has a namedItem method that returns either null or
one object. [1]
HTMLAllCollection has a namedItem method that returns either
null,
On Tue, 06 Apr 2010 17:32:49 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson i...@hixie.ch wrote:
Well you currently can do this by using the onbeforeprint and
onafterprint
hooks, though that's not exactly pretty. Hopefully it will also be
On Tue, Apr 6, 2010 at 9:55 AM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 06 Apr 2010 17:32:49 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson i...@hixie.ch wrote:
Well you currently can do this by using the onbeforeprint and
On Tue, 6 Apr 2010, James Kerr wrote:
Ian Hickson i...@hixie.ch wrote:
On Mon, 5 Apr 2010, Swampert wrote:
In your HTML5 draft standard, the default value for type attribute in
script element is text/javascript. While according to RFC 4329, the
MIME type text/javascript is obsolete, the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Apologies, I've just noticed that I accidentally sent a couple of further
posts directly to Anne instead of to the mailing list. I include them and
Anne's response here for the benefit of the list discussion...
-
On 4/6/10 12:17 PM, Perry Smith wrote:
I'm confused by the spec at this point. The title for section 13 is
obsolete features but then 13.3 is Requirements
Right. Just because a feature is obsolete doesn't mean that UAs aren't
required to implement it in a particular way.
I test a little
On Apr 6, 2010, at 12:24 PM, Boris Zbarsky wrote:
On 4/6/10 12:17 PM, Perry Smith wrote:
I'm confused by the spec at this point. The title for section 13 is
obsolete features but then 13.3 is Requirements
Right. Just because a feature is obsolete doesn't mean that UAs
aren't required to
On 4/6/10 1:37 PM, Perry Smith wrote:
Gack! probably. document.compatMode returns CSS1Compat so I'm in
no-quirks-mode which is probably what you mean by standards mode.
Yep.
-Boris
On Tue, Apr 6, 2010 at 8:32 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson i...@hixie.ch wrote:
Well you currently can do this by using the onbeforeprint and onafterprint
hooks, though that's not exactly pretty. Hopefully it will also be
possible
What about drag-drop? I should be able to drag a directory, a file, or a
list of files onto an input, no? If not, how is this distinction shown to
users? How will it be clear to users when they can do one or the other?
Ojan
On Thu, Apr 1, 2010 at 3:53 PM, John Gregg john...@google.com wrote:
That's a fair question, but how is it clear today whether an input can
accept multiple files vs. a single file using drag-and-drop? Currently if I
drag multiple files onto an input that doesn't have 'multiple', I get only
the first one. (In Chrome.)
Some good default text from the UA, like
In cases where we're having users upload content, we definitely wouldn't want
to block them uploading individual files, while also allowing them to upload
directories.
I would be tempted to make name the fully qualified path to the file (so it
remains unique), and add a third filename
Hi,
For input element in telephone state [1] specs say User agents may
change the punctuation of values that the user enters. I do not really
get it. What is the idea ?
[1] http://dev.w3.org/html5/spec/forms.html#telephone-state
Thanks,
--
Mounir
It's unfortunate that users need to distinguish between single and multiple
file inputs. That's not something we can change at this point. The web
started with single file inputs. We can avoid adding a third type of file
input they need to understand though.
Also, what should happen if you drag
On Tue, 2010-04-06 at 23:12 +0200, Mounir Lamouri wrote:
Hi,
For input element in telephone state [1] specs say User agents may
change the punctuation of values that the user enters. I do not really
get it. What is the idea ?
[1] http://dev.w3.org/html5/spec/forms.html#telephone-state
The most relevant issue is that in Windows/Mac/Linux, there are no system
dialogs that let the user select either a folder or a file. They each have
separate choose a file and choose a folder dialogs. I think the logical
reason for that is that when selecting a file, clicking a directory means
On Tue, 2010-04-06 at 14:28 -0700, John Gregg wrote:
The most relevant issue is that in Windows/Mac/Linux, there are no
system dialogs that let the user select either a folder or a file.
They each have separate choose a file and choose a folder
dialogs. I think the logical reason for that
On Tue, 6 Apr 2010, Mounir Lamouri wrote:
For input element in telephone state [1] specs say User agents may
change the punctuation of values that the user enters. I do not really
get it. What is the idea ?
For example, if I enter 1 650 253-, the user agent is allowed to
change that
On 04/07/2010 12:37 AM, Ian Hickson wrote:
On Tue, 6 Apr 2010, Mounir Lamouri wrote:
For input element in telephone state [1] specs say User agents may
change the punctuation of values that the user enters. I do not really
get it. What is the idea ?
For example, if I enter 1 650
On Wed, 7 Apr 2010, Mounir Lamouri wrote:
On 04/07/2010 12:37 AM, Ian Hickson wrote:
On Tue, 6 Apr 2010, Mounir Lamouri wrote:
For input element in telephone state [1] specs say User agents may
change the punctuation of values that the user enters. I do not really
get it. What is the
On 04/07/2010 12:55 AM, Ian Hickson wrote:
On Wed, 7 Apr 2010, Mounir Lamouri wrote:
On 04/07/2010 12:37 AM, Ian Hickson wrote:
On Tue, 6 Apr 2010, Mounir Lamouri wrote:
For input element in telephone state [1] specs say User agents may
change the punctuation of values that the user enters.
Hello fellas,
I agree with Mounir.
Thing is UA is allowed to do that, but without clear rules, this can be a
mess.
If for date and time, where we have a lot of formats and standards for
internationalization, how can UA specify and be no type mismatch, if we do
not have any standard about phone
On Wed, 7 Apr 2010, Mounir Lamouri wrote:
Well the alternative is to not have the user agent change the value at
all, in which case you still have to do server-side canonicalisation,
so I don't think it really makes any difference.
If the UA is not changing the value, we are sure at
On Tue, 6 Apr 2010, Davis Peixoto wrote:
Thing is UA is allowed to do that, but without clear rules, this can be
a mess. If for date and time, where we have a lot of formats and
standards for internationalization, how can UA specify and be no type
mismatch, if we do not have any standard
On 04/07/2010 01:08 AM, Ian Hickson wrote:
On Wed, 7 Apr 2010, Mounir Lamouri wrote:
Well the alternative is to not have the user agent change the value at
all, in which case you still have to do server-side canonicalisation,
so I don't think it really makes any difference.
If the UA is
On Tue, Apr 6, 2010 at 4:13 PM, Mounir Lamouri mounir.lamo...@gmail.com wrote:
As Davis said, there are too many phone numbers format out there so we
can't let the UA do a formatting because it will be a bad one in most of
the cases. For example, in France, we use 2-digit blocks but in the US
On 04/07/2010 01:18 AM, Tab Atkins Jr. wrote:
On Tue, Apr 6, 2010 at 4:13 PM, Mounir Lamouri mounir.lamo...@gmail.com
wrote:
As Davis said, there are too many phone numbers format out there so we
can't let the UA do a formatting because it will be a bad one in most of
the cases. For example,
On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson i...@hixie.ch wrote:
If there was a true standard, then the spec would refer to that, but as
you say, it's very varied in practice.
There is quite a standard, even if an implicit one: (almost) no punctuation.
Have you ever dialed a ( or a - when
When I was using MacOS X, I hated how the contact application was
restyling my phone numbers.
By the way, it lets me think about something: the telephone state can
still be used for autocomplete with phones from contacts.
--
Mounir
Good one, Mounir.
Tab, this does not means only
On Wed, 2010-04-07 at 01:28 +0200, Eduard Pascual wrote:
On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson i...@hixie.ch wrote:
If there was a true standard, then the spec would refer to that, but as
you say, it's very varied in practice.
There is quite a standard, even if an implicit one:
Other than that, the only safe alternative would be to leave the
values untouched, so the page can say what it wants, the user honor
it, and the server get it as expected; or gracefully degrade to an
error message that actually points to the user error (rather than an
error introduced by an
0-9, *, #, p, w
http://www.wikihow.com/Add-Pauses-to-a-Phone-Number
recognizing the difference between a 'P' and a 'p' (or a 'W' and a
'w') is moderately painful.
Sorry for the delay in replying ...
On Thu, Mar 25, 2010 at 1:31 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 21 Dec 2009, Dirk Pranke wrote:
In the course of testing something today, I attempted to create a window
and immediately post a message to it, and was surprised that it didn't
seem
On Wed, Apr 7, 2010 at 1:31 AM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
On Wed, 2010-04-07 at 01:28 +0200, Eduard Pascual wrote:
On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson i...@hixie.ch wrote:
If there was a true standard, then the spec would refer to that, but as
you say, it's
The goal of fool-proofing phone fields is a quite noble one but, let's
be honest: it's quite near to an utopia. Any solution that may cause
valid inputs to break is definitely bad. If fixing wrong inputs risks
valid ones to break, we are not only not solving the problem, but we
are moving
On 07/04/2010, at 9:21 AM, Mounir Lamouri wrote:
When I was using MacOS X, I hated how the contact application was
restyling my phone numbers.
I'm surprised this was an issue; the Mac OS X Address Book contains a dedicated
preferences screen to allow you to define custom formatting rules if
On Thu, 4 Feb 2010, Tab Atkins Jr. wrote:
On Thu, Feb 4, 2010 at 5:12 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 25 Jan 2010, Tab Atkins Jr. wrote:
Adam Barth rightfully points out that this only stops certain classes
of data exfiltration attacks, and so probably isn't worthwhile as a
42 matches
Mail list logo
