| 01:38 | <cabanier> | Hixie_: what can you tell me about the history of hit regions in canvas? |
| 02:13 | <MikeSmith> | cabanier: here now |
| 02:37 | <zewt> | grr @ sites that try to keep you from f5-refreshing forcing me to focus the address bar first (twitter) |
| 02:37 | <zewt> | very not understanding browsers allowing pages to preventDefault browser hotkeys |
| 03:07 | <cabanier> | MikeSmith: things are getting confusing with hit regions |
| 03:08 | <cabanier> | MikeSmith: I'm not sure where to go from here |
| 03:09 | <MikeSmith> | cabanier: me neither |
| 03:09 | <MikeSmith> | and now it appears Rich is going to be on vacation for quite some time |
| 03:09 | <cabanier> | MikeSmith: yes. I was hoping someone else could chime in |
| 03:10 | <MikeSmith> | I think at this point what's most important is what you and Dominic have to say |
| 03:10 | <cabanier> | MikeSmith: Well, I implemented what the spec said |
| 03:11 | <cabanier> | MikeSmith: I don't know enough about accessibility to know if it's useful |
| 03:11 | <MikeSmith> | well, Dominic does for sure |
| 03:12 | <cabanier> | If it's just the API call, that's relatively easy to change |
| 03:13 | <cabanier> | I was trying to find more history but I could only find a posting from 2011 where they split the calls |
| 03:13 | <cabanier> | It sounds like Hixie wanted that split |
| 03:13 | <MikeSmith> | that sounds vaguely familiar |
| 03:13 | <cabanier> | There was also a blog post from Steve Faulkner |
| 03:14 | <cabanier> | I tried to ping him to see if he remembers |
| 03:14 | <MikeSmith> | Steve may remember more of the history at this point |
| 03:14 | <cabanier> | he's probably asleep now |
| 03:14 | <MikeSmith> | yeah |
| 03:15 | <MikeSmith> | there's this guy Charles Pritchard who was involved somewhat |
| 03:15 | <MikeSmith> | dunno where he is now |
| 03:15 | <cabanier> | I found some posts from him as well, but it sounds like he wanted some sort of DOM |
| 03:15 | <MikeSmith> | or whether it's be worthwhile to ask him about the background |
| 03:15 | <MikeSmith> | yeah |
| 03:16 | <MikeSmith> | from what I recall there were a lot of unfounded assertions about the way things had to be for accessibility reasons, without any real evidence |
| 03:17 | <MikeSmith> | one use case that was behind a lot of it was the case of creating a text editor in canvas |
| 03:17 | <MikeSmith> | which we all universally agree is a bad idea |
| 03:18 | <cabanier> | yes |
| 03:18 | <cabanier> | it would be good if that was documented somewhere |
| 03:18 | <MikeSmith> | but they kept asserting that people are going to create text editors in canvas anyway, so we have to provide for it |
| 03:18 | <cabanier> | it seems that it could work with the current approach |
| 03:19 | <cabanier> | Not sure if authors will bother though |
| 03:19 | <MikeSmith> | I think they sort of preferred that it not be documented or even would have preferred not discussing it publicly |
| 03:19 | <MikeSmith> | yeah |
| 03:19 | <cabanier> | argh |
| 03:20 | <cabanier> | I'm inclined to say that if the a11y people signed off on this API, we should just implement it as-is |
| 03:21 | <cabanier> | I'm sure there were many discussions and I don't want to start from zero again |
| 03:22 | <cabanier> | Hopefully Hixie and Steve can enlighten me |
| 03:39 | <MikeSmith> | cabanier: I think the attitudie of "if the a11y people signed off on this API, we should just implement it as-is" is the wrong attitude to have |
| 03:39 | <MikeSmith> | that's what got us here to begin with |
| 03:40 | <MikeSmith> | first off there is no monolithic block of a11y people |
| 03:41 | <MikeSmith> | for example, there are many a11y people like James Craig who think that longdesc is actually bad for accessibility, but we now have it anyway |
| 03:43 | <MikeSmith> | there are some within the community who don't have enough technical insight into the details, so they just go along with what the party line is on it |
| 03:43 | <cabanier> | well, someone proposed this API and got it in the spec |
| 03:44 | <cabanier> | I must assume that they knew what they were doing |
| 03:44 | <MikeSmith> | I think you must now assume that |
| 03:44 | <cabanier> | that's why it would be great to see the discussion |
| 03:44 | <cabanier> | the current APIs seem very useful |
| 03:44 | <MikeSmith> | we are talking about basically 2 people who proposed that API and got it into the spec |
| 03:45 | <MikeSmith> | the rest of the people were along for the rid |
| 03:45 | <MikeSmith> | *ride |
| 03:46 | <cabanier> | brb |
| 03:46 | <MikeSmith> | *must not assume they knew what they were doing |
| 03:47 | <MikeSmith> | cabanier: when you're back I suggest you try to get some of Hixie's time to discuss this |
| 04:11 | <cabanier> | MikeSmith: who are the 2 people? |
| 04:27 | <MikeSmith> | Rich and Charles Pritchard |
| 04:27 | <MikeSmith> | cabanier: ↑ |
| 04:29 | <MikeSmith> | cabanier: I think if you are implementing things based on ane "I must assume that they knew what they were doing" principle, you are not helping anybody. |
| 04:29 | <cabanier> | Rich said that Hixie wanted the split |
| 04:29 | <cabanier> | :-) |
| 04:29 | <MikeSmith> | yeah I don't recall in this particular case |
| 04:30 | <MikeSmith> | which is another reason you really should talk Hixie |
| 04:30 | <cabanier> | yes |
| 04:30 | <MikeSmith> | but I think Hixie will be the first to tell you that you should not just assume that he knew what he was doing |
| 04:31 | <cabanier> | drawSystemFocusRing looks OK and Dominic is fine with it |
| 04:31 | <cabanier> | drawCustomFocusRing is OK too (I think), just that the name is confusing |
| 04:32 | <cabanier> | Maybe I should land it as an experimental feature in firefox and keep the API at risk |
| 06:05 | <Hixie_> | cabanier1: i'm briefly here now if you are around, otherwise i'll be back online tomorrow morning |
| 06:07 | <Hixie_> | afk. will be back tomorrow morning. |
| 09:51 | <jgraham> | Hmm, Monday morning, 118 emails from github over the weekend |
| 14:40 | <annevk> | arv: did you end up investigating hasAttributes() removal? |
| 14:40 | <annevk> | arv: I can't find an issue number |
| 14:41 | <arv> | annevk: I added a use counter. It will take time to get useful data |
| 14:41 | <annevk> | arv: aight, cool |
| 14:45 | <jgraham> | Ms2ger: Huh? What am I missing? |
| 14:45 | <Ms2ger> | ? |
| 14:46 | <jgraham> | Your review request |
| 14:46 | <jgraham> | I don't see where WebIDLParser.js would come from |
| 14:47 | jgraham | forwards review to darobin |
| 14:47 | <Ms2ger> | jgraham, should be symlinked or something, I think |
| 14:47 | <Ms2ger> | There definitely isn't a http://www.w3c-test.org/resources/webidl2.js |
| 14:47 | <jgraham> | No, it looks like it should be resources/webidl2/lib/webidl2.js |
| 14:49 | <Ms2ger> | I think we didn't want to require changing all files that use idlharness |
| 14:49 | <jgraham> | darobin: ^? |
| 14:49 | <jgraham> | I have no idea, really |
| 14:49 | <jgraham> | But I at least don't see how what you wrote works |
| 14:50 | <Ms2ger> | http://www.w3c-test.org/resources/WebIDLParser.js exists |
| 14:50 | <darobin> | yeah but it's symlinked |
| 14:51 | <darobin> | it would be better to change all the files that use idlharness, there aren't that many |
| 14:51 | <Ms2ger> | I'd rather not |
| 14:51 | <darobin> | well, either that or we might need something better than symlinking |
| 14:51 | <jgraham> | OK, "it's symlinked" isn't a good enough solution |
| 14:51 | <darobin> | because symlinking just won't work everywhere |
| 14:51 | <darobin> | I reckon the alternative is to have wptserve know about this |
| 14:52 | <Ms2ger> | "Not use this submodule crap" is one :) |
| 14:52 | <jgraham> | I think the alternative is just to make the change |
| 14:52 | <darobin> | Ms2ger: any reason not to change those files? |
| 14:52 | <darobin> | feel free to replace this with something better |
| 14:52 | <darobin> | one other option is an install script of some sort |
| 14:52 | <Ms2ger> | Cool URIs, and stuff |
| 14:52 | <jgraham> | Which it kind of seems like Aryeh is doing whilst we chat about it |
| 14:52 | <darobin> | webidl2 can be found on npm, or if not should |
| 14:53 | jgraham | isn't introducing a node dependency :) |
| 14:53 | <Ms2ger> | How does that help? |
| 14:54 | <jgraham> | Anyway, I think people should just have to write /resources/webidl2/lib/webidl2.js |
| 14:54 | <jgraham> | If this is just a sed-level change let's just fix up everything |
| 14:54 | <Ms2ger> | As long as you update m-c too :) |
| 14:55 | <jgraham> | What's the problem updating m-c? |
| 14:55 | <jgraham> | It doesn't seem harder than any other kind of update |
| 14:56 | <jgraham> | (but you are the expert) |
| 14:57 | <Ms2ger> | I'm lazy :) |
| 14:58 | darobin | gives Ms2ger a cookie to get him working |
| 14:58 | Ms2ger | eats the cookie, is still lazy |
| 16:20 | <dglazkov> | good morning, Whatwg! |
| 17:08 | <cabanier> | Hixie_: ping |
| 17:14 | <smaug____> | Hixie_: ping |
| 17:19 | <zewt> | it's like a radar testing facility in here |
| 17:20 | <jgraham> | Hixie_: I represent the silent majority who have no need of your attention right now |
| 17:24 | <zewt> | but are highlighting his window anyway |
| 17:25 | <jgraham> | That's only a minority of the aforementioned majority |
| 17:39 | <TabAtkins> | MikeSmith: Actually, that particular example is a *huge* improvement over srcset, for equivalent functionality. Check out Example 4 in my draft, which shows a similar example in both viewport-style and MQ-and-Nx style. The latter one is *much* worse, and it's not even as correct - getting it closer would make it even more horrible. |
| 17:40 | <TabAtkins> | If you're complaining that it's not as simple as a single, simple srcset, well duh - you're invoking much more powerful stuff. If you want equal power, it's *exactly identical to srcset's syntax*. |
| 17:42 | <TabAtkins> | jgraham: I'm just skimming the discussion, but if you're using Python and need a webidl parser, maybe try Peter Linss'? I'm using it in bikeshed. https://github.com/plinss/widlparser |
| 17:43 | jgraham | doesn't need a WebIDL parser |
| 17:43 | <TabAtkins> | jgraham: Okay, I just see y'all talking about webidlparser.js |
| 17:43 | <jgraham> | idlharness.js needs a javascript WebIDL parser. Which we have. But not in a convenient location |
| 17:43 | <TabAtkins> | Ah, never mind then. |
| 17:44 | <jgraham> | Thanks for the suggestion anyway :) |
| 18:01 | <smaug____> | Hixie_: nm |
| 18:02 | <Hixie_> | smaug____, cabanier, jgraham: pong |
| 18:02 | <Hixie_> | wait, not jgraham and not smaug____ any more |
| 18:02 | <Hixie_> | just cabanier |
| 18:03 | <annevk> | srcN looks even uglier |
| 18:06 | <cabanier> | Hixie_: hi |
| 18:06 | <cabanier> | Hixie_: can you tell me the history of the canvas focus rings? |
| 18:07 | <Hixie_> | not off the top of my head, no |
| 18:07 | <Hixie_> | anything in particular? |
| 18:07 | <cabanier> | Well, Dominc seems to have doubts about drawSystemFocusRing |
| 18:07 | <cabanier> | I think the name is very confusing... |
| 18:08 | <TabAtkins> | annevk: Try it, dude. For anything that srcset can do by itself, just do a s/srcset/src-1/ and you have converted it into my proposal. For anything that <picture>-with-MQ-and-srcset can do, srcN does more compactly and imo not any uglier, if you format well (similar to how you'd format the child elements of <picture>). For the things that srcN's viewport |
| 18:08 | <TabAtkins> | syntax does, <picture>-with-MQ-and-srcset is *way* longer and uglier. |
| 18:08 | <cabanier> | why was it split up in 2 methods? |
| 18:08 | <Hixie_> | cabanier: there's two use cases. Some people want to get whatever the system focus ring is, and some people want to draw their own focus rings. |
| 18:08 | <TabAtkins> | That last isn't something you can reasonably argue, unless you've just never actually seen the comparison and are arguing from a mistaken assumption of what each would look like. |
| 18:08 | <cabanier> | yeah. |
| 18:09 | <TabAtkins> | <picture> just ends up *way* longer, with loads of duplication. |
| 18:09 | <Hixie_> | isn't <picture> dead yet? |
| 18:09 | <annevk> | TabAtkins: I'm no fan of <picture> btw, that seems crazy |
| 18:09 | <cabanier> | but they both start with 'draw' so it's unclear that one of them doesn't draw |
| 18:09 | <Hixie_> | <picture> is a non-starter |
| 18:09 | <TabAtkins> | Hixie_: Practically, yes, since no implementor wants <source> elements. |
| 18:09 | <Hixie_> | TabAtkins: right |
| 18:09 | <Hixie_> | TabAtkins: that's what i told the <picture> advocates many times... |
| 18:09 | <annevk> | Using <video>-style markup (which was a disaster to begin with) but with way different semantics is ... |
| 18:09 | <Hixie_> | and srcset="" does everything <picture> does, anyway |
| 18:10 | <Hixie_> | cabanier: well, they both can draw |
| 18:10 | <Hixie_> | cabanier: i'm open to better names if there are any proposals on the table, though |
| 18:10 | <TabAtkins> | Hixie_: It doesn't, not quite, though for the common MQs you'd use with <picture>, it's fine. But both of them are horrible when you have a variable-width image that you want to deliver an appropriate-density image to. |
| 18:11 | <cabanier> | Hixie_: true that it could draw. I guess it's confusing either way |
| 18:11 | <Hixie_> | TabAtkins: what doesn't srcset handle? |
| 18:11 | <Hixie_> | TabAtkins: srcset="" is pretty much as terse as you can get it, i think. hard to see how you'd get the same information any more tersely. |
| 18:11 | <cabanier> | Hixie_: I thought src-set requires ugly complex syntax |
| 18:11 | <TabAtkins> | Say you have a header image meant to be 100% of the viewport wide. "100%" can translate to anywhere from ~300px to ~2000px (or more). |
| 18:11 | <cabanier> | Hixie_: srcN just pulls it apart |
| 18:12 | <Hixie_> | i don't know what srcn is |
| 18:12 | <TabAtkins> | A 1000px-wide source image functions as both a 1x image at 1000px viewport size, and a 2x iamge at 500px viewport size. |
| 18:12 | <TabAtkins> | And so to get that all to work correctly, you've got to write the same urls over and over again with different density descriptors, at different viewport widths that you have to kind of guess at. |
| 18:13 | <cabanier> | http://tabatkins.github.io/specs/respimg/Overview.html |
| 18:13 | <Hixie_> | that's pretty rare. you don't generally want an image to be half as big in the same space, surely. |
| 18:13 | <TabAtkins> | Hixie_: I... just described to you a case where you'd want that, and it's not rare at all. |
| 18:14 | <Hixie_> | show me a page that does this. |
| 18:15 | <TabAtkins> | I'm not going to go find you a page with a header image that fills the viewport. They're everywhere. If they're responsive rather than fixed-width, they're exactly the case I describe. |
| 18:15 | <SimonSapin> | http://lesgarsdelamarine.org/ |
| 18:15 | <TabAtkins> | SimonSapin: Hahaha |
| 18:16 | <Hixie_> | there's no art direction on that page, it's just a pixel density thing |
| 18:16 | <Hixie_> | so that's not a useful example |
| 18:16 | <TabAtkins> | ...yes, exactly. |
| 18:16 | <Hixie_> | srcset handles that one fine |
| 18:16 | <TabAtkins> | This isn't an art-direction case. |
| 18:16 | <TabAtkins> | It's a pixel-density case, where you can't describe the pixel density of each url once, because you dont' know what the target size will be. |
| 18:16 | <TabAtkins> | You have to describe it multiple times, at multiple target sizes. |
| 18:17 | <TabAtkins> | In that page Simon just provided, if you wanted to actually optimize your delivery, you'd want multiple version of the image at various sizes, and then you want to let the browser choose whether to download one that close to 1x, or close to 2x, or whatever. |
| 18:18 | <Hixie_> | sure. srcset handles that fine. |
| 18:18 | <TabAtkins> | No. No it doesn't. |
| 18:18 | <TabAtkins> | It handles it *extremely verbosely*. |
| 18:19 | <TabAtkins> | And with a lot of unnecessary work on the author's side, figuring out best guesses at where to cut the breakpoints for classifying a given image as 1x or 2x. |
| 18:19 | <TabAtkins> | Check example 3 here: http://tabatkins.github.io/specs/respimg/Overview.html#viewport |
| 18:19 | <TabAtkins> | Doing something equivalent in srcset would be really long and frustrating to read/write/edit. |
| 18:21 | <TabAtkins> | This precise case has been argued well by John Mellor regarding the CSS image-set() function, and applies equally to srcset (since MQ+image-set() is roughly equivalent to the full srcset syntax). |
| 18:22 | <Hixie_> | isn't it just <img style="width: 100%" src="big.jpeg" srcset="small.jpeg 500w, big.jpeg 500w 2x"> |
| 18:22 | <Hixie_> | ...? |
| 18:22 | <Hixie_> | http://damowmow.com/playground/demos/img/001.html |
| 18:22 | <TabAtkins> | Oh good lord not. |
| 18:22 | <Hixie_> | why not? what doesn't that do? |
| 18:23 | <Hixie_> | i'm trying to do the example you gave above. A 1000px-wide source image functions as both a 1x image at 1000px viewport size, and a 2x iamge at 500px viewport size. |
| 18:23 | <TabAtkins> | Only providing two images means that you're either sending *way* too many pixels to small screens, or way too few to large screens. |
| 18:23 | <Hixie_> | that's the example you gave |
| 18:23 | <Hixie_> | SimonSapin: (thanks, btw) |
| 18:24 | <TabAtkins> | That was an example of the wider problem. You want a 500px wide iamge as well, for a small-screen 1x version. And a 2000px wide image, for a large-screen 2x version. |
| 18:24 | <Hixie_> | please specify a specific problem that we can compare |
| 18:25 | <TabAtkins> | I dont' see why you can't trivially extrapolate this to the full problem. Do you not understand the problem I'm laying out? |
| 18:25 | <Hixie_> | if i did i wouldn't be pretending i didn't... |
| 18:26 | <TabAtkins> | It's honestly hard to tell sometimes... ^_^ |
| 18:26 | <Hixie_> | o_O |
| 18:26 | <SimonSapin> | TabAtkins: just give an example of the super verbose thing |
| 18:26 | <TabAtkins> | You sometimes do a really good impression of someone being intentionally obtuse, is all. |
| 18:26 | <TabAtkins> | SimonSapin: Yeah, writing that up. |
| 18:27 | <Hixie_> | i am never intentionally obtuse. i try to ask questions that will get me to a point of understanding a problem asap. |
| 18:27 | <TabAtkins> | Hixie_: Okay, so problem statement: You want to deliver an appropriate-density image regardless of what screen size the user has. You have to cover screens as small as 320px, and as large as 2000px. |
| 18:28 | <Hixie_> | how many images? |
| 18:28 | <Hixie_> | and what densities are we trying to support? |
| 18:28 | <TabAtkins> | You need to deliver a images that are approximately 1x and 2x for each screen, and it woudl be nice to also deliver .5x (for low-bandwidth situations). |
| 18:28 | <TabAtkins> | I'm getting there! |
| 18:29 | <Hixie_> | no rush, just asking questiosn to understand the situation :-) |
| 18:29 | <TabAtkins> | So, given those constraints, figure out how many breakpoints you need in srcset to cover all screens with those densities, and then write it out. |
| 18:30 | <TabAtkins> | I think you need at least 4 breakpoints, with each delivering 3 images. |
| 18:30 | <Hixie_> | what are we trying to optimise here? i'm confused |
| 18:30 | <Hixie_> | this is an underconstrained problem |
| 18:30 | <TabAtkins> | You're trying to display an image that is viewport-width, delivering an appropriately-sized image (in terms of number of pixels sent down). |
| 18:31 | <Hixie_> | what is "appropriate"? |
| 18:31 | <TabAtkins> | You dont' want to send a 1000px-wide image to a 320px viewport, for example, because that's at least a 3x. |
| 18:31 | <TabAtkins> | Close to 1x, 2x, and optimally .5x density. |
| 18:31 | <TabAtkins> | So for a 320px viewport seeking a 1x image, you should be able to deliver something that is approximately 320px wide. |
| 18:31 | <TabAtkins> | Etc. |
| 18:31 | <Hixie_> | (for the record, i don't think anyone ever wants to send .5x density images, but i'll ignore that for now) |
| 18:32 | <Hixie_> | 3x needed pixels is too much; is 2x too much? 1.5x? |
| 18:32 | <TabAtkins> | 2x is too much unless the device is *looking* for a 2x image, because it's a 200dpi screen or whatever. That's four times as many pixels, after all! |
| 18:33 | <TabAtkins> | You can make a reasonable choice as to exactly where the breakpoint is - I suggest either the additive or multiplicative average. |
| 18:35 | <Hixie_> | TabAtkins: dude whatever i pick you'll be like "well that's inappropriate, and with _this_ choice, srcN is better!", hence my wanting to pin it down |
| 18:35 | <TabAtkins> | I will be like that, because anything that's anywhere near close to the right behavior will be horrible as hell to write with srcset. |
| 18:35 | <TabAtkins> | I already know this, because I've been through this argument on your side of the table already. |
| 18:36 | <Hixie_> | TabAtkins: ok that's great but i'd like to know this also |
| 18:36 | <TabAtkins> | (While trying to argue against addressing this in image-set().) |
| 18:36 | <Hixie_> | TabAtkins: so what is the appropriate additional overhead? |
| 18:36 | <Hixie_> | maximum overhead |
| 18:36 | <Hixie_> | 1.25? |
| 18:36 | <Hixie_> | 1.5? |
| 18:36 | <Hixie_> | 1? |
| 18:36 | <TabAtkins> | Just go with 1.5. That's fine. |
| 18:36 | <Hixie_> | (1 being "never send an image bigger than needed) |
| 18:36 | <Hixie_> | ok |
| 18:37 | <TabAtkins> | More than that is definitely bad. 1.5 isn't ideal for optimality, but whatever, it's simple and not too far off. |
| 18:37 | <Hixie_> | (what's ideal?) |
| 18:37 | <Hixie_> | and these images are all the same image, just resized? |
| 18:37 | <TabAtkins> | Dunno, but probably the multiplicative average. |
| 18:37 | <TabAtkins> | Yeah. |
| 18:38 | <Hixie_> | with the master being 2000 * 2x? |
| 18:38 | <Hixie_> | (i've no idea what "the multiplicative average" means here) |
| 18:38 | <TabAtkins> | About 1.3. |
| 18:38 | <TabAtkins> | sqrt of 2 |
| 18:38 | <Hixie_> | ok, i can do 1.3 |
| 18:38 | <TabAtkins> | You can have a master of whatever size you want, but it should be appropriate to deliver at 2x density to a 2000px wide viewport, yeah. |
| 18:39 | <TabAtkins> | (If a different number would be easier, because it has more factors of 2 in it, that's fine.) |
| 18:39 | <SimonSapin> | Isn’t “ideal” approached asymptotically with infinitely many breakpoints? :) |
| 18:40 | <Philip`> | Surely ideal would be when the server has pre-generated an image that is precisely the same number of pixels as it will be displayed as, while also taking account of the screen's sub-pixel layout and orientation and the distance of the user's eyes |
| 18:40 | <Hixie_> | that's why i'm trying to find tab's definition |
| 18:41 | <TabAtkins> | This is a fair definition of ideal that lets you space things as far apart as possible without being silly. |
| 18:42 | <TabAtkins> | Btw, going to lunch now. Be back in an hour. My solution is Example 3 in my spec, which has been linked already. |
| 18:45 | <Hixie_> | (example 3 doesn't have enough images to satisfy your constraints) |
| 18:48 | <zewt> | "You have to cover screens as small as 320px, and as large as 2000px." newer monitors are 2560x1440 |
| 18:49 | <SimonSapin> | there is at least one 2560x1600 tablet |
| 18:49 | <Hixie_> | he said 2000px at 2x |
| 18:49 | <Hixie_> | so that's 4000px |
| 18:50 | <SimonSapin> | oh, CSS px |
| 18:50 | <Hixie_> | also, i don't have any photos that are 4000px wide in my albums, bummer. |
| 18:50 | <zewt> | ah |
| 18:50 | Hixie_ | goes to google image search |
| 18:52 | <zewt> | Hixie_: http://blogs.getty.edu/iris/open-content-an-idea-whose-time-has-come/ |
| 18:53 | <Hixie_> | that would also have worked, probably :-) |
| 18:53 | <zewt> | probably would take a bit longer, heh |
| 18:55 | <Philip`> | SimonSapin: There's at least one 3840x2560 tablet too |
| 18:55 | <SimonSapin> | cool |
| 18:55 | <Philip`> | 4K video is the hot thing now that everyone wants to support |
| 18:55 | <Philip`> | (Everyone who makes money from selling expensive technology, at least) |
| 18:55 | <zewt> | how long until 4k video at 2x |
| 18:57 | <Philip`> | HEVC apparently supports 8192x4320, but I guess you'll have to wait for another generation to codecs to go any higher |
| 18:58 | <Philip`> | (and I think almost all current hardware implementations are limited to 4K) |
| 19:01 | <zewt> | i wonder what the pixels-per-degree-of-vision is comparing 4k at 10' to iPad resolution at handheld distance |
| 19:02 | <Hixie_> | didn't Red make a camera that was 8K or something? |
| 19:02 | <Hixie_> | just recently |
| 19:02 | <zewt> | wouldn't be surprised if they want higher resolution than the final resolution, to allow for loss during postprocessing |
| 19:04 | <Hixie_> | TabAtkins: it's actually not anywhere near as bad as i thought it would be, with srcset="". I'm curious to see what your proposal would look like for this, fitting the same actual constraints (the one in the spec doesn't): http://damowmow.com/playground/demos/img/002/test.html |
| 19:04 | <Hixie_> | bbiab, lunch |
| 19:11 | <Philip`> | Camera resolutions are arguably cheating a bit since they only capture a single colour component per pixel, so they're not able to resolve as much detail as you might hope for |
| 19:27 | <annevk> | Hixie_: RED has 6K, with a little over 19MP, there's others that have 8K |
| 19:28 | <TabAtkins> | Hixie_: Right, to fully satisfy my requirements, I'd have to add one more image to the Example 3 syntax in my spec. |
| 19:30 | <TabAtkins> | Hixie_: But basically, under my proposal it requires almost 1/3 the urls, because you never have to duplicate them, and no real math to find breakpoints. |
| 19:33 | <annevk> | These examples seem crazy... I wonder what percentage of sites will ever use more than the 2x variant... |
| 19:33 | <annevk> | Over engineering like it's '95 |
| 19:34 | <TabAtkins> | annevk: Probably a smallish percentage, but when you need it, it's terrible any other way. In any case, just doing the Nx stuff is fine in my spec. |
| 19:40 | <zewt> | 1.5 is unfortunately common now too, Amazon needs to be deposited into the sun for that one |
| 19:41 | <TabAtkins> | zewt: What do you mean? |
| 19:42 | <TabAtkins> | Android devices span a remarkable spectrum of numbers from 1 to 2. |
| 19:42 | <zewt> | most of them are too uncommon to care about |
| 19:43 | <zewt> | to optimize for, at least |
| 19:57 | <zcorpan> | can a sequence use a union type in webidl? |
| 19:57 | <Ms2ger> | Sure |
| 20:04 | <jsbell> | Anyone know if any async APIs have been hooked up to window.onerror? |
| 20:04 | <Ms2ger> | The promise error reporting? |
| 20:04 | <Ms2ger> | If that's specced yet |
| 20:06 | <annevk> | jsbell: in what sense? |
| 20:08 | <jsbell> | annevk: in concrete terms, there's a "indexeddb should integrate with window.onerror" on my list of things to follow up on. Digging into window.onerror it's unclear that makes sense, so looking for precedent |
| 20:08 | <annevk> | jsbell: only exceptions bubble up there at the moment |
| 20:08 | <jsbell> | i.e. window.onerror is set up for giving you message/url/line number, so document parse errors and exceptions, yeah |
| 20:09 | <jsbell> | IDB would be uncaught error events; unhandled promise failures would be another plausible case (as Ms2ger points out) |
| 20:10 | <annevk> | Promises won't end up on window.onerror per current design |
| 20:10 | <annevk> | (and it was considered) |
| 20:11 | <jsbell> | IDB already has a place for apps to catch otherwise-unhandled errors, so it's not a huge win; may make more sense to wait for a hypothetical IDB-on-Promises and unify with whatever is figured out for Promises |
| 20:11 | <annevk> | They can't because that would expose garbage collection |
| 20:11 | <annevk> | The plan is to let the console handle it... |
| 20:20 | <zcorpan> | TabAtkins: the example still wouldn't satisfy the 1.3 constraint |
| 20:20 | <dglazkov> | Hixie_: https://code.google.com/p/chromium/issues/detail?id=301937? |
| 20:21 | <TabAtkins> | zcorpan: It'll satisfy the sqrt(2) that I said immediately afterwards, since it's doubling each time. |
| 20:21 | <TabAtkins> | 1.3 was my bad estimate of sqrt(2), because I was remembering sqrt(10), which is 3.1. |
| 20:21 | <TabAtkins> | approximately |
| 20:23 | <zcorpan> | it's doubling the width, but hixie's example has the widths 1.3x apart |
| 20:24 | <TabAtkins> | Yes? That's not actually necessary. |
| 20:24 | <TabAtkins> | If you have a 100px image and a 200px image, then a viewport at 141px wide downloading the 200px image as a 1x is overloading by a factor of sqrt(2). |
| 20:42 | <zcorpan> | so hixie's example should be more like http://pastebin.com/gVawS2dX |
| 20:45 | <zcorpan> | maybe with the x'es corrected for 1280.jpeg 2000w 0.5x, etc |
| 20:45 | <zcorpan> | 1.5625x |
| 20:46 | <zcorpan> | er |
| 20:46 | <TabAtkins> | Yeah, sure. |
| 20:46 | <TabAtkins> | Whatever, close enough. ^_^ |
| 20:47 | <zcorpan> | 0.64x |
| 20:47 | <TabAtkins> | Or just change the final breakpoint to 2560 and call it good enough. |
| 20:52 | <TabAtkins> | zcorpan, Hixie_: Here's Hixie's changed over to the same breakpoints as I do, just for easier comparison: http://pastebin.com/izF8GaF8 |
| 20:52 | <TabAtkins> | + what it would look like in my syntax. |
| 20:55 | <zcorpan> | i love that Hixie_ got the syntax wrong for srcset and TabAtkins got the syntax wrong for src1 (the attribute name) :-P |
| 20:55 | <TabAtkins> | No I didn't - I changed the spec over the weekend to ahve a dash. |
| 20:56 | <zcorpan> | oh |
| 20:56 | <TabAtkins> | At Yoav's request, to make it better match data-* mentally, and make it easier to super-quickly scan the attributes to see if there are any candidate attributes (so that if not, we can just fast-path the src attribute). |
| 20:57 | <TabAtkins> | A single check for any attributes starting with "src-" case-insensitively is apparently easier than checking for "src[1-9]". |
| 20:57 | <zcorpan> | i don't see that in http://tabatkins.github.io/specs/respimg/Overview.html |
| 20:57 | <TabAtkins> | Hrm. I thought I pushed that. |
| 20:58 | <zcorpan> | the check shouldn't be case-insensitive |
| 20:59 | <TabAtkins> | Duh, didn't regen the spec before pushing. Fixing now. |
| 20:59 | <TabAtkins> | zcorpan: Oh? I thought that HTML attributes were case-insensitive. |
| 21:00 | <zcorpan> | the html parser case-folds to lowercase, so checks in the DOM should look for lowercase |
| 21:01 | <TabAtkins> | Ah, ok. |
| 21:01 | <zcorpan> | img.setAttributeNS('', 'SRC', 'foo.jpg'); will be an unknown attribute |
| 21:01 | <TabAtkins> | Well anyway, still eaiser to do a search for "starts with src-" than "starts with src[1-9]". |
| 21:01 | <zcorpan> | yeah |
| 21:04 | <TabAtkins> | Note that the Hixie syntax falls back to some tiny image for screens greater than 2560 - you want another line in there to provide the 5120 image to arbitrary viewports, I think. |
| 21:07 | <Hixie_> | i think http://pastebin.com/izF8GaF8 is very misleading, because the srcset="" stuff doesn't get any more complicated at all, while srcN does |
| 21:07 | <Hixie_> | given that, the fact that they are so similar is kinda surprising to me |
| 21:07 | <Hixie_> | zcorpan: what syntax did i get wrong? |
| 21:08 | <Hixie_> | oh lol the x is in the wrong place |
| 21:08 | <zcorpan> | Hixie_: px instead of w, x before instead of after the number |
| 21:08 | <Hixie_> | that'll teach me to not look at my script's output |
| 21:08 | <TabAtkins> | Hixie_: I dont' understand your comment. What do you mean "doesn't get any more complicated at all"? |
| 21:09 | <Hixie_> | TabAtkins: there's no more features than that. this is literally as bad as srcset="" can get. |
| 21:09 | <Hixie_> | if you understand this, you understand it all. |
| 21:09 | <TabAtkins> | Yes, correct. And it's pretty bad when it gets that far. |
| 21:09 | <Hixie_> | zcorpan: (i didn't actually proofread the output of my script before going to lunch) |
| 21:09 | <Hixie_> | come now, it's almost the same as the srcN case |
| 21:09 | <TabAtkins> | But outside of this case, srcN and srcset are basically identical. |
| 21:09 | <Hixie_> | clearer, imho, since you can tell what image is going to be used for any particular width/density combination |
| 21:09 | <Hixie_> | at a glance |
| 21:09 | <TabAtkins> | It's twice as many lines, Hixie, and confusing both to read and write. |
| 21:10 | <Hixie_> | (updated damowmow.com/playground/demos/img/002/test.html to be correct) |
| 21:11 | <Hixie_> | verbose doesn't mean complex. complexity is also a measure of many axes there are to control things. |
| 21:11 | <Hixie_> | you can be really terse and more complex, or really verbose and more complex |
| 21:11 | <Hixie_> | the measure of complexity is how much you have to know to understand it |
| 21:13 | <TabAtkins> | Yes, of course. I think that, when addressing this case, srcset hits the "verbose and more complex" part. Less overall concepts to understand, but more *stuff* to comprehend in the individual instance. (Analogy - binary is simpler because it has less digits than decimal, but it's still harder to read and write because of the increased lengths of numbers.) |
| 21:14 | <zcorpan> | i think the nice thing about src-N's viewport thing is that the author doesn't need to think as much, nor pull up the calculator; just state the breakpoints and put in the images you want and give their actual widths, and the browser figures out the rest |
| 21:14 | <TabAtkins> | Yup, that's precisely it. |
| 21:15 | <TabAtkins> | I didn't like that I have two separate syntaxes embedded in srcN, but the viewport-stuff is too much and kinda inflexible when you just want to deliver a simple known-size image at different densities. |
| 21:15 | <Hixie_> | "harder to read and write" and "more complex" are orthogonal concerns, imho |
| 21:15 | <TabAtkins> | They both fall into the "bad" bucket, though. |
| 21:16 | <Hixie_> | maybe. but they trade off each other. |
| 21:16 | <TabAtkins> | (Though of course increased complexity's badness can be balanced by the utility of whatever additional stuff it grants.) |
| 21:17 | <Hixie_> | the multiple-attribute proposal imho makes the wrong trade-off. |
| 21:17 | <Hixie_> | but honestly, part of the problem is that we're talking about solutions again before talking about problems. |
| 21:18 | <Hixie_> | so it's hard to evaluate |
| 21:18 | <Hixie_> | i'm evaluating it based on the problems srcset="" was designed to address |
| 21:18 | <TabAtkins> | The problems are well-known. We've known them for a long time. We're only faffing about the solution-space to find a good syntax to address the problem. |
| 21:18 | <TabAtkins> | (And my spec does have a section describing the problems.) |
| 21:18 | <Hixie_> | the problems described at http://tabatkins.github.io/specs/respimg/Overview.html#problem are much better solved by srcset="" IMHO. |
| 21:19 | <Hixie_> | to start with, there's only one attribute. secondly, it's got less power. |
| 21:19 | <TabAtkins> | srcset *covers* the solution space adequately. It just doesn't do so with a great syntax in some not-too-corner cases. |
| 21:19 | <Hixie_> | yes, it's slightly more verbose if you're doing dozens of widths and densities, but i don't think that's something that's gonna happen in reality, as anne said above. |
| 21:20 | <TabAtkins> | srcN covers the same solution space (*slightly* wider, but nothing to write home about), is identical in syntax with srcset for the simpler cases (where srcset does well), and in many people's opinions has a more usable/convenient syntax outside of the simpler cases. |
| 21:20 | <Hixie_> | come on, you don't think multiple attributes with a complex media-query-based microsyntax is a _good_ syntax do you? i mean, i'll grant you maybe that srcset="" is as bad, but that's about it. it's definitely not better. |
| 21:21 | <TabAtkins> | The MQ part is the simplest part, to be honest. MQs are already well-known and familiar, as opposed to "300w", which is brand new and doesn't indicate what the width *is* - max or min? Yes, you just have to learn it, but it's one more new thing to learn when there is already a syntax for expressing these things. |
| 21:22 | <TabAtkins> | There's a reason that Blink's srcset implementation does *not* do the w/h stuff yet - people don't really like it. |
| 21:22 | <Hixie_> | "MQs are already well-known and familiar" is soooo not true |
| 21:22 | <Hixie_> | (adsly) |
| 21:22 | <Hixie_> | (sadly, evne) |
| 21:22 | <Hixie_> | even |
| 21:22 | <Hixie_> | jesus, can't type today |
| 21:22 | <TabAtkins> | Among the set of people who care enough about their craft to do this kind of thing in the first place, they are. |
| 21:22 | <zcorpan> | TabAtkins: is there a good reason to support all of MQ? |
| 21:22 | <Hixie_> | (btw, looks like you have a typo in 3.2 example 2, |src-1="pic.png,| presumably is missing something after the file name) |
| 21:23 | <TabAtkins> | Hixie_: No, that's right. Omitting the density defaults it to 1x. |
| 21:23 | <Hixie_> | then you have a parser problem; "," is a valid URL character |
| 21:23 | <Hixie_> | I have _no_ idea what this does, at a glance: |
| 21:23 | <Hixie_> | <img src-1="100 30em 400 70em 50%; |
| 21:23 | <Hixie_> | pic50.png 50, pic100.png 100, pic200.png 200, |
| 21:23 | <Hixie_> | pic400.png 400, pic800.png 800, pic1600.png 1600, |
| 21:23 | <Hixie_> | pic3200.png 3200"> |
| 21:24 | <Hixie_> | i mean that's SVG-like in its obscurity :-) |
| 21:24 | <zewt> | (zing) |
| 21:24 | <TabAtkins> | Hixie_: No, the parser specifically describes that the <url> production can't end in comma or semicolon. You have to escape them at the end if you want to do that. |
| 21:24 | <TabAtkins> | Hixie_: Uh, yes. That's the most complex possible example. |
| 21:24 | <Hixie_> | ugh, don't special-case URL syntax dude |
| 21:24 | <Hixie_> | that's crazytown |
| 21:25 | <TabAtkins> | It's that or complicate the syntax. :/ |
| 21:25 | <TabAtkins> | URLs are the devil. |
| 21:25 | <Hixie_> | TabAtkins: according to the spec, it's not the most complex example... |
| 21:25 | <TabAtkins> | Huh? |
| 21:25 | <Hixie_> | TabAtkins: it's the example before another example that's described as "more verbose" and "not even as correct" |
| 21:25 | <TabAtkins> | zcorpan: I don't know of a strong argument, no. Reusing the MQ syntax for breaking on viewport sizes is just a big win by itself for learning/understandability, and once you do that, allowing the rest of MQ is easy. |
| 21:26 | <TabAtkins> | Hixie_: Ok, you win a pedant point. |
| 21:26 | <TabAtkins> | For pointing out an anti-example specifically used as something to not do. |
| 21:26 | <Hixie_> | actually the next one looks clearer to me |
| 21:26 | <Hixie_> | though apparently it's wrong somehow |
| 21:26 | <TabAtkins> | The very next paragraph explains the somehow. |
| 21:27 | <Hixie_> | but i don't see why srcset="" wouldn't do that example better |
| 21:27 | <Hixie_> | it'd be just the one attribute |
| 21:27 | <TabAtkins> | In srcset you'd collapse them to one attribute, and distribute the MQs across each of the urls as NNNw descriptors, yes. |
| 21:27 | <TabAtkins> | Roughly equivalent. |
| 21:27 | <Hixie_> | yeah i don't understand the paragraph that explains why it's wrong |
| 21:28 | <TabAtkins> | Did you read the whole example, and understand the reason why the <size-viewport-list> is what it is in that example? |
| 21:28 | <Hixie_> | i read the whole example, can't say i fully understand it. |
| 21:29 | <TabAtkins> | The first paragraph attempts to explain it. I'm open to clarifying it, if you can tell me what you didn't understand. |
| 21:29 | <Hixie_> | i rarely know what i didn't understand, kind of by virtue of not understanding it :-) |
| 21:29 | <TabAtkins> | And I don't know what you didn't understand either, so shrug. |
| 21:29 | <zcorpan> | Hixie_: the key is that the image is 50% of the viewport in the widest layout, but the wrong example assumes it's 800px (at 1x) |
| 21:30 | <Hixie_> | surely the width of the image is decided by CSS |
| 21:31 | <TabAtkins> | Yes. But the image-loading code needs to make a decision before CSS starts applying. |
| 21:31 | <TabAtkins> | Or wait, no, that doen't even answer your question. |
| 21:31 | <TabAtkins> | Because I'm not sure what your statement even means, or how it's a reaction to zcorpan's. |
| 21:32 | <Hixie_> | does "the image" mean the file from the server, or the <img> element? |
| 21:32 | <TabAtkins> | In order to avoid *even more* verbosity, I stopped at three breakpoints there. But, much like the previous example I had you work through, to be really accurate you'd want more. |
| 21:32 | <TabAtkins> | You get that "more" super cheaply and easily under srcN. |
| 21:33 | <Hixie_> | i'm not convinced this is a real problem. |
| 21:33 | <TabAtkins> | Okay. Clueful people have said it is, and have offered arguments that were convincing to me. |
| 21:34 | <Hixie_> | what are those arguments? |
| 21:34 | <TabAtkins> | To directly answer your question - the <img> element will be 100px, 400px, or 50% wide. The code provided assumes that, in the last case, that 50% will resolve to 800px (that is, it assumes a viewport width of 1600px). |
| 21:34 | <Hixie_> | why would you assume a viewport width? |
| 21:34 | <TabAtkins> | I gave them earlier today. We spent like an hour discussing a use-case about this. |
| 21:35 | <TabAtkins> | Hixie_: Because you have to, under srcset or MQ+Nx syntax? |
| 21:35 | <TabAtkins> | Declaring that a given source is a given density presupposes that it's being displayed at a given size. |
| 21:35 | <Hixie_> | with srcset="" you specify the max viewport widths for each image, you don't assume anything |
| 21:36 | <TabAtkins> | When the final size will be a percentage of a viewport, you must thus translate this into an assumed size (or multiple assumed sizes). |
| 21:36 | <Hixie_> | i didn't see any arguments earlier that would convince me that people are going to actually provide 4x images, 0.5x images, nor that they would provide 7 different images (without art direction) per <img>. 2, 4 maybe. not 7. |
| 21:37 | <TabAtkins> | 4x screens are something we should prepare for in a few years. .5x images are something very nice to provide for low-bandwidth scenarios - I'd *love* if images downloaded at .5x when I was on an edge connection, even though I have a high-dpi phone. |
| 21:38 | <TabAtkins> | Both of these edge cases are things that come *for free* in the viewport-based half of srcN's syntax. |
| 21:38 | <TabAtkins> | It's future-friendly for things that we *know* will come up, or already exist, without the author having to do almost any additional work. |
| 21:39 | <TabAtkins> | I'm frustrated that you don't seem to understand the terribleness, to a normal author, of having to repeat the same url multiple times. People just won't do that - they'll ignore it, and only offer a few things, and produce a worse user experience. |
| 21:40 | <Hixie_> | as people keep telling me, what we personally might want shouldn't affect the spec :-) |
| 21:41 | <Hixie_> | in practice, i see no evidence that authors want to provide half-res images in low-bandwidth situations |
| 21:41 | <Hixie_> | and i'm not at all convinced 4x displays will exist coincident with 1x displays, let alone 1x displays that you want 0.5x images for |
| 21:41 | <Hixie_> | we can barely make 2x displays at any high resolution these days |
| 21:42 | <Hixie_> | people repeat urls all the time, why do you think they wouldn't? |
| 21:42 | <TabAtkins> | I *just* said that I have a 2x device that I would want .5x images for some times. Claiming that it would only be for 1x devices is disingenuous. |
| 21:43 | <Hixie_> | the srcset="" version of your "Example 4" in section 3.3, supporting just 1x and 2x, would be: |
| 21:43 | <Hixie_> | <img srcset="pic100.png 480w 1x, pic200.png 480w 2x, pic400.png 960w 1x, pic800.png 960w 2x, |
| 21:43 | <Hixie_> | pic00.png 160 0w 1x, pic1600.png 3200w 1x, pic3200.png 1x, pic1600.png 1600w 2x, pic3200.png 2x"> |
| 21:43 | <Hixie_> | woah, bad spacing paste |
| 21:43 | <TabAtkins> | And I suspect we'll have quite a spectrum of densities for some time, supporting 3x and 4x alongside 1x and 2x. |
| 21:43 | <Hixie_> | http://damowmow.com/playground/demos/img/003.html |
| 21:44 | <Hixie_> | what _you_ want isn't really the point dude. i want a ton of stuff that we're not gonna get. |
| 21:44 | <TabAtkins> | Uh, yes, I understand. What I'm saying, though, is that this is a useful thing that UAs can deliver to their users, and my syntax happens to give it for free in many cases, which is a good thing. |
| 21:45 | <TabAtkins> | The whole point of resolution discrimination is that bandwidth factors into things too. |
| 21:45 | <TabAtkins> | Otherwise this would be much easier. |
| 21:46 | <zewt> | ("resolution discrimination"? seriously?) |
| 21:46 | <Hixie_> | *shrug*. i gotta go. bbiab. if you can convince authors and implementors to do this, then i guess i'll update the spec. but i think it's more complex, not especially less verbose, and doesn't solve compelling problems that aren't solved by the simpler srcset. |
| 21:47 | <TabAtkins> | zewt: You don't like the phrase? |
| 21:49 | <zewt> | sounds like "associate something I don't with something much worse, to make it sounds more important than it really is" (racial discrimination! sexual discrimination! resolution discrimination!) |
| 21:51 | <TabAtkins> | That sentence doesn't parse, so I'm not quite sure what you're trying to say. |
| 22:00 | <TabAtkins> | zewt: Can you fill in the missing word in your sentence? Is it "like"? |
| 22:06 | <zewt> | ... yes |
| 22:06 | <zewt> | (sorry, work) |
| 22:06 | <TabAtkins> | Oh. In that case, I don't understand, because resolution discrimination is a good thing. ^_^ |
| 22:07 | <zewt> | oh. sorry, I read it as "bandwidth discrimination" (work or irc: pick one) |
| 22:07 | <zewt> | okay, that does make more sense :P |
| 23:31 | <Hixie_> | anyone got IE? need to test http://www.hixie.ch/tests/adhoc/dom/level0/window/showModalDialog/005.html |