Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Jul 24, 2013, at 7:19 AM, Rik Cabanier caban...@gmail.com wrote: On Tue, Jul 23, 2013 at 6:20 PM, Glenn Maynard gl...@zewt.org wrote: (The below is about Canvas only; I'm not very familiar with SVG. I think they should be two separate discussions.) Agreed. Sorry to confuse the issue. On Tue, Jul 23, 2013 at 6:19 PM, Rik Cabanier caban...@gmail.com wrote: we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ This happens because you offset 1 pixel and then draw a half pixel stroke on each side. Since it covers only half the pixel, the color gets mapped to 50% gray. You can work around this by doing an extra offset of half the devicepixelratio, For Canvas, you should always add 0.5, since you're in the canvas coordinate space, before the pixel ratio is applied. That seemed like an OK idea until I thought about it some more. Doing a .5 scale will also affect your fills so a rect will now have aliased borders. Also adjusting for non-round device pixel ratio or as Kornel mentions, having transforms will still result in blurry lines (unless you do a bunch of math) This is the same coordinate system used by OpenGL and Direct3D 10 (and up), with pixels centered around 0.5x0.5. That is, a pixel sits between 0x0 and 1x1. If you're specifying the center of the line (eg. where the stroke grows outwards from), you need to add a half pixel. (When you're specifying a bounding box, such as drawImage, you don't, since you're at the edge rather than the center of a pixel.) I'm not sure if there's a way to disable antialiasing for paths. Disabling antialiasing to allow people to specify wrong coordinates only seems like it would be more confusing, though. Disabling it is not a solution. The 'crispEdges' option does this and the results look bad. The only solution is to educate people about when and why they need to add a half pixel; even if there was a way to avoid this in general (I'm not sure there is, for an API with Canvas's functionality), it's much too late to change this. I agree that we can't change this, but maybe we can add something to make it better. In PDF there is a feature called strokeAdjust that will make the stroke align to pixel boundaries. Basically, if you turn it on strokeAdjust and the stroke doesn't fill the entire pixel, that pixel isn't drawn. If there's less than a pixel total, you expand the stroke to at least a pixel. Apple has a Core Graphics function called CGGStateSetStrokeAdjust so they would be able to implement this easily. :-) Means implementations would need to take viewport, transformations of the document, transformations on elements in the DOM hierarchy, zoom level, aspect ratio of the canvas, position of the canvas in the document, transformations in the canvas and device pixel resolution into account to snap lines to the correct position on the individual device, right?Otherwise it sounds to be hard to guarantee that you don't see antialiased strokes and lines might snap more then just one device pixel. This would also be a problem for aligning shapes to each other in the canvas I guess. What happens on the next transformation after a drawing operation. Say you draw a line that was snapped to the grid and then you do scale(1.1, 1.1). Shall the implementation redraw the canvas? After all it is an pixel image. A vector based drawing format would be better suited for such a task. Greetings, Dirk
Re: [whatwg] menu and friends
On Wed, Jul 24, 2013 at 12:45 AM, Ian Hickson i...@hixie.ch wrote: If the options are: - authors never use the feature - users lose their control over their browser - the feature has a complicated API ...then we're stuck in a bad place, certainly. But I don't think those are the only options; what about these, for instance: - authors use the feature anyway, and like that it gives users power - browsers default to showing mainly the author's menuitems, but offer a discoverable way for users to find more options if they need them Ok, the first of these two might be too optimistic, but the second should be workable, no? That's what the spec now suggests. I've added an example that shows how this could work: Before (only the author's commands): http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-collapsed.png After (the user having clicked a disclosure widget): http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-expanded.png I like it, it's a good compromise. Jan
Re: [whatwg] Modifying iframe sandbox attributes
On Mon, 22 Apr 2013, Tim Streater wrote: I need to add/remove the allow-scripts attribute to/from an iframe sandbox, since I use one frame for two purposes (sometimes with untrusted content, other times with my own content that uses JavaScript). I've tried the following: iframePtr.sandbox = allow-popups allow-same-origin allow-scripts; and: iframePtr.sandbox = allow-popups allow-same-origin; This doesn't appear to work in Safari 6.0.4. Is this the right syntax? Is such a possibility even implemented yet. It should work. Make sure you set them before you navigate the iframe, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Script-related feedback
On Wed, 9 Jan 2013, Anne van Kesteren wrote: On Wed, Jan 9, 2013 at 9:32 PM, Ian Hickson i...@hixie.ch wrote: Advantages of putting this in JS over multipart: - it's backwards-compatible - it's easier to parse a static barrier than a multipart/*'s wacky syntax. - it doesn't impact any of the current fetching logic, since it's still just one resource instead of introducing a layer in between script's logic and the JS logic. - it automatically works anywhere you can use JS, not just where HTTP is involved. - it can be shimmed more easily (if you trust the JS not to have arbitrary injection and be written with the shim in mind, especially). - it doesn't run into weird problems like what if a part has the wrong MIME type. - it's way easier to deploy (authors hate having to set MIME types). - it doesn't run into the problem that all UAs have historically ignored the MIME type of script. Adding magic meaning to certain JavaScript comments seems like a pretty big downside though. Furthermore, multipart logic, however weird, is a sunk cost both on consumer and producer side, whereas introducing /*@BREAK*/ seems like a very steep uphill battle. And actually img is a precedent for checking a MIME type before sniffing/executing and it hasn't been much of a problem. (The problems there were mostly figuring out how SVG should work.) Yeah, but the multipart logic has pretty big disadvantages -- mainly the opposite of the advantages for a built-in feature: - not backwards compatible - not as simple to understand, use, implement, or spec - doesn't really work outside HTTP - harder to shim - more edge cases to define (e.g. what if the MIME types of the parts change unexpectedly) - requires setting MIME types, which authors hate I think JavaScript would be the logical place to support this. We don't use multipart/* logic to do incremental rendering of HTML, we don't use it for incremental rendering of images (only for animating them), why would we use it for incremental execution of script? I think scripts, just like image formats, HTML, XML, etc, should have built-in support for incremental processing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Wed, Jul 24, 2013 at 6:20 AM, Glenn Maynard gl...@zewt.org wrote: On Tue, Jul 23, 2013 at 11:56 PM, Rik Cabanier caban...@gmail.com wrote: This happens because you offset 1 pixel and then draw a half pixel stroke on each side. Since it covers only half the pixel, the color gets mapped to 50% gray. You can work around this by doing an extra offset of half the devicepixelratio, For Canvas, you should always add 0.5, since you're in the canvas coordinate space, before the pixel ratio is applied. That seemed like an OK idea until I thought about it some more. Doing a .5 scale will also affect your fills so a rect will now have aliased borders. I meant you always want to add 0.5 to offsets, not ratio / 2. sorry, that was a typo. I meant to say 'translate(.5, .5)' will offset your fills. On a device with a pixel ratio of 2, you still want to add 0.5, not 1. You want to add 0.5 if you're drawing a 1px stroke, so the rect ends at 0.5 and the stroke extends to the edge of the pixel at 0. If you're drawing a filled rect with no stroke, you don't want to add 0.5, so the rect itself goes to the edge of the pixel rather than the stroke. That is very confusing. So, if there's a scale, you have to unapply the scale to the .5 offset? I agree this isn't all that obvious. What if there was an option for strokes to align themselves to the inside or outside of the path, instead of centering over the path? That way, drawing 5x5-10x10 would cause both the stroke and the edge of the fill to be pixel-aligned. This is Photoshop's Position stroke option, which can be set to inside, outside or center. I don't know if that makes sense with the way paths work, and it would make the stroke's path dependent on its width. That's a cool feature, but doesn't solve the problem. Users would still need to be aware that they need to align to whole pixels to stroke. Also adjusting for non-round device pixel ratio or as Kornel mentions, having transforms will still result in blurry lines (unless you do a bunch of math) Do you mean Canvas transforms or higher-level transforms, like CSS scaling? I don't think Canvas can help with the latter. Canvas transforms. I agree the resampling or transforming the canvas bitmap after the fact is not something we can control. Non-integer pixel ratios lead to all kinds of aliasing and quality problems. I suspect trying to fix them is futile... A lot of people have zoom turned on and there are quite a few devices that have non-integer pixel ratios. I'd like to solve the problem everywhere if possible. I agree that we can't change this, but maybe we can add something to make it better. In PDF there is a feature called strokeAdjust that will make the stroke align to pixel boundaries. I've attached a drawing that shows the feature. Basically, if you turn it on and the stroke doesn't fill the entire pixel, that pixel isn't drawn. Apple has a Core Graphics function called CGGStateSetStrokeAdjust so at least they would be able to implement this easily. :-) Isn't this simply disabling antialiasing? That's what the illustration seems to show. It tells the renderer not to use over-scan but center-scan for strokes. I was under the impression that GPU have centerscan by default and that implementors have to add a bunch of code to work around this. That'll work in certain cases, with the caveats that have been mentioned: you don't want it when animating lines, for diagonals, if you have rounded corners, etc. I *think* we still alias in certain cases. I will check.
Re: [whatwg] Script-related feedback
On Wed, Jul 24, 2013 at 11:18 AM, Ian Hickson i...@hixie.ch wrote: Yeah, but the multipart logic has pretty big disadvantages -- mainly the opposite of the advantages for a built-in feature: - not backwards compatible - not as simple to understand, use, implement, or spec - doesn't really work outside HTTP - harder to shim - more edge cases to define (e.g. what if the MIME types of the parts change unexpectedly) - requires setting MIME types, which authors hate I think JavaScript would be the logical place to support this. We don't use multipart/* logic to do incremental rendering of HTML, we don't use it for incremental rendering of images (only for animating them), why would we use it for incremental execution of script? I think scripts, just like image formats, HTML, XML, etc, should have built-in support for incremental processing. Given module loaders, new features to control script loading from HTML (in parallel thread) and lack of interest from implementers in this feature since it was last discussed we should probably hold off on this. -- http://annevankesteren.nl/
Re: [whatwg] Stack trace in window.onerror
On Fri, 12 Jul 2013, James Greene wrote: On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 5 Feb 2013, Nathan Broadbent wrote: The current information passed to window.onerror rarely provides sufficient information to find the cause of the error. The column number argument will be a big step forward, but a stack trace would be especially useful. I would like to add my support for improving the window.onerror arguments, with a fifth argument for stack trace. Is there anything that James or I could do to move this discussion along? This seems useful, but I don't think it's specific to window.onerror. I would recommend approaching the es-discuss list about this. I'm curious: would do you say that? All evergreen browsers already include a `stack` property on their core `Error` prototypes, so it seems to me that the only thing preventing us from getting that useful information for unhandled errors is the fact that `window.onerror` does not provide us with a real Error object instances (or even fake ones with shell properties in the case of cross-domain errors). Ah, I was unaware of Error.stack. Interesting! I've added a fifth argument to onerror, which has the exception object. On Fri, 12 Jul 2013, James Greene wrote: I'd rather get an Error-like duck-typed object with this shell info for cross-domain requests than to not get a real Error object when the unhandled error *is* from the same origin. For the cross-origin case, I've set error to null. Adding the trace as another new argument to `window.onerror` is certainly an option but the parameter list is getting long and I suspect that Error prototypes may still gain additional properties in the future. Yeah, exposing the error itself seemed better. On Fri, 12 Jul 2013, Elliott Sprehn wrote: Can we just add a new event that takes an event object instead of a huge list of arguments? :) There's already an event. You can get it if you use addEventListener() for 'error' rather than using onerror. (It's also exposed on the event object, for those of you using addEventListener() for error events rather than onerror.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Outline style to use for drawSystemFocusRing
I'm looking into implementing drawSystemFocusRinghttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawsystemfocusringin Blink, but it's unclear what style to use when drawing the focus ring - i.e. the color, thickness, etc., assuming that the user hasn't overridden it for accessibility. Here are some possible interpretations: 1. Hard-code default values. I don't think this would be ideal, since it wouldn't necessarily match the focus color of other elements that get the focus color from the system. 2. Get them from the default style of a generic element (which may match the system focus style). This could work, but I think this is less flexible for developers - if they picked a custom outline color for every other element in their site but would have no way to override it for canvas (other than using drawCustomFocusRing). 3. Get them from the outline style of the canvas element. This means every focus ring within the canvas would be the same, but otherwise I have no objection. 4. Get them from the outline style ofelement passed to drawSystemFocusRing. This is my preference. - Dominic
Re: [whatwg] Stack trace in window.onerror
On Wed, Jul 24, 2013 at 2:50 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 12 Jul 2013, James Greene wrote: On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 5 Feb 2013, Nathan Broadbent wrote: The current information passed to window.onerror rarely provides sufficient information to find the cause of the error. The column number argument will be a big step forward, but a stack trace would be especially useful. I would like to add my support for improving the window.onerror arguments, with a fifth argument for stack trace. Is there anything that James or I could do to move this discussion along? This seems useful, but I don't think it's specific to window.onerror. I would recommend approaching the es-discuss list about this. I'm curious: would do you say that? All evergreen browsers already include a `stack` property on their core `Error` prototypes, so it seems to me that the only thing preventing us from getting that useful information for unhandled errors is the fact that `window.onerror` does not provide us with a real Error object instances (or even fake ones with shell properties in the case of cross-domain errors). Ah, I was unaware of Error.stack. Interesting! There is no static property with the name stack on the [[Global]] built-in Error object, nor is the property added to Error.prototype. In v8, SpiderMonkey and JSC, the stack property appears on the actual instance object initialized by Error. Rick
Re: [whatwg] Stack trace in window.onerror
Rick — Thanks for clarifying/correcting both my comment and Hixie's! Sincerely, James Greene On Wed, Jul 24, 2013 at 4:24 PM, Rick Waldron waldron.r...@gmail.comwrote: On Wed, Jul 24, 2013 at 2:50 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 12 Jul 2013, James Greene wrote: On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 5 Feb 2013, Nathan Broadbent wrote: The current information passed to window.onerror rarely provides sufficient information to find the cause of the error. The column number argument will be a big step forward, but a stack trace would be especially useful. I would like to add my support for improving the window.onerror arguments, with a fifth argument for stack trace. Is there anything that James or I could do to move this discussion along? This seems useful, but I don't think it's specific to window.onerror. I would recommend approaching the es-discuss list about this. I'm curious: would do you say that? All evergreen browsers already include a `stack` property on their core `Error` prototypes, so it seems to me that the only thing preventing us from getting that useful information for unhandled errors is the fact that `window.onerror` does not provide us with a real Error object instances (or even fake ones with shell properties in the case of cross-domain errors). Ah, I was unaware of Error.stack. Interesting! There is no static property with the name stack on the [[Global]] built-in Error object, nor is the property added to Error.prototype. In v8, SpiderMonkey and JSC, the stack property appears on the actual instance object initialized by Error. Rick
Re: [whatwg] HTML: A DOM attribute that returns the language of a node
On Jul 16, 2013, at 11:25 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 16 Jul 2013, Takayoshi Kochi ($B2OFb(B $BN4?N(B) wrote: IIUC WebKit uses internally node's language to determine which font to use to render text, e.g for Han unification (https://en.wikipedia.org/wiki/Han_unification) WebKit has to choose a proper glyph depending on its lang attribute for the same Unicode codepoint. Sure, but internal UA uses aren't use cases for the Web. The use cases Peter gave over the weekend are valid, though. The fact browsers use the effective language for font selection is very relevant in HTML editing. For example, consider the following document: !DOCTYPE html html lang=ja html body section lang=zh p id=source$BANV}$(D7q(B/p /section blockquote p id=destination/p /blockquote /body /html If you were to get the innerHTML of #source and insert it into #destination, the effective language changes from Chinese and Japanese and the three characters transform their shapes because browsers will use different fallback fonts. - R. Niwa
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
While I'm not familiar with the spec for DocumentFragments, I've always consider them to be more equivalent to a detached element node than a document node. Keeping that interpretation in mind, adding these methods wouldn't make sense to me personally. Unless my understanding is completely off-base and fragments *are* supposed to be most similar to document nodes, I'd agree with the earlier suggestion that those who want this functionality should just add it themselves via JS. Sincerely, James Greene On Wed, Jul 24, 2013 at 7:39 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 28, 2013, at 5:32 PM, Zirak A zi...@mail.com wrote: But that's a bit looking at it backwards. Selectors are supposed to be an abstraction over these methods, not the other way around. No. The point here is that document fragments are documents - so they should have a consistent API. No. Adding this isn't about backwards compatibility or anything of the sort. It's adding methods that people already use, because as said, not everyone uses selectors (and not just because of browser-compat). getElementById is okay but we want to discourage authors from using methods like getElementsByTagName and getElementsByClassName that return live NodeList objects. They incur a lot of implementation cost in WebKit and hurts the DOM performance. e.g. whenever there is a LiveNode list somewhere in a document, WebKit walks up all ancestors of an inserted or removed element to clear their live node lists' caches. On Jun 29, 2013, at 3:47 PM, Glenn Maynard gl...@zewt.org wrote: On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater t...@clothears.org.uk wrote: But what I'm doing, I'm not doing for CSS purposes. I'm trying to find a particular row, by id, in order to modify the contents of cells in that row. I find it perverse to be using a style-related API call to do that. CSS uses selectors, not the other way around. querySelector() has nothing to do with styles. Indeed. Note that querySelector implementations in WebKit and Blink optimize #foo, .foo, etc... so that they're equally if not faster than getElementsById, getElementsByClassName, etc... - R. Niwa
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Wed, Jul 24, 2013 at 4:54 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jul 24, 2013 at 1:25 PM, Rik Cabanier caban...@gmail.com wrote: sorry, that was a typo. I meant to say 'translate(.5, .5)' will offset your fills. (All I meant in the first place was that the pixel ratio isn't a factor here. Maybe it's SVG that needs the ratio-dependent adjustment.) That is very confusing. So, if there's a scale, you have to unapply the scale to the .5 offset? If there's a scale, the width of the stroke is going to be scaled too. In that case, you either have to do adjustments across the board (no translation is going to make a 0.9-pixel stroke fill a pixel), or you need to do something like disabling antialiasing. I agree this isn't all that obvious. What if there was an option for strokes to align themselves to the inside or outside of the path, instead of centering over the path? That way, drawing 5x5-10x10 would cause both the stroke and the edge of the fill to be pixel-aligned. This is Photoshop's Position stroke option, which can be set to inside, outside or center. I don't know if that makes sense with the way paths work, and it would make the stroke's path dependent on its width. That's a cool feature, but doesn't solve the problem. Users would still need to be aware that they need to align to whole pixels to stroke. It solves the problem that it's a bit of a pain to have to supply edge-aligned coordinates when you're filling and centered coordinates when you're using a 1px stroke. It eliminates the need to do any half-pixel offsetting at all in a lot of cases. Do you mean Canvas transforms or higher-level transforms, like CSS scaling? I don't think Canvas can help with the latter. Canvas transforms. I agree the resampling or transforming the canvas bitmap after the fact is not something we can control. Non-integer pixel ratios lead to all kinds of aliasing and quality problems. I suspect trying to fix them is futile... A lot of people have zoom turned on and there are quite a few devices that have non-integer pixel ratios. I'd like to solve the problem everywhere if possible. If zoom is on, then that's the above: a compositing-stage transform that happens after rendering, which Canvas probably can't help with. If you have a non-integer pixel ratio, and no HD canvas backing store (it sounds like those may be getting dropped), then that seems like the same issue: the canvas will be rescaled at compositing time and there's nothing Canvas itself can do to prevent blurriness. (The developer could still work around it by hand, by using a higher-resolution Canvas so the backing store doesn't actually get resized at compositing time. They'll need to do this anyway, or everything will be blurry, not just strokes.) Yes, that's what I had in mind: the developer detects the device pixel ratio and scales up the canvas so the pixels match. In PDF there is a feature called strokeAdjust that will make the stroke align to pixel boundaries. I've attached a drawing that shows the feature. Basically, if you turn it on and the stroke doesn't fill the entire pixel, that pixel isn't drawn. Apple has a Core Graphics function called CGGStateSetStrokeAdjust so at least they would be able to implement this easily. :-) Isn't this simply disabling antialiasing? That's what the illustration seems to show. It tells the renderer not to use over-scan but center-scan for strokes. I was under the impression that GPU have centerscan by default and that implementors have to add a bunch of code to work around this. I don't follow the terminology, but from your image and description (If there's less than a pixel total, you expand the stroke to at least a pixel, that sounds like disabling antialiasing (maybe only for certain lines). It's more that the pixel is shrunk but is clamped to at least 1 pixel. I asked our rendering people and it sounds like the feature is implemented quite as described in the book. I'm still trying to find out the details... That'll work in certain cases, with the caveats that have been mentioned: you don't want it when animating lines, for diagonals, if you have rounded corners, etc. I *think* we still alias in certain cases. I will check. You could get more complex and turn off antialiasing for lines that aren't exactly vertical or horizontal. I suspect that would cause odd issues; for example, seams at the boundary between a horizontal line and a rounded edge, or a rounded edge being dimmer than the hard edges it connects. (I also don't know enough about paths and their implementations to know how feasible this is.) Yeah, it's quite complex. It sounds complex and with its own problems, and the only case where it might help is if you want to draw hard lines after calling canvas.scale(0.9, 0.9), which seems uncommon to me. In all typical cases, being able to set strokes to
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, Jul 25, 2013 at 3:39 AM, Ryosuke Niwa rn...@apple.com wrote: getElementById is okay but we want to discourage authors from using methods like getElementsByTagName and getElementsByClassName that return live NodeList objects. They incur a lot of implementation cost in WebKit and hurts the DOM performance. e.g. whenever there is a LiveNode list somewhere in a document, WebKit walks up all ancestors of an inserted or removed element to clear their live node lists' caches. Argh, I had forgotten about live NodeLists. OK, this is a reason that resonates with me and justifies calling these methods obsolete. Too bad these methods are so badly flawed and that it's not worth the cost to try to fix those methods to return something other than a live NodeList. As for getElementById(), I'm not sure how useful that is by itself. Cheers, Jussi On Jun 29, 2013, at 3:47 PM, Glenn Maynard gl...@zewt.org wrote: On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater t...@clothears.org.uk wrote: But what I'm doing, I'm not doing for CSS purposes. I'm trying to find a particular row, by id, in order to modify the contents of cells in that row. I find it perverse to be using a style-related API call to do that. CSS uses selectors, not the other way around. querySelector() has nothing to do with styles. Indeed. Note that querySelector implementations in WebKit and Blink optimize #foo, .foo, etc... so that they're equally if not faster than getElementsById, getElementsByClassName, etc... - R. Niwa
