| 01:31 | <falken> | Hixie_: Regarding https://www.w3.org/Bugs/Public/show_bug.cgi?id=20418, I thought the idea was to change non-modals to not be centered, not clipped, not in the initial containing block... and just be regular boxes. Which is different than what was spec'd before. |
| 01:38 | <aleray> | is it possible to achieve this: http://dpaste.com/1584387/ |
| 01:38 | <aleray> | ? |
| 01:38 | <aleray> | (moving the id attribute up) |
| 01:45 | <TabAtkins_> | aleray: ...yes, it is possible, through any number of means. What are you trying to do? Did you mean to ask that question in this room? |
| 01:54 | <aleray> | TabAtkins_, oups sorry |
| 01:54 | <aleray> | I meant using html5lib python |
| 01:55 | <aleray> | (or lxml since I'm using that too) |
| 01:55 | <TabAtkins_> | Oh, yeah. Just remove the id from the first element, move up with .getparent(), and add it back. |
| 01:56 | <aleray> | TabAtkins_, perfect |
| 01:56 | <TabAtkins_> | LXML is horribly documented. I sympathize. |
| 02:10 | <aleray> | something like this? line 11 http://dpaste.com/1584436/ |
| 02:10 | <aleray> | TabAtkins_, |
| 02:11 | <TabAtkins_> | That looks approximately right. |
| 02:33 | <aleray> | TabAtkins_, nice |
| 02:34 | <aleray> | can I make this code agnostic to the lib I use? ex using dom instead of lxml? |
| 02:34 | <JosephSilber> | TabAtkins_: Is it possible to have a flexbox with align items strech, while still extending beyond the container if needed? |
| 02:35 | <JosephSilber> | TabAtkins_: http://stackoverflow.com/questions/21515042/scrolling-a-flexbox-with-overflowing-content/21541021 |
| 02:36 | <TabAtkins_> | aleray: Dunno if there's a DOM library on top of lxml. I wrote some custom stuff for myself that's DOM-like because lxml is crap. |
| 02:37 | <aleray> | TabAtkins_, thanks. Time to sleep, I'll dive into it tommorow |
| 02:37 | <aleray> | thanks for helping |
| 02:38 | <TabAtkins_> | JosephSilber: Yes, just do the normal thing you would do with overflowing and such. |
| 02:38 | <TabAtkins_> | It works exactly normally. |
| 02:39 | <JosephSilber> | TabAtkins_: It doesn't http://codepen.io/anon/pen/Enjqg |
| 02:39 | <JosephSilber> | Oops. Wrong link. Here: http://codepen.io/anon/pen/qFbKg |
| 02:41 | <JosephSilber> | See the borders there? They don't extend beyond the container's size |
| 02:42 | <TabAtkins_> | JosephSilber: Ah, indeed. Sorry, I was looking at a smaller testcase where the flex item itself overflowed, rather than its contents. |
| 02:42 | <TabAtkins_> | I don't *think* there's a way to solve that, but I'll have to look later. Gotta head home now. |
| 02:53 | <TabAtkins_> | JosephSilber: Okay, looked into it more. |
| 02:53 | <TabAtkins_> | JosephSilber: You're right that it won't work by default. |
| 02:54 | <TabAtkins_> | To make it work, you'll need a min-height: min-content; declaration, from <http://dev.w3.org/csswg/css-sizing/>;, which I don't think is supported anywhere yet. |
| 02:54 | <JosephSilber> | :( |
| 02:55 | <JosephSilber> | thanks though |
| 02:55 | <TabAtkins_> | Such is life in today's paucity of sizing controls. |
| 02:55 | <TabAtkins_> | Alternately, setting align-self:flex-start and height:fill-available should probably work (but again, no support). |
| 02:56 | <JosephSilber> | No support for fill-available? |
| 02:57 | <JosephSilber> | TabAtkins_: There is a way to hack it, if the container has a set height. I can remove the display: flex from the container, then nest another element inside. Make *that* the flex container, and give it a min-height: 100% |
| 02:57 | <TabAtkins_> | Right, fill-available is also from Sizing, and also unsupported iirc. |
| 02:58 | <TabAtkins_> | Interesting hack. |
| 02:58 | <JosephSilber> | But the layout I'm dealing with needs the container to be fluid height :( |
| 03:02 | <TabAtkins> | JosephSilber: Then yeah, you're screwed until we get more sizing controls. |
| 03:03 | <JosephSilber> | TabAtkins: seems there is some support: http://caniuse.com/#feat=intrinsic-width |
| 03:07 | <TabAtkins> | Yup yup, but at least in Chrome, it's only supported for 'width'/etc *I think*. |
| 03:08 | <JosephSilber> | TabAtkins: Well, it kinda works here: http://codepen.io/anon/pen/qFbKg |
| 03:08 | <JosephSilber> | Just can't figure out why it forces scrollbars, even though I set box-sizing to border-box |
| 03:08 | <TabAtkins> | Not in Chrome, as far as I can tell. |
| 03:09 | <JosephSilber> | Interesting. I'm looking at it in Chrome. |
| 03:09 | <TabAtkins> | Hm. Oh, that pen isn't showing any use of the keywords at all. |
| 03:10 | <JosephSilber> | Hadn't saved. Here you go again: http://codepen.io/anon/pen/qFbKg |
| 03:21 | <TabAtkins> | That fill-available behavior is a bug. Mind reporting it? |
| 03:22 | <JosephSilber> | TabAtkins: Yep. I'll build an isolated case. |
| 03:23 | <TabAtkins> | If you swap around and use min-height:min-content instead, it works: http://codepen.io/anon/pen/dIlho |
| 03:24 | <TabAtkins> | Unfortunately you have to remove the box-sizing declaration. The behavior of box-sizing in my example is terrible, but not technically a bug, since that's what the spec actually mandates. |
| 03:24 | <TabAtkins> | I'll have to fix that tomorrow. |
| 03:25 | <JosephSilber> | min-height:min-content does fix it, but I don't understand why. |
| 03:26 | <TabAtkins> | stretch tries to set it to the flexbox's height, unless it's too tall explicitly. Setting min-height:min-content makes it as tall as its contents, so it triggers the "too tall" behavior. |
| 03:26 | <JosephSilber> | By default it should anyhow be expanding to it's content's height |
| 03:26 | <TabAtkins> | Nope, that's not how stretch works. |
| 03:26 | <JosephSilber> | So steretch doesn't care about the element's intrinsic height |
| 03:27 | <TabAtkins> | It does. An element's contents don't contribute to its intrinsic height. |
| 03:27 | <TabAtkins> | "intrinsic height" being a technical term with a specific definition in CSS. |
| 03:27 | <JosephSilber> | oh. ok. thanks a million. will play with it. |
| 03:28 | <TabAtkins> | No problem! Glad to find out that we did indeed fix 'height'/etc and make the keywords work on those properties. |
| 03:28 | <TabAtkins> | Now I just need to get that spec out the door so we can unprefix. |
| 03:30 | <JosephSilber> | I can't reproduce that m fill-available bug |
| 03:31 | <TabAtkins> | I'll try to reduce it later. |
| 03:48 | <JosephSilber> | TabAtkins: using min-height: min-content only stretches the ones whose content are actually taller, but it doesn't affect their siblings. Any flex item whose content doesn't extend beyong the parent's height will still be cut off there: http://codepen.io/anon/pen/ehLFl |
| 04:05 | <TabAtkins> | JosephSilber: Hm, you're right. Try inserting another container around the columns, and make *that* a flexbox with min-height:min-content. |
| 04:05 | <TabAtkins> | Then the columns should all stretch to the maximum height, I think. |
| 04:06 | <TabAtkins> | Unfortunately you can't just put those properties on .content, because .content has to host the scrollbar. |
| 04:06 | <TabAtkins> | (In the middle of making dinner, or I'd be trying this out myself.) |
| 04:07 | <JosephSilber> | TabAtkins: sorry for bothering you. will try |
| 04:17 | <JosephSilber> | That does the trick |
| 04:18 | <JosephSilber> | I just hate haviong to nest so many containers |
| 04:18 | <TabAtkins> | Yeah, I know. :/ |
| 04:18 | <TabAtkins> | Grid will help remove most of them. |
| 04:18 | <JosephSilber> | That's still some way out |
| 04:19 | <TabAtkins> | Not too far out. Chrome's gonna try to ship it early-ish this year. As soon as I take the spec to CR, which I plan to do Real Soon Now®. |
| 04:20 | <JosephSilber> | That's great news. |
| 04:21 | <JosephSilber> | How compatible would that be with what IE has today? |
| 04:21 | <TabAtkins> | Very close. |
| 04:21 | <TabAtkins> | I think property names changed a lot, like Flexbox, but that's it. |
| 04:22 | <TabAtkins> | And we added the template syntax, but that's not required to use Grid, just very helpful. |
| 04:22 | <JosephSilber> | TabAtkins: autoprefixer should be able to handle that just fine |
| 04:22 | <TabAtkins> | Yup. |
| 04:22 | <JosephSilber> | TabAtkins: I love you. Irally adore you. You've brought the most useful stuff to the web in a long time. |
| 04:23 | <JosephSilber> | Thanks |
| 04:23 | <TabAtkins> | Welcome. ^_^ |
| 04:51 | <JosephSilber> | <TabAtkins> JosephSilber: Hm, you're right. Try inserting another container around the columns, and make *that* a flexbox with min-height:min-content. |
| 04:51 | <JosephSilber> | Turns out, that *doesn't* work :( |
| 04:51 | <JosephSilber> | It removes the stretching from the columns. |
| 04:52 | <JosephSilber> | nvm. |
| 04:53 | <JosephSilber> | I keep on jumping between the pen and my real project, but I keep on running into issues in my real project. |
| 04:53 | <JosephSilber> | Hopefully I'll work it out |
| 10:31 | <yoav> | zcorpan: PhillipJ beat me to it :) |
| 10:32 | <zcorpan> | heh |
| 10:48 | <annevk> | zcorpan: can the stable state stuff even work? |
| 10:48 | <annevk> | zcorpan: iirc there's pages depending on img.src = x; if(img.width == 400) to work |
| 10:48 | <annevk> | zcorpan: combined with the document image map of course |
| 10:49 | <zcorpan> | annevk: the spec supports that. it's loaded immediately if the image is in cache |
| 10:49 | <annevk> | zcorpan: I see |
| 10:49 | <annevk> | What's up with the new Twitter? |
| 10:49 | <yoav> | annevk: Wouldn't such pages be racy even with immediate download? |
| 10:50 | <annevk> | yoav: ideally normally you'd queue a task before you update attributes |
| 10:51 | <annevk> | zcorpan: some aspects of that you might want to fix for <picture> btw |
| 10:51 | <annevk> | zcorpan: <img> being so broken is one of the main reasons lazyload is proposed |
| 10:52 | <zcorpan> | annevk: what would you want changed? |
| 10:53 | <annevk> | zcorpan: I think I'd prefer the whole thing to queue a task and then do the fetch |
| 10:54 | <annevk> | zcorpan: and not have the document image cache lookup |
| 10:54 | <annevk> | zcorpan: sorry, do have that lookup, but don't have it be sync |
| 10:54 | <zcorpan> | annevk: how can it not be sync if pages depend on it? |
| 10:54 | <annevk> | zcorpan: you can't change it for <img> |
| 10:55 | <zcorpan> | lunch |
| 10:55 | <yoav> | annevk: Do you have an example of such a page? I find it odd that pages would rely on width and get away with it, even today |
| 10:56 | <annevk> | see topic |
| 10:58 | <yoav> | annevk: The "sense of logic" part? :) |
| 11:00 | <yoav> | All I'm saying is that I doubt there's lots of contents relying on it, since it's likely to fail to work today, at least when the image is not in cache |
| 11:01 | <annevk> | they rely on the special image cache to be there, that's the whole reason the special image cache is defined |
| 11:01 | <annevk> | well, expected perf is another I suppose |
| 11:01 | <annevk> | I don't really have any example pages though |
| 11:01 | <annevk> | I'm sure you can find some crawling through browser bugs |
| 11:03 | <yoav> | OK |
| 11:39 | <annevk> | SimonSapin: is your parser complete? |
| 11:39 | <annevk> | SimonSapin: I like it |
| 12:07 | <zcorpan> | annevk: picture uses img so it can't not use the image cache |
| 12:10 | <SimonSapin> | annevk: I think some corner cases with file: are wrong |
| 12:10 | <SimonSapin> | but yeah, should be mostly complete |
| 12:11 | <Ms2ger> | SimonSapin, wouldn't the while i < input.len() { loops look better with iterators? |
| 12:39 | <annevk> | zcorpan: what do you mean uses img? |
| 12:39 | <zcorpan> | annevk: it's the <img> element that runs the selection algorithm |
| 12:48 | <annevk> | zcorpan: hmm, is there a spec for picture? |
| 12:48 | <zcorpan> | http://picture.responsiveimages.org/ |
| 12:49 | <SimonSapin> | Ms2ger: the thing is, I often want i to outlive the loop |
| 12:51 | <annevk> | Are we really putting CSS syntax into HTML attributes zcorpan? |
| 12:51 | <annevk> | I guess we did it for media queries... |
| 12:51 | <zcorpan> | for some value of css syntax |
| 12:54 | <annevk> | Well now you can use CSS escapes to define the URL |
| 12:54 | <SimonSapin> | the CSS Syntax spec deliberately makes the tokenizer available separately |
| 12:54 | <Ms2ger> | zcorpan, r? https://critic.hoppipolla.co.uk/r/645 |
| 12:54 | <annevk> | The original srcset did not have that |
| 12:54 | <annevk> | SimonSapin: that's very generous |
| 12:55 | <zcorpan> | annevk: hmm. not sure that's intentional. TabAtkins? |
| 12:56 | <zcorpan> | Ms2ger: i'll get to it :-) |
| 12:56 | <Ms2ger> | Thanks! |
| 13:17 | <MikeSmith> | hmm Samsung intending to implement context menus in blink |
| 13:43 | <darobin> | annevk: hey, do you know if Encoding has a test suite? |
| 13:44 | <annevk> | no, just adhoc stuff |
| 13:44 | <darobin> | ok, thanks |
| 13:49 | <darobin> | annevk: do you have that stuff somewhere? I wonder if I could find someone foolish enough to take a stab at this one |
| 13:49 | <darobin> | and even ad hoc stuff can help bootstrap |
| 13:50 | <annevk> | darobin: oh, I actually did write a test for single-byte encodings |
| 13:51 | <annevk> | darobin: http://dump.testsuite.org/encoding/ |
| 13:51 | <darobin> | annevk: cool, ta! |
| 13:51 | <annevk> | darobin: I have a bunch more scattered locally and some old hard drive that's online somewhere, but it's probably easier to start from scratch for those |
| 13:51 | <darobin> | those single byte tests even look pretty sane |
| 13:52 | <annevk> | Yeah, I forgot about those |
| 13:52 | <darobin> | thanks, that's useful |
| 13:52 | <darobin> | I reckon the TS could be bootstrapped with just a port of this to testharness.hs |
| 13:52 | <darobin> | *js |
| 13:53 | <gsnedders> | You really just want to write a testharness.hs to generate the testharness.js |
| 13:53 | darobin | whacks gsnedders behind the ears |
| 13:53 | <gsnedders> | Deep inside, you know you really want to be using Haskell. |
| 13:55 | <annevk> | darobin: note that some of that might be out of date a bit |
| 13:55 | <annevk> | darobin: haven't kept it up to date with changes to the spec |
| 13:57 | <darobin> | annevk: an out of date starting place is better than nothing at all |
| 13:58 | <darobin> | gsnedders: no, at jgraham's behest I only code in Coq |
| 13:59 | <gsnedders> | darobin: But then you can at least programmatically extract Haskell from your theorems! |
| 14:03 | <darobin> | gsnedders: I don't often programmatically extract from my theorems, but when I do, it's in Haskell |
| 14:10 | <annevk> | what's all this Haskell love |
| 14:13 | <jgraham> | Haskell :: p -> ♡ p |
| 14:22 | <gsnedders> | annevk-cloud: Dude, I worked on Carakan post-release. Of course I'm a Haskell fanboy. |
| 14:33 | zcorpan | notices hsivonen.iki.fi is now hsivonen.fi |
| 14:35 | <zcorpan> | hsivonen: /test is gone? |
| 14:35 | <zcorpan> | oh needs trailing slash |
| 14:46 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=24485 is why ping="" would be nice |
| 14:46 | <smaug____> | dglazkov: so what is the plan with shipping shadow dom? |
| 14:47 | <smaug____> | I hope we'll get it a bit more stable and spec reviewed before anyone ships it |
| 14:48 | <MikeSmith> | smaug____: there as an intent message on blink-dev yesterday |
| 14:48 | <MikeSmith> | intent to ship I guess |
| 14:49 | <smaug____> | that is why I ask |
| 14:49 | <smaug____> | what does that mean in practice |
| 14:49 | <smaug____> | like when |
| 14:49 | <smaug____> | and how major changes they are ok to still make |
| 14:50 | <MikeSmith> | I assume Chrome 34 but maybe it's later |
| 14:50 | <smaug____> | need to be more careful with this kind of major change comparing to some smaller APIs |
| 14:52 | <MikeSmith> | smaug____: you could post a reply to blink-dev |
| 14:54 | smaug____ | wonders if that requires use of a google account |
| 14:55 | <MikeSmith> | no |
| 14:55 | <MikeSmith> | I don't think |
| 14:55 | <MikeSmith> | it's just a mailing list with a really horrible Web UI dropped on top of it |
| 14:56 | <MikeSmith> | ah shit maybe you actually do need a google account |
| 14:56 | <MikeSmith> | as far as subscribing |
| 14:58 | MikeSmith | checks the message headers for a subscribe thingey |
| 14:58 | <hsivonen> | zcorpan: good catch. Try /test/ |
| 14:58 | <zcorpan> | hsivonen: yeah that worked |
| 14:58 | <MikeSmith> | smaug____: http://groups.google.com/a/chromium.org/group/blink-dev/subscribe |
| 15:00 | <MikeSmith> | smaug____: blink-dev+subscribe⊙co |
| 15:18 | <MikeSmith> | smaug____: anyway as far as I can tell you can actually subscribe to it using any arbitrary e-mail address you want. They just go out of their way to make it a massive PITA to do it |
| 15:20 | <jgraham> | Everyone uses google, right? |
| 15:22 | <annevk-cloud> | I subscribe using an email address that does not have a Google Account |
| 15:22 | <smaug____> | MikeSmith: I think I managed to subscribe using my spam-email account |
| 15:23 | <annevk-cloud> | smaug____: I suspect you need to give some detailed feedback though |
| 15:24 | <annevk-cloud> | I wonder if they ended up special casing Text nodes |
| 15:24 | <smaug____> | annevk-cloud: yeah, that is the problem. Would need to have time to review the stuff again |
| 15:25 | <smaug____> | but I'm actually mostly wondering why they think the spec is stable enough |
| 15:25 | <annevk-cloud> | Seems like a fair question |
| 15:25 | <annevk-cloud> | Also, I recommend making time :) |
| 15:32 | <foolip> | annevk-cloud: sorry about that, see your inbox :/ |
| 17:01 | <yoav> | annevk-cloud: Regarding what we discussed earlier - I see Gecko returning width when the image is cached, but not Chrome |
| 17:01 | <yoav> | http://jsbin.com/OdOqiSO/2 |
| 17:02 | <yoav> | And even in Gecko it (rightfully) breaks when the page is refreshed (F5, not even ctrl+F5) |
| 17:04 | <yoav> | So it seems like a very fragile thing for authors to count on |
| 17:30 | <annevk-cloud> | yoav: interesting, maybe things can be made better |
| 19:03 | <dglazkov> | good morning, Whatwg! |
| 19:14 | <zcorpan> | "identical elements are replace with a 'use' element; " ;_; http://libregraphicsworld.org/blog/entry/svg-cleaner-0-6 |
| 20:22 | <zcorpan> | yoav: what does http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2795 log for you? |
| 20:24 | <yoav> | log: 0 |
| 20:24 | <yoav> | rendering mode: CSS1Compat |
| 20:24 | <yoav> | document has no title |
| 20:24 | <yoav> | log: 195 |
| 20:25 | <zcorpan> | that means it makes the width available immediately when the image is cached |
| 20:30 | <yoav> | zcorpan: If I understand correctly, the second log, that shows the width, is printed after onload,so after the image was loaded (regardless of caching) |
| 20:31 | <zcorpan> | yoav: in window.onload, test() is run again which creates a new <img> and logs its width |
| 20:31 | <yoav> | Right |
| 20:31 | <zcorpan> | yoav: so at that point the image it points to will be in the cache, because a different <img> loaded it earlier |
| 20:32 | <zcorpan> | yoav: if caching was disabled completely, both would log 0 |
| 20:33 | <yoav> | Yeah, I get your point |
| 20:35 | <yoav> | So, does that mean that the stable state stuff cannot work? |
| 20:42 | <yoav> | zcorpan: Or must be simulated, rather than implemented as is? |
| 20:43 | <zcorpan> | yoav: the stable state stuff is about waiting to fetch an image that is *not* in the cache |
| 20:44 | <zcorpan> | yoav: the spec requires images that are in the cache to be available immediately |
| 20:44 | <zcorpan> | yoav: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data step 7 substep 3 |
| 20:46 | <zcorpan> | yoav: "A user agent that obtains images immediately must also synchronously update the image data of an img element whenever that element has its src, srcset, or crossorigin attribute set, changed, or removed." #the-img-element |
| 20:47 | <yoav> | zcorpan: Need to dig up and see how this translates to code... |
| 21:05 | <zcorpan> | yoav: btw i found https://bugzilla.mozilla.org/show_bug.cgi?id=466586 when searching for bugs in this area. not sure what the bug is there exactly but it seems the page in question expects .width to be available |
| 21:07 | <yoav> | zcorpan: Basically, it seems like we'd need to split/duplicate ImageLoader::updateFromElement and create an updateFromElementIfCached or something of that sort |
| 21:09 | <zcorpan> | yoav: i'm not familiar with the code so i'm not sure what that means :-) maybe foolip does |
| 21:10 | <yoav> | zcorpan: :) Basically I'm looking for ways to split out the "image is already cached" case, so that all other algos will be activated on stable state |
| 21:10 | <zcorpan> | yoav: ok |
| 21:11 | <yoav> | The alternative is to start loading the image, and cancel it if something changes, which gets complicated once we have src, srcset,crossorigin and picture to take into consideration |
| 21:12 | <zcorpan> | yeah we don't want to do that |
| 21:13 | <zcorpan> | at least if "start loading" means we can hit the network before we decide to cancel |
| 21:14 | <yoav> | zcorpan: Oh, definitely. But even if it doesn't hit the network, it can get really complicated to juggle all that |
| 21:15 | <zcorpan> | yeah |
| 21:17 | <zcorpan> | i wonder if it's a good idea to make the sync cache thing unaware of srcset/picture, if that makes the implementation simpler |
| 21:21 | <yoav> | zcorpan: for srcset, it shouldn't matter much |
| 21:21 | <yoav> | for picture, maybe. I need to think about it |
| 22:26 | <sicking> | Hixie: why navigator.getLanguages() rather than navigator.languages? |
| 22:26 | <Hixie> | what would navigator.languages return? |
| 22:27 | <sicking> | A frozen Array of string values |
| 22:27 | <sicking> | the frozen is part is still being debated |
| 22:27 | <sicking> | but we'll only remove it if it's what authors actually think is more JSy |
| 22:27 | <Hixie> | a new one each time? |
| 22:27 | <sicking> | no, same Array until the contents changes |
| 22:27 | <Domenic_> | can the languages change? |
| 22:28 | <sicking> | see https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682 |
| 22:28 | <Domenic_> | ah right hte compromise |
| 22:28 | <sicking> | this is use-case B |
| 22:28 | <sicking> | Domenic_: heycam should be drafting you and a few others an email about whether to freeze or not |
| 22:28 | <heycam> | yeah |
| 22:28 | <heycam> | will do that this week |
| 22:29 | <Domenic_> | cool. excited that people are hammering this out. |
| 22:29 | <sicking> | Domenic_: it seems like freezing is the closest thing we have to the desired behavior that we have. Though I know freezing is frowned upon by a lot of people |
| 22:29 | <Hixie> | sicking: returning a frozen anything seems like a bad idea since it means you can't use it like a normal object (even Node can have expandos, e.g.). returning an Array seems like a bad idea since it means that n.languages !== n.languages sometimes. |
| 22:29 | <sicking> | Hixie: no, n.languages === n.languages will always return true. It only changes value from a task |
| 22:29 | <Domenic_> | sicking: I think freezing works really well. I will be sure to give it some thought though when that email comes around. |
| 22:30 | <Hixie> | sicking: n.languages !== oldnlanguages |
| 22:30 | <sicking> | Hixie: sure, Node.nodeValue !== oldNodeValue too sometimes |
| 22:30 | <sicking> | Hixie: Same thing with Element.innerHTML |
| 22:30 | <Hixie> | sicking: those don't return objects. |
| 22:31 | <sicking> | Hixie: so? |
| 22:31 | <sicking> | Hixie: Node.firstChild !== oldNodeFirstChild |
| 22:32 | <Hixie> | sicking: sure but if you change the first child back, then it goes back to its old value |
| 22:32 | <Hixie> | sicking: it doesn't start returning a new object with the same value as the old old object |
| 22:32 | <sicking> | Hixie: true, but if you create a new Node with the same contents then that's not the case |
| 22:32 | <Hixie> | sicking: it's just bad API design to return a non-live array from a property, imho. Causes all kinds of weird behaviour. |
| 22:33 | <Hixie> | especially a non-live mutable array. |
| 22:33 | <sicking> | Hixie: like? |
| 22:34 | <sicking> | Hixie: As an implementor, I'm more interested in following concentions used elsewhere. I'm happy to wait until we've established a recommended syntax in WebIDL though. But if so, please remove getLanguages() in the meantime |
| 22:34 | <Hixie> | is there any other API anywhere where we return an array? |
| 22:35 | <Hixie> | hm, i guess there are some |
| 22:35 | <Hixie> | oh but those are live and readonly |
| 22:35 | <sicking> | See the use-cases in the bug |
| 22:35 | <Domenic_> | live and readonly arrays do not exist |
| 22:35 | <sicking> | live is generally hated by everyone |
| 22:36 | <sicking> | it's generally not something i'm willing to implement for anything new |
| 22:36 | <Hixie> | i agree |
| 22:36 | <Hixie> | i'm just saying if they're _not_ live then we shouldn't return them from an attribute |
| 22:36 | <Hixie> | it's just wacked |
| 22:37 | <sicking> | Hixie: you appear to be in minority in that opinion |
| 22:37 | <Hixie> | e.g. it forces the UA to remember what it last returned |
| 22:37 | <sicking> | yup, we've already added that ability into our WebIDL code |
| 22:37 | <Hixie> | we chaned a bunch of APIs specifically to avoid doing this, i'm kinda surprised this is even controversial |
| 22:37 | <sicking> | with a specific hook for throwing away that cache |
| 22:37 | <Hixie> | changed |
| 22:38 | <sicking> | Hixie: which APIs were changed? from what to what? |
| 22:39 | <Hixie> | e.g. this is why PropertyNodeList has .getValues() rather than .values |
| 22:39 | <sicking> | where is that used? |
| 22:39 | <sicking> | is this in the microdata API? |
| 22:40 | <Hixie> | yeah |
| 22:40 | <sicking> | ah |
| 22:40 | <sicking> | i don't know that api well enough to comment |
| 22:41 | <sicking> | Generally I think property vs. function should be a choise based on what the specific thing is/does. Not what type it returns |
| 22:42 | <Hixie> | to answer your earlier question, the problems are things like setting an expando on the array, and then it being there until magically one day it isn't because the user happened to tweak the settings |
| 22:42 | <Hixie> | or getting the length of the array, and iterating over it in a timeout loop, and half-way-through it changes length |
| 22:43 | <sicking> | Hixie: if it's frozen that won't happen |
| 22:43 | <Hixie> | being frozen is even worse |
| 22:43 | <Hixie> | since then you can't even _set_ expandos |
| 22:43 | <Hixie> | which is unlike everything on the Web |
| 22:43 | <sicking> | not being able to set them seems like a good thing if you can't reliably get them |
| 22:43 | <Hixie> | a method gives you a much clearer affordance that what you're getting is a new array |
| 22:43 | <Hixie> | then you can set them and get them and it all works |
| 22:43 | <Hixie> | i honestly am quite baffled by wanting a non-method here |
| 22:44 | <sicking> | i'm not going to get into the frozen vs. non-frozen debate though. I'll leave that to people with more JS experience than me |
| 22:44 | <Hixie> | why would you want a property to return a (non-live) array? |
| 22:44 | <sicking> | it seems like a property of the navigator. Not a function of it |
| 22:45 | <sicking> | Hixie: would you have made navigator.language a function too? |
| 22:45 | <Hixie> | can you think of any attribute that returns a non-live array where suddenly the attribute returns a new array? |
| 22:45 | <Hixie> | no, that returns a primitive value |
| 22:45 | <sicking> | Hixie: right, like I said, i think property vs. function should not be a decision based on return-type |
| 22:45 | <sicking> | that answers the why |
| 22:46 | <sicking> | but i agree it's an opinion |
| 22:46 | <Hixie> | i'm just trying to be consistent with the platform here |
| 22:46 | <sicking> | i think the property way will be more consistent with where things are heading |
| 22:46 | <Hixie> | (my _opinion_ is that all of this sucks either way :-) ) |
| 22:46 | <Hixie> | things shouldn't be heading to something different than they already are |
| 22:47 | <Hixie> | because then we'll have an even more multiple-personality platform |
| 22:47 | <Hixie> | it's the Web's biggest failing as a platform |
| 22:47 | <Hixie> | that every API is idosyncratic in its own way |
| 22:47 | <sicking> | this is the old "stick with old suckyness and be consistent vs. create something better even though it breaks with old" debate |
| 22:48 | <sicking> | generally i come down on the "create something better" side |
| 22:48 | <sicking> | but it's a judgement call |
| 22:48 | <sicking> | however I'll note that we get a lot of complaints that "the DOM" isn't very consistent with other JS APIs |
| 22:48 | <Hixie> | i'm very strongly on the "be consistent" side, because if it's inconsistent, it isn't better regardless. |
| 22:49 | <Hixie> | yes, our APIs being inconsistent is what i'm saying |
| 22:50 | <Hixie> | anyway. i don't want to be the one to first introduce an attribute that returns a non-live same-object array |
| 22:50 | <Hixie> | imho that's a mistake, and one we've intentionally avoided before |
| 22:56 | <sicking> | Hixie: at least IDBObjectStore.indexNames IDBDatabase.objectStoreNames navigator.gamepads and HTMLInputElement.files will all be doing that soon |
| 22:56 | <sicking> | Hixie: if you don't want to go first then that's fine, but please remove getLanguages in the meantime |
| 22:57 | <Hixie> | wait, what is happening to HTMLInputElement.files? |
| 22:57 | <sicking> | we're working on removing the FileList class (since it's icky and live) and just having .files return an Array |
| 22:57 | <sicking> | it's unclear if .files should be readonly or not still, but either way it'll return an Array |
| 22:58 | <Hixie> | sicking: (what's with this "my way or remove it" thing you've got going recently? can't we instead try to come up with designs we both think are good?) |
| 22:58 | <Hixie> | hm, yeah, HTMLInputElement.files does have this behaviour already (not with an array, but the problem is the same either way) |
| 22:59 | <sicking> | Hixie: I just don't want features in the spec drafts that implementors don't like. I know you don't think what's in the draft matters and what's in the implementations is the only thing that does. However there's a lot of work trying to convince other people that what's in the spec draft is just a proposal and not to be taken as written in stone |
| 23:00 | <Hixie> | sicking: "sicking doesn't like" isn't the same as "implementors don't like". i haven't heard any other implementors, including those who wanted this feature, say that getLanguages() is bad. |
| 23:00 | <Hixie> | but in any case you have provided compelling evidence that this is already a pattern, so i'm happy to change to an attribute |
| 23:00 | <sicking> | Hixie: which other implementors have asked for this feature |
| 23:01 | <sicking> | Hixie: it isn't a pattern yet since WebIDL doesn't really support it. But we've spent a lot of time debating how to make WebIDL support this |
| 23:01 | <Hixie> | arv commented that he wanted it for chrome at some point |
| 23:01 | <Hixie> | nah, HTMLInputElement.files already does this |
| 23:01 | <sicking> | Hixie: and has arv said that he prefers getLanguages() over .languages? |
| 23:01 | <Hixie> | he hasn't said either way |
| 23:02 | <sicking> | so the only feedback you have is that it's not good? I.e. the one from me? |
| 23:02 | <arv> | getFoo is an anti pattern. I prefer using real getters |
| 23:02 | <Hixie> | i have feedback that one person didn't like the way it was specced, yes |
| 23:02 | <Hixie> | two now :-) |
| 23:03 | <arv> | I was in favor of exposing the capability |
| 23:03 | <Hixie> | right |
| 23:04 | <sicking> | Hixie: generally, whatever you put in the spec gets a lot of momentum, no matter if you've put it in there as a proposal and have no feedback from the people that asked for the feature or not |
| 23:04 | <Hixie> | i wish |
| 23:04 | <Hixie> | but sure |
| 23:04 | <Hixie> | i'm not saying the spec should have bad stuff in it |
| 23:04 | <Hixie> | i'm just saying that one person saying it's bad doesn't mean it's bad :-) |
| 23:05 | <Hixie> | and moreover, that rather than removing it, we should just find a better solution |
| 23:05 | <Hixie> | and then replace it |
| 23:05 | <sicking> | Hixie: sure, add navigator.languages which returns sequence<DOMString> |
| 23:06 | <sicking> | Hixie: i'm happy to replace with something better. But until we agree on what's better I prefer to not have bad features in there |
| 23:06 | <Hixie> | you can't have an attribute return sequence<>s. But they can return DOMString[], which is what i'm speccing. |
| 23:07 | <Hixie> | sicking: i think it's worth at least trying to find common ground for a few minutes before demanding that something be removed, is all i'm saying. "hey, you just did what i wanted, except not quite, so immediately remove it!" is how it comes across. |
| 23:07 | <sicking> | Hixie: cool. Hopefully DOMString[] will go away when we fix the webidl bug. But using it until then seems fine |
| 23:08 | <sicking> | Hixie: i tried to find common ground first. Which is why I pushed for .languages. But since we couldn't reach agreement I asked that it was removed until there was agreement |
| 23:08 | <Hixie> | "i want X" "i want Y" "remove Y" is not trying to find common ground. |
| 23:09 | <Hixie> | "i want X" "i want Y" "how about Z" would be trying to find common ground. |
| 23:09 | <sicking> | what would the Z be here? |
| 23:09 | <Hixie> | i've no idea |
| 23:09 | <Hixie> | that's the "finding" part of "finding common ground" |
| 23:09 | <Hixie> | "i want X" "i want Y because R" "R is false because D" "ok let's do X" would be good too |
| 23:10 | <Hixie> | instead of "i want X" "i want Y because R" "remove Y" "but R!" "R is false because D" "ok let's do X" which is what we did above |
| 23:10 | <Hixie> | anyway |
| 23:10 | <sicking> | a lot of this stuff comes down to opinions |
| 23:11 | <sicking> | you felt that getFoo was an ok pattern, i did not |
| 23:11 | <Hixie> | sure, but the opinions aren't what mattered in the end |
| 23:12 | <sicking> | no? |
| 23:12 | <Hixie> | you showed me a feature that already existed that had the semantics you wanted, disproving my argument regarding lack of precedent. |
| 23:13 | <sicking> | my strategy was always to do that. Which is why I asked it to be removed until there was precedence |
| 23:17 | <Hixie> | sicking: it felt more like "you're wrong, i'm right, i'd rather the spec not have this feature than have it be your way, and i'll just wait until i have more specs to point to rather than convince you now". but whatever. |
| 23:17 | <Hixie> | sicking: see new checkin, let me know if it's ok! |
| 23:22 | <sicking> | Hixie: I generally don't know how to convince you given that a lot API design is not about X being provaly better than Y |
| 23:23 | <sicking> | Hixie: I still don't know how to convince you that .foo is better than .getFoo() |
| 23:24 | <sicking> | especially since that's not always the case. I would have done .innerHTML as getInnerHTML() or as serializeToHTML() |
| 23:25 | <Hixie> | i wouldn't have done innerHTML at all :-) |
| 23:25 | <Hixie> | IMHO attributes are good when you can treat them like variables - cheap to access, unsurprising to reuse |
| 23:26 | <Hixie> | methods are good when you want the author to consider the call expensive, or when you want them to cache the result and operate on that |
| 23:26 | <sicking> | Hixie: another reason that it's hard to convince you in this case is that we disagree on the "do the best we can for new APIs vs. do the most consistent we can for new APIs" issue |
| 23:26 | <Hixie> | yeah |
| 23:26 | <Hixie> | well |
| 23:26 | <Hixie> | more to the point, i disagree with that characterisation of the issue |
| 23:27 | <sicking> | Hixie: sounds like we do agree on the attributes vs. function thing |
| 23:27 | <Hixie> | i think it's "do the best we can for new APIs vs keep changing patterns so authors have to know what year the API was invented to know how to use it" |
| 23:28 | <Hixie> | or more to the point, i don't think it's "best" vs something, it's "consistent" vs "using new idioms" |
| 23:28 | <Hixie> | and it's not at all clear to me that using new idioms is automatically better than being consistent |
| 23:28 | <Hixie> | consistency is a huge part of what makes an API usable |
| 23:28 | <sicking> | Hixie: Another way to put it would be "be consistent with popular JS libraries so that the DOM doesn't look like an alien spaceship vs. be self-consistent within the DOM so that people can find their way around the spaceship" |
| 23:29 | <sicking> | I think it's a judgement call |
| 23:29 | <sicking> | but ultimately I think that I'm more agressive about abandoning existing conventions in the DOM |
| 23:30 | <Hixie> | well, the problem is that "popuplar JS libraries" change every other year |
| 23:30 | <Hixie> | we can't target today's libraries or yesterday's or tomorrow's. We have to design an API for decades. |
| 23:31 | <Domenic_> | i like the spaceship analogy |
| 23:31 | <Hixie> | (also, i'd argue it's the libraries that are the aliens!) |
| 23:32 | <sicking> | Hixie: I've made the same judgement call in the past btw. FileReader was designed to be consistent with XHR. On direct request from authors |
| 23:32 | <sicking> | Hixie: (same judgement call as you made I mean) |
| 23:32 | <Hixie> | well, you have to be consistent with the right thing :-P |
| 23:32 | <Hixie> | XHR is a disaster |
| 23:32 | <sicking> | Hixie: many people argue that the DOM is a disaster |
| 23:33 | <Hixie> | including me, sure |
| 23:33 | <Hixie> | i wouldn't be consistent with .getElementById() over introducing something like .find(), e.g. |
| 23:33 | <Hixie> | but i probably would argue for .getElementsByClassName() rather than .searchClasses() |
| 23:33 | <sicking> | Hixie: patch looks good |
| 23:34 | <sicking> | Hixie: like I said, most if this is judgement calls. Which is why I don't know how to convince you |
| 23:35 | <Hixie> | nor i you |
| 23:36 | <Hixie> | it's probably a case-by-case basis thing |
| 23:36 | <sicking> | yup |
| 23:36 | <sicking> | Hixie: re bug 23988 |
| 23:36 | <sicking> | Hixie: you need some asynchronousness there |
| 23:37 | <Hixie> | hm, good point |
| 23:37 | <sicking> | Hixie: the iterator should probably be a Stream<File> |
| 23:37 | <zewt> | "authors" will request everything, since there are a lot of authors, heh |
| 23:37 | <Hixie> | Stream<> ? |
| 23:37 | <zewt> | this author sure doesn't care much for "consistent with xhr" as a design goal |
| 23:37 | <sicking> | I.e. a Stream where all the returned objects are Files |
| 23:37 | <sicking> | Hixie: though... |
| 23:37 | <zewt> | (i copy and paste code every time i use xhr since I can never remember it, heh) |
| 23:38 | <Hixie> | i figured Stream<File> was a Stream which returned Files, but what's a Stream? |
| 23:38 | <sicking> | Hixie: basically an asynchronous iterator |
| 23:38 | <Hixie> | is that documented anywhere? |
| 23:39 | <Hixie> | i figured async stuff should use promises |
| 23:39 | <sicking> | there's a spec. I don't know how finished it is yet. Nor if it handles objects yet |
| 23:39 | <Hixie> | do you have a url to this spec? WebIDL doesn't mention it... |
| 23:39 | <sicking> | Hixie: Domenic_ is editing. He can fill you in on its status |
| 23:39 | <Domenic_> | https://github.com/whatwg/streams. I would not call it finished (and definitely not polished.) But it does handle objects. |
| 23:40 | <Hixie> | aha, i was wondering when that spec would become something i had to read :-) |
| 23:41 | <Domenic_> | Here is a version that is more readable but omits the crunchy details because I haven't ported them over yet. Click "this one" at https://github.com/whatwg/streams/issues/62 |
| 23:41 | <Domenic_> | (the actual URL is too long for my IRC client) |
| 23:41 | <zewt> | (the only thing I saw about streams was a bug that said "this is replacing blob, so ...", which is silly so I stopped paying attention) |
| 23:41 | <sicking> | zewt: it's not replacing Blob |
| 23:41 | <zewt> | i know that :P |
| 23:41 | <sicking> | similar but separate use cases |
| 23:42 | <sicking> | ah |
| 23:42 | <zewt> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23975 i'm sure there's a context I'm not aware of, all I saw was "stream will replace most roles of Blob" |
| 23:43 | <zewt> | guess I should look at the actual pre-spec so I at least know what it's about |
| 23:46 | <Hixie> | i don't really understand either of these specs |
| 23:46 | <Hixie> | Domenic_: so i have a method that returns an object that represents an asynchronously iterated list of File objects |
| 23:47 | <Hixie> | Domenic_: var list = input.getFileIterator() |
| 23:47 | <Hixie> | Domenic_: how do i use "file", if it's one of these thingies, to pass each File to a method process(file) ? |
| 23:47 | <Hixie> | er |
| 23:47 | <Hixie> | how do i use "list"... |
| 23:48 | <zewt> | <- can't read the examples |
| 23:49 | <Hixie> | i'd like something like function iterate (list) { if (list.done) return; process(list.value); list.moveNext(iterate); }; list.moveNext(iterate); |
| 23:50 | <zewt> | promises are the least intuitive api i've seen on the platform in a long time |
| 23:50 | <Hixie> | though ideally without hte duplicate list.moveNext() |
| 23:50 | <Hixie> | even better would be: |
| 23:50 | <Hixie> | list.readAll(process); |
| 23:50 | <Hixie> | (where readAll's callback gives you controls to pause the iteration) |
| 23:50 | <Hixie> | (e.g. return false to stop) |
| 23:54 | <Domenic_> | Hixie: search for streamToConsole in the anolis-ified version. |
| 23:55 | <Hixie> | yeah that seemed pretty long, i was assuming there was some briefer alternative |
| 23:55 | <Domenic_> | yeah. |
| 23:55 | <Domenic_> | i am not sure streams are perfect for this use case |
| 23:55 | <Hixie> | k |
| 23:56 | <Domenic_> | the benefit would be that you could integrate with a larger ecosystem of streams, e.g. pipe to a transform stream that transforms files into decoded video data, then another transform that muxes them, then pipe them into a video tag. |
| 23:56 | <Domenic_> | but for naive usage something like an iterator of promises would get you closer to your original code |
| 23:57 | <Domenic_> | an iterator of promises would give `function iterate(list) { var entry = list.next(); if (entry.done) { return; } entry.value.then(v => { process(v); iterate(list); }); }` |
| 23:57 | <Domenic_> | anyway got to run |
| 23:57 | <Hixie> | shouldn't streams be simple enough that you could use them here? |
| 23:58 | <Domenic_> | they are meant as a pretty low-level primitive |
| 23:58 | <Domenic_> | for e.g. raw file or socket I/O |
| 23:58 | <Hixie> | low-level doesn't mean they can't be simple... |