Re: [whatwg] BroadcastChannel should support structured clones
On Thu, 17 Apr 2014, Jonas Sicking wrote: > > It would be very useful to be able to send structured data, including > Blobs, through the BroadcastChannel API. > > This is something we've seen any time we've done storage or message > passing, that one of the first thing authors ask for is to not have to > do JSON serialization/parsing manually. The ability to pass ArrayBuffers > and Blobs is somewhat less commonly asked for, likely because binary > data is less often used, but seems important nonetheless. > > We can't allow transferring of objects, since you can't transfer > something to all listeners of a broadcasting API. But plain structured > clones should be no problem to support conceptually (though more work to > implement of course). > > We've started looking at doing structured clone support for Firefox and > likely won't ship until we have that implemented. This would make a lot of sense. I think when I was first speccing this I wanted to avoid transferring and forgot that you could clone without transferring! I see that you filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25415 ...so I'll track it there. For implementation purposes you can assume that I'm going to make this change. On Thu, 17 Apr 2014, Jonas Sicking wrote: > > Another thing that seems like an oversight in the spec is that the spec > currently says that BroadcastChannel should be exposed in Window > context. We should also expose it in Worker contexts. I had filed a bug to track this earlier: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24414 If you want to implement this in workers please do go ahead. I was just waiting for people to implement it at all before doing the minor work of updating the spec for workers (mostly, as noted in the bug, changing the "responsible document" stuff to check for worker event loops instead when in a worker, and excluding suspended workers). I've moved the bug back onto my radar. For people following on at home, there's also this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25414 ...relating to the order of events in a broadcast channel, and this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25413 ...wherein I'm about to change how channel names are exposed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] feedback
> > > > > > and it is not possible to resolve font sizes in physical length > > > > units unless the document is associated with a view. > > > > > > Why not? The canvas has a pixel density (currently always 1:1), no? > > > > 1:1 is not a physical pixel density. To resolve a font size that is > > specified in physical units (e.g. millimeters or inches) you need > > something like a DPI value, which requires information about the output > > device. > > No, not any more. CSS "physical" units are defined as mapping to CSS > pixels at 96 CSS pixels per CSS inch, and canvas is defined as mapping CSS > pixels to canvas coordinate space units at one CSS pixel per coordinate > space unit. As far as I know, all browsers do this now. > Right... So I think there is a bug in Blink then. Thanks. > > > > > My 2 cents: specifying fallback behaviors for all use cases that are > > > > context dependent could be tedious and I have yet to see a > > > > real-world use case that requires being able to paint a canvas in a > > > > frame-less document. Therefore, I think the spec should clearly > > > > state elements that are in a document without a browsing > > > > context are unusable. Not sure what the exact behavior should be > > > > though. Should an exception be thrown upon trying to use the > > > > rendering context? Perhaps canvas draws should fail silently, and > > > > using the canvas as an image source should give transparent black > > > > pixels? > > > > > > As far as I can tell, this is all already specified, and it just gets > > > treated like a normal canvas. > > > > Agreed. The fallback behavior is specified. But is it good enough? There > > will be discrepancies, sometimes large ones, between text rendered with > > and without a browsing context. > > I don't think there should be any discrepancies. > One major discrepancy I noticed is that web font resolution fails but I don't think that is due to lack of a browsing context per se. It is more precisely due to the fact that we don't compute style on documents that are not displayed (web fonts are defined in CSS). > > > Instead, we should use adaptive algorithms, for example always using > > > the prettiest algorithms unless we find that frame rate is suffering, > > > and then stepping down to faster algorithms. > > > > Such an adaptive algorithm implies making some kind of weighted decision > > to chose a reasonable compromise between quality and performance. > > Sounds like the perfect place to use a hint. > > If we really need a hint. But do we? Do we have data showing that adaptive > algorithms can't do a good job without a hint? > Fair enough. Will give it a try. > On Mon, 7 Apr 2014, Justin Novosad wrote: > > > > Dashing is one thing that would be affected. I think some > > implementations are currently in a non-compliant state probably because > > the line dashing feature was added recently. Back when strokeRect was > > originally implemented, we could get away with blindly normalizing > > rectangles because there was no impact on the rendering result. The > > other thing that is affected is fill rule application. For example, if > > you have a path that contains two intersecting rectangles and you are > > filling in with the nonzero rule. If one of the two rectangles is > > flipped, then the intersection region should be unfilled. If the > > rectangles are "normalized" internally by the implementation, then you > > will get the wrong (non spec compliant) result. > > I've added "in that order" to rect(). > Thanks. > I couldn't find the original reason for strokeRect() only drawing one line > in the one-dimensional case, though it dates back to 2007 at least. That speaks for itself: If no one has complained about that since 2007... > I haven't changed rect() to do that too. > Good. I think it is best for rect to not optimize to a line because that would affect filling in an undesirable way and it would affect the start point of the next sub-path. That being said, it is probably safe to optimize it to two lines, but that does not have to be detailed in the spec since it is an implementation optimization that has no effect on the rendered result. > > On Sun, 6 Apr 2014, Dirk Schulze wrote: > > > > The spec says that the object TextMetrics[1] must return font and actual > > text metrics. All things require information from the font or the font > > system. In many cases either font or font system just do not provide > > these information. > > Which cases? The information is needed for text layout purposes; if the > browser can't get the information, how is it conforming to CSS? > It conforms by applying approximation rules (or guesses?) that derive the missing metrics from the ones that are available. It's ugly, but it kinda works.
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Wed, 16 Apr 2014, Boris Zbarsky wrote: > > Right now canvas drawImage ignores EXIF orientation metadata. > > Could we add a version that doesn't do that? Especially with CSS > growing things like the image-orientation property, it would be good to > support drawing the image in its correct orientation. On Wed, 16 Apr 2014, Justin Novosad wrote: > > But why a new version of drawImage? Couldn't we just modify the existing > drawImage definition to state that it takes into account the > image-orientation property on the source image? The default value for > image-orientation is 0deg, which corresponds to the current drawImage > behavior. So I think we can make that change to the drawImage spec > without breaking stuff, as long as we make the change while > image-orientation is still an experimental feature. On Wed, 16 Apr 2014, Anne van Kesteren wrote: > > Why is image-orientation in CSS for ? For background-image that > makes sense, but if you are actually affecting the semantics of the > image that is displayed, it seems like it should be in HTML or a hint in > the image format. On Wed, 16 Apr 2014, Justin Novosad wrote: > > Yes, that makes a lot of sense IMHO. I just posted feedback to www-style The feedback seemed positive: http://lists.w3.org/Archives/Public/www-style/2014Apr/thread.html#msg179 This proposal seems pretty reasonable. I'm tracking this in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 On Wed, 16 Apr 2014, Justin Novosad wrote: > > Another use case to think about is: XHR->Blob->ImageBitmap->Canvas(2D or > WebGL) With that data flow, there is no opportunity to use a CSS > property to tweak image orientation. > There is this idea though: http://wiki.whatwg.org/wiki/ImageBitmap_Options Tracking this in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25507 If other vendors want to do this, please comment on the bug (or here). Here is a summary of related bugs: Regarding EXIF: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23510 Allow EXIF data to be passed to toBlob() This is pending implementation interest from browsers outside Mozilla, and someone coming up with a way to map EXIF to JSON in a well-defined way. https://www.w3.org/Bugs/Public/show_bug.cgi?id=23511 Expose EXIF data of images in elements This is pending implementation interest and would also benefit from a way to map EXIF to an API in a well-defined way. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25507 Have createImageBitmap() take options, e.g. to honour EXIF orientation This is pending implementation interest outside Chrome. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 Have an attribute that honours EXIF orientation This seems to have implementation interest from everyone, and I'll hopefully be adding it soon. Need a good name; if you have a suggestion, add it to the bug. Regarding drawImage(): https://www.w3.org/Bugs/Public/show_bug.cgi?id=17427 drawImage() should accept SVGImageElement () This is blocked on the SVG spec being updated to define image loading in a suitable level of detail. It could also do with interest from browser vendors other than Mozilla. Regarding ImageBitmap: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21346 Have ImageBitmap expose height and width attributes This is pending implementation interest outside Chrome. Regarding : https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842 Feature to make elements not load their images until needed This is something I plan to deal with at the same time as
[whatwg] feedback
On Tue, 8 Apr 2014, Rik Cabanier wrote: > On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson wrote: > > > > > > > > > > > > So this is not how most implementations currently have it > > > > > > defined. > > > > > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > > > definitely do store the path in user coordinates. The spec > > > > > currently says otherwise [1] though. > > > > > > > > I'm not sure what you're referring to here. > > > > > > All graphics backends for canvas that I can inspect, don't apply the > > > CTM to the current path when you call a painting operator. Instead, > > > the path is passed as segments in the current CTM and the graphics > > > library will apply the transform to the segments. > > > > Right. That's what the spec says too, for the current default path. > > No, the spec says this: > > For CanvasRenderingContext2D objects, the points passed to the methods, > and the resulting lines added to current default path by these methods, > must be transformed according to the current transformation matrix > before being added to the path. As far as I can tell, these are block-box indistinguishable statements. Can you show a test case that demonstrates how the spec doesn't match browsers? > > > [use case: two paths mapping to the same region] > > > > Just use two different IDs with two different addHitRegion() calls. > > That's a lot less complicated than having a whole new API. > > That doesn't work if you want to have the same control for the 2 areas, > from the spec for addHitRegion: > ># If there is a previous region with this control, remove it from the ># scratch bitmap's hit region list; then, if it had a parent region, ># decrement that hit region's child count by one. Interesting. You mean like a case where you had a button that got split into multiple segments animated separately that then joined together, but where you want to be able to click on any part of that split-up button? Hmm. There's several ways we could support that. The simple way would be to allow multiple regions to refer to a control. The more subtle way would be to allow the control logic to defer to the parent region, but that's probably a bad idea (where would you put the parent region?). So I guess the question is: is it more useful to be able to refer to the same control from multiple regions, or is it more useful for the previous region to be automatically discarded when you add a new one? It's probably more useful to have multiple regions. You can always do the discarding using IDs. > Even if you don't use the control, it would be strange to have 2 > separate hit regions for something that represents 1 object. Why? I think that makes a lot of sense. There are multiple regions, why not have multiple hit regions? This becomes especially true when the multiple regions might be differently overlapped by other regions, or where different parts of the canvas are renderings from different angles of the same underlying scene. It would be silly for things to be easier to do with two canvases than one, in that kind of case, no? I've changed the spec to not discard regions based on the control. > > > > On Fri, 6 Dec 2013, Jürg Lehni wrote: > > > > > > > > > > Instead of using getCurrentPath and setCurrentPath methods as a > > > > > solution, this could perhaps be solved by returning the internal > > > > > path instead of a copy, but with a flag that would prevent > > > > > further alterations on it. > > > > > > > > > > The setter of the currentPath accessor / data member could then > > > > > make the copy instead when a new path is to be set. > > > > > > > > > > This would also make sense from a a caching point of view, where > > > > > storing the currentPath for caching might not actually mean that > > > > > it will be used again in the future (e.g. because the path's > > > > > geometry changes completely on each frame of an animation), so > > > > > copying only when setting would postpone the actual work of > > > > > having to make the copy, and would help memory consummation and > > > > > performance. > > > > > > > > I don't really understand the use case here. > > > > > > Jurg was just talking about an optimization (so you don't have to > > > make an internal copy) > > > > Sure, but that doesn't answer the question of what the use case is. > > From my recent experiments with porting canvg ( > https://code.google.com/p/canvg/) to use Path2D, they have a routine > that continually plays a path into the context which is called from a > routine that does the fill, clip or stroke. Because that routine can't > simply set the current path, a lot more changes were needed. Sure, but the brief transitional cost of moving from canvas current default paths to Path2D objects is minor on the long run, and not worth the added complexity cost paid over the lifetime of the Web for the feature. So for something like this, we need a stronger
[whatwg] hidden attribute useless with display: flex?
Hi,
// CSS:
div{
display: flex;
}
// HTML:
Per spec, the div should be shown right? I imagine there is no way back
on that?
Does it mean hidden only works when the default (UA stylesheet) display
value is kept? Does it mean hidden is completely useless when trying to
combine it with display:flex?
What I'm trying to do is just that an element have display:flex and to
hide it with the hidden attribute when I don't need the element to be
shown. I guess my only option is changing style.display?
Thanks,
David
Re: [whatwg] HTML spec incorrectly suggests that can have its rendering changed with CSS
This discussion focused around the various behaviours that browsers have
around the rendering of .
On Thu, 23 Jan 2014, Boris Zbarsky wrote:
>
> What Gecko does with is basically to treat it like a special box
> type that has special sizing/painting/linebreak behavior. But we do
> still allow that box to be positioned/floated, just like an ...
On Tue, 28 Jan 2014, Elliott Sprehn wrote:
>
> Blink treats (conceptually) like a subclass of Text, there's
> nothing to style because it's just a run of text with a forced break.
On Wed, 29 Jan 2014, Tab Atkins Jr. wrote:
>
> We talked this over in the CSSWG meeting, and came up with a proposal
> for non-magical styling that is still very close to current behavior in
> all browsers:
>
> br {
> display-box: contents;
> content: "\A";
> white-space: pre;
> }
I've filed a bug to track this. It would be useful if browser vendors
could indicate whether they think Tab's proposal is satisfactory (in
particular, is 'display-box' something that browsers will implement?
Apparently Gecko is doing it, anyone else?).
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] [Notifications] Notification.hasPermission() instead of Notification.permission
The Notification specification defines a static Notification.permission
accessor, which returns one of {granted, denied, default}. This requires
the browser to synchronously determine whether the page has permission to
show notifications, whereas checking this may be an asynchronous operation.
This is the case in Chrome.
Before this becomes a paradigm, could we consider having a static
hasPermission() instead, returning a Promise?
I'll add a UseCounter to Blink for tracking Notification.permission usage,
but it will take some time before conclusive usage data comes in.
Thanks,
Peter
