Re: [whatwg] scoped style sheets and @-rules
On Monday 2013-01-21 11:17 -0800, Tab Atkins Jr. wrote: > On Mon, Jan 21, 2013 at 6:39 AM, L. David Baron wrote: > > Thus I think the specification should mandate that @keyframes and > > @font-face are ignored in scoped style sheets, just like @page. > > > > I think it would also be good if the specification left the effects > > of unknown @-rules undefined until whether they should be supported > > can be properly considered. > > Should we ignore them entirely, or just ignore the scoped-ness and > have them fill in the global dictionary? I prefer ignoring them entirely, since authors will notice if things aren't working as expected. -David -- š¯„˛ L. David Baron http://dbaron.org/ š¯„‚ š¯„¢ Mozilla http://www.mozilla.org/ š¯„‚
Re: [whatwg] Polling APIs in JavaScript vs Callbacks
On Mon, Feb 11, 2013 at 10:56 PM, Garrett Smith wrote: > On 2/9/13, Glenn Maynard wrote: > > On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr. > > wrote: > > > >> That said, there *are* still some isolated use-cases for polling. ^_^ > >> When an event-based approach would potentially deliver far too many > >> events, with separation between them perhaps less than 1ms, exposing a > >> polling-based API instead can be useful. I haven't followed the > >> Gamepad API lately, but I know this was at least considered for some > >> of the types of feedback, such as the exact position of joysticks or > >> pressure on buttons, both of which can change very rapidly in > >> realistic scenarios. > >> > > > > A polling API doesn't help you there, since you can't poll every 1ms in > > script (certainly not in the UI thread, and probably not reliably even > in a > > worker). In fact, since setTimeout will be throttled but events fired by > > the browser don't have to be, events can be sent faster than you can poll > > in the UI thread (though this is probably a bad idea most of the time). > > > > The solution is probably a matter of buffering the changes, and limiting > > how frequently "something was buffered" events fire. > Are you proposing event quantization threshold? > There's no reason to have a threshold. We should just batch and deliver at checkpoints like end-of-microtask (MutationObserver) or rAf (Animations). - E
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Feb 12, 2013 at 2:56 PM, Stephen White wrote: > On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson wrote: > > > On Thu, 29 Mar 2012, Jeremy Apthorp wrote: > > > On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp > >wrote: > > > > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson wrote: > > > >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote: > > > >> > > > > >> > I'd like to draw non-antialiased lines in a . Currently it > > > >> > seems that the only way to do this is to directly access the pixel > > > >> > data. > > > >> > > > > >> > Is there a reason there's no way to turn off antialiasing? > > > >> > > > >> What's the use case? > > > > > > > > Pixel-art style games. > > > > > > Specifically: even with the new image smoothing stuff in place for > > > drawImage, a 1:2 diagonal line will still be anti-aliased (only the > > > antialiasing will look silly scaled up to 2x). > > > > Do you have an example of a game where lines are drawn using a line API > > without antialiasing, then scaled up? Most "pixel art" games I've seen > > tend to use bitmaps for that kind of thing. > > > > > > On Mon, 12 Nov 2012, Justin Novosad wrote: > > > > > > For many types of apps, DOM-based rendering is uncompetitively slow > > > [so we should make text rendering in canvas more controllable] > > > > This seems like something we should fix, not something we should work > > around by having people use canvas instead. Using canvas has all kinds of > > terrible side-effects, like reducing the likely accessibility of the > page, > > making searcheability much worse, etc. > > > > Also, do you have any metrics showing the magnitude of this problem on > > real-world sites that might consider using canvas instead? > > > > > > > If LCD text were enable-able, authors would have to be mindful of a > > > number of caveats in order to avoid rendering artifacts. > > > > Do we have any reason to believe the majority of authors would make the > > right decisions here? > > > > (The main reason we haven't provided control over things like > antialiasing > > is that many authors tend to make terribly bad decisions.) (Before anyone > > gets offended, by the way: that you are reading this almost guarantees > > that you are above average in terms of authoring ability.) > > > > > > On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote: > > > > > > We'd have to define what happens when you use subpixel antialiasing > > > "incorrectly", because we can be pretty sure authors will use it > > > incorrectly and expect to get interoperable behavior. > > > > That's certainly true. > > > > > > > Mozilla supports a "mozOpaque" attribute which makes the canvas buffer > > > RGBX (initialized to solid black) and enables subpixel antialiasing for > > > most text drawing. That might be enough to address your use-cases. > > > > I haven't specified this; if other vendors intend to implement this let > me > > know and I can spec it. I'm not sure it's worth it though. > > > > [blowing the dust off this thread] > > Folks on the Chrome team are looking into implementing this attribute, and > would be interested in seeing it spec'ed. What are you implementing? Initializing the canvas to black or subpixel antialiasing? > > > > > On Wed, 14 Nov 2012, Robert O'Callahan wrote: > > > On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad > > wrote: > > > > > > > > Are there precedents for exposing features with documented caveats? > > > > (excluding caveats that were discovered after the fact) > > > > > > Yes, and many of them have been extremely problematic, because Web > > > authors will ignore the caveats. > > > > Right. I'd really like to avoid adding more if we can help it. > > > > > > On Wed, 14 Nov 2012, Justin Novosad wrote: > > > > > > There is a recent improvement in Chrome called "deferred 2D canvas > > > rendering" (enabled by default as of Chrome 23). It is a mechanism > that > > > records 2d canvas commands during JS execution, and only executes them > > > for real when the render buffer needs to be resolved (draw to screen, > > > getImageData, toDataURL, etc.). If you want to check it out, the guts > > > are in Skia: SkGPipe is a sort of FIFO for graphics commands, > > > SkDeferredCanvas is a wrapper that manages the GPipe and automatically > > > flushes it and applies some command culling optimizations. > > > > > > So to come back to the problem of with and without subpixel AA buffers: > > > if rendering is deferred, the non-AA buffer would never get rasterized > > > (and possibly never even allocated), unless it needs to be. Obviously > > > there are practical limitations, for example we cannot store an > > > unlimited stream of recorded commands, so if the canvas draws > > > indefinitely without ever being cleared, at some point we have to > > > rasterize the non-AA buffer just so that we can safely discard the > > > recording data. Also, if at record time the necessary conditions for > > > subpixel AA are not met, perhaps we just forget about it. > > > > > > I
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson wrote: > On Thu, 29 Mar 2012, Jeremy Apthorp wrote: > > On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp >wrote: > > > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson wrote: > > >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote: > > >> > > > >> > I'd like to draw non-antialiased lines in a . Currently it > > >> > seems that the only way to do this is to directly access the pixel > > >> > data. > > >> > > > >> > Is there a reason there's no way to turn off antialiasing? > > >> > > >> What's the use case? > > > > > > Pixel-art style games. > > > > Specifically: even with the new image smoothing stuff in place for > > drawImage, a 1:2 diagonal line will still be anti-aliased (only the > > antialiasing will look silly scaled up to 2x). > > Do you have an example of a game where lines are drawn using a line API > without antialiasing, then scaled up? Most "pixel art" games I've seen > tend to use bitmaps for that kind of thing. > > > On Mon, 12 Nov 2012, Justin Novosad wrote: > > > > For many types of apps, DOM-based rendering is uncompetitively slow > > [so we should make text rendering in canvas more controllable] > > This seems like something we should fix, not something we should work > around by having people use canvas instead. Using canvas has all kinds of > terrible side-effects, like reducing the likely accessibility of the page, > making searcheability much worse, etc. > > Also, do you have any metrics showing the magnitude of this problem on > real-world sites that might consider using canvas instead? > > > > If LCD text were enable-able, authors would have to be mindful of a > > number of caveats in order to avoid rendering artifacts. > > Do we have any reason to believe the majority of authors would make the > right decisions here? > > (The main reason we haven't provided control over things like antialiasing > is that many authors tend to make terribly bad decisions.) (Before anyone > gets offended, by the way: that you are reading this almost guarantees > that you are above average in terms of authoring ability.) > > > On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote: > > > > We'd have to define what happens when you use subpixel antialiasing > > "incorrectly", because we can be pretty sure authors will use it > > incorrectly and expect to get interoperable behavior. > > That's certainly true. > > > > Mozilla supports a "mozOpaque" attribute which makes the canvas buffer > > RGBX (initialized to solid black) and enables subpixel antialiasing for > > most text drawing. That might be enough to address your use-cases. > > I haven't specified this; if other vendors intend to implement this let me > know and I can spec it. I'm not sure it's worth it though. > [blowing the dust off this thread] Folks on the Chrome team are looking into implementing this attribute, and would be interested in seeing it spec'ed. Thanks, Stephen > > On Wed, 14 Nov 2012, Robert O'Callahan wrote: > > On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad > wrote: > > > > > > Are there precedents for exposing features with documented caveats? > > > (excluding caveats that were discovered after the fact) > > > > Yes, and many of them have been extremely problematic, because Web > > authors will ignore the caveats. > > Right. I'd really like to avoid adding more if we can help it. > > > On Wed, 14 Nov 2012, Justin Novosad wrote: > > > > There is a recent improvement in Chrome called "deferred 2D canvas > > rendering" (enabled by default as of Chrome 23). It is a mechanism that > > records 2d canvas commands during JS execution, and only executes them > > for real when the render buffer needs to be resolved (draw to screen, > > getImageData, toDataURL, etc.). If you want to check it out, the guts > > are in Skia: SkGPipe is a sort of FIFO for graphics commands, > > SkDeferredCanvas is a wrapper that manages the GPipe and automatically > > flushes it and applies some command culling optimizations. > > > > So to come back to the problem of with and without subpixel AA buffers: > > if rendering is deferred, the non-AA buffer would never get rasterized > > (and possibly never even allocated), unless it needs to be. Obviously > > there are practical limitations, for example we cannot store an > > unlimited stream of recorded commands, so if the canvas draws > > indefinitely without ever being cleared, at some point we have to > > rasterize the non-AA buffer just so that we can safely discard the > > recording data. Also, if at record time the necessary conditions for > > subpixel AA are not met, perhaps we just forget about it. > > > > I admit this is a complex solution for implementors, but it makes the > > management of subpixel-AA safety transparent to web authors. > > I think it'd be reasonable (for some definition of reasonable that > relates to whether it's compatible with the spec, anyway) for implementors > to do this today, without having to expose any control to the author
Re: [whatwg] Adding the imageSmoothingEnabled back into 2dContext Level 2 spec.
Is there an implementation report on this?
If browsers stabilized on this feature, it might be time to drop the prefix.
On Tue, Feb 12, 2013 at 7:30 AM, Ashley Gullen wrote:
> I would re-emphasise this is important for many game applications. Here's
> an image showing the effect it can have from a recent blog post I wrote:
> https://www.scirra.com/images/sampling-point-linear.png
> For a game in this style it is essential to be able to force
> nearest-neighbour. Games in that "retro" style are often unplayable
> because they look so awful if they get bilinear interpolation forced on
> them. On the other hand, modern hi-res style games which intend to use
> bilinear interpolation only look marginally worse if they get
> nearest-neighbour. So I think the existing spec was fine as it was:
> imageSmoothingEnabled = false means "require nearest-neighbour
> interpolation", imageSmoothingEnabled = true means "any smoothing
> algorithm, or nearest-neighbour".
>
> I would also emphasise this should definitely also apply to patterns, for
> the same reason: games are likely to use a pattern to render tiles, and
> those should be rendered with the same interpolation as everything else.
>
> Ashley
>
>
>
> On 8 February 2013 12:25, Rik Cabanier wrote:
>
>> I agree we should bring it back.
>>
>> Personally, it would be nice that have a more formal definition of what
>> smoothing actually means so user agents can implement it similarly.
>>
>> Rik
>>
>> On Tue, Feb 5, 2013 at 7:14 AM, Jay Munro wrote:
>>
>> > For CR, we took the imageSmoothingEnable feature out because it hadn't
>> > been given a chance to be discussed by the working group. For level 2,
>> I'm
>> > adding it back in, but asking for any discussion that needs to be made
>> > first.
>> >
>> > Silence will be taken to mean there is no objection, but positive
>> > responses are encouraged. If I don't hear any objections by Monday Feb
>> 11,
>> > I'll check it in.
>> >
>> > The following is the pending check in:
>> >
>> >
>> > @@ -40677,6 +40677,10 @@ dictionary TrackEventInit :
>> > EventInit {
>> >// compositing
>> > attribute unrestricted double > > title="dom-context-2d-globalAlpha">globalAlpha; // (default 1.0)
>> > attribute DOMString > >
>> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation;
>> > // (default source-over)
>> > +
>> > + // image smoothing
>> > + attribute boolean > >
>> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled;
>> > // (default true)
>> > +
>> >
>> >This specification does not define the algorithm to
>> >use when scaling the image, if necessary.
>> >
>> > + If the > > +
>> >
>> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled
>> > + attribute is set to true, then the user agent should attempt to
>> > + apply a smoothing algorithm to the image data when it is scaled.
>> > + Otherwise, the image must be rendered using nearest-neighbor
>> > + interpolation.
>> > +
>> > + This specification does not define the precise
>> > + algorithm to use when scaling an image when the > > +
>> >
>> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled
>> > + attribute is set to true.
>> > +
>> >When a canvas is drawn onto itself, the drawing
>> >model requires the source to be copied before the image is
>> drawn
>> >back onto the canvas, so it is possible to copy parts of a canvas
>> > @@ -46040,6 +46063,36 @@ function AddCloud(data, x, y) { ... }
>> >
>> >
>> >
>> > + Image smoothing
>> > +
>> > +
>> > +
>> > + context . > >
>> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled [
>> > = value ]
>> > +
>> > +
>> > +
>> > +Returns whether pattern fills and the > > +title="dom-context-2d-drawImage">drawImage() method will
>> > +attempt to smooth images if they have to rescale them (as opposed
>> > +to just rendering the images with "big pixels").
>> > +
>> > +Can be set, to change whether images are smoothed (true) or not
>> > +(false).
>> > +
>> > +
>> > +
>> > +
>> > +
>> > +
>> > +
>> > + The > > +
>> >
>>
>> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled
>> > + attribute, on getting, must return the last value it was set to. On
>> > + setting, it must be set to the new value. When the
>> > + CanvasRenderingContext2D object is created, the
>> > + attribute must be set to true.
>> > +
>> > +
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>
Re: [whatwg] Why do we have and ?
On Tue, Feb 12, 2013 at 9:39 AM, Jukka K. Korpela wrote: > 2013-02-12 19:26, Tab Atkins Jr. wrote: >> The fact that authors today have a random assortment of displays for >> the exact same feature (credit card expirys) is something that would >> be great to fix, not bemoan as a loss to the world. ^_^ > > Well, maybe, from some point of view, but is there really something to be > fixed, and is it probable that would fix it? > > I have seen many input widgets for such data and used them a lot in test > purchases. In general, the more advanced they try to be, the more annoying > they get. I can type "03/15", or whatever reads in the card, rather fast. > But if I have to pick things up from dropdowns or click on something in a > calendar picker, I surely hope I won't need to do this a dozen more times. > > What are the odds that browser vendors will implement in > a simple manner that allows fast typing as one input method? Rather small I > think. > > This would make the most obvious, and perhaps the most common, use for > a case *against* it. Credit card expiry month is best > handled with a text input field, with suitable checks on the input string. > There may be *other* cases where graphic widgets are good when selecting a > month, but authors can use libraries for such purpose, and I don't see any > particular reason why this should be standardized across pages but not > across browsers. This argument appears to apply equally well to all the date inputs, and perhaps most of the other new inputs. I believe it's wrong. * Most people don't type very fast. We email-happy people are an exception. For most, clicking on things is faster and easier. * Experience shows that most authors appear to prefer a pair of dropdowns for selecting month and year, rather than a text input. Might as well move closer to author expectations. * Text inputs are permanently subject to the vagaries of whatever arcane syntax the author happened to want (or didn't want, but accidentally required when they miswrote their regex) - Do I just type two numbers with a slash? Or do I use a dash? Or a space? What if I use a slash surrounded by spaces? Or do I use the month name? Long or short name? Two digit or four digit year? - while visual inputs put your options in front of you and avoid all of that. > Even if became widely supported, many, probably most, > authors will keep using libraries or their own code, because they get > consistent look and feel and functionality across browsers. Some authors > would be misled into using for any month input because > that's "logical" or "semantic" (as it is in a sense), but this will create > questionable user experience in many common cases. This same argument keeps getting deployed against type="date". We'll see what actually happens. I expect (and deeply hope) that the ease of use of the built-ins will win the day, once they're supported on every browser sites expect their visitors to use. ~TJ
Re: [whatwg] Why do we have and ?
2013-02-12 19:26, Tab Atkins Jr. wrote: The fact that authors today have a random assortment of displays for the exact same feature (credit card expirys) is something that would be great to fix, not bemoan as a loss to the world. ^_^ Well, maybe, from some point of view, but is there really something to be fixed, and is it probable that would fix it? I have seen many input widgets for such data and used them a lot in test purchases. In general, the more advanced they try to be, the more annoying they get. I can type "03/15", or whatever reads in the card, rather fast. But if I have to pick things up from dropdowns or click on something in a calendar picker, I surely hope I won't need to do this a dozen more times. What are the odds that browser vendors will implement in a simple manner that allows fast typing as one input method? Rather small I think. This would make the most obvious, and perhaps the most common, use for a case *against* it. Credit card expiry month is best handled with a text input field, with suitable checks on the input string. There may be *other* cases where graphic widgets are good when selecting a month, but authors can use libraries for such purpose, and I don't see any particular reason why this should be standardized across pages but not across browsers. Even if became widely supported, many, probably most, authors will keep using libraries or their own code, because they get consistent look and feel and functionality across browsers. Some authors would be misled into using for any month input because that's "logical" or "semantic" (as it is in a sense), but this will create questionable user experience in many common cases. Yucca
Re: [whatwg] Why do we have and ?
On Tue, Feb 12, 2013 at 9:20 AM, Mounir Lamouri wrote: > On 01/02/13 15:39, Glenn Maynard wrote: >> FYI, I would find this annoying. CC expiry entry forms are typically >> select boxes containing 01-12. The text lines up with what's on my credit >> card, so I don't have to translate "07" to "July" in my head when entering >> it off of my card. Any month picker for credit card expiry dates should >> always have month numbers (of course, names *in addition* to numbers are >> fine, though probably pointless). > > That's exactly why I think the use case is weak: it is easy to implement > a month picker: > > > Given how easy it is, authors might quickly end up expecting specific > behaviour that the UAs do not provide. For example, Having "01 - > January" or "January - 01" or even "01" instead of "January". They could > want the year to show up as 2 digits or 1 digit, as a textfield, a > or an with a min and a max. > Anyway, I still believe that the pros of are quite > low but in another hand, it shouldn't cost too much for UA to implement > it if or date-time-related types are already implemented and it provides > a real benefit on Mobile. The fact that authors today have a random assortment of displays for the exact same feature (credit card expirys) is something that would be great to fix, not bemoan as a loss to the world. ^_^ ~TJ
Re: [whatwg] Why do we have and ?
On 01/02/13 15:39, Glenn Maynard wrote: > On Thu, Jan 31, 2013 at 6:20 AM, Bruce Lawson wrote: > >> The use-case for an input type I imagine is that a browser can have a >> select-like UI (Jan, Feb, March, April ...) which, in a French language >> browser becomes "Janvier, Fevrier, Mars, Avril .. " (or even VendƩmiaire to >> Fructidor for FRC fans). >> > > FYI, I would find this annoying. CC expiry entry forms are typically > select boxes containing 01-12. The text lines up with what's on my credit > card, so I don't have to translate "07" to "July" in my head when entering > it off of my card. Any month picker for credit card expiry dates should > always have month numbers (of course, names *in addition* to numbers are > fine, though probably pointless). That's exactly why I think the use case is weak: it is easy to implement a month picker: Given how easy it is, authors might quickly end up expecting specific behaviour that the UAs do not provide. For example, Having "01 - January" or "January - 01" or even "01" instead of "January". They could want the year to show up as 2 digits or 1 digit, as a textfield, a or an with a min and a max. Anyway, I still believe that the pros of are quite low but in another hand, it shouldn't cost too much for UA to implement it if or date-time-related types are already implemented and it provides a real benefit on Mobile. Regarding week, I still believe that the use cases are pretty weak but the most important issue is that there is no good UI for this on Mobile AFAIK. Cheers, -- Mounir
