I have questions about some inputmode attributes.
In the desktop case, full-width-latin, kana and katakana look to intend
user local IME. Right?
I think whether IME is on or off is very important to user because some IME
have state and show some window to input character.
It is much different from
If this is strictly a performance issue, then we definitely should fix
that before adding new API, IMHO. It would be great to get some reduced
test cases where save()/restore() is a bottleneck.
I'd argue its not strictly a performance issue. More generally its awkward
that you can reset any
On Sat, Aug 10, 2013 at 11:07 PM, Rik Cabanier caban...@gmail.com wrote:
On Sat, Aug 10, 2013 at 7:50 AM, Glenn Maynard gl...@zewt.org wrote:
On Sat, Aug 10, 2013 at 7:42 AM, Stephen White
senorbla...@chromium.orgwrote:
Chrome (well, Skia actually) uses a hairline mode for line widths
Reading through the spec, I am not seeing how an application can determine
whether a drop into a different window was successful.
Example use case: An app wants to take advantage of multiple screens, and so
it opens two different windows which can be placed on different screens. The
user can
On Mon, Aug 12, 2013 at 4:50 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Aug 12, 2013 at 12:16 PM, Joshua Bell jsb...@google.com wrote:
To recap history: early iterations of the Encoding API proposal did have
base64 but it was removed with the suggestion to extend atob()/btoa()
instead,
On Mon, 12 Aug 2013, Kenneth Russell wrote:
The use case is the passing of ImageData objects back and forth to
workers to fill and refill with data.
An ImageData is essentially a wrapper for the underlying
Uint8ClampedArray, providing an associated width and height. However,
the only
On Tue, 13 Aug 2013, Daniel Trebbien wrote:
Reading through the spec, I am not seeing how an application can
determine whether a drop into a different window was successful.
This was an error in the spec. Good catch.
I've updated the spec. The trick is to check event.dataTransfer.dropEffect
On Aug 12, 2013, at 11:28 PM, Yoichi Osato yoic...@google.com wrote:
I have questions about some inputmode attributes.
In the desktop case, full-width-latin, kana and katakana look to intend
user local IME. Right?
I think whether IME is on or off is very important to user because some IME
On Thu, 8 Aug 2013, Boris Zbarsky wrote:
On 8/8/13 5:05 PM, Ian Hickson wrote:
I think the problem is that I have no idea what these ES6 terms are or
what they mean.
OK. Which terms, exactly?
Probably all the JS terms that were introduced since the late 90s...
(Thanks for the education
On 2013-08-13 19:56 (GMT) Ian Hickson composed:
...Firefox...
...Firefox...
...Firefox ... Firefox...
Please type Gecko unless you mean to exclude SeaMonkey, Camino and other
browsers built on Gecko. It's only five letters, thus quicker to type than
Firefox's seven, and should help to
On Jul 28, 2013, at 10:29 AM, James Greene james.m.gre...@gmail.com wrote:
I think it makes sense, too. That said, if the goal is to REPLACE the
NodeIterator and TreeWalker APIs completely, it wouldn't be all that
valuable for me as my most common use case has always been to get TEXT
NODES
Am 13.08.2013 um 23:10 schrieb Edward O'Connor eocon...@apple.com:
Hi Anselm,
You wrote:
[A]s WebKit today implemented the srcset attribute [1] according to
the W3C specification [2] I do think it is time to update the WHATWG
specification [3] reflecting the syntax as written in W3C's
On Tue, Aug 13, 2013 at 11:57 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 12 Aug 2013, Kenneth Russell wrote:
The use case is the passing of ImageData objects back and forth to
workers to fill and refill with data.
An ImageData is essentially a wrapper for the underlying
Uint8ClampedArray,
I concur with Boris's concerns. Can we at least avoid having OverrideBuiltins
on Document?
Or can we keep HTMLDocument that just defines name getter?
- R. Niwa
On Jul 12, 2013, at 11:04 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/12/13 1:57 PM, Ian Hickson wrote:
Having not heard any
14 matches
Mail list logo
