Re: [whatwg] Simplified picture element draft
This is a part of the proposal that got people excited. The linked document defines picture's source selection algorithm. It contains some parts that I'm not sure have a consensus around them yet: * It defines picture as controlling img, where earlier on this list we discussed mostly the opposite (img querying its parent picture, if one exists) * It defines img as a part of picture's shadow DOM, which we need to see how it fits with having fallback img elements (which are necessary in the near future). This proposal does contain srcset as a subcomponent, but it's not the same srcset as defined in the HTML spec, but a modified version based on improvements from the src-N spec. (that cover the variable-width images use-case) The proposal will also require some changes to img and specifically, when not created by JS, img will have to avoid loading of resources until the element is added to the DOM, and can see if its direct parent is picture. If the parent is picture, img would then query the parent (or wait to be controlled by its parent), otherwise, it'll load its resources as usual. On Mon, Nov 25, 2013 at 8:33 AM, Adam Barth w...@adambarth.com wrote: I'm trying to sort out from the many messages on this topic which proposal I should read in detail. Is the one linked below the one that people are most excited about? I'm I correct in understand that this proposal contains srcset as a subcomponent? Thanks, Adam On Sat, Nov 23, 2013 at 3:04 PM, Kornel Lesiński kor...@geekhood.net wrote: I've written down proposal for the simplified source selection algorithm: http://geekhood.net/picture-element.html This also includes variant of the idea from the recent picture redux proposal to use an actual img element as the basis for the picture element definition. This draft doesn't include all features of src-N *yet*, but I expect this to be added either via extended srcset syntax to something like source sizes once there's consensus how to approach this. To simplify implementation even further I've allowed UAs to flatten fallback DOM to a plaintext string (in case they need to emulate img alt for existing screen readers or accessibility APIs). I've dropped usemap. It could be added, but I'm not sure if there is need for it. I've specified very few IDL attributes. This area may need to be extended. -- regards, Kornel
Re: [whatwg] Simplified picture element draft
On 25 November 2013 08:00:10 Yoav Weiss y...@yoav.ws wrote: It contains some parts that I'm not sure have a consensus around them yet: * It defines picture as controlling img, where earlier on this list we discussed mostly the opposite (img querying its parent picture, if one exists) Controlling image is a great idea. It greatly simplifies the spec and hopefully implementations as well. I chose not to expose that implementation detail, assuming that one day (when all UAs, crawlers implement it) we will not need explicit img fallback any more. If picture was explicitly controlled by img then websites could start depending on that behavior, and we'd be stuck with it. OTOH picture can have native DOM interface and still reuse img for implementation. * It defines img as a part of picture's shadow DOM, which we need to see how it fits with having fallback img elements (which are necessary in the near future). I've added section about preloader. The img in fallback content should be ignored by the preloader. It's purely for picture-less UAs. I do wonder however if fallback img should be used as equivalent of a source to save authors a bit of repetition. (in selection algorithm the first step would be for each source or img child...) or perhaps be used as last-resort fallback when no source matches (step 2 of the algorithm). This proposal does contain srcset as a subcomponent, but it's not the same srcset as defined in the HTML spec, but a modified version based on improvements from the src-N spec. (that cover the variable-width images use-case) Indeed. This part of the spec isn't ironed out yet. The proposal will also require some changes to img and specifically, when not created by JS, img will have to avoid loading of resources until the element is added to the DOM, and can see if its direct parent is picture. If the parent is picture, img would then query the parent (or wait to be controlled by its parent), otherwise, it'll load its resources as usual. I've specified something like that. I think it can be as simple as a flag that preload scanner uses internally. I think we don't need to add any runtime behavior changes for this, as scripts constructing picture will not insert explicit fallback img node - it makes more sense to rely on picture polyfill instead (that will use img with correct src from the start). -- regards, Kornel
Re: [whatwg] Simplified picture element draft
On Mon, Nov 25, 2013 at 11:32 AM, Kornel Lesiński kor...@geekhood.netwrote: On 25 November 2013 08:00:10 Yoav Weiss y...@yoav.ws wrote: It contains some parts that I'm not sure have a consensus around them yet: * It defines picture as controlling img, where earlier on this list we discussed mostly the opposite (img querying its parent picture, if one exists) Controlling image is a great idea. It greatly simplifies the spec and hopefully implementations as well. I'm not saying it isn't, but it's not what we previously discussed on the list. I chose not to expose that implementation detail, assuming that one day (when all UAs, crawlers implement it) we will not need explicit img fallback any more. If picture was explicitly controlled by img then websites could start depending on that behavior, and we'd be stuck with it. OTOH picture can have native DOM interface and still reuse img for implementation. I believe these interfaces would be something you'd need to test, so you would have testing duplication, even if you save code duplication. I'm not sure that the goal of getting rid of img 5-10 years from now, is worth that cost. * It defines img as a part of picture's shadow DOM, which we need to see how it fits with having fallback img elements (which are necessary in the near future). I've added section about preloader. The img in fallback content should be ignored by the preloader. It's purely for picture-less UAs. The problem here is not the preloader, but the HTMLImageElement itself, which currently downloads a resource upon creation. With that said, it's an issue we'd have to deal with in both cases, regardless of which element controls which, and if picture has the control, we can probably define that it controls only the first/last img it encounters. I do wonder however if fallback img should be used as equivalent of a source to save authors a bit of repetition. (in selection algorithm the first step would be for each source or img child...) or perhaps be used as last-resort fallback when no source matches (step 2 of the algorithm). I agree that it would make sense for authors. This proposal does contain srcset as a subcomponent, but it's not the same srcset as defined in the HTML spec, but a modified version based on improvements from the src-N spec. (that cover the variable-width images use-case) Indeed. This part of the spec isn't ironed out yet. The proposal will also require some changes to img and specifically, when not created by JS, img will have to avoid loading of resources until the element is added to the DOM, and can see if its direct parent is picture. If the parent is picture, img would then query the parent (or wait to be controlled by its parent), otherwise, it'll load its resources as usual. I've specified something like that. I think it can be as simple as a flag that preload scanner uses internally. Again, this is an issue with HTMLImageElement itself, not the preload scanner. It'd probably require modifications to the img section of the HTML spec. I think we don't need to add any runtime behavior changes for this, as scripts constructing picture will not insert explicit fallback img node - it makes more sense to rely on picture polyfill instead (that will use img with correct src from the start). -- regards, Kornel
Re: [whatwg] Simplified picture element draft
On 25/11/13 10:32, Kornel Lesiński wrote: On 25 November 2013 08:00:10 Yoav Weiss y...@yoav.ws wrote: It contains some parts that I'm not sure have a consensus around them yet: * It defines picture as controlling img, where earlier on this list we discussed mostly the opposite (img querying its parent picture, if one exists) Controlling image is a great idea. It greatly simplifies the spec and hopefully implementations as well. I chose not to expose that implementation detail, assuming that one day (when all UAs, crawlers implement it) we will not need explicit img fallback any more. This suffers from some of the same problems that were previously brought up with picture; because it defines a new element that should behave like img you have to test that the new element works in all the same places that img ought to work. The fact that the spec tries to define this in terms of the shadow DOM isn't really helpful; you still need to ensure that implementations actually proxy the underlying img correctly in all situations. The advantage of the scheme that zcorpan proposed is that there is no magic proxy; we just add a capability to img to select its source using more than just a src attribute. This has better fallback than your design and is easier to implement.
Re: [whatwg] Simplified picture element draft
On 25 November 2013 10:59:15 Yoav Weiss y...@yoav.ws wrote: On Mon, Nov 25, 2013 at 11:32 AM, Kornel Lesiński kor...@geekhood.netwrote: If picture was explicitly controlled by img then websites could start depending on that behavior, and we'd be stuck with it. OTOH picture can have native DOM interface and still reuse img for implementation. I believe these interfaces would be something you'd need to test, so you would have testing duplication, even if you save code duplication. Yes, you need to test the integration point, but you only need to test that assignment of one attribute affects the other. You don't need to repeat tests that test it deeper. I do wonder however if fallback img should be used as equivalent of a source to save authors a bit of repetition. (in selection algorithm the first step would be for each source or img child...) or perhaps be used as last-resort fallback when no source matches (step 2 of the algorithm). I agree that it would make sense for authors. Which variant you think is better? I've specified something like that. I think it can be as simple as a flag that preload scanner uses internally. Again, this is an issue with HTMLImageElement itself, not the preload scanner. It'd probably require modifications to the img section of the HTML spec. I believe it won't be an issue in the approach I've specified - when the fallback img is separate from controlling image. Scripts can avoid creating fallback img at all, because when scripting is enabled they will use polyfill and can treat all UAs as supporting picture. In that case fallback img would be like document.write(noscript) ;) Maybe the spec should have authoring guidelines for this? The controlling image starts with no src, so it won't download anything that wasn't deliberately chosen through picture. -- regards, Kornel
Re: [whatwg] Simplified picture element draft
The advantage of the scheme that zcorpan proposed is that there is no magic proxy; we just add a capability to img to select its source using more than just a src attribute. This has better fallback than your design and is easier to implement. I believe that from testing perspective both approaches are equivalent. The spec I propose *is* only another way to control src of an image. The only difference is that I don't expose the img to scripts. That may make it even simpler, because you can't have odd cases like author moving/removing the controlling img or setting values directly on img that conflict with picture's definitions. -- regards, Kornel
Re: [whatwg] Alignment of empty buttons
On 11/25/13 12:59 AM, Ian Hickson wrote:
It's more like svg:g. The CSS model just doesn't apply. Even in Firefox,
it's not really CSS that's working there. It's some weird proprietary
variant.
It's really not, once you have a DOM and are inside option.
I mean, as you've pointed out, child nodes of the select that
aren't option or optgroup are mysteriously hidden
That's select, not option.
but also, the option elements obey some values of 'display' but don't obey
e.g.
'position' or 'float';
That's pure CSS: it's a !important rule in a UA stylesheet. I guess you
could claim that supporting !important in a UA stylesheet is a
proprietary extension, albeit one that's in the process of being specified.
'white-space' doesn't seem to work right in a select or option;
option { white-space: nowrap !important; }
in UA stylesheet.
the height of the select seems to be based in some
weird way on the height of some of the options...
That's about select, not option.
in the drop-down mode, it's even worse
My comments were specifically about option in a listbox. A combobox
is a different and more complicated story (though even there the layout
of the option itself is pure CSS in Gecko).
Put another way, there is no custom layout code for option in Gecko.
It's all done entirely by the CSS renderer, based on the computed values
of CSS properties for the element. Some of those computed values come
from !important rules in a UA stylesheet, but that's it.
(By the way, in testing this, I discovered option label isn't supported
in Firefox.
That's correct. https://bugzilla.mozilla.org/show_bug.cgi?id=40545
HTH. Also ::first-line on a display:table-row doesn't seem to be work,
though I couldn't tell if that was per-spec or not. It doesn't seem to
work for regular divs either.)
::first-line on a display:table-row shouldn't work in Gecko right now,
yes. Whether it's per-spec depends on which spec you're reading and the
phase of the moon. ;)
It should work on a block, of course, and does in my testing.
-Boris
Re: [whatwg] Simplified picture element draft
Thanks Yoav. Tab asked me to provide some more feedback to this list, but it's hard to tell from the lengthy discussion what proposal folks are most interested in. Is there an editor's draft or some other relatively self-contained write-up that I could review? Thanks, Adam On Mon, Nov 25, 2013 at 12:00 AM, Yoav Weiss y...@yoav.ws wrote: This is a part of the proposal that got people excited. The linked document defines picture's source selection algorithm. It contains some parts that I'm not sure have a consensus around them yet: * It defines picture as controlling img, where earlier on this list we discussed mostly the opposite (img querying its parent picture, if one exists) * It defines img as a part of picture's shadow DOM, which we need to see how it fits with having fallback img elements (which are necessary in the near future). This proposal does contain srcset as a subcomponent, but it's not the same srcset as defined in the HTML spec, but a modified version based on improvements from the src-N spec. (that cover the variable-width images use-case) The proposal will also require some changes to img and specifically, when not created by JS, img will have to avoid loading of resources until the element is added to the DOM, and can see if its direct parent is picture. If the parent is picture, img would then query the parent (or wait to be controlled by its parent), otherwise, it'll load its resources as usual. On Mon, Nov 25, 2013 at 8:33 AM, Adam Barth w...@adambarth.com wrote: I'm trying to sort out from the many messages on this topic which proposal I should read in detail. Is the one linked below the one that people are most excited about? I'm I correct in understand that this proposal contains srcset as a subcomponent? Thanks, Adam On Sat, Nov 23, 2013 at 3:04 PM, Kornel Lesiński kor...@geekhood.net wrote: I've written down proposal for the simplified source selection algorithm: http://geekhood.net/picture-element.html This also includes variant of the idea from the recent picture redux proposal to use an actual img element as the basis for the picture element definition. This draft doesn't include all features of src-N *yet*, but I expect this to be added either via extended srcset syntax to something like source sizes once there's consensus how to approach this. To simplify implementation even further I've allowed UAs to flatten fallback DOM to a plaintext string (in case they need to emulate img alt for existing screen readers or accessibility APIs). I've dropped usemap. It could be added, but I'm not sure if there is need for it. I've specified very few IDL attributes. This area may need to be extended. -- regards, Kornel
Re: [whatwg] High-density canvases
On Tue, 10 Sep 2013, Ian Hickson wrote:
On Tue, 10 Sep 2013, Ian Hickson wrote:
It would be nice to fix these all at once, and I think we can, by
introducing a configuration option on getContext(), in the style of
WebGL:
getContext('2d', { density: 'autosize' });
This would trigger the following behaviour: When the context is
created, and subsequently when the canvas changes size (e.g. due to
being sized with CSS relative units and the element they're relative
to changing), or when the display density changes size (e.g. due to
page zoom), then:
- the width and height of the canvas bitmaps get updated to match the
new native size of the canvas, at native density.
- the coordinate space of the canvas (context.width/context.height)
gets updated to match the size of the canvas in CSS pixel units.
- a 'resize' event gets fired at the canvas.
We would dump the *HD versions of the methods, and make the regular
ones go back to returning the actual raw pixels, since that would now
work fine and still provide HD-quality content everywhere it's
available.
What do people think?
Rik pointed out on IRC that it's common to have out-of-DOM canvases,
e.g. for storing textures, which would need to track the density of the
one in the DOM. I'd have to think about it in more detail, but in
principle it seems some sort of slaving mechanism should be able to
handle that too.
Proposed slaving mechanism:
var context1 = pageCanvas.getContext('2d', { density: 'autosize' });
var context2 = hiddenCanvas.getContext('2d', { density: pageCanvas });
Assuming we go with http://wiki.whatwg.org/wiki/WorkerCanvas :
If the 'density' value isn't the string 'autosize', it has to be a canvas
element or, if this is a worker, a WorkerCanvas object. Either way, that
object has to have had a context already created for it, using density set
to 'autosize'. Note that this means there's no way to have this magic
behaviour make a worker's canvases change size to match a canvas being
drawn on on the main thread. When using a WorkerCanvas, the browser takes
care of forwarding density changes from the main thread to the worker (I'm
not sure I understand the proposal properly, but I assume it autocommits
when the worker goes idle, even if the main thread is busy).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Simplified picture element draft
On Mon, Nov 25, 2013 at 8:33 AM, Adam Barth w...@adambarth.com wrote: Thanks Yoav. Tab asked me to provide some more feedback to this list, but it's hard to tell from the lengthy discussion what proposal folks are most interested in. Is there an editor's draft or some other relatively self-contained write-up that I could review? I'll be writing up a draft which more closely follows the discussion in WHATWG, and posting it soonish. I'm technically on vacation all this week*, so I might not get to it until next week, but I'll try to put something up sooner than that. * I'm just taking this week off to veg and play videogames. ~TJ
Re: [whatwg] Alignment of empty buttons
On Mon, Nov 25, 2013 at 4:32 AM, Boris Zbarsky bzbar...@mit.edu wrote: That's pure CSS: it's a !important rule in a UA stylesheet. I guess you could claim that supporting !important in a UA stylesheet is a proprietary extension, albeit one that's in the process of being specified. Already specced and in CR: http://dev.w3.org/csswg/css-cascade/#cascade-origin ~TJ
[whatwg] Drawing shapes on canvas and feedback thereon
On Fri, 27 Sep 2013, Ruben Rodriguez II wrote: On 09/05/2013 05:22 PM, Ian Hickson wrote: Not always, only if you don't draw the line aligned with the pixel grid (e.g. you draw a diagonal line, or a horizontal or vertical line that isn't centered in the middle of pixels on the pixels grid, or a horizontal or vertical line whose width isn't an integral number of pixels, etc). The options, on a pixel grid display, are: - don't honour the position precisely -- this leads to very ugly artifacts when animating (lines jerk around), and basically means that the graphics aren't accurate. - instead of describing the shapes as vectors, describe them using programs that can adapt to the position and size they're being drawn at, such that they automatically snap to the pixel grid in a pretty fashion -- this is what fonts do. - try to trick the eye by using anti-aliasing when things don't line up exactly on the pixel grid. The first two really aren't plausible options for canvas. I would just like to note that sometimes we do not WANT to draw precise shapes. :) Many people enjoy the aesthetic of 2d pixel-based graphics, and it should be a viable choice for the graphical style of a game, for instance. Canvas makes this more difficult, and it shouldn't be so! I don't really understand what you mean by the aesthetic of 2D pixel-based graphics. Can you elaborate? Maybe with examples? How does the 2D Canvas API make this more difficult? Why can't we have a global option to turn this off if we want to? I'm not trying to advocate for throwing away all antialiasing... I understand that most applications will probably want it by default, and agree with having it as the default. Basically all it is is http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#image-smoothing ... except that we're not talking about scaling. What does turn this off mean, exactly? What are you turning off? If you just turn off the current algorithms for drawing lines, you don't get different lines, you get no lines. What is it you want instead? Consider in particular lines drawn on high-res displays, lines drawn from 0,0.5 to 100,0.5, animations, etc. On Fri, 27 Sep 2013, Jasper St. Pierre wrote: The issue here is that the canvas API does not specify how pixels are sited on the canvas: if you imagine pixels as enlarged squares on a grid (shush, I know), does an X coordinate of 5 name the center of the square, or the intersection between 4th and 5th squares? It is defined: The CanvasRenderingContext2D 2D rendering context represents a flat linear Cartesian surface whose origin (0,0) is at the top left corner, with the coordinate space having x values increasing when going right, and y values increasing when going down. The x-coordinate of the right-most edge is equal to the width of the rendering context's scratch bitmap in CSS pixels; similarly, the y-coordinate of the bottom-most edge is equal to the height of the rendering context's scratch bitmap in CSS pixels. The answer is the intersection. Neither of these are perfect solutions when you have transforms; perhaps optional support for crisp lines or otherwise turning off AA would be a good idea. It is indeed the idea that led to this part of the thread. :-) The problem is, it's not clear what that would mean exactly: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/0040.html On Sat, 28 Sep 2013, Rik Cabanier wrote: Yeah, this should be specified somewhere. As you point out, luckily everyone is in agreement. It's not luck. :-) On Sat, 28 Sep 2013, Rik Cabanier wrote: On Fri, Sep 27, 2013 at 2:08 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 5 Sep 2013, Rik Cabanier wrote: On Thu, Sep 5, 2013 at 3:22 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 10 Aug 2013, Rik Cabanier wrote: 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. [...] I think canvas should have a similar feature... Can you elaborate on how exactly you would want this to work? How would you avoid the alignment and distortion problems when applying this to anything less trivial than a rectangle? Basically, this would *just* move the control points and the width of paths so the strokes are always aligned to the pixel grid (This would take pixel density and transformations into account). After this, you would draw as usual. Can you define aligned to the pixel grid? If I have a line from x1,y to x2,y, followed by an arc from x2,y back to x1,y with radius r, what should happen and why? Align the anchor points of all the segments. Don't change any of the anti-aliasing behavior. How does this differ from simply always using
