Re: [whatwg] Why do we have input type='month' and input type='week'?

[Mounir Lamouri]

On 01/02/13 15:39, Glenn Maynard wrote:
 On Thu, Jan 31, 2013 at 6:20 AM, Bruce Lawson bru...@opera.com 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:
select name='month'!--fill with option for each
month--/selectselect name='year'!-- fill with option for each year
you want to show --/select

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
select or an input type='number' with a min and a max.
Anyway, I still believe that the pros of input type='month' 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

Re: [whatwg] Why do we have input type='month' and input type='week'?

[Tab Atkins Jr.]

On Tue, Feb 12, 2013 at 9:20 AM, Mounir Lamouri mou...@lamouri.fr 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:
 select name='month'!--fill with option for each
 month--/selectselect name='year'!-- fill with option for each year
 you want to show --/select

 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
 select or an input type='number' with a min and a max.
 Anyway, I still believe that the pros of input type='month' 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 input type='month' and input type='week'?

[Jukka K. Korpela]

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 input type=month 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 input type=month 
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 
input type=month 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 input type=month 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 input type=month 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 input type='month' and input type='week'?

[Tab Atkins Jr.]

On Tue, Feb 12, 2013 at 9:39 AM, Jukka K. Korpela jkorp...@cs.tut.fi 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 input type=month 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 input type=month 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
 input type=month 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 input type=month 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 input type=month 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] Adding the imageSmoothingEnabled back into 2dContext Level 2 spec.

[Rik Cabanier]

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 ash...@scirra.com 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 caban...@gmail.com 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 jaymu...@microsoft.com 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 dfnTrackEventInit/dfn :
  spanEventInit/span {
 // compositing
  attribute unrestricted double span
  title=dom-context-2d-globalAlphaglobalAlpha/span; // (default 1.0)
  attribute DOMString span
 
 title=dom-context-2d-globalCompositeOperationglobalCompositeOperation/span;
  // (default source-over)
  +
  +  // image smoothing
  +   attribute boolean span
 
 title=dom-context-2d-imageSmoothingEnabledimageSmoothingEnabled/span;
  // (default true)
  +
   !--
 // v7 we've also received requests for:
 - turning off antialiasing to avoid seams when patterns are painted
  next to each other
  @@ -40945,7 +40949,8 @@ interface dfnPath/dfn {
 
 
 title=dom-context-2d-globalCompositeOperationglobalCompositeOperation/code,
  code
  title=dom-context-2d-fontfont/code, code
  title=dom-context-2d-textAligntextAlign/code, code
  -   title=dom-context-2d-textBaselinetextBaseline/code./li
  +   title=dom-context-2d-textBaselinetextBaseline/code, code
  +
 
 title=dom-context-2d-imageSmoothingEnabledimageSmoothingEnabled/code./li
 /ul
 
 p class=noteThe spancurrent default path/span and the
  @@ -43416,10 +43421,16 @@ try {
 
 pIf the original image data is a bitmap image, the value painted
 at a point in the area of the repetitions is computed by filtering
  -  the original image data. The user agent may use any filtering
  +  the original image data. If the code
  +
 
  title=dom-context-2d-imageSmoothingEnabledimageSmoothingEnabled/code
  +  then the user agent may use any filtering
 algorithm (for example bilinear interpolation or nearest-neighbor).
  -  When the filtering algorithm requires a pixel value from outside the
  -  original image data, it must instead use the value from wrapping the
  +  If the code
  +
 
  title=dom-context-2d-imageSmoothingEnabledimageSmoothingEnabled/code
  +  attribute is set to false, the image must be rendered using
  +  nearest-neighbor interpolation. When such the filtering algorithm
  +  requires a pixel value from outside the original image data, it
  +  must instead use the value from wrapping the
 pixel's coordinates to the original image's dimensions. (That is,
 the filter uses 'repeat' behavior, regardless of the value of
 var title=repetition/var.)
  @@ -44539,6 +44550,18 @@ v6DVT (also check for '- -' bits in the part
  above) --
 p class=noteThis specification does not define the algorithm to
 use when scaling the image, if necessary./p
 
  +  pIf the code
  +
 
  title=dom-context-2d-imageSmoothingEnabledimageSmoothingEnabled/code
  +  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./p
  +
  +  p class=noteThis specification does not define the precise
  +  algorithm to use when scaling an image when the code
  +
 
  

Re: [whatwg] Enabling LCD Text and antialiasing in canvas

[Stephen White]

On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson i...@hixie.ch wrote:

 On Thu, 29 Mar 2012, Jeremy Apthorp wrote:
  On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp jere...@chromium.org
 wrote:
   On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson i...@hixie.ch wrote:
   On Fri, 13 Jan 2012, Jeremy Apthorp wrote:
   
I'd like to draw non-antialiased lines in a canvas. 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 ju...@chromium.org
 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.


 On Thu, 15 Nov 2012, Fred Andrews wrote:
 
  The canvas that scripts draw into could be over-sized with the UA down
  sampling 

Re: [whatwg] Enabling LCD Text and antialiasing in canvas

[Rik Cabanier]

On Tue, Feb 12, 2013 at 2:56 PM, Stephen White senorbla...@chromium.orgwrote:

 On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson i...@hixie.ch wrote:

  On Thu, 29 Mar 2012, Jeremy Apthorp wrote:
   On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp jere...@chromium.org
  wrote:
On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 13 Jan 2012, Jeremy Apthorp wrote:

 I'd like to draw non-antialiased lines in a canvas. 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 ju...@chromium.org
  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 

Re: [whatwg] Polling APIs in JavaScript vs Callbacks

[Elliott Sprehn]

On Mon, Feb 11, 2013 at 10:56 PM, Garrett Smith dhtmlkitc...@gmail.comwrote:

 On 2/9/13, Glenn Maynard gl...@zewt.org wrote:
  On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr.
  jackalm...@gmail.comwrote:
 
  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] scoped style sheets and @-rules

[L. David Baron]

On Monday 2013-01-21 11:17 -0800, Tab Atkins Jr. wrote:
 On Mon, Jan 21, 2013 at 6:39 AM, L. David Baron dba...@dbaron.org 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/   턂