Re: [whatwg] Grouping in canvas 2d
Here another simple example: When both filling and stroking a path and then drawing it with with an opacity of less than 100%, the path will be rendered differently than in an SVG (a large stroke width will make the issue more apparent): - In Canvas, both the fill and the stroke will be rendered with the given opacity, and the fill will shine through the inner half of the stroke. - In SVG, the stroke will cover the fill, and the fill will not shine through the inner half of the stroke, regardless of the opacity. If you'd like to emulate the SVG behavior in Canvas (which we happen to do in Paper.js), then the only way to do so currently is to draw the path's fill and stroke at 100% opacity into a separate canvas, and then blit the whole thing over with the given opacity. This is *much* slower than directly drawing into the Canvas, and happens to be one of the worst bottlenecks in Paper.js I would really appreciate a solution to this problem. Jürg On Mar 14, 2014, at 19:09 , Ian Hickson i...@hixie.ch wrote: Can you elaborate on what precisely the performance bottleneck is? I was looking through this thread but I can't find a description of the use cases it addresses, so it's hard to evaluate the proposals.
Re: [whatwg] Various autocomplete= topics
On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson i...@hixie.ch wrote: Also, consider the case of login forms without username fields. You see this sort of thing a lot these days, when sites remember who was last logged in: form labelPassword for hober: input type=password name=pw/label pNot hober? a href=...Click here to sign in/a. /form It's difficult for tools to manage the user's auth info for such pages. How can tools discover what the username is? The obvious solution, in a world with autocomplete=username, would be to add input type=hidden autocomplete=username name=username value=hober to the form. So far, autocomplete= hasn't applied to input type=hidden. This would be a bit weird, giving it a different meaning than usual (providing information to the UA, rather than getting information from the UA). I'm a bit skeptical of this kind of overloading. Not sure what the right solution is, though. As Garrett noted, this is already a solution Google is using, though not with explicit syntax, just taking advantage of existing heuristics. Paving this (potential) cowpath isn't really that weird. That said, an alternative might be to add a mechanism of associating autocompletion metadata with the field in order to give the UA enough context to fill it in. For example, if a password is being requested for a known username, that username could be added as an new autocomplete-username attribute (similar to the 'data-*' construct HTML already supports): input type=password autocomplete-username=hober -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Various autocomplete= topics
[General point, so not quoting anyone in particular] [Resending to list, apologies to Ian] Why would you define any address components other than those in vCard, a standard with massive implementation and interoperable with most address book applications and services? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Effect on window.opener when navigating an existing window using window.open
On Wed, Apr 2, 2014 at 3:09 PM, Bob Owen bobowenc...@gmail.com wrote: On 2 April 2014 22:00, Ian Hickson i...@hixie.ch wrote: It's worth noting that there are many many ways to navigate a browsing context beyond window.open(), e.g. a target=, window.location, drag-and-drop of a link, window.history.go(), etc. Absolutely, if we were to converge on the spec for the current opener and people felt that last navigator would be useful, then it would need to be updated in all cases. Although, the history case might hold the original state. Anyway, getting way ahead of myself. I'll see if there are any more opinions, then look to move Gecko towards the spec and see if any compat issues arise. For what it's worth, I think we'd be open to changing Blink to match the spec as well, if you don't find any compat issues. Charlie
