| [00:12:54] | * grigs has left #respimg (grigs) |
| [00:13:01] | * zcorpan has joined #respimg |
| [00:14:42] | * zcorpan has joined #respimg |
| [00:17:42] | * Wilto has joined #respimg |
| [00:49:17] | * zcorpan has joined #respimg |
| [00:59:55] | * zcorpan has joined #respimg |
| [01:41:13] | * zcorpan has joined #respimg |
| [03:43:00] | * newtron has joined #respimg |
| [03:54:23] | * JonathanNeal has joined #respimg |
| [03:54:30] | <JonathanNeal> | Hi again. |
| [04:14:23] | <TabAtkins> | What's up, JonathanNeal ? |
| [04:19:43] | <JonathanNeal> | Not much, TabAtkins. I love that srcset is going to be a thing and that syntax you came up with on the napkin is now kind of a reality. |
| [04:20:28] | <TabAtkins> | It's been a wild ride. |
| [04:20:41] | <TabAtkins> | But yeah, if you want something done, get drunk with John Mellor. |
| [04:20:43] | <TabAtkins> | Can't argue with results. |
| [04:21:50] | <JonathanNeal> | John Mellor, does he frequent IRC? |
| [04:21:51] | <JonathanNeal> | Still barking up the tree of element queries, made some remarks @ should have preemptively made my spiel about circularity being an issue worth concern but not limited to element queries, and also mentioning how browsers current handle it. |
| [04:22:17] | <JonathanNeal> | TLDR; get drunk with John and talk about element queries. |
| [04:24:47] | <TabAtkins> | Yeah, that post spends a lot of inches talking about nearly identical selector syntaxes, which is the least important part of getting this thing done. |
| [04:25:33] | <TabAtkins> | Important thing is (a) ensuring that it is indeed important to indicate that something is a "viewport" in markup, and that we can't somehow work around that in an easier manner |
| [04:25:51] | <TabAtkins> | and then (b) figuring out what that markup is, assuming we do need it (or whatever the syntax would be). |
| [04:26:16] | <TabAtkins> | Then using :media((min-width: 400px)) or :min-width(400px) or whatever can be discussed. |
| [04:30:41] | <JonathanNeal> | I still don’t get how the viewport element ignores the dimensions of its descendants and remains useful. |
| [04:31:08] | <JonathanNeal> | But that might not be anyone’s problem but my own. |
| [04:33:13] | <TabAtkins> | Because it's responding to the dimensions of the things around it instead. |
| [04:33:16] | <TabAtkins> | That's the point, after all. |
| [04:33:34] | <TabAtkins> | The viewport element responds to some sizing constraints from the page, and the descendants respond to that. |
| [04:33:47] | <JonathanNeal> | So, the reason you think we would need a viewport element or viewport style is to reduce circularity? |
| [04:34:13] | <TabAtkins> | I'm completely sure of that. |
| [04:34:28] | <JonathanNeal> | So, if it’s container shrinks, it does, in fact, shrink, but it treats its descendants in an overflow:visible kind of way? |
| [04:34:32] | <TabAtkins> | Basically, impls will almost certainly strongly reject anything that doesn't kill the circularity issues. |
| [04:34:40] | <TabAtkins> | Yeah, something like that. |
| [04:34:52] | <TabAtkins> | It's just an iframe that lives in the page. |
| [04:37:06] | <zcorpan> | yoav: says web compat needs expired images to actually reload (at least in some cases, i haven't looked into if <img src=x> ... <img src=x> is different from img.src = img.src etc |
| [04:37:16] | <zcorpan> | ) |
| [04:37:21] | <JonathanNeal> | So, if we have a tree like Element, Viewport, Child; does the presence of Viewport mean Child will not impact Element’s width? |
| [04:39:55] | <JonathanNeal> | My guess is yes, because it acts just like an iframe. |
| [04:47:40] | <TabAtkins> | JonathanNeal: Yes. |
| [04:47:54] | <TabAtkins> | As far as Element is concerned, Viewport is *empty*. |
| [04:48:17] | <JonathanNeal> | Earlier me below and later me above, after any conversation with you |
| [04:49:53] | <TabAtkins> | All Gaston is Best Gaston. |
| [04:53:11] | <JonathanNeal> | Are we able to give shadow DOM to elements that would still keep child elements? |
| [04:56:12] | <TabAtkins> | Yeah, having a shadow tree is independent of whether something has children. |
| [04:58:31] | <JonathanNeal> | Whenever I try something like webkitCreateShadowRoot, it wipes out all of its children. |
| [05:00:15] | <TabAtkins> | It no longer *displays* its children. |
| [05:00:18] | <TabAtkins> | They're still there. |
| [05:00:27] | <TabAtkins> | But if an element has a shadow root, the shadow root gets rendered instead. |
| [05:04:52] | <JonathanNeal> | Got it. I had tried throwing a hidden <iframe> inside a container to simulate part of element queries, but I couldn’t make the iframe a shadow element and still have the container display its descendants. Ah well. |
| [05:09:40] | <TabAtkins> | Right, only one tree gets displayed at a time. |
| [05:18:17] | <JonathanNeal> | Oi, what about it’s height? |
| [05:18:35] | <JonathanNeal> | ^ sorry, back to the viewport element. |
| [05:20:47] | <TabAtkins> | The viewport element, like iframe, would have a "default" width and height. Probably 300x150 just so it's consistent. |
| [05:21:19] | <TabAtkins> | Otherwise you have to set the height yourself probably. |
| [05:21:39] | <TabAtkins> | Though maybe we can make this more subtle, and allow "viewporting" either width *or* height, and restrict what queries you can run if you're only doing one of them. |
| [05:22:08] | <TabAtkins> | So that a column can have its width set by the page's 'grid' property, but be as tall as it needs to be based on contents. |
| [05:22:19] | <TabAtkins> | So you can only run width queries, not height or aspect-ratio. |
| [05:25:06] | <JonathanNeal> | Interesting. Regarding the default width, wouldn’t most folks override <view> with width: 100%? |
| [05:46:26] | * yoav has joined #respimg |
| [05:47:43] | * yoav_ has joined #respimg |
| [05:47:43] | * yoav_ has quit ("Ex-Chat") |
| [06:06:49] | * anssik has joined #respimg |
| [06:08:49] | <TabAtkins> | I wouldn't bet on that. People do all kinds of crazy things. |
| [06:09:05] | * anssik has left #respimg () |
| [06:14:32] | <JonathanNeal> | Could it be as simple as display: viewport? |
| [06:20:54] | <JonathanNeal> | Is the reason CSS doesn’t have something like :has also because of circularity? |
| [06:26:43] | <TabAtkins> | JonathanNeal: No, because that means we have to go back and redo large swaths of layout if a display:viewport comes late in the document, blah blah blah. |
| [06:26:57] | <TabAtkins> | It's not impossible, but it's unlikely to be adopted. bz has argued against it. |
| [06:27:26] | <TabAtkins> | :has() is totally fine. No circularity, just slow performance because it invalidates various assumptions we can often make about when some mutation will trigger changes in styles. |
| [07:27:41] | * zcorpan is super-jetlagged right now :-( |
| [07:53:26] | * richt has joined #respimg |
| [08:00:15] | * yoav_ has joined #respimg |
| [08:00:48] | * kasperg has joined #respimg |
| [08:04:00] | * yoav has left #respimg () |
| [08:15:50] | * darobin has joined #respimg |
| [08:23:36] | * zcorpan has joined #respimg |
| [08:24:25] | <zcorpan> | cbiesinger__: any idea how to find a real-world page/app that loads lots of images in a similar fashion as the benchmark and so is also affected? |
| [08:24:39] | * zcorpan gotta go again, will read logs later |
| [08:25:12] | * zcorpan has joined #respimg |
| [09:08:40] | * Kolombiken has joined #respimg |
| [09:27:38] | * darobin has joined #respimg |
| [10:25:29] | * richt has joined #respimg |
| [10:26:05] | * richt_ has joined #respimg |
| [10:26:39] | * richt has joined #respimg |
| [10:27:02] | * zcorpan has joined #respimg |
| [10:32:47] | <darobin> | FWIW I created an HTML/responsive category on in case anyone here wants to use that |
| [11:07:00] | <yoav_> | darobin: Cool! Not yet sure how to use that (how to follow stuff you're interested in, etc) but it looks pretty cool |
| [11:18:06] | * Kolombiken has joined #respimg |
| [11:28:43] | <darobin> | yoav_: I'm also discovering it to be honest |
| [11:29:03] | <darobin> | but a number of OSS projects are now using it (e.g. Ember) and so far the feedback is very positive |
| [11:29:34] | <darobin> | basically it's "forums done right" and you can even more or less treat them as mailing list if you prefer email |
| [11:29:46] | <darobin> | so, it's an experiment to see if that'd work for standards |
| [11:30:02] | <darobin> | I can already tell it has a *MUCH* lower bar for entry than mailing list discussions |
| [11:30:37] | <yoav_> | But it's lacking the good-old-fashioned mailing list look & feel |
| [11:30:52] | <darobin> | rofl |
| [11:31:06] | <darobin> | I haven't tweaked the CSS yet, I'm sure we can get it to look like Hypermail :) |
| [11:31:15] | <yoav_> | awesome |
| [11:31:47] | <darobin> | :) |
| [11:31:54] | <yoav_> | That way we can keep designers out of the standard discussion, since it would disqualify them from actually doing any design |
| [11:52:16] | * TimWright has joined #respimg |
| [12:24:34] | <zcorpan> | if catches on we should probably add an integrity() descriptor or so to srcset |
| [12:29:51] | <yoav_> | zcorpan: Yeah, I've discussed it with Mike West last week |
| [12:30:19] | <yoav_> | I'm not sure a descriptor is the best way to tackle this though |
| [12:31:14] | <yoav_> | Need to come up with a reasonable syntax |
| [12:31:30] | <zcorpan> | yoav_: maybe not. but what else can we do? |
| [12:32:00] | <yoav_> | an "integritylist" attribute? |
| [12:32:15] | <zcorpan> | integrityset :-) |
| [12:32:23] | <yoav_> | :) |
| [12:32:58] | <zcorpan> | isn't that more likely to get out of sync? |
| [12:33:26] | <yoav_> | yeah, probably |
| [12:34:37] | <yoav_> | personally, I think SRI is great for JS/CSS, but it's not ready to tackle images just yet (as long as streaming content is not supported) |
| [12:35:31] | <zcorpan> | yeah since <img> is basically streaming it doesn't make sense now |
| [12:36:18] | <yoav_> | They're talking about adding merkle tree support and multiple hashes per resource, to enable streaming |
| [12:36:37] | <yoav_> | With srcset, that can get hairy pretty quickly |
| [12:36:58] | <yoav_> | at least with the integrity() descriptor approach |
| [12:37:03] | <zcorpan> | yeah |
| [12:37:49] | <zcorpan> | foo.jpg 100w integrity-1(...) integrity-2(...) ... :-| |
| [12:39:44] | <yoav_> | It may just be foor.jpg 100w integrity(<15 hashes separated by ; or whatever>) |
| [12:39:55] | <yoav_> | but still |
| [12:40:14] | <zcorpan> | right yeah |
| [12:40:41] | <zcorpan> | i still think it's good to have the hashes right next to the url you're planning on actually loading |
| [12:43:02] | <yoav_> | probably |
| [12:43:22] | <yoav_> | what are they doing for CSS resources? |
| [12:44:33] | <zcorpan> | that seems like an open issue also. i may bring it up tomorrow since i'm at a css f2f :-) |
| [12:45:03] | <yoav_> | :) |
| [12:45:04] | <zcorpan> | anne suggested somenewthing("url", some new syntax) |
| [12:45:29] | <zcorpan> | so you can do integrity, crossorigin, etc, for background-image and @import etc |
| [12:45:33] | <yoav_> | somenewthing sounds like a solid function name |
| [12:46:09] | <zcorpan> | csswg are excellent at bikeshedding names so i don't have to come up with anything |
| [12:47:03] | <yoav_> | I've been bugging TabAtkins about adding mime type to for a while now |
| [12:47:26] | <yoav_> | Maybe a type attr can also be a parameter there |
| [12:48:14] | <yoav_> | and it can somehow get merge into image() |
| [12:48:31] | <yoav_> | Dunno |
| [12:48:40] | * kasperg_ has joined #respimg |
| [12:48:52] | <yoav_> | zcorpan: You asked about selfClosing() the other day. Did you see my response? |
| [12:53:16] | * zcorpan_ has joined #respimg |
| [13:01:12] | <yoav> | zcorpan_: You asked about selfClosing() the other day. Did you see my response? |
| [13:01:28] | <zcorpan_> | nope. can check backlog |
| [13:01:50] | <yoav> | basically, it returns true for a self closing token |
| [13:01:55] | <yoav> | e.g. <img /> |
| [13:02:12] | <zcorpan_> | is it true for <img> ? |
| [13:02:15] | <yoav> | no |
| [13:02:21] | <yoav> | no HTML logic |
| [13:02:31] | <zcorpan_> | is it true for <p /> ? |
| [13:02:41] | <yoav> | (which is why I added a list of token names that are void) |
| [13:02:45] | <yoav> | yes |
| [13:03:01] | <zcorpan_> | then i think you should ignore selfClosing() altogether |
| [13:03:41] | <yoav> | ok, is <p /> identical to <p> ? |
| [13:03:45] | <zcorpan_> | yes |
| [13:03:52] | <yoav> | didn't know that |
| [13:04:02] | <yoav> | then, I guess you're right |
| [13:04:37] | <yoav> | + add a test to see that such tokens don't trip me up |
| [13:04:49] | <zcorpan_> | i guess it has an effect for svg/mathml elements though, but maybe you don't want to care about that |
| [13:05:01] | <yoav> | no, I don't |
| [13:05:23] | <yoav> | just HTML tokens |
| [13:06:13] | <zcorpan_> | well my point is that you can't tell if it's an "HTML" token or an "SVG" token without running the treebuilder |
| [13:06:25] | <zcorpan_> | consider <svg><picture><source> |
| [13:06:38] | <zcorpan_> | picture and source are in the svg namespace |
| [13:06:54] | <zcorpan_> | but the preloader probably thinks they're html elements, no? |
| [13:07:23] | <yoav> | Dunno what happens there, but sounds like another test case :) |
| [13:07:50] | <yoav> | Although, I'm guessing that's true for other tokens as well |
| [13:08:08] | <zcorpan_> | it depends on what the tokens are |
| [13:08:24] | <yoav> | I mean, <svg><a href rel=stylesheet></svg> shouldn't load either |
| [13:08:32] | <zcorpan_> | some aggressively escape out of svg/math |
| [13:08:37] | <zcorpan_> | <a> is one of them iirc |
| [13:08:50] | <zcorpan_> | maybe you meant <link>? |
| [13:08:57] | <yoav> | I means <link href> |
| [13:09:10] | * yoav cannot type for some reason |
| [13:10:17] | <yoav> | yeah |
| [13:10:57] | <zcorpan_> | hmm seems a and link don't break out |
| [13:11:01] | <zcorpan_> | but img does |
| [13:11:11] | <zcorpan_> | so yeah, link is also broken |
| [13:11:25] | <zcorpan_> | (i'd guess, i haven't tested) |
| [13:11:44] | <yoav> | zcorpan_: I'll add tests cases, and if they fail, I'll fix :) |
| [13:12:24] | <zcorpan_> | yoav: you'll end up implementing the treebuilder if you want correctness in all cases |
| [13:13:20] | <yoav> | zcorpan_: Nah, adding an "inSVG" flag is easy :) It's awesome that you're reviewing this, BTW |
| [13:13:44] | <yoav> | highly appreciated |
| [13:13:46] | <zcorpan_> | how do you know when to switch it off? |
| [13:13:53] | <yoav> | </svg> |
| [13:13:56] | <zcorpan_> | that's wrong |
| [13:14:02] | <zcorpan_> | :-) |
| [13:14:05] | <yoav> | :) |
| [13:14:09] | <zcorpan_> | see #whatwg /topic |
| [13:14:27] | <yoav> | nested SVGs? |
| [13:15:34] | * newtron has joined #respimg |
| [13:15:50] | <zcorpan_> | no, it can end earlier if you do <svg><img> == <svg></svg><img>, or it can end later if you do <svg><title (this is svg)><style (this is html)></svg (this is plain text)></style></title><link (still svg)></svg> |
| [13:16:06] | * newtron has joined #respimg |
| [13:16:17] | <yoav> | Oh |
| [13:16:24] | <zcorpan_> | i think your only options if you want correctness is stop the prefetcher altogether when seeing <svg> or <math>, or implement the full treebuilder |
| [13:17:09] | <yoav> | Maybe this is why SVG is not currently implemented... |
| [13:17:11] | <zcorpan_> | or you can accept that it's not going to be correct and leave it as is |
| [13:17:23] | <zcorpan_> | no, svg is implemented in the html parser |
| [13:17:35] | <zcorpan_> | or do you mean svg prefetching? |
| [13:17:44] | <yoav> | Yeah, but not in HTMLPreloadScanner (I think) |
| [13:17:49] | <zcorpan_> | ok yeah |
| [13:17:56] | * yoav is going to actually look at the damned code |
| [13:18:31] | <yoav> | Yeah, no svg |
| [13:18:45] | <yoav> | style and template are covered using an "in*" flag |
| [13:19:42] | <yoav> | Would a list of tagNames that break out of SVG be enough to implement it? |
| [13:20:19] | <yoav> | e.g. so "if inSVG and current token is in list => inSVG=false" |
| [13:20:35] | <zcorpan_> | no, it doesn't help for my second case above ("it can end later") |
| [13:20:41] | <yoav> | zcorpan_: Not sure it's worth it, but I want to understand my options |
| [13:21:09] | <zcorpan_> | yoav: see |
| [13:23:20] | * hellogeri has joined #respimg |
| [13:23:21] | <yoav> | zcorpan_: Your 2nd case would work since everything inside style/template is ignored |
| [13:23:49] | <yoav> | Are there other element that can contain "</svg>"? |
| [13:23:57] | <zcorpan_> | yoav: replace style with script or xmp or plaintext etc |
| [13:24:08] | <yoav> | zcorpan: OK, I give up |
| [13:24:09] | <yoav> | :) |
| [13:24:16] | <zcorpan_> | yoav: :-) |
| [13:24:24] | <zcorpan_> | low battery, need sleep |
| [13:24:27] | * eeeps has joined #respimg |
| [13:24:31] | <zcorpan_> | both me and my computer |
| [13:24:39] | <yoav> | Good night! :) |
| [13:24:46] | <zcorpan_> | gnight! |
| [13:25:19] | * zcorpan has joined #respimg |
| [13:25:41] | <darobin> | hey, you folks had a nicer version of the "THIS IS A FUCKING STALE TR VERSION" dialog didn't you? |
| [13:25:45] | * darobin looking for it |
| [13:28:11] | * Wilto has joined #respimg |
| [13:28:31] | <Wilto> | Morning. |
| [13:40:32] | * hellogeri1 has joined #respimg |
| [13:52:09] | <yoav> | Wilto: morning! |
| [13:52:20] | <Wilto> | What’s good? |
| [13:52:48] | <yoav> | 2 patches landed - source selection and currentSrc as absolute URL |
| [13:53:02] | <yoav> | Got the preloader left on my side of things |
| [13:53:10] | <yoav> | zcorpan have been poking holes in it |
| [13:53:52] | <Wilto> | ugh man c’mon don’t point out bugs just like ignore them until they go away |
| [13:54:59] | <yoav> | we're likely to do that for <svg> tags |
| [13:55:01] | <yoav> | :) |
| [13:56:27] | <newtron> | what's wrong with <svg>? |
| [13:56:40] | <yoav> | so <svg><picture><img> is likely to download the wrong resource, but that's invalid, and prob rare |
| [13:57:14] | <yoav> | nothing wrong with svg, beside the fact that you can break out of it in a gazillion different ways |
| [13:58:48] | <newtron> | ah i see |
| [14:01:25] | <yoav> | newtron: and between doing extra preloads for invalid SVG and not enough for valid content with svgs in it, I prefer the latter |
| [14:01:42] | <newtron> | yoav: that definitely makes sense |
| [14:12:13] | * uniqname has joined #respimg |
| [14:13:26] | <Wilto> | So, I am looking to assemble a Team. |
| [14:14:55] | <Wilto> | Scott and I have some Picturefill 2.1 stuff soon to land, but we’re having trouble keeping up with general triage stuff with client work and all—confirming issues, kicking things back for retesting, etc. Anyone up for being the Official Picturefill Co-Triageist? |
| [14:43:23] | <newtron> | Wilto: how much time are you thinking? |
| [14:43:55] | <Wilto> | I have no idea. Just having another set of eyes on things would help; confirming issues and whatnot. |
| [14:44:11] | <newtron> | i'm happy to contribute when/where i can |
| [14:44:20] | <newtron> | but i won't have a *lot* of time |
| [14:53:49] | <TimWright> | Wilto: I can throw some time at it |
| [14:54:41] | <Wilto> | Sweet; the more the merrier. |
| [15:33:25] | <TabAtkins> | Note: type info isn't going to go in image(). We agreed to kill the image fallback behavior from image(), and focus on improving image-set() to be feature-equivalent to <picture>, then allow optional fallback in there as well. |
| [15:34:16] | <yoav> | TabAtkins: Sounds good! |
| [15:35:39] | * eeeps has joined #respimg |
| [15:40:40] | * kasperg has joined #respimg |
| [15:41:54] | <Wilto> | Man, I haven’t been tuned in to that stuff at all. Got a link handy, TabAtkins? |
| [15:42:33] | <TabAtkins> | |
| [15:42:43] | <TabAtkins> | But "we agreed" yesterday, so I haven't done the edits yet. |
| [15:43:10] | <Wilto> | Gotcha. |
| [15:44:27] | <Wilto> | Wait. Does that mean MQ in there, or just `sizes`-esque stuff? |
| [15:55:06] | <TabAtkins> | MQs are already in CSS, so just the sizes stuff. |
| [15:55:08] | <TabAtkins> | And the type stuff. |
| [16:13:02] | * richt has joined #respimg |
| [16:16:51] | <Wilto> | Yeah; didn’t know if things were about to get weird, MQ-wise. |
| [16:29:29] | <Wilto> | `sizes` accepting MQ and all, I worried that Xzibit was smiling knowingly somewhere. |
| [16:39:41] | * kasperg has joined #respimg |
| [16:42:10] | <TabAtkins> | I've gotten enough Xzibit in my life. |
| [16:46:21] | * grigs has joined #respimg |
| [16:52:33] | <Wilto> | Whatup, grigs. |
| [16:53:17] | <grigs> | The usual. Trying desperately to avoid writing about responsive images AGAIN and failing. |
| [16:53:45] | <Wilto> | Story of my career. |
| [16:54:30] | <Wilto> | Wat’chu thinking about writing? The server angle? |
| [16:56:19] | <grigs> | A series on what’s next for responsive images. e.g., what do you do now that *maybe* the picture spec is going to be the long term direction. |
| [16:56:33] | <Wilto> | Pssh, “maybe.” |
| [16:57:23] | <grigs> | maybe = I still think it is likely that the spec could change once we get implementations. That wouldn’t be abnormal for a standard. |
| [16:57:23] | <Wilto> | But yeah, I’m all about getting more “alright it’s real LET’S USE THIS” posts out there. |
| [16:57:28] | <Wilto> | Oh, oh. |
| [16:57:53] | <Wilto> | Yeah, details are gonna change here and there, but impl. is pretty far along in a couple of places as it stands now. |
| [16:58:03] | <grigs> | My previous sentence was poorly worded. |
| [16:59:25] | <grigs> | Series would include: conducting an audit of images on a site, finding or developing an image resizing service, revisiting the pandora’s box of determining image breakpoints, options for how to handle hero images, and using type in hero images to determine image breakpoints for said images. |
| [16:59:55] | <grigs> | those are the things rattling around in my head |
| [17:10:01] | * grigs killed the conversation. |
| [17:48:33] | * jlembeck has joined #respimg |
| [18:09:39] | * kasperg_ has joined #respimg |
| [18:10:59] | * kasperg has joined #respimg |
| [18:14:01] | <Wilto> | Well, lunch sorta did. |
| [18:51:57] | * richt has joined #respimg |
| [18:52:05] | <yoav> | cbiesinger__: Around? |
| [19:15:07] | * uniqname has joined #respimg |
| [19:23:30] | * newtron_ has joined #respimg |
| [19:30:35] | * uniqname1 has joined #respimg |
| [19:49:02] | <eeeps> | grigs! hi |
| [19:50:08] | <eeeps> | “using type in hero images to determine breakpoints” — care to elaborate? I’m assuming you’re talking about cropping an image to ensure a readable size? |
| [19:55:13] | <eeeps> | also, I haven’t really looked at image resizing services… is there a tradeoff to “dynamic”? I assume they all cache, so after the first request for /img.jpg?width=1024 or whatever nobody has to wait for the server to do any on-the-fly resizing |
| [19:57:44] | <eeeps> | (guessing the real tradeoff is complexity, or lack of ownership/control if you choose a 3rd party service) |
| [20:25:42] | * TimWright has left #respimg (TimWright) |
| [20:28:39] | <grigs> | “hero images” often have type in them. As far as I can tell, the requirements for hero images are something like “marketing needs a box that they can use to promote whatever might come up". |
| [20:29:37] | <grigs> | In an ideal world, marketing would have someone who could create a fully responsive asset that separated type from the image. But in the real world, the people in marketing don’t have the time nor the people with the skills to do that. |
| [20:31:32] | <grigs> | So for a recent project, we started with photoshop doc that was the size of the largest possible hero image and put the brand typeface in various weights and sizes in it. Saved it as a png and put it in a test page to resize. |
| [20:32:29] | <grigs> | We resized it down until the desired type size was unreadable. Then we created a new image with a set of type samples at that size and then resized again. |
| [20:33:40] | <grigs> | It told us that if they wanted to use 14pt in their hero designs, they needed four breakpoints. If they were ok with using a minimum of 18pt, they could get by with three image breakpoints. |
| [20:52:07] | <eeeps> | grigs: huh. and no matter what the thing-of-the-month going in that box is, the type is always going to be that size, so the art-direction breakpoints are always going to be the same… |
| [20:53:15] | <cbiesinger__> | yoav: hi |
| [20:53:21] | <cbiesinger__> | sorry, I had to deal with a sick puppy :( |
| [20:56:05] | <eeeps> | I’m curious to see what CMSs do with art direction. When you’re dealing with fixed-size type you can get pretty rigid about the requirements. But with photo content what needs to be “legible” (say, facial expressions) and how to keep it so at the widest range of sizes possible is much more subjective. |
| [20:56:12] | <eeeps> | exciting times ahead! |
| [20:58:45] | * uniqname has joined #respimg |
| [20:59:28] | <grigs> | eeeps: ideally, the designers would evaluate the compressed image size, readability of the type, etc. for each image. But for now, simply asking them to triple their workload is enough of a challenge. So absent an unforeseen need, the breakpoints will always be the same because the typeface guidelines dictate it. |
| [21:02:45] | <eeeps> | grigs: yeah. The new spec gives us so much freedom; I think the real challenge of using these tools is going to be choosing sensible constraints. |
| [21:03:34] | <grigs> | eeeps: EXACTLY. That’s what I want to write about. For most designers and developers, the spec will be the easy part. :-) |
| [21:06:05] | <eeeps> | grigs: can’t wait to read it! |
| [21:38:15] | * richt has joined #respimg |
| [22:28:10] | * uniqname has joined #respimg |
| [23:20:12] | * grigs has quit (grigs) |
| [23:25:12] | * Wilto has joined #respimg |
