Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
On Mon, 20 Aug 2012, Kevin Gadd wrote: Hi, I've been digging into an inconsistency between various browsers' Canvas implementations and I think the spec might be allowing undesirable behavior here. The current version of the spec says (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawimage): If the original image data is a bitmap image, the value painted at a point in the destination rectangle is computed by filtering the original image data. The user agent may use any filtering algorithm (for example bilinear interpolation or nearest-neighbor). When the filtering algorithm requires a pixel value from outside the original image data, it must instead use the value from the nearest edge pixel. (That is, the filter uses 'clamp-to-edge' behavior.) While clamp-to-edge is desirable, the way this is specified means that it only ever clamps to the edges of the source bitmap, not to the source rectangle. That means that attempting to do the equivalent of css sprites or video game style 'tile sets' - where a single source image contains many smaller images - is not possible, because the spec allows implementations to read pixels from outside the source rectangle. There's two ways to do scaled sprites with drawImage(): have a border of transparent black around each sprite, or copy the data out of the sprite sheet and into a temporary canvas at its original size, then scaling from that. Unfortunately, at present Internet Explorer and Firefox both read pixels from outside the source rectangle, as demonstrated by this test case: https://dl.dropbox.com/u/1643240/canvas_artifacts.html Worse still, in implementations with imageSmoothingEnabled available, turning off image smoothing is not sufficient to eliminate the artifacts. Disabling image smoothing will increase artefacts, that's kind of the point. :-) Having said that, I don't really see what that test case is demonstrating. Can you elaborate? Google Chrome appears to implement this the way you would probably want it to work - by clamping to the edges of the source rectangle, instead of the source image. I can't think of a good reason to prefer the current behavior over what Chrome does, and I haven't been able to find a reliable way to compensate for the current behavior. The reason to prefer the current behaviour is if you want to just update a small part of an image. For example, if you draw a bit photo, then draw text over it, then want to remove the text by just drawing the photo over where the text was but not redrawing the whole thing. If we clamped to source rectangle, we'd get artefacts in this case that couldn't be worked around (unlike the problems with scaling sprites, which can be worked around, albeit in a suboptimal fashion). On Mon, 20 Aug 2012, Justin Novosad wrote: The same artifact use to be present in Chrome not that long ago. When we fixed it, we chose to interpret original image data as meaning the part of the image data that is within the bounds of the of the source rectangle. I don't think this reading is consistent with the usage of the term original image data in the spec. It's pretty consistently used to mean the whole image. I've clarified the spec to make this even less ambiguous. Also, it makes more sense to do it that way. I think arguments could be made for both ways, but the problem is there's only a way to work around one of the ways. On Mon, 10 Sep 2012, Vladimir Vukicevic wrote: This is pretty tricky to get right -- there's just a general graphics problem in this case. There are valid use cases for both sampling outside and not sampling outside the source rectangle, as well as implementation issues for being able to do source rectangle clamping. For example, should you be able to take a source image and draw it scaled up using 4 rectangles (one for each quadrant) and have the result be equal to just doing it in one draw? Or take any random subimage (for example, for efficient updates of some destination) and draw it in. Right. At best, I think a new mode toggle or flag would be needed to allow you to select. I'd be happy to add a flag if it's something browser implementors want to support. Additionally, I think there's a related bug filed from a while ago about defining how to sample pixels that are outside of the source bounds -- do you clamp to edge, do you sample transparent black, etc. Fixing that bug is how the current text came to be, IIRC. On Mon, 10 Sep 2012, Justin Novosad wrote: You are referring to the fact that clamping modes only apply to texture borders in OpenGL and DirectX? That is not that big of a big deal, you can implement the clamp in a shader. I think Vladimir makes a good point that there are valid use cases for both ways. To summarize the issues: * clamping to source rect can cause filtering artefacts at
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
(Sorry if you get this twice. For some reason my first reply was bounced by the listserv?) On Mon, Dec 10, 2012 at 10:24 AM, Ian Hickson i...@hixie.ch wrote: There's two ways to do scaled sprites with drawImage(): have a border of transparent black around each sprite, or copy the data out of the sprite sheet and into a temporary canvas at its original size, then scaling from that. How big does the border of transparent black have to be? Maybe I'm reading the spec incorrectly, but given the way it's written, implementations would be free to make use of hardware mip-maps when rendering images, which would mean that when scaling down, values from arbitrarily far outside the source rectangle could get pulled in. Temporary canvases for every blit seems like it would imply a significant performance penalty, as well, but I haven't tested that technique - maybe it's okay. I do know that creating a large number of temporary canvases causes performance issues in IE. Disabling image smoothing will increase artefacts, that's kind of the point. :-) Having said that, I don't really see what that test case is demonstrating. Can you elaborate? If the test case is demonstrating the behavior I argue correct, the drawn images in the canvas at the bottom will not show any red pixels. Another arguably correct approach would be for red pixels only to appear with image smoothing enabled. It doesn't make sense even given the current spec for red pixels to appear when smoothing is disabled - if you're drawing with nearest neighbor sampling, the red pixels that appear in the current test case (in Firefox on Windows, at least) can only be there if partial pixels are being rendered, which shouldn't be possible using nearest neighbor. An acceptable compromise in this case, IMO, would be to at least require that pixels from outside the source rectangle are not read if image smoothing is disabled. The reason to prefer the current behaviour is if you want to just update a small part of an image. For example, if you draw a bit photo, then draw text over it, then want to remove the text by just drawing the photo over where the text was but not redrawing the whole thing. If we clamped to source rectangle, we'd get artefacts in this case that couldn't be worked around (unlike the problems with scaling sprites, which can be worked around, albeit in a suboptimal fashion). Using a clip seems like the right way to do that. If you want to update a subregion, set a clip to the region to update, and run the exact same drawing code you ran before. That would work regardless of the semantics defined for source rectangles, and be applicable for all drawing primitives, not just drawImage. I can see how the performance characteristics for canvas clips might be too awful for that to be viable, though, but in that case we're now arguing over which applications should get the bigger performance hit. In that scenario, I would strongly suggest that games should be the ones to get privileged performance since they're extremely performance dependent to begin with. I don't know what applications actually use that behavior, though, so maybe they're just as performance focused. -kg
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
On Mon, Dec 10, 2012 at 1:24 PM, Ian Hickson i...@hixie.ch wrote: The reason to prefer the current behaviour is if you want to just update a small part of an image. For example, if you draw a bit photo, then draw text over it, then want to remove the text by just drawing the photo over where the text was but not redrawing the whole thing. If we clamped to source rectangle, we'd get artefacts in this case that couldn't be worked around (unlike the problems with scaling sprites, which can be worked around, albeit in a suboptimal fashion). I disagree. There is an efficient workaround for updating a subregion of an image without getting filtering artifacts around the edges : use clipping to limit the update region On the other hand, the workaround to prevent color bleeding when using spritemap is much less efficient since it requires padding, which is wasteful by definition, and in cases where the sprite can be downsized, the padding margins may have to be very large. -Justin
Re: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online
On Fri, 24 Aug 2012, Josh Sharpe wrote: I have a manifest that looks something like this: CACHE MANIFEST # e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a /a/application.js /a/application.css NETWORK: * FALLBACK: / /offline Notably, it has a / /offline fallback section which is, obviously, a prefix for every page on my site. This is good, because the goal is to have my users redirected to what's at /offline when they navigate to www.mydomain.com while offline. Note that the Offline Application Cache feature is for Offline Applications, not Offline Sites. What you're trying to do here is not what appcache was designed to do. Also, it's not clear what you mean by offline. For the record, in the spec, offline includes I'm on wifi but there's a captive portal and I'm online but the server is broken. As the fallback section is a prefix for everything, it's a prefix for any url/path that results in an error condition such as a 404 or 500 response. These are cases where it's assumed that the server is broken, i.e. offline, and the cache is therefore used. It seems that the application cache, when it encounters an error state such as a 404 or 500, doesn't check to see if the browser is still in the 'online' state, and immediately falls over to the fallback section. It does check -- by definition, if it receives a 4xx or 5xx, it's assumed that the server is offline (broken). While online, I would expect my 4xx and 5xx page to be rendered normally. Offline Application Cache doesn't have a while online mode, it just always works as if you were offline and tries to get the data from the server while the server is able to respond. This is an important facet of how appcache works: it doesn't work online or work offline. It always acts in offline mode (or rather, always works in internet connection is flaky mode). Finally, the fallback section in my example is very typical of most examples I find in various docs, including the whatwg spec. I don't think I'm doing anything abnormal here. What's abnormal is having the user visit pages that return 4xx or 5xx error codes when there's no problem. :-) Should I design this differently or is there something missing from the spec? It's hard to know exactly without understanding more about your use case. Can you elaborate on what you're trying to do? We could just exclude 4xx (and maybe 5xx? Though that seems less reasonable) error codes from being considered offline for fallback- supported resources, if people are commonly linking people to missing pages intentionally (and don't want the problem hidden from users by having it fall back to locally-generated pages). But that seems like a weird thing to do... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for public data in drag events
On Thu, 30 Aug 2012, Trevor Burnham wrote: The main use case I have in mind is an interface where elements respond to the object being dragged. A common case is showing visual feedback depending on whether the element emitting a dragenter/dragover is a valid drop target for the object being dragged. Currently, this can only be done in response to the types attribute. Right, that's what the type is for. Using global state in tandem with the types attribute is a viable workaround for drags within a document, but an inelegant one. Indeed. The types are supposed to be the solution here. If something is a valid thing to drop, it should have a type that can be accepted, and vice versa. Are there use cases where this doesn't work somehow? It's also incompatible with multi-touch. Although no multi-touch implementation of the dnd spec currently exists (to my knowledge), the spec does not preclude multiple simultaneous drags, so this may be a concern in the future. On Thu, 30 Aug 2012, Bronislav Klu�~Mka wrote: If you want example of cross window, I can give you one, I was working on administration, where certain information were presented using the same DOM constructions but they can be inserted/placed in different views so I've created the application as a set of iframes. But while using DD I've run into similar problem (I had a treeview of categories and certain data from another iframe can be copied/moved to certain nodes, not every data to every node), I had to solve it by putting data information in drag data item type... Being able to access some complex data in e.g. dragover event would be peachy Could you elaborate on this? What information would you use in the dragover event that isn't just a type label? It seems to me like you'd just use the category as part of the type and then the datagrid would accept certain types in certain places. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
On Mon, Dec 10, 2012 at 11:03 AM, Justin Novosad ju...@chromium.org wrote: On Mon, Dec 10, 2012 at 1:24 PM, Ian Hickson i...@hixie.ch wrote: The reason to prefer the current behaviour is if you want to just update a small part of an image. For example, if you draw a bit photo, then draw text over it, then want to remove the text by just drawing the photo over where the text was but not redrawing the whole thing. If we clamped to source rectangle, we'd get artefacts in this case that couldn't be worked around (unlike the problems with scaling sprites, which can be worked around, albeit in a suboptimal fashion). I disagree. There is an efficient workaround for updating a subregion of an image without getting filtering artifacts around the edges : use clipping to limit the update region How is that an efficient workaround? It involves setting a clip, calling drawimge with a larger (complete?) image and then removing the clip. This seems much more expensive for such as common operation. (ie a game that wants to remove an animated character) On the other hand, the workaround to prevent color bleeding when using spritemap is much less efficient since it requires padding, which is wasteful by definition, and in cases where the sprite can be downsized, the padding margins may have to be very large. As Ian said, copying the sprite image to a non-scaled canvas first (which most games probably do anyway) works around the issue. There is no need for padding in that case.
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
I can't speak for the most common approach in HTML5 games, but using a temporary surface for drawing sprites is definitely not a common approach in non-canvas games. I've never seen it proposed before this thread for canvas dev, either, but I'm not an expert there. This is at least an area where someone who has a passing familiarity with graphics programming is not going to have their expectations met. One reason spritemaps get used is to reduce overhead when deploying game content. In that case, copying the individual images out is not a problem and it's no big deal that canvas is specified this way. Another reason is that in Direct3D and OpenGL, historically state changes have come at a significant cost, so putting all of your individual images into a single texture allows you to draw lots of objects with no state changes. While state changes are dramatically cheaper on modern hardware, they still aren't free. Of course, this doesn't necessarily apply to canvas backends, but that's part of why people do it. If, like me, you're building browser games that use WebGL where available and use canvas for fallback, it is basically impossible to convert your texture atlases/spritemaps into individual images because texture coordinates (and as a result, the canvas source rectangles used in fallback) can map to any part of the texture. Re: the efficiency of clips, I don't think you can state that it's 'much more expensive' unless you've tested it. The kind of clip he describes is absurdly fast on 3D hardware and built into both the Direct3D and OpenGL specs: http://msdn.microsoft.com/en-us/library/windows/desktop/bb147354%28v=vs.85%29.aspx http://www.opengl.org/sdk/docs/man/xhtml/glScissor.xml It should be possible to apply a similar technique to software canvas implementations, but I won't claim to know whether that's done. Canvas clipping in general is certainly more complicated, but what he described is not. I agree that using clips is a reasonable way to express that kind of rendering operation (especially since it simplifies the javascript you have to write) and it allows both of these use cases - spritemaps and subregion updates - to coexist. It's also not a safe assumption that subregion updates are common in games. Certainly any game using Direct3D, OpenGL or WebGL is unlikely to be doing subregion updates since typically your entire framebuffer is discarded by the GPU (or at least not reliable) after you swapbuffers/present. Doing partial updates requires extra effort to set up offscreen render targets and make copies of pixel data. I wouldn't be shocked if there are canvas-based games out there doing subregion updates, but I can't think of more than one or two that I've ever seen. If we're talking about optimizing for one use case over another, there should be data to support that it is the only important use case. Arguably, it should be possible to provide reasonable performance for both use cases here... -kg On Mon, Dec 10, 2012 at 1:04 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Dec 10, 2012 at 11:03 AM, Justin Novosad ju...@chromium.org wrote: On Mon, Dec 10, 2012 at 1:24 PM, Ian Hickson i...@hixie.ch wrote: The reason to prefer the current behaviour is if you want to just update a small part of an image. For example, if you draw a bit photo, then draw text over it, then want to remove the text by just drawing the photo over where the text was but not redrawing the whole thing. If we clamped to source rectangle, we'd get artefacts in this case that couldn't be worked around (unlike the problems with scaling sprites, which can be worked around, albeit in a suboptimal fashion). I disagree. There is an efficient workaround for updating a subregion of an image without getting filtering artifacts around the edges : use clipping to limit the update region How is that an efficient workaround? It involves setting a clip, calling drawimge with a larger (complete?) image and then removing the clip. This seems much more expensive for such as common operation. (ie a game that wants to remove an animated character) On the other hand, the workaround to prevent color bleeding when using spritemap is much less efficient since it requires padding, which is wasteful by definition, and in cases where the sprite can be downsized, the padding margins may have to be very large. As Ian said, copying the sprite image to a non-scaled canvas first (which most games probably do anyway) works around the issue. There is no need for padding in that case. -- -kg
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
On Mon, Dec 10, 2012 at 4:04 PM, Rik Cabanier caban...@gmail.com wrote: As Ian said, copying the sprite image to a non-scaled canvas first (which most games probably do anyway) works around the issue. There is no need for padding in that case. Yes, I am sure a lot of games do it already to work around the color bleeding problem but there is a performance cost to doing that. Couldn't we just make everyone happy by making the behavior controllable through a context attribute or an additional overload of drawImage that takes an extra argument?
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
On Mon, Dec 10, 2012 at 1:18 PM, Justin Novosad ju...@chromium.org wrote: On Mon, Dec 10, 2012 at 4:04 PM, Rik Cabanier caban...@gmail.com wrote: As Ian said, copying the sprite image to a non-scaled canvas first (which most games probably do anyway) works around the issue. There is no need for padding in that case. Yes, I am sure a lot of games do it already to work around the color bleeding problem but there is a performance cost to doing that. Couldn't we just make everyone happy by making the behavior controllable through a context attribute or an additional overload of drawImage that takes an extra argument? I assume this would only be for the 9 argument version of drawImage? FWIW I was curious why this bug doesn't show up in WebKit so I looked at the implementation. They actually catch cases where there's scaling of a portion of an image and special case it by copying the non-scaled image to a temporary canvas first: // When the image is scaled using high-quality interpolation, we create a temporary CGImage // containing only the portion we want to display. We need to do this because high-quality // interpolation smoothes sharp edges, causing pixels from outside the source rect to bleed // into the destination rect. See rdar://problem/6112909. It would be nice to see why the Safari folks added this code since it makes them inconsistent with the spec.
Re: [whatwg] gradient edge case
On Sat, 1 Sep 2012, Rik Cabanier wrote: Currently the canvas spec specifies the following: If x0 = x1 and y0 = y1, then the linear gradient must paint nothing. and If x0 = x1 and y0 = y1 and r0 = r1, then the radial gradient must paint nothing Why is this? At this point: it's what browsers (mostly) do. On Sat, 1 Sep 2012, David Dailey wrote: While on the topic, it seems like reflected linear gradients would be quite handy -- insert an edge into the stop-sequence and then reflect or repeat from there. Can't you just do that by listing the colours forwards and backwards? On Sat, 1 Sep 2012, Rik Cabanier wrote: Since Canvas has support for pattern, you could fairly easy emulate this behavior. I think it would be handy if you could add the 'reflect' idiom to patterns. Can't you just make the larger pattern and use that? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Quirks mode handling of rowspan=0
On Sun, 2 Sep 2012, Boris Zbarsky wrote: Per HTML5 spec, rowspan=0 should span to the end of the table section. WebKit seems to not implement this at all. Opera implements this in quirks and standards mode. Gecko implements this in standards mode only; in quirks mode, rowspan=0 is treated like rowspan=1. When we last tried to do the right thing in quirks mode, back in 2003 or so, we ran into site compatibility issues, hence the current setup. I don't know what Trident does here; worth testing. In any case, my suggestion is that in quirks mode, rowspan=0 not be supported. On Mon, 3 Sep 2012, Kang-Hao (Kenny) Lu wrote: IE seem to follow WebKit in every mode I tested with. (i.e. not support) On Thu, 6 Sep 2012, Simon Pieters wrote: greping for rowspan=\0\ in http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/ and http://dotnetdotcom.org/ I find the following pages being broken in Opera but working in Firefox/Chrome: http://www.persianv.com/ http://www.quicherchetrouve.be/index.php?r1=2an=3anb=239page=3 http://www.kvaak.fi/keskustelu/index.php?topic=1914.0 http://www.timekillerarcade.com/game.php?id=1941 http://www.elginisd.net/cgi-bin/calcium37.pl?CalendarName=David_SchmittOp=ShowItAmount=WeekNavType=BothType=ListDate=2008/8/1 I stopped after going through about half of the matches. All of these are quirks mode. I didn't find any that work in Opera/Firefox but are broken in Chrome (i.e. rely on it being unsupported in standards mode). I didn't find any that work in Opera but are broken in Firefox/Chrome (i.e. expect it to work in quirks mode). This is enough to convince me that the feature should not be supported in quirks mode. Done. On Mon, 3 Sep 2012, Jukka K. Korpela wrote: Generally, attempts at defining quirks mode would mean making it an alternate mode and will not be successful due to the wide variation across browsers and versions. It's called quirks for a reason. We have indeed created an alternate mode (two, actually). See the HTML spec, search for quirks. Specifically, as some browsers already support rowspan=0 in quirks mode, and some don't, you cannot ensure backwards compatibility no matter how you define it. Depends if UAs are willing to change quirks mode. By and large, they are. On Mon, 3 Sep 2012, Boris Zbarsky wrote: Yes, it does: once all browsers agree, the barrier to entry for new entrants is lower because they just need to implement the behavior everyone already agrees on. That's the dream! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] gradient edge case
On Mon, Dec 10, 2012 at 4:07 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 1 Sep 2012, Rik Cabanier wrote: Currently the canvas spec specifies the following: If x0 = x1 and y0 = y1, then the linear gradient must paint nothing. and If x0 = x1 and y0 = y1 and r0 = r1, then the radial gradient must paint nothing Why is this? At this point: it's what browsers (mostly) do. If this is consistently implemented, it's probably OK. This 'flicker' type of situations usually points to a problem with the model. On Sat, 1 Sep 2012, David Dailey wrote: While on the topic, it seems like reflected linear gradients would be quite handy -- insert an edge into the stop-sequence and then reflect or repeat from there. Can't you just do that by listing the colours forwards and backwards? On Sat, 1 Sep 2012, Rik Cabanier wrote: Since Canvas has support for pattern, you could fairly easy emulate this behavior. I think it would be handy if you could add the 'reflect' idiom to patterns. Can't you just make the larger pattern and use that yes, however it will be slower since the pattern has to be rendered two or four times. If you can reflect in x and y, you can calculate the pattern cell once and then have your hardware do the tiling.
Re: [whatwg] Cycles in anchored positioning
On Fri, Dec 7, 2012 at 3:58 PM, Matt Falkenhagen fal...@chromium.org wrote: How are cycles with magically aligned[1] elements resolved? For example, if a and b are dialogs and you do: a.show(b); b.show(a); I think an anchoring cycle can also occur if an element |a| is anchored to a descendent of an element anchored to |a|. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#magically-aligned This is a closely-related problem to what I ran into when writing up my proposal for Positioned Layout http://www.xanthir.com/blog/b48H0. The only correct answer is to do cycle-detection, and break the cycle at some predictable location. In Positioned Layout I used document order to figure out where to break the cycle, but here you have a nice temporal ordering already available - if a show() call would produce a cycle, it should instead act as if no anchor was provided. ~TJ
Re: [whatwg] Autocomplete and autofill features and feedback thereon
On Wed, 21 Nov 2012, Ilya Sherman wrote:
On Tue, Nov 20, 2012 at 5:17 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 16 Oct 2012, Ilya Sherman wrote:
The payment instrument type is almost certainly appropriate to add
-- it is included on almost every website that I've encountered that
includes payment card fields. It was an oversight on my part to
omit it from the initial proposal.
It's redundant data, the credit card number itself says what type it
is.
More importantly, I don't know how to store the information. What
values should we be expecting here? If a site has radio buttons v,
m and a, and another has a select with 4, 5, and 3, and
yet another has three buttons which set a type=hidden with the values
visa, mastercard and amex, how is the user agent to figure out
what's going on? This makes the magic needed around dates look
positively easy.
I agree that it's redundant data, but many websites ask for it
separately anyway. One common reason for this is that the website only
supports a subset of all possible credit card issuers -- for example,
many do not support DiscoverCard. While the site *could* theoretically
infer from the entered card number that the card is not supported, and
show the user an error, most sites instead force the user to select the
card type, and inform the user of unsupported card types by omitting
them from the list.
Regarding storing of the data: I think being able to fill the data is
more important than being able to store it. For example, Chrome stores
just the card number, and not the type; but Chrome supports filling the
type by inferring it from the stored card number. For filling the card
type, I think it's strictly easier than filling a select dropdown
containing country names, since localization issues don't come into play
as much. The user agent is presumably not going to be able to handle
*every* case; but in my experience, it's not too hard to handle
many/most of the real-world cases. Since this attribute is used just as
a hint, esoteric difficult cases don't seem like enough reason to omit
the card type as a known token in the spec.
Fair enough. Added.
Finally, I have gotten a request to include a field type for bank
account numbers, though I have only seen this info actually
requested on a small handful of extremely prominent (and generally
trusted) websites: Amazon, PayPal, and I think Google Wallet.
Is there any reason we shouldn't just treat bank accounts like just
another credit card, and use cc-number for these?
Yes: Most websites that support credit card numbers as inputs do not
support bank account numbers. The few websites that do support bank
account numbers use separate fields for these vs. credit card number
inputs. Labeling both fields identically would leave the browser unable
to distinguish which field to fill with what info.
Fair enough. So what do you need for bank account information? Account
number? Account holder name (and subproperties for that like for cc-*)?
Routing transit number? IBAN? SWIFT-BIC? I hesitate to do something US-
specific here; what do sites ask for in other countries? If it's always a
name, a bank number of some sort, and an account number, I can add those
three fields (plus the two name subfields) pretty easily.
On Wed, 31 Oct 2012, Dan Beam wrote:
The experimental implementation [1] has been updated to dispatch an
autocompleteerror as per convention/your feedback.
autocompleteerror seems like it'd be fired for an error, not user
cancelation. User cancelation is usually called either abort or
cancel. I think autocompletecancel is fine. It's consistent with
oncancel, which we used for dialog. (Fullscreen's error event is
for a slightly different case, based on what the spec says.)
There are also cases where we'd want to return actual errors. For
example, in Chrome, we are only planning to support this dialog for
sites served over HTTPS and without security errors. We might also want
to fire an error in case the input fails to pass the form's validation
requirements. Should we use autocompleteerror for the errors, and
autocompletecancel for user cancelations? Firing separate events for
cancelations vs. errors forces developers to check for each of these
cases separately, which seems like a less convenient API than just
checking for one sort of failure event. Perhaps we should have a single
event named something like autocompletefail or something like that?
autocompleteerror is fine.
On Wed, 21 Nov 2012, Dan Beam wrote:
I definitely agree to a single event. It would be great to do this and
give enumerable failure reasons (if this is deemed secure enough).
An example:
enum ErrorCause {
FROM_FRAME,
NEEDS_GESTURE,
NOT_SECURE,
};
This could be a property on the event (event.cause, event.reason?)
argument
Re: [whatwg] gradient edge case
On Mon, 10 Dec 2012, Rik Cabanier wrote: yes, however it will be slower since the pattern has to be rendered two or four times. If you can reflect in x and y, you can calculate the pattern cell once and then have your hardware do the tiling. If it's something that happens a lot, then certainly it makes sense to add it. But I've heard very few requests for this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Autocomplete and autofill features and feedback thereon
On Mon, Dec 10, 2012 at 7:49 PM, Ian Hickson i...@hixie.ch wrote: Finally, I have gotten a request to include a field type for bank account numbers, though I have only seen this info actually requested on a small handful of extremely prominent (and generally trusted) websites: Amazon, PayPal, and I think Google Wallet. Is there any reason we shouldn't just treat bank accounts like just another credit card, and use cc-number for these? Yes: Most websites that support credit card numbers as inputs do not support bank account numbers. The few websites that do support bank account numbers use separate fields for these vs. credit card number inputs. Labeling both fields identically would leave the browser unable to distinguish which field to fill with what info. Fair enough. So what do you need for bank account information? Account number? Account holder name (and subproperties for that like for cc-*)? Routing transit number? IBAN? SWIFT-BIC? I hesitate to do something US- specific here; what do sites ask for in other countries? If it's always a name, a bank number of some sort, and an account number, I can add those three fields (plus the two name subfields) pretty easily. I honestly haven't done enough research to answer these questions. I was mostly including this type for completeness, since several people mentioned it to me in offline discussion. However, since I'm not aware of any browsers that currently support or are planning to add support for autofilling bank account numbers, and I'm only aware of a handful of websites that request them, I'm ok with punting on this for now. If someone else has done the research and thinks it would be valuable to add this type to the spec, please do post here.
Re: [whatwg] Autocomplete and autofill features and feedback thereon
On Mon, 10 Dec 2012, Ilya Sherman wrote: On Mon, Dec 10, 2012 at 7:49 PM, Ian Hickson i...@hixie.ch wrote: Finally, I have gotten a request to include a field type for bank account numbers, though I have only seen this info actually requested on a small handful of extremely prominent (and generally trusted) websites: Amazon, PayPal, and I think Google Wallet. Is there any reason we shouldn't just treat bank accounts like just another credit card, and use cc-number for these? Yes: Most websites that support credit card numbers as inputs do not support bank account numbers. The few websites that do support bank account numbers use separate fields for these vs. credit card number inputs. Labeling both fields identically would leave the browser unable to distinguish which field to fill with what info. Fair enough. So what do you need for bank account information? Account number? Account holder name (and subproperties for that like for cc-*)? Routing transit number? IBAN? SWIFT-BIC? I hesitate to do something US- specific here; what do sites ask for in other countries? If it's always a name, a bank number of some sort, and an account number, I can add those three fields (plus the two name subfields) pretty easily. I honestly haven't done enough research to answer these questions. I was mostly including this type for completeness, since several people mentioned it to me in offline discussion. However, since I'm not aware of any browsers that currently support or are planning to add support for autofilling bank account numbers, and I'm only aware of a handful of websites that request them, I'm ok with punting on this for now. Ok, sounds good. If someone else has done the research and thinks it would be valuable to add this type to the spec, please do post here. Indeed. I'm happy to add this if browser vendors want to support it and we have good data on it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed
On Dec 3, 2012, at 11:19 PM, Adam Barth w...@adambarth.com wrote: On Mon, Dec 3, 2012 at 9:57 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 3, 2012, at 2:11 PM, William Chan (陈智昌) willc...@chromium.org wrote: Unless I am misunderstanding, SPDY will not solve this problem. SPDY uses prioritized multiplexing of streams. It seems to me like SPDY could make this case work better: script async src=path/to/script-part1.js/script script async src=path/to/script-part2.js/script script async src=path/to/script-part3.js/script Specifically the individual script chunks could be ordered and prioritized such that all of script-part1.js transfers before any of script-part3.js. That's harder to do with HTTP because the scripts could be loading on wholly separate HTTP connections, while SPDY will use one connection to the server. That being said, I do not know if SPDY will actually achieve this. Presumably it makes sense for it to serialize within a given priority level, at least a priority level that's likely to correspond to resources that are only atomically consumable, like scripts. But I don't know if SPDY implementations really do that. It also has disadvantage (3): ---8--- (3) This approach requires the author who loads the script to use different syntax than normally used for loading script. For example, this prevents this technique from being applied to the JavaScript libraries that Google hosts (as described by https://developers.google.com/speed/libraries/). ---8--- Yes, but I presumed that multiple script tags is less deviation than the iframe approach. Perhaps that is not the case. Note that in the case of systematically named parts, a single inline script could document.write() the relevant sequence of external script tags, if verbosity is the concern. But it would indeed be different. Do you expect the multipart idea would work with no syntax change in the markup currently embedding the libraries? If so, how? Content negotiation? UA sniffing? Regards, Maciej
Re: [whatwg] Canvas in Workers
discussion seems to have died down here but I'd like to bring up another
issue
In WebGL land we have creation attributes on the drawingbuffer made for a
canvas. Example
gl = canvas.getContext(webgl, { preserveDrawingBuffer: false });
We're working out the details on how to set those options for the case
where we have 1 context and multiple canvases.
The particular option above would apparently be a huge perf win for canvas
2d for mobile. Which suggests that whatever API is decided on it would be
nice if it worked for both APIs the same.
