Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage
If your argument is that WebGL sometimes falls back to canvas2d, this generally only happens when the system has crappy drivers that are blacklisted for being insecure/unstable. The solution to this is to develop and distribute better drivers that are not blacklisted. This is already happening and making good progress - according to Mozilla's stats, Firefox users who get WebGL support has increased from 33% in 2011 to 85% in 2014 ( http://people.mozilla.org/~bjacob/gfx_features_stats/). I feel it is likely to continue to approach ubiquitous WebGL support, making fallbacks unnecessary. This also solves the problem of having to have dual renderer implementations: only the WebGL renderer will be necessary, and this is far more compelling than a souped-up canvas2d, since WebGL can use shader effects, have advanced control over textures and co-ordinates, also do 3D, and so on. This cannot all be brought to canvas2d without simply reinventing WebGL. Further, crappy drivers can also cause software-rendered canvas2d as well, which is likely so slow to begin with that batching will have no important performance improvement. Software-rendered WebGL is just another workaround to crappy drivers (or in rare cases systems without GPUs, but then who's going to be gunning for high performance there?) and there is still no guarantee falling back to canvas2d will be GPU-accelerated, especially since the system already has such poor drivers that the browser has blacklisted it for WebGL support. The real problem is that there is not 100% WebGL support everywhere, but with drivers improving and Apple and Microsoft on board I'm sure that will fix itself eventually. Please don't spec features to improve canvas2d performance in the mean time; I don't see it having any long-term utility for the web platform. Ashley On 5 August 2014 16:21, Justin Novosad wrote: > On Mon, Aug 4, 2014 at 6:39 PM, Robert O'Callahan > wrote: > > > It looks reasonable to me. > > > > How do these calls interact with globalAlpha etc? You talk about > > decomposing them to individual drawImage calls; does that mean each image > > draw is treated as a separate composite operation? > > > > Composited separately is the intent. A possible internal optimization: the > implementation could group non-overlapping draw and composite them > together. > > > > Currently you have to choose between using a single image or passing an > > array with one element per image-draw. It seems to me it would be more > > flexible to always pass an array but allow the parameters array to refer > to > > an image by index. Did you consider that approach? > > > > Had not thought of that. Good idea. > > On Mon, Aug 4, 2014 at 7:35 PM, Katelyn Gadd wrote: > > > I'd suggest that this needs to at least handle > > globalAlpha. > > > > It would be trivial to add a an addition format that includes alpha. > > > > Replacing the overloading with individual named methods is something > > I'm also in favor of. > > > That's something I pondered and was not sure about. Eliminating the > parameter format argument would be nice. Your feature-detection argument is > a really good reason. > > > > > I get the impression that ordering is implicit for this call - the > > batch's drawing operations occur in exact order. It might be > > worthwhile to have a way to indicate to the implementation that you > > don't care about order, so that it is free to rearrange the draw > > operations by image and reduce state changes. Doing that in userspace > > js is made difficult since you can't easily do efficient table lookup > > for images. > > > > I am not sure exposing that in the API is a good idea because it opens the > door to undefined behavior. It could result in different implementations > producing drastically different yet compliant results. > Perhaps implementations could auto-detect draw operations that are > commutative based on a quick overlap analysis, and use that knowledge to > automatically group draw calls that use similar drawing state (e.g. the > same source GPU texture) > > > > > > Would it be possible to sneak rgba multiplication in under the guise > > of this feature? ;) Without it, I'm forced to use WebGL and reduce > > compatibility just for something relatively trivial on the > > implementer's side. (I should note that from what I've heard, Direct2D > > actually makes this hard to implement. > > > > I think that would make this feature significantly more complex to spec, > and to implement. It really should be treated as an orthogonal feature > request. Your suggestion is very use-case specific. A more general > incarnation of your request would be to have a blendMode parameter that > that determines how the source image gets blended with the fillStyle. With > that, you resolve your specific use case by setling the fill style to an > rgba color, and using a multiply blend op to use it to modulate images. > > On Tue, Aug 5, 2014 at 7:47 AM, Ashley Gullen wrote: > > > I am against
Re: [whatwg] Notifications improvements
On Tue, Aug 5, 2014 at 7:09 AM, Anne van Kesteren wrote: > On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote: >> I think the most low hanging fruit would be to add the following as >> data that can be displayed in a notification: >> >> * Progress bar > > Tracked here: https://github.com/whatwg/notifications/issues/17 Sweet! >> * Lists of title/body pairs > > What exactly is this for? The place that this has come up in FirefoxOS is when notifying about incoming emails. We would like to display the sender and the subject for each newly arrived email. At first this seemed like a pretty unusual edge case, but after looking at chrome-apps notification API they had this exact feature. So it seemed like this has come up elsewhere too. >> * Date (for things like "event will happen in 10 minutes") > > Should this be part of a generic alarm API? The goal of the Alarm API is to enable a website to do some processing (and possibly open full UI) at a particular wallclock time. An alarm clock application is a primary example of this. The goal of a Date field for notifications is quite different. It's to enable a notification that's associated with an event that happend, or is going to happen, at a different time than when the notification API JS call happened. For example a calendar application might want to create a notification. The notification should be created and displayed to the user 10 minutes before the event is about to happen, but the timestamp shown next to the notification should at first say "in 10 minutes". As time passes the timestamp should change to "in 9 minutes" ... "in 5 minutes" ... "now" ... "1 minute ago" ...etc. The only way you could do that right now is to 10 minutes before the event happens create a notification which says "CoolMeeting in 10 minutes", then after a minute replace that with "CoolMeeting in 9 minutes" etc. This both has the problem that the application needs to constantly be running and replace the notification. It would also mean that the notification would render the platform provided timestamp. This might look something like "CoolMeeting in 10 minutes. Just now". Another use case is when creating notifications for text messages (or other messaging systems). A text message carries the time when it was created, which might be very different from when the message was received by the user's device. It would here be nice to immediately create a notification which says "Message from Anne, 6 minutes ago" without that again creating the double timestamp like "Message from Anne, 6 minutes ago. 2 minutes ago". >> We also need to keep state on the Notification object if the user has >> clicked the notification or not. > > Why is that? Relying on the application to track this perfectly has two problems. First off it means that applications has to register a ServiceWorker handler for all notification objects and run any logic related to handling a click right away. Rather than simply handle it next time the application is started, which would save on both CPU and battery. Second, it's much more error prone to track this in application space given potential for bugs, crashes and IO errors. / Jonas
Re: [whatwg] Notifications improvements
On Fri, Jul 11, 2014 at 12:57 AM, Andrew Wilson wrote: > > On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking wrote: >> >> On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson >> wrote: >> > >> > On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote: >> >> >> >> Hi All, >> >> >> >> We've on and off discussed various features added to notifications. >> >> It'd be great to move forward with some of these improvements. >> >> >> >> I think the most low hanging fruit would be to add the following as >> >> data that can be displayed in a notification: >> >> >> >> * Progress bar >> >> * Lists of title/body pairs >> >> * Date (for things like "event will happen in 10 minutes") >> >> >> > >> > So, many of these cases were what the original HTMLNotification API was >> > supposed to address. This was eventually shot down for a number of >> > (good) >> > reasons: too much complexity on the implementation side, and more >> > importantly, the fact that these more complex notifications aren't >> > compatible with various platform notification frameworks and so this >> > would >> > be a source of platform/UA incompatibility. It's not clear to me that >> > re-adding support for these use cases one at a time as distinct >> > notification >> > types is really a good path forward, or that it's necessarily >> > "low-hanging >> > fruit" unless we have a good idea for how to deal with the >> > platform-compatibility issue. >> >> Actually, given that the UA has a very high degree of semantic >> understanding of these properties, I think it should be doable to >> implement on top of all existing platform notification systems. In all >> of the above cases you can come up with a reasonable string to add to >> the end to render the content. This is what pages have to do right now >> anyway. > > > I had assumed from the examples you gave that the goal of these new > notification types was to have dynamically updating notifications (progress > bar, timestamps that update with a countdown to an event, etc), which it > wasn't clear could be cleanly implemented across all platform notification > systems without significant jank. For dates the idea is definitely to enable the notifications to be dynamically updated by the platform. For progress bars my expectation was not that it would be automatically updated. Instead it would be updated using the exact same mechanism that we have for notifications today, i.e. using the "tag" mechanism. So the jank would be the same whether OS notifications supports rendering progress bars or if they are just able to render text. For lists the idea is not to update them any more or less than for plain text content. Just like with text content pages will likely want to update them occasionally, but that's not a core aspect of the feature. > The intent for things like progress bars > would be that they have greater visibility than your typical "5 seconds and > then hidden" email notification, which also may not be doable with many > notification frameworks. This is a quite interesting idea. I hadn't thought of that. > I'm slightly dubious about adding > new semantic notification types (I'd still rather give app developers the > tools to build their own richer notifications instead of giving them a > canned set), but it's definitely worth discussing further. I'm not sure I understand this argument. If you are concerned about having poor fallback on platforms that can't render the UI components discussed above, then surely that concern is even greater if we enable pages to build their own rich notifications? My goal has been two-fold: * Don't limit the web to the lowest common denominator of the platforms on which it runs. * Don't encourage pages that simply don't work unless you use the right OS. The "pre canned" capabilities enable us to on OSs that have advanced capabilities enable web developers to take advantage of those for the most commonly requested notification content. While still enabling users on OSs that don't have such capabilities to still get a useful experience. / Jonas
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Tue, Aug 5, 2014 at 5:04 PM, Peter Beverloo wrote: > On Tue, Aug 5, 2014 at 3:48 PM, Anne van Kesteren wrote: >> Is that available within a service worker? > > It would be reasonable to expose it, but it currently isn't (afaik). Okay, we'd need to sort that out somehow. > Defaulting to the current Service Worker sounds good. > > One case Jake and I thought of was if/when a Service Worker could get > registrations for other SWs in the origin, but that's only a theoretical > case today. I guess if that becomes available you could override it. That would work. >> We could throw a TypeError. (DOMError is not a thing.) Equivalent to >> what happens when you get the type wrong. > > I think it would be nice to be able to distinguish the invalid-value-type > case from the no-service-worker case, wouldn't you lose that by throwing > TypeErrors in both cases? It seems like you should just wait for the .ready promise, no? What is a scenario where you'd look at the error and do something different that's not clearly a bug? I filed https://github.com/whatwg/notifications/issues/19 to track this by the way. I got some positive signals from Ehsan at Mozilla. Would be nice to have a few more before we add it, but I guess there's not really that many ways to tackle this. -- http://annevankesteren.nl/
Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage
On Tue, Aug 5, 2014 at 11:21 AM, Justin Novosad wrote: > On Tue, Aug 5, 2014 at 7:47 AM, Ashley Gullen wrote: > > > I am against this suggestion. If you are serious about performance then > > you should use WebGL and implement your own batching system, which is > what > > every major 2D HTML5 game framework I'm aware of does already. Adding > > batching features to canvas2d has three disadvantages in my view: > > > > 1. Major 2D engines already support WebGL, so even if this new feature > was > > supported, in practice it would not be used. > > 2. There is opportunity cost in speccing something that is unlikely to be > > used and already well-covered by another part of the web platform. We > could > > be speccing something else more useful. > > 3. canvas2d should not end up being specced closer and closer to WebGL: > > canvas2d should be kept as a high-level easy-to-use API even with > > performance cost, whereas WebGL is the low-level high-performance API. > > These are two different use cases and it's good to have two different > APIs > > to cover them. If you want to keep improving canvas2d performance I would > > worry you will simply end up reinventing WebGL. > > > > > These are good points. The only counter argument I have to that is that a > fallback from WebGL to canvas2d is unfortunately necessary for a > significant fraction of users. Even on web-browsers that do support WebGL, > gl may be emulated in software, which can be detected by web apps and > warrants falling back to canvas2d (approx. 20% of Chrome users, for > example). I realize that there is currently a clear ease of use vs. > performance dichotomy between 2d and webgl, and this proposal blurs that > boundary. Nonetheless, there is developer-driven demand for this based on a > real-world problem. Also, if 2D canvas had better performance > characteristics, it would not be necessary for some game engines to have > dual (2d/webgl) implementations. > > -Justin > My take is similar to Ashley's, and I wonder how buffing up the toy API (2D) compensates for the fact that the performance API (GL) has compatibility problems, even on platforms that support it. If the goal is to solve the latter, why not introduce more direct proposals?
Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage
On Mon, Aug 4, 2014 at 6:39 PM, Robert O'Callahan wrote: > It looks reasonable to me. > > How do these calls interact with globalAlpha etc? You talk about > decomposing them to individual drawImage calls; does that mean each image > draw is treated as a separate composite operation? > Composited separately is the intent. A possible internal optimization: the implementation could group non-overlapping draw and composite them together. > Currently you have to choose between using a single image or passing an > array with one element per image-draw. It seems to me it would be more > flexible to always pass an array but allow the parameters array to refer to > an image by index. Did you consider that approach? > Had not thought of that. Good idea. On Mon, Aug 4, 2014 at 7:35 PM, Katelyn Gadd wrote: > I'd suggest that this needs to at least handle > globalAlpha. > It would be trivial to add a an addition format that includes alpha. > Replacing the overloading with individual named methods is something > I'm also in favor of. That's something I pondered and was not sure about. Eliminating the parameter format argument would be nice. Your feature-detection argument is a really good reason. > > I get the impression that ordering is implicit for this call - the > batch's drawing operations occur in exact order. It might be > worthwhile to have a way to indicate to the implementation that you > don't care about order, so that it is free to rearrange the draw > operations by image and reduce state changes. Doing that in userspace > js is made difficult since you can't easily do efficient table lookup > for images. > I am not sure exposing that in the API is a good idea because it opens the door to undefined behavior. It could result in different implementations producing drastically different yet compliant results. Perhaps implementations could auto-detect draw operations that are commutative based on a quick overlap analysis, and use that knowledge to automatically group draw calls that use similar drawing state (e.g. the same source GPU texture) > > Would it be possible to sneak rgba multiplication in under the guise > of this feature? ;) Without it, I'm forced to use WebGL and reduce > compatibility just for something relatively trivial on the > implementer's side. (I should note that from what I've heard, Direct2D > actually makes this hard to implement. > I think that would make this feature significantly more complex to spec, and to implement. It really should be treated as an orthogonal feature request. Your suggestion is very use-case specific. A more general incarnation of your request would be to have a blendMode parameter that that determines how the source image gets blended with the fillStyle. With that, you resolve your specific use case by setling the fill style to an rgba color, and using a multiply blend op to use it to modulate images. On Tue, Aug 5, 2014 at 7:47 AM, Ashley Gullen wrote: > I am against this suggestion. If you are serious about performance then > you should use WebGL and implement your own batching system, which is what > every major 2D HTML5 game framework I'm aware of does already. Adding > batching features to canvas2d has three disadvantages in my view: > > 1. Major 2D engines already support WebGL, so even if this new feature was > supported, in practice it would not be used. > 2. There is opportunity cost in speccing something that is unlikely to be > used and already well-covered by another part of the web platform. We could > be speccing something else more useful. > 3. canvas2d should not end up being specced closer and closer to WebGL: > canvas2d should be kept as a high-level easy-to-use API even with > performance cost, whereas WebGL is the low-level high-performance API. > These are two different use cases and it's good to have two different APIs > to cover them. If you want to keep improving canvas2d performance I would > worry you will simply end up reinventing WebGL. > > These are good points. The only counter argument I have to that is that a fallback from WebGL to canvas2d is unfortunately necessary for a significant fraction of users. Even on web-browsers that do support WebGL, gl may be emulated in software, which can be detected by web apps and warrants falling back to canvas2d (approx. 20% of Chrome users, for example). I realize that there is currently a clear ease of use vs. performance dichotomy between 2d and webgl, and this proposal blurs that boundary. Nonetheless, there is developer-driven demand for this based on a real-world problem. Also, if 2D canvas had better performance characteristics, it would not be necessary for some game engines to have dual (2d/webgl) implementations. -Justin
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Tue, Aug 5, 2014 at 3:48 PM, Anne van Kesteren wrote: > On Tue, Jul 29, 2014 at 4:28 PM, Peter Beverloo > wrote: > > When used from a Service Worker, the attribute will implicitly default to > > the ServiceWorkerRegistration of the running Service Worker. > > Is that available within a service worker? > It would be reasonable to expose it, but it currently isn't (afaik). > If serviceWorker is set to null/undefined within a ServiceWorker context, > a > > TypeError will be thrown. > > I thought the idea was to have it default somehow. It seems to me > within a service worker you cannot specify it and you simply always > get a notification associated with that service worker. > Defaulting to the current Service Worker sounds good. One case Jake and I thought of was if/when a Service Worker could get registrations for other SWs in the origin, but that's only a theoretical case today. > 1. If registration.activeWorker is null, then: > > 1. Throw a DOMError with name “InvalidStateError” > > 2. Abort these steps. > > We could throw a TypeError. (DOMError is not a thing.) Equivalent to > what happens when you get the type wrong. > I think it would be nice to be able to distinguish the invalid-value-type case from the no-service-worker case, wouldn't you lose that by throwing TypeErrors in both cases? > Events will be delivered to either the Notification instance, or to the > > Service Worker, not both. All four events will be exposed to a Service > > Worker [onnotificationshow, onnotificationclick, onnotificationclose, > > onnotificationerror]. The events will receive a NotificationEvent which > will > > contain a notification instance. > > So with each event you get a new instance of the object? I guess > that's probably what we want given how getClones() et al work. A bit > wasteful, but not too bad. > I don't think this is a massive problem, in general Notification objects will be very small (depending on the data property, of course). Peter -- > http://annevankesteren.nl/ >
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Tue, Jul 29, 2014 at 4:28 PM, Peter Beverloo wrote: > When used from a Service Worker, the attribute will implicitly default to > the ServiceWorkerRegistration of the running Service Worker. Is that available within a service worker? > If serviceWorker is set to null/undefined within a ServiceWorker context, a > TypeError will be thrown. I thought the idea was to have it default somehow. It seems to me within a service worker you cannot specify it and you simply always get a notification associated with that service worker. > 1. If registration.activeWorker is null, then: > 1. Throw a DOMError with name “InvalidStateError” > 2. Abort these steps. We could throw a TypeError. (DOMError is not a thing.) Equivalent to what happens when you get the type wrong. > Events will be delivered to either the Notification instance, or to the > Service Worker, not both. All four events will be exposed to a Service > Worker [onnotificationshow, onnotificationclick, onnotificationclose, > onnotificationerror]. The events will receive a NotificationEvent which will > contain a notification instance. So with each event you get a new instance of the object? I guess that's probably what we want given how getClones() et al work. A bit wasteful, but not too bad. -- http://annevankesteren.nl/
Re: [whatwg] Notifications improvements
On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote: > I think the most low hanging fruit would be to add the following as > data that can be displayed in a notification: > > * Progress bar Tracked here: https://github.com/whatwg/notifications/issues/17 > * Lists of title/body pairs What exactly is this for? > * Date (for things like "event will happen in 10 minutes") Should this be part of a generic alarm API? There's also a request for transient/toast notifications: https://github.com/whatwg/notifications/issues/11 > Second, we really need to figure out the story around handling user > clicking notifications after the user has closed the original page. There's a proposal for that in a separate thread: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jul/0204.html > We need to change the GC behavior. Right now it seems like if a > Notification object is created, but no event listeners are attached, > because the page is expecting to use the SW event to listen for > clicks, the notification won't be kept alive and so the SW can't get > to any of its data. Notification objects can go away, but the notification concept cannot be GC'd. > We also need to keep state on the Notification object if the user has > clicked the notification or not. Why is that? > We should also consider enabling passing a URL to the Notification > constructor which is opened when the user clicks the notification. > Probably this should attempt to reuse an existing tab with said URL if > one is open. That might be an interesting way to let service workers spawn a new window. > Third, we should look at enabling minimal user input through the > Notification. It's very common for notifications to support having one > or more buttons that the user can click. It would also be good to > enable putting a simple text-input in the notification. This area is > definitely more complex though so happy to put this last. -- http://annevankesteren.nl/
Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage
I am against this suggestion. If you are serious about performance then you should use WebGL and implement your own batching system, which is what every major 2D HTML5 game framework I'm aware of does already. Adding batching features to canvas2d has three disadvantages in my view: 1. Major 2D engines already support WebGL, so even if this new feature was supported, in practice it would not be used. 2. There is opportunity cost in speccing something that is unlikely to be used and already well-covered by another part of the web platform. We could be speccing something else more useful. 3. canvas2d should not end up being specced closer and closer to WebGL: canvas2d should be kept as a high-level easy-to-use API even with performance cost, whereas WebGL is the low-level high-performance API. These are two different use cases and it's good to have two different APIs to cover them. If you want to keep improving canvas2d performance I would worry you will simply end up reinventing WebGL. As developers of a HTML5 game engine with WebGL support and fallback to canvas2d, this has no utility to us at all. It would be more useful to work on WebGL 2. Ashley Gullen Scirra.com On 5 August 2014 00:35, Katelyn Gadd wrote: > Many, many uses of drawImage involve transform and/or other state > changes per-blit (composite mode, global alpha). > > I think some of those state changes could be viably batched for most > games (composite mode) but others absolutely cannot (global alpha, > transform). I see that you handle transform with > source-rectangle-and-transform (nice!) but you do not currently handle > the others. I'd suggest that this needs to at least handle > globalAlpha. > > Replacing the overloading with individual named methods is something > I'm also in favor of. I think it would be ideal if the format-enum > argument were not there so that it's easier to feature-detect what > formats are available (for example, if globalAlpha data is added later > instead of in the '1.0' version of this feature). > > I get the impression that ordering is implicit for this call - the > batch's drawing operations occur in exact order. It might be > worthwhile to have a way to indicate to the implementation that you > don't care about order, so that it is free to rearrange the draw > operations by image and reduce state changes. Doing that in userspace > js is made difficult since you can't easily do efficient table lookup > for images. > > if rgba multiplication were to make it into canvas2d sometime in the > next decade, that would nicely replace globalAlpha as a per-draw > value. This is an analogue to per-vertex colors in 3d graphics and is > used in virtually every hardware-accelerated 2d game out there, > whether to tint characters when drawing text, fade things in and out, > or flash the screen various colors. That would be another reason to > make feature detection easier. > > Would it be possible to sneak rgba multiplication in under the guise > of this feature? ;) Without it, I'm forced to use WebGL and reduce > compatibility just for something relatively trivial on the > implementer's side. (I should note that from what I've heard, Direct2D > actually makes this hard to implement. > > On the bright side there's a workaround for RGBA multiplication based > on generating per-channel bitmaps from the source bitmap (k, r/g/b), > then blending them source-over/add/add/add. drawImageBatch would > improve perf for the r/g/b part of it, so it's still an improvement. > > On Mon, Aug 4, 2014 at 3:39 PM, Robert O'Callahan > wrote: > > It looks reasonable to me. > > > > How do these calls interact with globalAlpha etc? You talk about > > decomposing them to individual drawImage calls; does that mean each image > > draw is treated as a separate composite operation? > > > > Currently you have to choose between using a single image or passing an > > array with one element per image-draw. It seems to me it would be more > > flexible to always pass an array but allow the parameters array to refer > to > > an image by index. Did you consider that approach? > > > > Rob > > -- > > oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo > > owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo > > osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo > > owohooo > > osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o > > oioso > > oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo > > owohooo > > osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro > > ooofo > > otohoeo ofoioroeo ooofo ohoeololo. >
Re: [whatwg] Typed numeric 'input'
2014-08-05 10:14, Christoph Päper wrote: You do realize that font size control was just an example? Well, maybe not quite; the original message discussed font size control in detail and did not mention other examples. A combined widget for number and unit would be useful in many places. I would expect most applications to decide on a unit or (sub)multiple of unit for each quantity. To process the input, the value would normally need to be converted to use a specific unit anyway. Although most of us use metric units exclusively for almost all applications, there are still a lot of scenarios where two or more units are commonly used – even with the SI some may prefer centimetres over millimetres sometimes (or vice versa). The SI unit of distance is the meter. The centimeter and the millimeter are just submultiples of the meter. But I can see that it might be useful on some contexts to let the user decide which of these submultiples is used, e.g. when specifying dimensions of household equipment. This however sounds rather simple: have just one field for the number and a dropdown with “mm” and “cm” as alternatives. Even then, fixing the unit might actually be better usability (don’t force the user make to decisions if there is a reasonable way to avoid that(. An addition to the ways mentioned, the font size control could be simply two buttons, one for increasing and one for decreasing the size, (…) This seems like a special cased ‘numeric’ or ‘range’ widget and is agnostic of units. It is, and probably therefore favored by many designers. It’s simple, often too simple, but I mentioned it just as a common example. The designer needs to decide the internal representation of the font size and to map the alternatives in the UI to that. I don’t see how additions to HTML would significantly help here, even if they happened to match the approach that is selected by the designer. The point is that some such approaches are possible already, but not all. The simple possible solutions are rather clumsy and not very user-friendly. I don’t see anything clumsy with two fields, one for a number, another for a unit. If there is any clumsiness, it’s in the idea of making the user select the unit. There can be reasons to do so, of course, but in such special cases, the UI and the code implementing it needs to be tuned according to the special requirements. Every author could, of course, just parse all free user input from a ‘text’ input server-side, but why shouldn’t browsers sanitize such input like they do for other form controls? Because it is up to the designer to decide what the allowed formats are, how errors are handled, etc. The format is generally locale-dependent, and localization is poorly handled at present in HTML – it has a vague idea of using the system locale, the browser locale, the document language locale, or something else. This mess should be cleared up before new features requiring localizations are added. To the extent that general code for handling such issues can be written, it should be in libraries and frameworks, rather than as constructs that browsers are required to implement. Yucca
Re: [whatwg] Typed numeric 'input'
Jukka K. Korpela : > 2014-08-04 20:06, Christoph Päper wrote: > >> Imagine a text layout GUI made with HTML. >> It would probably feature a font size selection control. >> There are different ways to do such a thing: > > There are, and they are preferred in different ways by different people, as > programmers or as end users. This is why any solution, in addition to > introducing considerable complexity into HTML, would be used for a small > fraction of potential use cases only. You do realize that font size control was just an example? A combined widget for number and unit would be useful in many places. Although most of us use metric units exclusively for almost all applications, there are still a lot of scenarios where two or more units are commonly used – even with the SI some may prefer centimetres over millimetres sometimes (or vice versa). Not to mention US localisation. > An addition to the ways mentioned, the font size control could be simply two > buttons, one for increasing and one for decreasing the size, (…) This seems like a special cased ‘numeric’ or ‘range’ widget and is agnostic of units. > The designer needs to decide the internal representation of the font size and > to map the alternatives in the UI to that. I don’t see how additions to HTML > would significantly help here, even if they happened to match the approach > that is selected by the designer. The point is that some such approaches are possible already, but not all. The simple possible solutions are rather clumsy and not very user-friendly. Every author could, of course, just parse all free user input from a ‘text’ input server-side, but why shouldn’t browsers sanitize such input like they do for other form controls?
