| 14:59 | <gnarf> | anyone know if there is a spec / polyfill implementation for the CSS colors API: http://dev.w3.org/csswg/css-color/#apis ? |
| 14:59 | <gnarf> | s/spec/tests/ |
| 15:00 | <Ms2ger> | Neither |
| 15:00 | <gnarf> | I might start working on one / look at turning into jQuery Color 3 |
| 15:00 | <gnarf> | the api is close enough i could consume it in jQuery color |
| 15:01 | <caitp> | i'm surprised lea doesn't have something like that already |
| 15:40 | <Domenic> | gnarf: I think that API is less than a week old :) |
| 15:40 | <gnarf> | *shrug* |
| 15:40 | <gnarf> | worth looking into |
| 15:40 | <gnarf> | i already have most of it written |
| 15:42 | <Domenic> | definitely! just, i would be surprised if any polyfills existed |
| 15:43 | <gnarf> | i'm never surprised when someone beats me to a polyfill though :) |
| 18:19 | <smaug____> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/#rules-for-parsing-a-hash-name-reference step 3. What is the context there? "Return the first element" is rather vague. Should it be return the first element in document ... Or is it about the same subtree where img element lives (in case of usamap)? |
| 18:19 | <smaug____> | usemap |
| 18:19 | Hixie | looks... |
| 18:20 | <Hixie> | hm yeah, it doesn't say which Document, huh |
| 18:23 | <Hixie> | smaug____: do you happen to know the right answer? |
| 18:23 | <Hixie> | smaug____: i've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26359 -- if you happen to know what the compat need is, add a comment; otherwise, you can assume i'm going to make the spec use the Document of the <img> or <object>, not the home subtree |
| 18:24 | <smaug____> | yeah, Document sounds better |
| 18:24 | <smaug____> | shadow DOM may want some changes, but not sure what kind of |
| 19:05 | <caitp> | if you open http://plnkr.co/edit/Wli7OkXQJ2V772jH95rb?p=preview in firefox, is the behaviour in firefox acceptable in terms of the spec? (like, is this an implementation-defined thing where no standard behaviour should ever be expected?) |
| 19:55 | <MikeSmith> | caitp: you mean that gecko changes the value the moment you focus on it, instead of waiting for you to actually select it? |
| 19:55 | <caitp> | yeah |
| 19:56 | <caitp> | it seems to be correct as far as things are defined in the spec, but it still seems really bizarre |
| 19:58 | <gsnedders> | caitp: yeah, that's well into impl-defined behaviour |
| 19:58 | <caitp> | I don't think that should be implementation defined, because it breaks interoperability under certain circumstances |
| 19:59 | <caitp> | we've found a whole pile of interop issues between the different implementations with select controls, it makes things very difficult :( |
| 20:14 | <MikeSmith> | caitp: gsnedders I think even if the spec doesn't explicitly prohibit it, that's bad UX for end users, and counter-intuitive for Web developers |
| 20:15 | <MikeSmith> | I don't expect my application behavior to change when a user simply changes the focus of a select control without actually you know, intentionally selecting something |
| 20:18 | <gsnedders> | I feel like for some of the form widgets many mobile platforms don't have the clear focusing distinction that you get on most desktop OSes |
| 20:18 | <caitp> | one of the interns filed a bug about this with gecko, I'm just trying to make a case for it |
| 20:19 | <gsnedders> | but maybe that's not true, idk |
| 20:19 | <caitp> | well I think it's more that on mobile/touch screens you can't really "hover" |
| 20:22 | <MikeSmith> | caitp: hard to judge from that plunk, since when I view it in Nightly on my mobile I don't even get a select control showing up |
| 20:25 | <caitp> | yeah, I think plunker has some issues with a good number of browsers, have to talk to ggoodman about that =) it should work better in jsfiddle |
| 20:25 | <MikeSmith> | oh http://run.plnkr.co/gZNU4S2M19ttmRa0/ does work on mobile though |
| 20:26 | <smaug____> | caitp: what is bizarre in the Gecko behavior ? |
| 20:26 | <caitp> | smaug____, the bizarre thing is that the selectedness of options change when you hover the cursor over them |
| 20:26 | smaug____ | could be missing something |
| 20:26 | <smaug____> | so? |
| 20:26 | <caitp> | so, this is not behaviour shared with any other browser on the market, and is kind of unexpected |
| 20:27 | <smaug____> | why it is unexpected? |
| 20:27 | <MikeSmith> | caitp: and if you use it on mobile the action of changing the focus of the select control does in fact amount to the same action as actually selecting a new value. No clear distinction, as gsnedders pointed out |
| 20:27 | <caitp> | yes, but I think that's fine for touch screens |
| 20:28 | <caitp> | it's more awkward for actual pointers |
| 20:28 | <MikeSmith> | yeah, agreed |
| 20:28 | <MikeSmith> | on desktop that's counter-inutitive and badly surprising |
| 20:29 | smaug____ | can't understand the issue |
| 20:30 | <caitp> | imagine you're ordering a pizza, and you are just reading the menu, and the act of reading the menu causes your credit card to be charged before you've made a decision |
| 20:30 | <caitp> | it's kinda like that |
| 20:30 | <MikeSmith> | smaug____: a user doesn't expect things to change in an application if they simply just focus on a different option in a select control prior to actually intentionally selecting a different option |
| 20:31 | <MikeSmith> | it's a two-step action on desktop, where you have a pointer |
| 20:32 | <MikeSmith> | and gecko is prematurely deciding the user has selected something before the user has actually completed the action |
| 20:33 | <smaug____> | it is the current selection |
| 20:34 | <smaug____> | I don't see the UX issue, but I can see how this could lead to issues if web apps rely on behavior of other browsers |
| 20:50 | <gnarf> | TabAtkins: you happen to be around? |
| 20:52 | <gnarf> | TabAtkins: looking at implementing some tests / the ecmascript api for css color module 4 - one question i had - how do to deal with out of range values, i.e. 1.1 lightness - 110% ? |
| 20:52 | <TabAtkins> | Nothing special. They're valid, and get handled by CSS when you serialize them. |
| 20:53 | <gnarf> | to hex? |
| 20:53 | <gnarf> | 256 -> hex ? |
| 20:54 | <TabAtkins> | Is possible to specify colors outside if the sRGB gamut. |
| 20:54 | <TabAtkins> | The hex IDL prevents them from going above 255 or below 0 |
| 20:54 | <gnarf> | aha - i see |
| 20:54 | <TabAtkins> | [Clamp] octet does that |
| 20:54 | <Domenic> | gnarf: write them as web-platform-tests so you can contribute them to the common browser test suite! |
| 20:54 | <gnarf> | miseed that [Clamp] octet |
| 20:55 | <MikeSmith> | smaug____: https://bugzilla.mozilla.org/show_bug.cgi?id=1039047 (regarding the select behavior) by way of caitp by way of https://github.com/angular/angular.js/pull/8221 |
| 20:56 | <caitp> | oh man, our top secret conversation! |