| 03:01 | <annevk> | TC39: Work with us. "W3C": Okay, how do I solve X in a way that makes sense? TC39: GTFO. |
| 03:02 | <annevk> | sad panda |
| 03:17 | <zcorpan> | annevk: up early? |
| 03:19 | <annevk> | zcorpan: late today actually. I'm in Taipei |
| 03:20 | <zcorpan> | ah |
| 03:21 | <annevk> | zcorpan: about to upload your merge to the server |
| 03:22 | <zcorpan> | what merge? |
| 03:23 | <annevk> | zcorpan: NOTE requiring whitespace |
| 03:23 | <zcorpan> | ah |
| 03:24 | <zcorpan> | first i considered filing a bug but i figured it would be about the same effort to do a PR |
| 03:41 | <MikeSmith> | Taipei |
| 03:42 | <MikeSmith> | annevk: nice |
| 03:42 | <MikeSmith> | been there only one time but I'd really like to visit again |
| 03:43 | <annevk> | MikeSmith: mostly been working thus far, but Saturday I'll have a chance to visit a few things and maybe go for a hike |
| 03:44 | <annevk> | MikeSmith: unfortunately the TAG F2F is in London next week so I couldn't hang around longer. Ideally I would've just stayed in Asia until the AC thingie... |
| 03:45 | <MikeSmith> | annevk: people probably suggested this already, but I recommend going to the night market if you have time |
| 05:08 | <nimbu> | Taipeiii |
| 05:09 | <nimbu> | i was only there to buy the first tiny asus computer |
| 05:09 | <nimbu> | and i never used it since |
| 05:11 | <annevk> | sounds like my XO laptop |
| 05:12 | <annevk> | although I got that in Oslo |
| 05:14 | <nimbu> | ya exactly |
| 06:22 | <annevk5> | Why is "intertwinedness" not a word? |
| 06:59 | <Ms2ger> | hober, yeah, I believe the one thing the whatwg members did was making annevk a member |
| 07:21 | <hallvors> | morning annevk5 |
| 07:21 | <annevk> | hallvors: good afternoon |
| 07:22 | <hallvors> | so it's you and not a clone - 5 of you would be a bit rich, though between you you'd get a lot of spec stuff done :-p |
| 07:22 | <hallvors> | joking aside: thanks for the response headers fix |
| 07:22 | <annevk> | heh |
| 07:22 | <annevk> | 5 is an obscure reference to 5 > 2, which is itself obscure |
| 07:35 | <hallvors> | layered obscurity. Sounds like something a spec editor would be into, yes |
| 07:35 | <hallvors> | ;) |
| 07:39 | <annevk> | only in off hours |
| 07:47 | <hsivonen> | MikeSmith: did Vic Gundotra make you take the "(tm)" bit out on G+? |
| 08:40 | <hallvors> | Does the CORS spec have a test suite? |
| 08:41 | <annevk> | hallvors: yeah, Odin wrote one |
| 08:41 | <odinho> | ^_^ |
| 08:41 | <hallvors> | great, but where is it? |
| 08:41 | <odinho> | The obvious place |
| 08:41 | <hallvors> | I was looking around at w3c-test a bit |
| 08:41 | <odinho> | webappsec/cors |
| 08:41 | <odinho> | BUT! |
| 08:41 | <hallvors> | ah |
| 08:41 | <hallvors> | thanks |
| 08:41 | <odinho> | I will move it :D |
| 08:41 | <odinho> | Because I am allowed now |
| 08:41 | <odinho> | "allowed" |
| 08:42 | <annevk> | put it in Fetch :) |
| 08:43 | <odinho> | annevk: I'll put it in web-platform-tests/ -- but I should use the TR name, and that's still cors at W3C. :/ |
| 08:43 | <annevk> | odinho: there's a requirement to that effect? |
| 08:43 | <odinho> | Dunno when the man will take Fetch. |
| 08:43 | <odinho> | annevk: Yep. To make it easy to find tests-specs. |
| 08:44 | <odinho> | I think it's a good rule :) |
| 08:44 | <annevk> | good rule of thumb, sure |
| 08:44 | <Ms2ger> | odinho, just put them under fetch |
| 08:44 | <odinho> | annevk: Easy to move when webapps/someone taks fetch |
| 08:48 | <hallvors> | odinho: could you also make sure the correct server names and port numbers work on w3c-test.org ? |
| 08:48 | <hallvors> | or rewrite the tests to use http://www.w3.org/wiki/Testing/Requirements#The_Web_test_server_must_be_available_through_different_domain_names |
| 08:50 | <Ms2ger> | Does webappssec have anything else? |
| 09:09 | <hallvors> | annevk: why is there no text about redirects under "cross-origin request event rules"? |
| 09:09 | <hallvors> | http://xhr.spec.whatwg.org/#cross-origin-request-event-rules |
| 09:09 | <annevk> | Apparently my site is the reference Stackoverflow uses to comment on why application/xml is better than text/xml, except that blog post is really old and obsolete by now (although the bad RFC has not yet been updated). |
| 09:10 | <annevk> | hallvors: CORS handles redirects |
| 09:10 | <annevk> | hallvors: all redirect text is going away once I patch XMLHttpRequest to use Fetch |
| 09:10 | hallvors | will look at CORS |
| 09:10 | <annevk> | Look at Fetch |
| 09:10 | <annevk> | CORS is the past |
| 09:12 | <hallvors> | http://www.w3.org/TR/2013/CR-cors-20130129/#redirect-steps |
| 09:12 | hallvors | will look at Fetch too |
| 09:14 | <annevk> | o_O TR/ |
| 09:14 | <annevk> | http://steps.dodgson.org/b/2013/05/19/polymer-and-web-components/ "The New Gang of Four" :-) |
| 09:15 | <hallvors> | annevk: that's the CORS spec your XHR spec on whatwg links to :) |
| 09:16 | hallvors | believes in clicking links on the web |
| 09:16 | <annevk> | o_O |
| 09:16 | <annevk> | might be the latest I suppose, all the more reason to fetchify it |
| 09:17 | <hallvors> | ugh annevk, come back - I need you :-/ |
| 09:20 | <hallvors> | So Fetch says "If the CORS flag is set and response's location's origin is not request's url's origin, set request's origin to a globally unique identifier." |
| 09:21 | <hallvors> | I'm not entirely sure what that means |
| 09:21 | <hallvors> | but as far as I can tell, it doesn't apply if a CORS resource redirects back to a same-origin resource |
| 09:31 | <odinho> | hallvors: They should use that. |
| 09:32 | <hallvors> | odinho: you meant the server names stuff? |
| 09:32 | <odinho> | Yea. I made a support.js file for that at least. But can double check it when I move it. Was sidetracked by a meeting just now. |
| 09:33 | <hallvors> | excellent |
| 09:34 | <odinho> | hallvors: globally unique identifier is just a long random string, -- and the important part is that it stringifies to "null" but one guid is always != another guid |
| 09:35 | <odinho> | hallvors: If you mysite -> flickr -> flickr, then origin=flickr, if you do anything else, it's guid. |
| 09:35 | <odinho> | hallvors: So even mysite -> flickr -> mysite == guid |
| 09:35 | <hallvors> | OK.. |
| 09:36 | <hallvors> | So that sends no Origin header in the next request - what about cookies? |
| 09:37 | hallvors | sometimes dislikes algorithm-style specs :-/ |
| 10:00 | <hallvors> | Fetch makes NO sense anyway. "If request's omit credentials mode is always": include cookies and auth. Huh? What does 'omit' mean again? |
| 10:03 | <odinho> | Sounds strange. "omit credentials" always should not include cookies and auth. |
| 10:11 | <hallvors> | I just reported a bug for it |
| 10:11 | <hallvors> | probably an error |
| 10:34 | <Ms2ger> | hallvors, 'manual foo.html' in the MANIFEST |
| 10:35 | <jgraham> | Not that that's an agreed standard, but it works with Mozilla's infrastructure at least |
| 10:36 | <hallvors> | OK, thanks |
| 10:36 | <hallvors> | I admit that I don't usually update MANIFEST files |
| 10:36 | <hallvors> | I didn't know what they were for, really.. |
| 10:37 | <Ms2ger> | I've got a tool to automatically run the tests listed there, and they're used for Mozilla's importing code too |
| 10:54 | <gsnedders> | Ms2ger: I started hanging around here when I was 15, not HTML WG fantasy land. |
| 11:04 | darobin | wonders why anyone would *not* want to go to fantasy land! |
| 11:19 | <annevk> | hallvors: seems I inverted the logic there |
| 11:19 | <annevk> | hallvors: for both statements |
| 11:19 | <annevk> | sloppy :/ |
| 11:21 | <odinho> | Ah, I has a pull request BTW. https://github.com/w3c/web-platform-tests/pull/112 |
| 11:21 | <odinho> | I added my todo list to it :-) |
| 11:48 | <hallvors> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22150 . And maybe you can add an explanatory note so that I'll understand why I don't have to report https://www.w3.org/Bugs/Public/show_bug.cgi?id=22151 next time.. ;) |
| 11:56 | <hallvors> | jgraham: was there a new review for https://critic.hoppipolla.co.uk/r/27 somewhere? URL? |
| 11:56 | <hallvors> | (if you haven't gotten around to it, no worries - I'll read through the old review and make fixes) |
| 12:35 | <Ms2ger> | Done with https://critic.hoppipolla.co.uk/r/116 for now, if anybody feels like reviewing |
| 12:49 | <MikeSmith> | hsivonen: about Google Plus, yeah, I got an admin message telling me I had to drop the [tm] from my name in order to comply with their misguided "real name" policy |
| 12:52 | <darobin> | they still have a "real name" policy? |
| 12:54 | <hsivonen> | MikeSmith: :-( |
| 12:57 | <Ms2ger> | Pff, g+ |
| 12:57 | <hsivonen> | Today I learned. If you know the secret address of a shared calendar on Google Calendar and try to subscribe to it from another account, the you don't get to subscribe, but you are told the name of the calendar |
| 13:05 | <MikeSmith> | darobin: yeah they still have such a plicy afaik |
| 13:06 | <darobin> | MikeSmith: so basically it's okay for there to be zillions of bots friending people pretending to be sexy girls so long as they use real names? |
| 13:07 | miketaylr | pretends to be a sexy girl |
| 13:07 | <MikeSmith> | darobin: yep, that's an accurate description |
| 13:07 | <Ms2ger> | Of miketaylr? |
| 13:07 | <MikeSmith> | they really have their priorities straight |
| 13:07 | <MikeSmith> | Ms2ger: heh :) |
| 13:07 | <miketaylr> | :D |
| 13:11 | <Ms2ger> | Oh, looks like Gecko has <track> now |
| 13:21 | <nessy> | nice, nice, nice! |
| 13:35 | <hsivonen> | You'd think that the new Privacy Policy that allows Google to combine data across services would give them a way to tell bots and people apart by analyzing activity on other services |
| 13:37 | <Ms2ger> | That sounds even creepier |
| 13:47 | <jgraham> | Which part of "giant organisation that stores a complete record of everything you view online, your shopping habits, your email, your appointments, your documents and your social contacts" didn't already sound creepy? |
| 13:47 | <darobin> | jgraham: the part where they do the same for bots — poor sods haven't been asking for it |
| 13:47 | <Ms2ger> | "Creepier" doesn't imply it wasn't already creepy |
| 13:48 | <zewt> | the fight for bot privacy |
| 14:42 | GPHemsley | grumbles something about mimesniff |
| 14:44 | <GPHemsley> | Apparently a number of changes have been made to the Gecko sniffer in areas covered by the mimesniff without anyone letting me know |
| 14:45 | <GPHemsley> | +spec |
| 16:17 | <dglazkov> | good morning, Whatwg! |
| 17:16 | Ms2ger | always has to do a double take to figure out whether a tweet came from @FakeAlexRussell or @slightlylate |
| 17:29 | <TabAtkins> | annevk: intertwindedness *is* a word. |
| 17:29 | <Ms2ger> | winded? |
| 17:30 | <TabAtkins> | intertwinedness |
| 17:30 | <TabAtkins> | Too many d's. |
| 17:31 | <TabAtkins> | tantek: Mind editing UI to specify that 'cursor' propagates from the root to the viewport? |
| 17:31 | <TabAtkins> | tantek: See "Addressing space outside a document's root element" thread. |
| 17:32 | <tantek> | what does it mean for something to propagate to the viewport? |
| 17:32 | <tantek> | sounds reasonable |
| 17:32 | <TabAtkins> | The effect of the property applies to the viewport. Check the wording around background. |
| 17:32 | <tantek> | thread on which list? URL if you happen to be looking at it? |
| 17:32 | <TabAtkins> | www-style, one sec for link |
| 17:33 | <TabAtkins> | http://www.w3.org/mid/kmqqts$ql1$1⊙ggo |
| 17:33 | <TabAtkins> | bz and I agree on it |
| 17:36 | <tantek> | TabAtkins - do we have a preferred canonical reference for this notion of viewport in CSS3, or are we still using 2.1 for that? |
| 17:36 | <TabAtkins> | Still 2.1. |
| 17:36 | <tantek> | k |
| 17:36 | <TabAtkins> | Unless B&B has something useful in it. |
| 17:36 | <tantek> | that's what I was wondering actually. |
| 17:36 | <TabAtkins> | Hm, wonder where the concept of "viewport" would even go... |
| 17:39 | <tantek> | yeah, that question. |
| 17:39 | <Ms2ger> | css-viewport-3 |
| 17:39 | <TabAtkins> | Ms2ger: Consisting of two non-boilerplate paragraphs? |
| 17:40 | <Ms2ger> | Sounds like par for the course |
| 17:40 | <TabAtkins> | jerk. ^_^ |
| 17:41 | <Ms2ger> | Me? I'd never! :) |
| 17:43 | <scott_gonzalez> | dglazkov Hixie: The idea of using the new input types (such as <input type="date">) with a custom UI has been discussed a few times on the mailing list, but there's never been a solid answer to this. |
| 17:43 | <scott_gonzalez> | The most recent response I've gotten from Hixie was that custom elements would solve this. |
| 17:44 | <scott_gonzalez> | Is that still the plan? |
| 17:46 | <TabAtkins> | Yes. |
| 17:46 | <scott_gonzalez> | Ok, so this presents two challenges. One hopefully easier to overcome than the other. |
| 17:46 | <scott_gonzalez> | The first problem is that nobody supports this. |
| 17:47 | <scott_gonzalez> | Chrome/Canary throw an error if you try to replace the Shadow DOM for an input: http://jsfiddle.net/tj_vantoll/uTa2d/ |
| 17:47 | <Ms2ger> | Well, nobody supports anything else either |
| 17:47 | <scott_gonzalez> | That's the problem that's hopefully easy to overcome. |
| 17:48 | <TabAtkins> | Yes, that's something we know about and will fix as we go along. |
| 17:48 | <scott_gonzalez> | The bigger problem is that you wouldn't actually want to replace all <input> elements, just the ones of a certain @type. |
| 17:48 | <TabAtkins> | That is indeed the hard problem. :/ |
| 17:48 | <TabAtkins> | <input> was badly designed from the start. |
| 17:48 | <TabAtkins> | No real way around it. |
| 17:49 | <scott_gonzalez> | Ok, let's start with an easier problem. Let's say you want to just create a new element instead of hijacking <input type="date"> |
| 17:49 | <scott_gonzalez> | So you create a custom element like <foo-date> |
| 17:49 | <scott_gonzalez> | Which inherits from <input> |
| 17:49 | <scott_gonzalez> | We'll need a way to specify that it actually inherits from <input type="date"> so that all the semantics work. |
| 17:50 | <scott_gonzalez> | Will custom elements be able to leverage native validation or will everything have to go through setCustomValidity()? |
| 17:53 | <TabAtkins> | We don't yet let you define your own form elements yet. When we do, though, we'll provide hooks for all the APIs. |
| 17:53 | <TabAtkins> | (And probably make satisfying the hooks required - no form elements that provide a submit value but don't understand the validity API, etc.) |
| 17:57 | <tj_vantoll> | It seems like if that were possible you probably wouldn't want to go the route of changing the shadow root of an <input>. |
| 17:58 | <scott_gonzalez> | Well, this is just the same old progressive enhancement of HTML4, upgraded to HTML5. |
| 17:58 | <TabAtkins> | Changing, no. Adding a new shadow root, yes. |
| 17:58 | <scott_gonzalez> | Doesn't adding a new shadow root remove the old one? |
| 17:59 | <scott_gonzalez> | Or did you just mean that we're not reaching into the existing one and changing it. |
| 17:59 | <TabAtkins> | Not quite - it shadows (hah!) the old one, but you can surface the old one through the <shadow> element in your shadow tree. |
| 18:03 | <tj_vantoll> | Has any work started towards specifying custom form elements yet? |
| 18:04 | <TabAtkins> | There has been thought about it. Nothing specified yet. |
| 18:07 | <jgraham> | I assumed intertwindness had been banned as a word to prevent Authur C. Clarke using it in a sex scene |
| 18:07 | <TabAtkins> | I suspect he already has, though I'd have to reread. |
| 18:09 | <tj_vantoll> | Ok so just to make sure I understand what has been discussed, the fact that you cannot add a new shadow root to form elements in Chrome is an implementation issue, but it should be possible at some point. And, the long term plan is to allow for custom form elements that will have hooks into things like the validation APIs. |
| 18:10 | <TabAtkins> | Yes. |
| 18:11 | <jgraham> | FWIW the design of <input> is helpful if you don't start from the point of view of trying to make components work |
| 18:11 | <jgraham> | e.g. <input type=number> can fall back to a text input without problems |
| 18:11 | <TabAtkins> | jgraham: Not particularly. It means that you have to swap out interfaces based on attribute changes, which is nasty in a component-less world too. |
| 18:11 | <TabAtkins> | Yeah, that's the one good thing about it. |
| 18:11 | <jgraham> | Well yes, there is that |
| 18:12 | <TabAtkins> | But can also be solved (with a drop in usability) by allowing fallback contents. |
| 18:14 | <tj_vantoll> | Ok. Thanks TabAtkins. |
| 18:30 | GPHemsley | wonders what is lurking in the shadows... |
| 18:34 | <Ms2ger> | Me |
| 19:53 | <TabAtkins> | GPHemsley: Note that the shadow/light dom naming was originally a reference to legend of zelda. |
| 19:57 | <miketaylr> | so that's the real reason we have <link> for components |
| 19:57 | <TabAtkins> | Well, duh. Surprised it took you so long. |
| 19:58 | <miketaylr> | or is it import now? |
| 19:58 | <TabAtkins> | Still a link. |
| 20:06 | <jgraham> | When do we get the boomerang? |
| 20:06 | Ms2ger | falls over |
| 20:06 | <Ms2ger> | It's here! |
| 21:27 | <rniwa> | TabAtkins: yt? |
| 21:27 | <TabAtkins> | rniwa: pong |
| 21:27 | <rniwa> | TabAtkins: hi |
| 21:27 | <rniwa> | TabAtkins: i have a question for object-fit |
| 21:27 | <TabAtkins> | Shoot |
| 21:27 | <rniwa> | TabAtkins: so suppose we have an image with an instrinstic ratio of 3:2 |
| 21:28 | <rniwa> | TabAtkins: and then set width & height of an img element that uses this page to be 120px and 80px |
| 21:28 | <rniwa> | TabAtkins: now further suppose that I set max-width to 100px; |
| 21:28 | <rniwa> | TabAtkins: in this case, does img element still occupy 80px in height? |
| 21:28 | <hober> | rniwa: what's the value of object-fit? |
| 21:28 | <rniwa> | TabAtkins: (at least that's my current understanding of the spec) |
| 21:29 | <rniwa> | hober: oh very important |
| 21:29 | <rniwa> | TabAtkins, hober: with object-fit: contain |
| 21:29 | <TabAtkins> | That has nothing to do with object-fit, but rather to the sizing algorithm. |
| 21:29 | <TabAtkins> | object-fit doesn't change the sizing algorithm in any way. |
| 21:29 | <rniwa> | TabAtkins: but why? |
| 21:29 | <TabAtkins> | And the sizing algorithm just receives a specified size of 100 by 80 |
| 21:29 | <TabAtkins> | rniwa: Why what? |
| 21:29 | <rniwa> | TabAtkins: why doesn't sizing algorithm change the height to be 66px instead? |
| 21:30 | <rniwa> | TabAtkins: what's the use case for leaving that extra space for img element? |
| 21:30 | <TabAtkins> | ...because why would it? You set the height to 80px. We believe you when you say that. |
| 21:30 | <TabAtkins> | If you want CSS to compute the height, leave it auto. |
| 21:30 | <rniwa> | TabAtkins: so 120px and 80px are bad examples |
| 21:30 | <rniwa> | TabAtkins: a realistic example will be something like 100% by 100% |
| 21:31 | <rniwa> | TabAtkins: or 1em by 1em |
| 21:31 | <hober> | if you don't know what the width or height of an image is, so you don't know it's intrinsic aspect ratio, you want to constrain both width and height and maintain the aspect ratio without having weird extra space on either side |
| 21:31 | <TabAtkins> | Still all bad examples, because you're setting the height. |
| 21:31 | <TabAtkins> | hober: I don't think it's possible to enforce that many constraints at once. |
| 21:31 | <rniwa> | TabAtkins: why not? |
| 21:32 | <TabAtkins> | rniwa: Because you're setting the height. Again, *we believe you* if you set it. |
| 21:32 | <hober> | i *think* we're talking about this case: <img src=unknown.jpg> img { max-width: 100%; max-height: 100%; object-fit: contain; } |
| 21:32 | <TabAtkins> | Okay, so that's a new situation. |
| 21:32 | <rniwa> | hober: s/max-// |
| 21:33 | <hober> | oh, interesting |
| 21:33 | <TabAtkins> | Let's assume that both of the 100%s resolve to a definite length. |
| 21:33 | <rniwa> | <img src=unknown.jpg> img { width: 100%; height: 100%; max-width: 1000px; max-height:1000px; object-fit: contain; } |
| 21:33 | <TabAtkins> | Now, width and height are both auto, so you enter the sizing algorithm with a specified size that's only constrained on the max side. |
| 21:34 | <rniwa> | TabAtkins: wait, why are width & height auto in this case? |
| 21:34 | <TabAtkins> | rniwa: No, your example doesn't demonstrate anything anything, again because width and height are both set. |
| 21:34 | <rniwa> | TabAtkins: yeah |
| 21:34 | <TabAtkins> | hober's does, because they're auto. |
| 21:34 | <rniwa> | TabAtkins: but this is the case i'm talking about. |
| 21:34 | <TabAtkins> | rniwa: Your case has nothing interesting going on, assuming that both 100%s resolve to a definite length. |
| 21:34 | <rniwa> | TabAtkins: no, i'm not interested in talking about the case where width & height are auto. |
| 21:34 | <rniwa> | TabAtkins: what I want is for height or width to shrink |
| 21:35 | <rniwa> | TabAtkins: preserving the aspect ratio |
| 21:35 | <TabAtkins> | rniwa: That's not what you'll get. |
| 21:35 | <rniwa> | TabAtkins: instead of leaving empty space there |
| 21:35 | <TabAtkins> | As I keep explaining. |
| 21:35 | <rniwa> | TabAtkins: so what will happen? |
| 21:35 | <TabAtkins> | If you *leave height auto*, it'll do what you want. |
| 21:35 | <rniwa> | TabAtkins: we don't want to :( |
| 21:35 | <TabAtkins> | Unless the height is too tall, I guess. Then it'll squish. |
| 21:35 | <hober> | if i were to try to put the author of rniwa's example's intent into english, it's "make this image super big, but with max constraints in both dimensions, while preserving aspect ratio" |
| 21:36 | <TabAtkins> | Yeah, I get the intent. |
| 21:36 | <rniwa> | hober: yeah. |
| 21:36 | <TabAtkins> | He just keeps asking me about specific code that doesn't express that intent. ^_^ |
| 21:36 | <hober> | TabAtkins: so how would you acheive that intent, given that you don't know the intrinsic aspect ratio of unknown.jpg? |
| 21:37 | <miketaylr> | isn't that object-fit: cover? |
| 21:37 | miketaylr | should read up |
| 21:37 | <TabAtkins> | miketaylr: No, object-fit has no effect on the <img> element's size. |
| 21:37 | <TabAtkins> | It affects the size of the image *within* the <img> element. |
| 21:38 | <miketaylr> | right |
| 21:38 | <rniwa> | TabAtkins: right, but I'm challenging that behavior isn't useful. |
| 21:38 | <hober> | and how many authors realize that those are different things? |
| 21:38 | <rniwa> | TabAtkins: what most of authors want is for the width & height of img to be affected by object-fit. |
| 21:38 | <hober> | actually, how many authors want those to be different things? |
| 21:38 | <hober> | on the order of zero i'm guessing |
| 21:39 | <TabAtkins> | rniwa: I... don't think they do? I mean, the entire example is about the image changing size within the <img> tag. |
| 21:39 | <rniwa> | TabAtkins: but why do we want that? |
| 21:39 | <TabAtkins> | What you're looking for is a stronger way to enforce aspect ratios than CSS gives you currently. |
| 21:39 | <rniwa> | TabAtkins: when do you want to resize the image within img? |
| 21:39 | <TabAtkins> | For videos, for example, to do letterboxing. |
| 21:40 | <TabAtkins> | When your video and <video> aspect ratios don't match. |
| 21:40 | <rniwa> | TabAtkins: maybe. |
| 21:40 | <TabAtkins> | I don't believe CSS currently has a way to enforce aspect ratios the way you guys are asking for. |
| 21:40 | <rniwa> | TabAtkins: yeah. |
| 21:40 | <rniwa> | TabAtkins: we don't. |
| 21:40 | <TabAtkins> | Not maybe - it's the required and expected behavior in HTML, and you can now express it in CSS. |
| 21:40 | <hober> | letterboxing is an interesting case, yeah, but i think it's the less commonly desired behavior |
| 21:40 | <TabAtkins> | (regarding letterboxing) |
| 21:40 | <rniwa> | hober: right. |
| 21:41 | <hober> | i think we should make the more commonly desired behavior at least as easy to achieve as letterboxing, if not easier |
| 21:41 | <rniwa> | TabAtkins: I'd argue that in most cases, authors want img to change its width & height in accordance to its aspect ratio. |
| 21:41 | <TabAtkins> | hober: Another example is, for example, zooming a large image within a small square. With object-fit and object-position this is pretty easy - just set the width/height to what you want for the "window", object-fit to "none", and then adjust objec-tposition with JS. |
| 21:41 | <TabAtkins> | rniwa: What you want is real aspect ratio control. |
| 21:41 | <rniwa> | TabAtkins: I don't see why we'd want img element to have an extra for letterboxing |
| 21:41 | <TabAtkins> | This isn't just about images. |
| 21:42 | <rniwa> | extra space* |
| 21:43 | <TabAtkins> | Including the ability to say "I'm giving you width/height, but I need you to enforce the aspect-ratio over it anyway", perhaps by declaring a contain or cover constraint within the width/height rectangle. |
| 21:43 | <rniwa> | TabAtkins: right. |
| 21:43 | <TabAtkins> | I have a basic (but slightly broken) proposal for aspect-ratio on my blog which I need to dust off and put into a spec. If you're interested in some implementation, I can work on it and make sure your use-cases are addressed. |
| 21:44 | <TabAtkins> | (I've been ignoring it so far due to lack of implementor interest.) |
| 21:45 | <rniwa> | TabAtkins: that'll be great. |
| 21:46 | <rniwa> | TabAtkins: but i don't think we need anything fancy for now. |
| 21:46 | <rniwa> | TabAtkins: just preserving aspect ratio in the example I gave you earlier. |
| 21:46 | <TabAtkins> | Yeah, not too hard. |
| 21:46 | <TabAtkins> | Dealing with the edge-cases are interesting, but that's it. |
| 21:47 | <TabAtkins> | And with the aspect-ratio property giving an aspect-ratio to arbitrary content (not just replaced elements), it'll work pretty widely. |
| 21:47 | <rniwa> | TabAtkins: all we need to do is to fiddle with the width computation when we're enforcing min/max constriant. |
| 21:47 | <TabAtkins> | More or less, but you also have to fiddle with height. |
| 21:47 | <TabAtkins> | Declaring the constraints you want to follow up-front will fix the issues I had in my aspect-ratio property. |
| 21:48 | <TabAtkins> | Where I tried to magically determine which constraints to respect, based on which things were auto. |
| 21:52 | <TabAtkins> | rniwa: More use-cases for object-fit as it currently stands: Your layout needs a user-supplied image to fill a certain rectangle, but you don't control the aspect ratio of the user-supplied images. Keep a transparent background on the <img> and use object-fit:contain to force the image to fully display withing your specified bounds. |
| 21:53 | <TabAtkins> | (This could also be doable with our new hypothetical property, resizing the <img> itself to contain within your desired bounds.) |
| 21:55 | <hober> | TabAtkins: that sounds just like the letterboxing case to me |
| 21:55 | <hober> | which is definitely an interesting use case, but not as common as the problem rniwa's highlighting |
| 21:55 | <TabAtkins> | hober: Similar, but not quite, because you don't have to worry about the interaction with controls which fill a certain size. |
| 21:55 | <hober> | (which is a very common feature request) |
| 21:55 | <TabAtkins> | hober: Sure, that may be true. Doesn't mean the solution is to abuse an existing property into doing what you want. ^_^ |
| 21:56 | <TabAtkins> | I'm not going to allow another vertical-align train-wreck. ^_^ |
| 21:56 | <hober> | heh. we could just nuke the existing property |
| 21:56 | <TabAtkins> | Already used in the HTML default stylesheet! |
| 21:56 | <hober> | does anyone even implement the current one (besides presto, r.i.p.)? |
| 21:56 | <TabAtkins> | Dunno. |
| 21:56 | <TabAtkins> | Well, printers. |
| 21:56 | <TabAtkins> | Dunno among browsers. Maybe. |
| 21:57 | <hober> | i think people google around for how to do what rniwa wants, they find object-fit: contain, they assume it does what they want, and then they see this weird extra space for no apparent reason |
| 21:57 | <hober> | the other case (letterboxing etc.) isn't as common/compelling |
| 21:59 | <TabAtkins> | Again, all that means is that we need a property that does what they want. |
| 21:59 | <TabAtkins> | It doesn't negate the use-case for object-fit. |
| 22:01 | <hober> | while true, i'd rather change object-fit to do something like what rniwa wants in the common case, and then additionally make it possible to do the (weirder) behavior with some additional values |
| 22:01 | <hober> | 'object-fit: contain letterbox' or some such |
| 22:01 | <rniwa> | TabAtkins: it seems better to address a more common use case. |
| 22:02 | <TabAtkins> | Oh god no. Again, no vertical-align trainwreck. A single property doing two very different things is just asking for confusion. |
| 22:02 | <TabAtkins> | Like, what would "letterbox" even mean for regular content? It's nonsense. |
| 22:03 | <rniwa> | TabAtkins: exactly, that's why it doesn't make much sense for "object-fit: contain" to behave that way. |
| 22:03 | <TabAtkins> | Listen. Just let me define the property for you. I'll post it on the list. You can implement it. Everyone will be happy. |
| 22:04 | <rniwa> | TabAtkins: adding a new property to address my use case will be great |
| 22:04 | <rniwa> | TabAtkins: but I still have concerns for the current behavior of object-fit: contain because it's confusing for authors. |
| 22:05 | <TabAtkins> | Only because their is no way to get what they currently want, and they don't believe that, so they try everything that looks remotely like it'll work. |
| 22:05 | <TabAtkins> | I'm not going to keep repeating myself about the value of object-fit's current behavior. It has its uses. |
| 22:06 | <rniwa> | TabAtkins: and I'm saying that those use cases aren't compelling. |
| 22:06 | <TabAtkins> | Unluckily for you, we have existing things in the web that use the functionality. Removing object-fit just means those things are more magical and can't be tweaked. |
| 22:06 | <rniwa> | TabAtkins: what existing things? |
| 22:07 | <TabAtkins> | <video>. I've already explained this. |
| 22:07 | <rniwa> | TabAtkins: how can video be using this feature when no browsers other than Opera have implemented it? |
| 22:08 | <TabAtkins> | Video is using the functionality that object-fit describes. |
| 22:08 | <TabAtkins> | It letterboxes. |
| 22:08 | <rniwa> | TabAtkins: also, the fact that some element has some interesting layout algorithm doesn't mean we have to expose that as a css property |
| 22:08 | <TabAtkins> | If we dont' have object-fit, that just means you can't do that yourself, or tweak the existing behavior. |
| 22:09 | <TabAtkins> | Unless the "interesting layout algorithm" is a legacy mistake, it is a good thing to make the web platform self-describable. |
| 22:09 | <rniwa> | TabAtkins: I don't those are use cases |
| 22:09 | <rniwa> | think* |
| 22:09 | <TabAtkins> | I do. Shrug. |
| 22:09 | <TabAtkins> | People get to ahve different opinions! |
| 22:10 | <rniwa> | TabAtkins: sure, i agree to disagree |
| 22:11 | <TabAtkins> | (Or rather, people get to disagree because I'm not willing to put the effort into either convincing them, or convincing myself and self-updating sufficiently to be consistent again. No one should ever disagree, as reality is objective, if we had enough processing power.) |
| 22:11 | <rniwa> | reality is very subjective. |
| 22:11 | <TabAtkins> | Wrong. ^_^ |
| 22:11 | <rniwa> | TabAtkins: again, i agree to disagree :) |
| 22:12 | <TabAtkins> | And since reality is objective, there's an objective answer to that question. |
| 22:12 | <TabAtkins> | Your perception of reality is subjective, by definition. |
| 22:13 | <hober> | offhand, i think you could describe <video> with existing platform features without object-fit |
| 22:14 | <hober> | but i didn't just try that :) |
| 22:15 | <TabAtkins> | If you reify <video> into a non-replaced element containing a [video-pane thing], sure. |
| 22:15 | <TabAtkins> | Or rather, you could, once we introduce the sizing property that respects aspect-ratios better. |
| 22:15 | <hober> | then we wouldn't need the weird property value any more, wheee |
| 22:17 | <TabAtkins> | You'd need an equalivalent property, plus enough Web Components to describe <video>, plus some way of describing [video-pane thing]. |
| 22:18 | <TabAtkins> | Better? Arguably either way, I think. ^_^ |
| 22:18 | <hober> | you don't need enough web components to describe video, you just need a pseudo element for the [video-pane thing] |
| 22:19 | <hober> | which could be useful for "the image in the <img>" etc |
| 23:06 | GPHemsley | wants the hookshot |