Re: [whatwg] inputmode feedback

[Yoichi Osato]

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 alphabetic direct keyboard input.
See
https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#composer-section
At least Chinese and Korean IME have state.
In this point we should add attributes corresponding to chinese and korean.
I don't know whether there are any other such a IME but I think many non
English native people input in alphabet or hir/her native language.
So should we add "native" attribute?

Following Ian's graph:
http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control
How about this?
User Default Input Method
- Latin text verbatim
-- Latin name


--- Latin prose
- Native language (includes like Hiragana, Hanja, which are first character
set in  each native language)
-- Latin Full Width
-- Katakana
-- (some modes that is not first character set in native language)





On Mon, Aug 12, 2013 at 6:26 PM, Takayoshi Kochi (河内 隆仁)
wrote:

> +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 fuzzies, but is there
>> really
>> >> any semantic use we will get out of these that we wouldn't by using
>> >> "lowercase", "titlecase" or "autocapitalized"?
>> >
>> > The reason I used the more "semantic" names is that the names like
>> > "lowercase", "titlecase" or "autocapitalized" aren't accurate. For
>> > example, you can hit shift in "lowercase" mode to get uppercase. You can
>> > have a "titlecase" mode that doesn't capitalise every word (e.g. it
>> > recognises the "van" in "van Kesteren"). A value that is explicitly for
>> > names can use a different dictionary than one that is just for
>> capitalised
>> > text (e.g. derived from the user's contact list). And so on.
>> >
>> >
>> >> I take it verbatim and name would disable any spelling corrections,
>> >> and name would also titlecase? But the difference between text and
>> >> prose seems really hard to understand.
>> >
>> > In the spec, "verbatim" does not correction at all, e.g. passwords;
>> > "latin" is for human-to-computer communications, e.g. free-form text
>> > search fields, and would do spelling correction and automatically
>> > inserting spaces between words in swiping keyboards, etc; and
>> > "latin-prose" is intended for human-to-human communications, with
>> > aggressive automatic typing correction, e.g. text prediction and
>> automatic
>> > capitalisation at the start of sentences.
>>
>> I think a really important question is if this is understandable to
>> authors. There's also a big risk that if these modes aren't noticeably
>> different in initial implementations, it will be hard to add such
>> differences later.
>>
>> / Jonas
>>
>
>
>
> --
> Takayoshi Kochi
>

Re: [whatwg] Blurry lines in 2D Canvas (and SVG)

[Rik Cabanier]

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 with your approach, why not with strokes that are
>> drawn from the center?
>>
>
> It might be possible, in principle, to only snap the "border" of the
> stroke instead of the whole thing, but I don't know how to do that or if
> it'd be worthwhile.  It seems like sharp lines are only particularly
> important for thin strokes (especially 1px), and in those cases the
> difference between a center and an outer stroke are minor.  (I don't know
> if it's harder to implement, eg. so there's no gap between a fill followed
> by an outer stroke.)
>
> I was wondering if this is something that happens in Flash as well. It
>> turns out that there's an option called "hinting: Keep stroke anchors on
>> full pixels to prevent blurry lines." There's a blog post on what this
>> does:
>> http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html 
>> 
>>
>
> I don't know about this, but the description sounds similar to what I'm
> suggesting.
>

Great! I think we're both on the same page on how the problem can be solved.
Do you still believe it's up to the author to do so, or are you leaning
towards solving it on the browser side?

I would also like to know if people see this as a problem that is worth
solving. Many of our Illustrator customers complain about this. We've tried
to fix it on the authoring side but it doesn't always work.

Re: [whatwg] Blurry lines in 2D Canvas (and SVG)

[Glenn Maynard]

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 center?
>

It might be possible, in principle, to only snap the "border" of the stroke
instead of the whole thing, but I don't know how to do that or if it'd be
worthwhile.  It seems like sharp lines are only particularly important for
thin strokes (especially 1px), and in those cases the difference between a
center and an outer stroke are minor.  (I don't know if it's harder to
implement, eg. so there's no gap between a fill followed by an outer
stroke.)

I was wondering if this is something that happens in Flash as well. It
> turns out that there's an option called "hinting: Keep stroke anchors on
> full pixels to prevent blurry lines." There's a blog post on what this
> does:
> http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html 
> 
>

I don't know about this, but the description sounds similar to what I'm
suggesting.

-- 
Glenn Maynard

Re: [whatwg] Proposal: ImageData constructor or factory method with preexisting data

[Kenneth Russell]

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 data. The main use case is to display arbitrary data in
>> > > the 2D canvas context with no data copies.
>> >
>> > Doesn't ImageBitmap support this already? I'm not sure I understand
>> > the use case here. Where are you getting the image data from, that
>> > it's already in raw RGBA form rather than compressed e.g. as a PNG?
>> > (Presumably this isn't coming over the network, since I would imagine
>> > the time to compress and decompress an image is far smaller than the
>> > time to send uncompressed data. But maybe I'm wrong about that.)
>>
>> From re-reading the thread, it seems that this data comes from the
>> server (or a web worker?) as uncompressed data. The http protocol likely
>> did compression on the packets so the size difference is probably not
>> that great.
>>
>> I think the use-case is to avoid having to copy over the data pixel by
>> pixel from the arraybuffer.
>
> Could you elaborate on the use case?
>
> I'm happy to believe that there are times that a server or worker is
> generating lots of pixel data, but having never run into such a case
> myself, I would very much like to understand it better. It may be that
> there are better solutions to the real underlying problem.

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 way to draw raw pixels into a Canvas is using an ImageData.

Currently a Unit8ClampedArray can be constructed, but the only way to
create an ImageData is to ask a Canvas for one, and there's no way to
associate it with a pre-allocated Uint8ClampedArray. This means that
if you want to pass an ImageData to a worker for filling, transferring
the underlying Uint8ClampedArray, you need to be very careful about
bookkeeping, and to not lose the reference to the ImageData object.

IMO there ought to be a factory method for ImageData taking a
Uint8ClampedArray, width, height, and possibly resolution (or a
dictionary?), which validates the width, height and resolution against
the size of the Uint8ClampedArray, and makes a new ImageData object.
This would ease management of ImageData instances.

-Ken

Re: [whatwg] remove resetClip from the Canvas 2D spec

[Stephen White]

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 12, 2013 at 6:34 PM, Rik Cabanier  wrote:

>
>
> 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 current transform
>> clip: save only the current clip
>>
>> if mode is not specified, the entire context state is saved (for backward
>> compatibility)
>>
>> The restore method's interface does not change. It restores whatever
>> state was saved by the matching save call.
>>
>
> I wasn't really thinking about a new API surface :-)
> Can't this be fixed under the hood? The tricks that Simon is doing, could
> be done by the browser itself.
>
> If not, this proposal looks reasonable (if you turn it into a dict like
> Tab says).
>
>>
>> On Mon, Aug 12, 2013 at 4:56 PM, Simon Sarris wrote:
>>
>>> > 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 slow to set, probably because of some CSS parser
>>> activity, but I'm not wise enough to know.
>>>
>>> If there was merely a way to save and restore the context, or perhaps
>>> some other subset of state, that would probably work nicely too.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

[Glenn Maynard]

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 like StringToBytesConverter::convert() and
> BytesToStringConverter::convert() it would make more sense for encoding of
> both text (use StringToBytes) and binary data (use BytesToString).
>

I thought about suggesting something like "StringToBytes", but that seems
less obvious for the (probably) more common usage of encoding/decoding a
String, and it's still a bit off (though not *strictly* wrong) for
converting to UTF-16, UTF-32, etc.  I tend to think the slightly
unintuitive names of TextEncoder and TextDecoder aren't bad enough that
it's worth renaming them.


> While we're re-opening this can of worms, there's been a request to add a
> flush() method to the TextEncoder/TextDecoder objects, which would behave
> the same as calling encode(null, {stream: false}) / decode(null,
> {stream:false}) but make the code more readable. This fails the "adding a
> new method for something that behaves exactly like something we already
> have" test. Opinions?
>

I think you only need to say encode() and decode(), which is less of a win,
especially since creating two ways of doing the same thing means that
people have to learn both ways.  Otherwise, they'll see code end with
".encode()" and not realize that it's the same as the ".finish()" they've
been using.

On Mon, Aug 12, 2013 at 6:26 PM, Jonas Sicking  wrote:

> I don't think that base64 encoding fits with the current
> TextEncoder/Decoder API. Not because of names, but because base64
> encoding is by nature opposite. I.e. the encoded format is in string
> form, whereas the decoded format is in binary form.
>

The names are the only things that are opposite.  TextEncoder is just a
streaming String-to-binary-blob conversion API, and TextDecoder is just a
streaming binary-blob-to-String API, and that's precisely what base64
encoding and decoding are.  That's the same whether you're converting
String-to-base64 or String-to-UTF-8.  The only difference is that the names
we've given to those ideas are reversed here.

One thing that might need special attention is that U+FFFD error handling
doesn't make sense for base64; errors should probably always be fatal.

-- 
Glenn Maynard

Re: [whatwg] HTML: A DOM attribute that returns the language of a node

[Ryosuke Niwa]

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 style
>>> sheet. This is a rather uncommon scenario these days; authors are
>>> more than eager to set fonts.
>> 
>> Do you have actual statistics to support this point?
> 
> No, it’s just an impression from looking at numerous pages and their coding 
> as well as views presented in authors’ forums.
> 
>> As far as I
>> checked, neither baidu.com nor yahoo.com.tw seems to explicitly
>> specify a Chinese font.
> 
> They both have font-family settings, slightly different, but basically the 
> most common (sorry, no statistic on this either) setup that uses Arial 
> (possibly with Helvetica as second option, which does not change much). So, 
> granted, they don’t specify a Chinese font in the sense of including any 
> specific fonts containing CJK characters in the font-family list.
> 
> Baidu doesn’t set lang either, so they seem to be accepting, for any 
> characters not covered by Arial, whatever happens to be in each browser’s 
> list of fallback fonts, when no information about content language is 
> available. Yahoo.com.tw sets lang="zh-tw", so they do care, but only to the 
> extent that the fallback font should be one intended for Traditional Chinese.
> 
> So the lang markup may affect fonts, but only under some conditions. And if 
> you care about fonts, as an author, then an explicit list of font 
> alternatives has better chances of creating the desired result.

That's not a practical solution because we can't possibly know the list of 
Chinese & Japanese fonts available by default in all operating systems.

>>> It is true that they might specify a font list where none of the
>>> fonts supports some characters that might be entered, and then a
>>> fallback font would be used. However, using “annotations”
>>> (presumably, lang attributes, along with extra  elements when
>>> needed) does not sound like a feasible approach to this.
>> 
>> Whether it’s feasible or not, that’s what we have been doing due to
>> the Han unification.  If we could, we’ll undo the Han unification and
>> use different glyphs for each character but we can’t do that at this
>> point in time.
> 
> If a page contains texts to be rendered using different forms (Traditional 
> Chinese, Simplified Chinese, Japanese, Korean) for Han characters, you will 
> need to control the rendering somehow. Using lang markup might be 
> theoretically most adequate, but it’s indirect and less effective than just 
> setting different fonts (via font-family lists that contain reasonably many 
> alternatives).

Controlling the rendering isn't the goal here.  The point is to use the correct 
glyph in each language so that each character is recognizable by users.  Again, 
specifying a font name is not a practical solution as authors have no way of 
knowing the list of Chinese & Japanese fonts provided by all current and future 
operating systems.

> But even if lang attributes are used, I don’t think the issue has much 
> relevance to the original question here. A DOM attribute that returns the 
> language of a node would be useful for the purpose only if you intend to 
> affect rendering via JavaScript.

No.  The point is that any code that attempts to move or copy contents must 
preserve the effective value of the lang attribute.

- R. Niwa

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

[Jonas Sicking]

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-exposed already in FF?
>
> Yes, since Firefox 18 (since Firefox 20 in workers).

I assume we are talking about TextEncoder/TextDecoder here, and not
new versions of atob and btoa.

If so, yes, we've been shipping that for a while now.

>> 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 like StringToBytesConverter::convert() and
>> BytesToStringConverter::convert() it would make more sense for encoding of
>> both text (use StringToBytes) and binary data (use BytesToString).
>
> I can't really speak for Gecko, but I suspect we wouldn't like
> changing it over half a year after deploying it. Jonas?

I guess we'd have to do a cost/benefit analysis. What is it that
people want to change about the current API, and why?

Moving to new function names might be doable, by implementing the new
names and adding warnings to the old ones. But we should consider the
confusion it will cause, and how much it will delay deployment.

>> While we're re-opening this can of worms, there's been a request to add a
>> flush() method to the TextEncoder/TextDecoder objects, which would behave
>> the same as calling encode(null, {stream: false}) / decode(null,
>> {stream:false}) but make the code more readable. This fails the "adding a
>> new method for something that behaves exactly like something we already
>> have" test. Opinions?
>
> Adding that seems fine.

I don't have strong opinions either way.

I don't think that base64 encoding fits with the current
TextEncoder/Decoder API. Not because of names, but because base64
encoding is by nature opposite. I.e. the encoded format is in string
form, whereas the decoded format is in binary form.

I.e. encodings like utf8 and friends encode string data into binary
data. base64 encodes binary data into string data.

/ Jonas

Re: [whatwg] remove resetClip from the Canvas 2D spec

[Rik Cabanier]

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 current transform
> clip: save only the current clip
>
> if mode is not specified, the entire context state is saved (for backward
> compatibility)
>
> The restore method's interface does not change. It restores whatever state
> was saved by the matching save call.
>

I wasn't really thinking about a new API surface :-)
Can't this be fixed under the hood? The tricks that Simon is doing, could
be done by the browser itself.

If not, this proposal looks reasonable (if you turn it into a dict like Tab
says).

>
> On Mon, Aug 12, 2013 at 4:56 PM, Simon Sarris wrote:
>
>> > 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 slow to set, probably because of some CSS parser
>> activity, but I'm not wise enough to know.
>>
>> If there was merely a way to save and restore the context, or perhaps
>> some other subset of state, that would probably work nicely too.
>>
>>
>>
>>
>>
>>
>

Re: [whatwg] Form-associated elements and the parser

[Adam Klein]

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
 that you need to handle is this one:

 http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2432

 In this case, web compatibility requires that the  is
 associated with the form. Specifically hidden  elements would
 often end up moved, but still had to show up in form.elements as well
 as get submitted along with the form.
>>>
>>> That case definitely makes sense to me, and I think it's fine to keep
>>> that behavior for compat. The only one I'm asking to change is the
>>> case when the  and  end up in different trees.
>>
>> Sure, as long as you come up with a formalized algorithm for when
>> there is an association and when there isn't. Keep in mind that by the
>> time that the input-element is inserted, the form-element might have
>> been moved elsewhere. We likely don't need the association in that
>> case, but detecting that that has happened sounds tricky.
>
> My concrete proposal would be something like this:
>
> In step 4 of 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#create-an-element-for-the-token,
> add a requirement that "intended parent" and the "form element
> pointer" be part of the same "home subtree" (defined at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#home-subtree).

For what it's worth, we're giving this a try in Blink
(https://src.chromium.org/viewvc/blink?revision=155949&view=revision),
as it's by far the safest fix for the related crashes. I'll update
this thread if we run into any compat issues in the wild (or if we
don't!).

- Adam

>> The way that Gecko currently works IIRC is that it creates the
>> association any time it has seen a "" without seeing a
>> "". And it breaks the association anytime an input-element's
>> parent chain changes and the associated form-element is no longer in
>> the parent chain.
>
> This is basically the same thing Blink & WebKit do, with the caveat
> that we also avoid associating s with elements inside
> s (this is now reflected in step 4 of the algorithm, see
> above).
>
>> On a related note, when are you guys going to add a cycle collector or
>> other not-plain-refcounting memory manager :-)
>
> Yes, that would be nice :)
>
> - Adam
>
>> / Jonas
>>
 On Tue, Aug 6, 2013 at 2:01 PM, Adam Klein  wrote:
> Hixie opened my eyes last week to parser-association behavior of the
> sort found at 
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2428.
> In that case, an  in a detached tree is associated with a
>  in the main document. This causes badness in WebKit and Blink
> because the association between the  and the  (e.g., as
> exposed in the HTMLFormElement.elements collection) is only weakly
> held to avoid reference loops (and thus memory leaks). And that
> weakness occasionally results in crashes when one of these objects is
> collected before the other.
>
> While all modern HTML parser implementations I tested seemed to agree
> on their treatment of the above example (they all return "1" as
> elements.length), this feature doesn't strike me as terribly useful.
> And for what it's worth, it doesn't seem to be present in legacy IE.
>
> I'm interested what others would think about changing the parser to
> only associate a  with an  if both are in the same "home
> subtree" 
> (http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#home-subtree).
> Or is there some deep web-compat reason for this parsing oddity?
>
> - Adam

Re: [whatwg] remove resetClip from the Canvas 2D spec

[Tab Atkins Jr.]

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 current transform
> clip: save only the current clip
>
> if mode is not specified, the entire context state is saved (for backward
> compatibility)

This isn't very extensible.  You're missing some options, and if we
ever want to add more, we have to add more combination options as
well.

Better is to define a dictionary with keys of "transform" and "clip"
(+more?), whose values are bools.  Like you say, not passing the
dictionary is taken to mean "save everything".

~TJ

Re: [whatwg] remove resetClip from the Canvas 2D spec

[Justin Novosad]

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 specified, the entire context state is saved (for backward
compatibility)

The restore method's interface does not change. It restores whatever state
was saved by the matching save call.



On Mon, Aug 12, 2013 at 4:56 PM, Simon Sarris wrote:

> > 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 slow to set, probably because of some CSS parser
> activity, but I'm not wise enough to know.
>
> If there was merely a way to save and restore the context, or perhaps some
> other subset of state, that would probably work nicely too.
>
>
>
>
>
>

Re: [whatwg] remove resetClip from the Canvas 2D spec

[Simon Sarris]

> 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 slow to set, probably because of some CSS parser
activity, but I'm not wise enough to know.

If there was merely a way to save and restore the context, or perhaps some
other subset of state, that would probably work nicely too.

Re: [whatwg] remove resetClip from the Canvas 2D spec

[Justin Novosad]

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 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
 created the current state stack level?
 In other words, restore the clip, but without popping it off the
 save/restore stack.

>>>
>>> It would be good to hear specific use cases for 'resetClip' so we can
>>> make that call.
>>> I think your proposal could be made to work with Core Graphics.
>>>
>>
>> Agreed. I only had Simon Sarris's use case in mind (app uses reset
>> instead of save/restore for perf reasons) when I wrote that.
>>
>
> Simon's example tries to work around performance problems with
> save/restore.
> Wouldn't it be better to fix that? Why is a simple save/restore so slow?
>

Good point, I think part of the problem has to do with the fact that save
is non-selective (saves all of the state).
Might be worthwhile to have a selective save that pushes only a
user-specified subset of the current state onto the stack.


>
>
>>
>>
>>>
>>>
 Also, resetMatrix could be defined to do the same.
>>>
>>>
>>> Is that API defined somewhere?
>>>
>>
>> Sorry, I meant "resetTransform".  It is currently unimplemented in Blink.
>>
>>
>

Re: [whatwg] remove resetClip from the Canvas 2D spec

[Rik Cabanier]

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 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
>>> created the current state stack level?
>>> In other words, restore the clip, but without popping it off the
>>> save/restore stack.
>>>
>>
>> It would be good to hear specific use cases for 'resetClip' so we can
>> make that call.
>> I think your proposal could be made to work with Core Graphics.
>>
>
> Agreed. I only had Simon Sarris's use case in mind (app uses reset instead
> of save/restore for perf reasons) when I wrote that.
>

Simon's example tries to work around performance problems with save/restore.
Wouldn't it be better to fix that? Why is a simple save/restore so slow?


>
>
>>
>>
>>> Also, resetMatrix could be defined to do the same.
>>
>>
>> Is that API defined somewhere?
>>
>
> Sorry, I meant "resetTransform".  It is currently unimplemented in Blink.
>
>

Re: [whatwg] remove resetClip from the Canvas 2D spec

[Justin Novosad]

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?
>> >
>> >
>> What if resetClip restored the clip to what it was at the save call that
>> created the current state stack level?
>> In other words, restore the clip, but without popping it off the
>> save/restore stack.
>>
>
> It would be good to hear specific use cases for 'resetClip' so we can make
> that call.
> I think your proposal could be made to work with Core Graphics.
>

Agreed. I only had Simon Sarris's use case in mind (app uses reset instead
of save/restore for perf reasons) when I wrote that.


>
>
>> Also, resetMatrix could be defined to do the same.
>
>
> Is that API defined somewhere?
>

Sorry, I meant "resetTransform".  It is currently unimplemented in Blink.

Re: [whatwg] remove resetClip from the Canvas 2D spec

[Simon Sarris]

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 background and all of their children - and they contain any number
of Panels or TextBlocks or other elements, and TextBlocks set the context
font (to their font) and draw some text.

The drawing structure is hierarchical, and drawn elements may be offset
from their immediate parent. So a drawing hierarchy might look like this:

Panel(A)
Panel(B)
TextBlock
TextBlock

That is, Panel(A) contains Panel(B) and a TextBlock. And Panel(B) contains
another TextBlock. In practice, nesting could be much deeper and more
complicated.

Now suppose also that Panels have some settings, such as a maximum width,
that might cause their visual elements to be clipped. So a panel might need
to save(), clip(), draw all of its children, and then restore(). Nesting
means multiple levels of clipping, for instance with the above hierarchy it
might look like:

Panel(A)
clip (save)
drawChildren:
Panel(B)
clip (save)
drawChildren:
TextBlock
sets font X
fillText
restore
TextBlock
sets font X
fillText
restore

This is problematic, because it means:

1. I must use save() and restore(), which are slow in their own right
2. The usage of save() and restore() means that, even if all (or most) of
my fonts are set to the same value, I have to keep setting them over and
over. Setting the font is slow in practice, even if it is set to the same
value as before, and so it should be cached if at all possible. See:

http://jsperf.com/can-attribs
and
http://jsperf.com/cached-attributes

(fill/stroke styles should be cached too, but the performance diff is not
as drastic)

With a nested drawing structure,when using clipping, I am much less able to
cache the canvas font/fillStyle/strokeStyle. This hurts performance. It's
still possible, some of the time, but its harder to realize gains.

All the while this is happening I am translating, rotating, and scaling the
transformation matrix to position nested visual elements, but this is not a
problem since I can undo those either with setTransform or inverse
transforms, so they do not necessitate use of save() and restore().
Clipping has no such ability, to undo any clipping region I must clobber
the context state with a save and restore.

I hope that was clear. This is a real-world use case for a production
canvas diagramming library.

In general, junov's idea will work well for anyone who wants this because
they need to occasionally clip while keeping their webapp performant, since
those people are unlikely to be touching save() and restore() in the first
place.



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?
> > >
> > >
> > What if resetClip restored the clip to what it was at the save call that
> > created the current state stack level?
> > In other words, restore the clip, but without popping it off the
> > save/restore stack.
> >
>
> It would be good to hear specific use cases for 'resetClip' so we can make
> that call.
> I think your proposal could be made to work with Core Graphics.
>
>
> > Also, resetMatrix could be defined to do the same.
>
>
> Is that API defined somewhere?
>

Re: [whatwg] remove resetClip from the Canvas 2D spec

[Rik Cabanier]

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
> created the current state stack level?
> In other words, restore the clip, but without popping it off the
> save/restore stack.
>

It would be good to hear specific use cases for 'resetClip' so we can make
that call.
I think your proposal could be made to work with Core Graphics.


> Also, resetMatrix could be defined to do the same.


Is that API defined somewhere?

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

[Anne van Kesteren]

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 workers).


> 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 like StringToBytesConverter::convert() and
> BytesToStringConverter::convert() it would make more sense for encoding of
> both text (use StringToBytes) and binary data (use BytesToString).

I can't really speak for Gecko, but I suspect we wouldn't like
changing it over half a year after deploying it. Jonas?


> While we're re-opening this can of worms, there's been a request to add a
> flush() method to the TextEncoder/TextDecoder objects, which would behave
> the same as calling encode(null, {stream: false}) / decode(null,
> {stream:false}) but make the code more readable. This fails the "adding a
> new method for something that behaves exactly like something we already
> have" test. Opinions?

Adding that seems fine.


-- 
http://annevankesteren.nl/

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

[Joshua Bell]

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, which will be less confusing than reusing
> > TextDecoder/TextEncoder.
> >
>
> I disagree with the idea of adding a new method for something that behaves
> exactly like something we already have, just to give it a different name.
>
> (It may not be too late to rename those functions, if nobody has
> implemented them yet, but I'm not convinced it's much of a problem.)
>

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?

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 like StringToBytesConverter::convert() and
BytesToStringConverter::convert() it would make more sense for encoding of
both text (use StringToBytes) and binary data (use BytesToString).

While we're re-opening this can of worms, there's been a request to add a
flush() method to the TextEncoder/TextDecoder objects, which would behave
the same as calling encode(null, {stream: false}) / decode(null,
{stream:false}) but make the code more readable. This fails the "adding a
new method for something that behaves exactly like something we already
have" test. Opinions?

Re: [whatwg] inputmode feedback

[河内 隆仁]

+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 fuzzies, but is there really
> >> any semantic use we will get out of these that we wouldn't by using
> >> "lowercase", "titlecase" or "autocapitalized"?
> >
> > The reason I used the more "semantic" names is that the names like
> > "lowercase", "titlecase" or "autocapitalized" aren't accurate. For
> > example, you can hit shift in "lowercase" mode to get uppercase. You can
> > have a "titlecase" mode that doesn't capitalise every word (e.g. it
> > recognises the "van" in "van Kesteren"). A value that is explicitly for
> > names can use a different dictionary than one that is just for
> capitalised
> > text (e.g. derived from the user's contact list). And so on.
> >
> >
> >> I take it verbatim and name would disable any spelling corrections,
> >> and name would also titlecase? But the difference between text and
> >> prose seems really hard to understand.
> >
> > In the spec, "verbatim" does not correction at all, e.g. passwords;
> > "latin" is for human-to-computer communications, e.g. free-form text
> > search fields, and would do spelling correction and automatically
> > inserting spaces between words in swiping keyboards, etc; and
> > "latin-prose" is intended for human-to-human communications, with
> > aggressive automatic typing correction, e.g. text prediction and
> automatic
> > capitalisation at the start of sentences.
>
> I think a really important question is if this is understandable to
> authors. There's also a big risk that if these modes aren't noticeably
> different in initial implementations, it will be hard to add such
> differences later.
>
> / Jonas
>



-- 
Takayoshi Kochi