On Thu, 4 Feb 2010, Tab Atkins Jr. wrote:
> On Thu, Feb 4, 2010 at 5:12 AM, Ian Hickson 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
>
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 t
>
>
> 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
On Wed, Apr 7, 2010 at 1:31 AM, Ashley Sheridan
wrote:
>
> On Wed, 2010-04-07 at 01:28 +0200, Eduard Pascual wrote:
>
> On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson wrote:
> > If there was a true standard, then the spec would refer to that, but as
> > you say, it's very varied in practice.
>
> The
Sorry for the delay in replying ...
On Thu, Mar 25, 2010 at 1:31 AM, Ian Hickson 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 to wor
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.
>
>
> 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
On Wed, 2010-04-07 at 01:28 +0200, Eduard Pascual wrote:
> On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson 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
>
> 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 onl
On Wed, Apr 7, 2010 at 1:10 AM, Ian Hickson 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 phoning someo
On 04/07/2010 01:18 AM, Tab Atkins Jr. wrote:
> On Tue, Apr 6, 2010 at 4:13 PM, Mounir Lamouri
> 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 us
On Tue, Apr 6, 2010 at 4:13 PM, Mounir Lamouri 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
> people write 3-digit
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.
>>
>
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 stand
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
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 nu
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 tha
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
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
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
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
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 mean
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-
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 fi
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
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" attrib
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 "Choo
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 wrote:
> For context, Ian Fe
On Tue, Apr 6, 2010 at 8:32 AM, Tab Atkins Jr. wrote:
> On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson 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, thoug
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 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
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 litt
-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 Tue, 6 Apr 2010, James Kerr wrote:
> Ian Hickson 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, t
On Tue, Apr 6, 2010 at 9:55 AM, Anne van Kesteren wrote:
> On Tue, 06 Apr 2010 17:32:49 +0200, Tab Atkins Jr.
> wrote:
>>
>> On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson wrote:
>>>
>>> Well you currently can do this by using the onbeforeprint and
>>> onafterprint
>>> hooks, though that's not exac
On Tue, 06 Apr 2010 17:32:49 +0200, Tab Atkins Jr.
wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson 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
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, o
On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson 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
> ends up working in CSS. If this pro
Sorry for misunderstanding your original suggestion.
On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas wrote:
> 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 would be really ni
> 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 layout text in Canvas.
It would certainly help - might it also be possible to add a similar "baseline"
(or "ascent") att
On Tue, 06 Apr 2010 11:32:01 +0200, James Kerr wrote:
Ian Hickson 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
Ian Hickson 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,
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+0
On Sat, 03 Apr 2010 17:23:39 +0300, Greg Brown 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 layout text in
44 matches
Mail list logo
