On Tue, Mar 31, 2009 at 10:22 AM, Boris Zbarsky wrote:
> I agree that entering a week is pretty rare, though. ;)
>
As someone working on supporting new input types in WebKit: Supporting any
one form of "date" is nontrivial, but supporting the rest after you support
the first _is_ trivial. So w
On Wed, Jan 28, 2009 at 10:27 AM, Křištof Želechovski wrote:
> Spelling quizzes are an artificial example; they are not interesting once
> spell checking is commonly available because the user can cheat by
> temporarily using another control that is being checked.
>
They can cheat today by pastin
On Wed, Jan 28, 2009 at 2:35 AM, Křištof Želechovski wrote:
> *No, the _original_ use was to turn it on on fields where it would
> otherwise have been on.
> *
>
>
>
> I do not understand. If spell checking would be on, why turn it on
> explicitly?
>
I mistyped. The last word should have been "o
2009/1/27 Křištof Želechovski
> The original use of the spellcheck attribute was to switch spell checking
> off
>
No, the _original_ use was to turn it on on fields where it would otherwise
have been on.
> (I think we both believe it should generally be on). Using a private
> language for the
2009/1/26 Křištof Želechovski
> Q: Should the localization influence the spell checking mechanism?
>
> A: Definitely, since the user is likely to write most messages in his
> preferred UI language.
>
Which is why this is a perfectly valid input for the heuristic the UA uses
to determine the chec
On Sun, Jan 25, 2009 at 10:52 AM, Křištof Želechovski wrote:
> Gmail can use
> 1. the localisation preferences chosen by the user in GMail configuration,
> 2. the localisation preferences chosen by the user in the browser
> configuration
> to determine the what language the user is likely to use
On Wed, Jan 21, 2009 at 7:38 PM, Calogero Alex Baldacchino <
alex.baldacch...@email.it> wrote:
> Why not to let the user choose the language, as it happens in word
> processors? A UA can't choose accurately whether, for instance, "color" is a
> correct American English, a wrong British English, or
On Wed, Jan 21, 2009 at 1:15 AM, Mikko Rantalainen <
mikko.rantalai...@peda.net> wrote:
> If the browser does not know the language of the content, how on earth
> is it supposed to *correctly* spellcheck it?
As others have noted, the user's preferences are generally a better
indicator of how som
2009/1/20 Mikko Rantalainen
> I agree. I think that specifying the spellcheck attribute would be a
> mistake. It allows only forcing the automatic spell checking on or off
> but it doesn't help a bit to allow mixing different languages on a
> single page.
I don't see how the second sentence is
On Mon, Jan 19, 2009 at 4:53 PM, Robert O'Callahan wrote:
> Actually I was just poking around and noticed that we don't actually
> support variation of spellcheck values within different parts of an editable
> element. So I won't make any claims about how hard that is to support.
>
Doesn't the sp
On Tue, Dec 30, 2008 at 3:38 AM, Ian Hickson wrote:
> The same engineers have since implemented this feature in Chrome also,
Incorrect. One engineer implemented a crude hack in a small portion of the
Chromium glue code that implements a fraction of the spec -- enough to make
Gmail work a littl
el aspect
> > ratio override.
>
> I'm certainly open to other solutions. What do you suggest?
>From reading the above paragraph, "do nothing, for now". I don't see a
problem in need of an HTML 5 spec solution.
On Mon, 17 Nov 2008, Peter Kasting wrote:
> >
On Mon, Nov 17, 2008 at 1:58 PM, Pierre-Olivier Latour <[EMAIL PROTECTED]>wrote:
>
> 1) I don't remember any major media system I've dealt with so far having an
> explicit pixel aspect ratio override API,
> 2) on the web, neither QT plug-in nor Flash have it,
> 3) in the case of this spec, the way
On Wed, Oct 15, 2008 at 12:04 PM, Sander van Zoest <[EMAIL PROTECTED]>wrote:
> I do not see why we are condoning hacks on top of hacks, when it is so
> simple
> to just specify hSpace and vSpace.
>
The entire problem is that it is not simple. It is less simple to spec,
less simple to declare, le
On Wed, Oct 15, 2008 at 2:08 AM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> For example, if Alice uses Browser A, and finds that when rewinding the
> sound isn't played, and thus does a hack that fakes the sound playback by
> having a separate hidden element while rewinding, in which she
> seeks, p
On Tue, Oct 14, 2008 at 8:00 AM, Eric Carlson <[EMAIL PROTECTED]>wrote:
> Some media formats and/or engines may not support reverse playback, but I
> think it is a mistake for the spec to mandate this behavior. Why is reverse
> playback different from other situations described in the spec where
On Thu, Jul 31, 2008 at 2:31 AM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Wed, 30 Apr 2008, Peter Kasting wrote:
> >- Otherwise, if the element is not larger than the viewport, scroll
> such
> >that the element is centered* in the viewport (within the scrolli
On Tue, Jul 29, 2008 at 5:10 PM, Russell Leggett
<[EMAIL PROTECTED]>wrote:
> That is a performance killer.
>
>
> I don't think it is as much of a performance killer as you say it is.
> Correct me if I'm wrong, but the standard connection limit is two.
>
The standard connection limit is 6, not 2,
On Tue, May 6, 2008 at 6:44 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Sat, 14 Apr 2007, Geoffrey Garen wrote:
> >
> > 1.4
> > "when not qualified to explicitly refer"
> > when not qualified explicitly to refer
> > (split infinitive)
>
> I prefer the current text.
How about "when not qualif
On Wed, Apr 30, 2008 at 10:58 AM, David Bolter <[EMAIL PROTECTED]>
wrote:
> Specifically I would ask that:
>
> 1. scrollIntoView not do anything in the case that the element is already
> fully visible (possibly in the middle of the viewport), or
> 2. ensureElementIsVisible to be added as described
On Wed, Apr 16, 2008 at 6:41 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote:
> Peter Kasting wrote:
>
>> I think the argument assumed you were communicating with a single frame in
>> the common case, in which case the current API is more awkward than one in
>> which
On Wed, Apr 16, 2008 at 3:17 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote:
> - Processing a reply synchronously is awkward in any case, since you need
> > a callback.
> >
>
> I'm not sure I follow this argument, I actually come to the opposite
> conclusion.
>
> Say that a page is communicating with
On Sun, Apr 6, 2008 at 1:52 AM, Aaron Boodman <[EMAIL PROTECTED]> wrote:
> We have on one hand authors with reasons
> (however edge casey you may believe them to be) they would prefer the
> API be asynchronous,
Here's another problem an async API would automatically address:
https://bugzilla.moz
On Sat, Apr 5, 2008 at 2:19 PM, Jeff Walden
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>>
wrote:
> Peter Kasting wrote:
>
> > It doesn't matter if the stack will not _commonly_ be too deep, or if it
> > isn't too deep for the callers that you know about right
(Apologies if the threading on this gets messed up. I was not subscribed to
the list when the original message was sent.)
I want to paint Eric's scenario more strongly, because it seems like people
think if it would rarely blow up then it doesn't matter.
If you want to handle _any_ request sent
101 - 125 of 125 matches
Mail list logo
