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
On Mon, Aug 12, 2013 at 6:45 PM, Glenn Maynard wrote:
> On Sat, Aug 10, 2013 at 9:43 PM, Rik Cabanier wrote:
>
>> Ah, so you are relying on pixel snapping (=rounded up to 2 pixels).
>>
>
> Rounded to the nearest integer pixel. If you give 1.25, the width would
> be 1.
>
>
>> If you can do that
On Sat, Aug 10, 2013 at 9:43 PM, Rik Cabanier wrote:
> Ah, so you are relying on pixel snapping (=rounded up to 2 pixels).
>
Rounded to the nearest integer pixel. If you give 1.25, the width would be
1.
> If you can do that with your approach, why not with strokes that are drawn
> from the ce
On Fri, Aug 9, 2013 at 2:34 PM, Ian Hickson wrote:
> On Fri, 9 Aug 2013, Rik Cabanier wrote:
>> On Fri, Aug 9, 2013 at 1:32 PM, Ian Hickson wrote:
>> > On Mon, 11 Mar 2013, Kenneth Russell wrote:
>> > >
>> > > It would be useful to be able to create an ImageData [1] object with
>> > > preexisting
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.
(Incidentally, we did some performance fixes recently for setFont() in
Chrome.)
Stephen
On Mon, Aug
On Mon, Aug 12, 2013 at 12:16 PM, Joshua Bell 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, and due to the confusion around the encode/decode verbs. If the
> APIs were something
On Aug 8, 2013, at 7:29 AM, Jukka K. Korpela wrote:
> 2013-08-08 2:57, Ryosuke Niwa wrote:
>
>> On Aug 2, 2013, at 6:10 AM, Jukka K. Korpela
>> wrote:
> [...]
>>> But regarding the effect of language markup on fonts, the effect is
>>> limited to situations where the font is not specified in a
On Mon, Aug 12, 2013 at 10:27 AM, Anne van Kesteren wrote:
> On Mon, Aug 12, 2013 at 6:16 PM, Joshua Bell wrote:
>> FWIW, I've landed an experimental (behind a flag) implementation of the API
>> in Blink/Chromium; changing it is definitely possible for us. I believe Moz
>> is shipping it web-expo
On Mon, Aug 12, 2013 at 2:26 PM, Justin Novosad wrote:
> Ok, so here is a simple proposal:
>
> IDL:
> enum CanvasSaveMode { "all", "transform", "clip", "transform-and-clip" };
> save(optional CanvasSaveMode mode);
>
> Modes:
> all: save the entire rendering context state
> transform: save only th
On Tue, Aug 6, 2013 at 4:47 PM, Adam Klein wrote:
> On Tue, Aug 6, 2013 at 4:38 PM, Jonas Sicking wrote:
>> On Tue, Aug 6, 2013 at 4:27 PM, Adam Klein wrote:
>>> On Tue, Aug 6, 2013 at 4:21 PM, Jonas Sicking wrote:
As I recall it (it was ages since I dealt with this), the tricky case
On Mon, Aug 12, 2013 at 2:26 PM, Justin Novosad wrote:
> Ok, so here is a simple proposal:
>
> IDL:
> enum CanvasSaveMode { "all", "transform", "clip", "transform-and-clip" };
> save(optional CanvasSaveMode mode);
>
> Modes:
> all: save the entire rendering context state
> transform: save only the
Ok, so here is a simple proposal:
IDL:
enum CanvasSaveMode { "all", "transform", "clip", "transform-and-clip" };
save(optional CanvasSaveMode mode);
Modes:
all: save the entire rendering context state
transform: save only the current transform
clip: save only the current clip
if mode is not spec
> Good point, I think part of the problem has to do with the fact that save
> is non-selective (saves all of the state).
Yes, since save() and restore() save and restore everything, it creates the
side effect of needing to set ctx.font/fillStyle/strokeStyle more often
than otherwise, which are slo
On Mon, Aug 12, 2013 at 4:34 PM, Rik Cabanier wrote:
>
>
> On Mon, Aug 12, 2013 at 1:24 PM, Justin Novosad wrote:
>
>>
>>
>>
>> On Mon, Aug 12, 2013 at 2:15 PM, Rik Cabanier wrote:
>>
>>>
>>>
>>> On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad wrote:
>>>
On Fri, Aug 9, 2013 at 4:20 PM, Ian
On Mon, Aug 12, 2013 at 1:24 PM, Justin Novosad wrote:
>
>
>
> On Mon, Aug 12, 2013 at 2:15 PM, Rik Cabanier wrote:
>
>>
>>
>> On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad wrote:
>>
>>> On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson wrote:
>>>
>>> >
>>> > This is a quite widely requested featur
On Mon, Aug 12, 2013 at 2:15 PM, Rik Cabanier wrote:
>
>
> On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad wrote:
>
>> On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson wrote:
>>
>> >
>> > This is a quite widely requested feature. What should we do to address
>> > this request instead?
>> >
>> >
>> Wh
I think most performance-minded use cases will be fine with junov's idea
since they will not want to touch the stack in the first place.
Here's a simple use case: Suppose there are nested objects to be drawn,
Panels, TextBlocks, and other visual elements. Panels are containers that
draw a backgrou
On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad wrote:
> On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson wrote:
>
> >
> > This is a quite widely requested feature. What should we do to address
> > this request instead?
> >
> >
> What if resetClip restored the clip to what it was at the save call that
On Mon, Aug 12, 2013 at 6:16 PM, Joshua Bell wrote:
> FWIW, I've landed an experimental (behind a flag) implementation of the API
> in Blink/Chromium; changing it is definitely possible for us. I believe Moz
> is shipping it web-exposed already in FF?
Yes, since Firefox 18 (since Firefox 20 in wo
Back from a vacation, sorry about the late reply - hopefully still useful.
On Wed, Aug 7, 2013 at 3:02 PM, Glenn Maynard wrote:
> On Wed, Aug 7, 2013 at 4:21 PM, Chang Shu wrote:
>
> > If we plan to enhance the Encoding spec, I personally prefer a new pair
> of
>
> BinaryDecoder/BinaryEncoder,
+Yoichi Osato, who is working on implementing inputmode spec for Blink and
Chromium.
On Fri, Jun 7, 2013 at 8:04 AM, Jonas Sicking wrote:
> On Thu, Jun 6, 2013 at 2:08 PM, Ian Hickson wrote:
> > On Fri, 15 Feb 2013, Jonas Sicking wrote:
> >>
> >> Using semantic names might give us the warm fuz
21 matches
Mail list logo
