| 00:00 | <zewt> | ... so you want sites to arbitrarily disable browser features for everyone? whether you want autofill is an issue between you and your browser, not websites |
| 00:00 | <boogyman> | zewt: yes, and i know i am in the minority, but i know i am more data sensitive than most. |
| 00:01 | <boogyman> | it's my personal opinion that this should be an "opt-in" option for sites, not an "opt out" by UA, but as i stated before, that's really on the authors, not the spec. |
| 00:02 | <zewt> | sorry, but unless you can defend that a bit better, i think that's an opinion without merit |
| 00:03 | <zewt> | "browsers should make it easier to globally disable autofill" would be fine, but "99% of users should have an inconsistent and severely inconvenient browsing experience so 1% of people don't have to go into a menu" frankly seems absurd |
| 00:03 | <caitp> | you'd hope that public computers give you a new profile every time you login, and I think most/many do |
| 00:04 | <caitp> | but the world is a big place, and there are an awful lot of public computers |
| 00:04 | <zewt> | personally i'd say if you're entering information into a public computer, no matter what settings you're changing it'd better not be sensitive info |
| 00:05 | <zewt> | if you have access to change settings (and if the profile doesn't reset every time, as caitp says), then you probably have access to install user scripts for the next guy... |
| 00:07 | <boogyman> | the opinion has merit, just probably not applicable to the "99%" as you stated. |
| 00:08 | <zewt> | no opinion has merit if it's not defended :) |
| 00:10 | <zewt> | bleh, still need to unscrew firefox after that last horrific update, and I assume the inspector still doesn't work with chrome windows... |
| 00:10 | <caitp> | what do you mean by "upload user scripts", anyway? you mean like, they'd sign into someone elses account because the info was autofilled, and exploit that by using their credentials to get some other exploit onto the server? |
| 00:11 | <boogyman> | The opinion was based upon the notion that i don't believe pii/pci data should have the option to enable autocomplete=on, but the difficulty there is around defining unique inputs for things that will contain that type of data, but once again, it's really up to the authors to implement the most semantically appropriate tag. |
| 00:11 | <zewt> | no, just install a foo.user.js as a plugin |
| 00:11 | <zewt> | that's not really defending the opinion at all, it's just stating it |
| 00:12 | <zewt> | *why* do you think that I should be disallowed from having my billing and shipping info autofilled? |
| 00:12 | <caitp> | because it's good practice to memorize your credit card number and home address |
| 00:14 | <boogyman> | while i agree caitp, that's not a reason for why the spec should demand it. the defense comes in the form of personal defense of that information and business liability (although you really cannot prevent stupid). |
| 00:14 | <caitp> | that was not a serious statement boogyman, it can be hard to tell with me sometimes |
| 00:14 | <boogyman> | There's always a tradeoff of ease of use and security and performance. |
| 00:16 | <caitp> | I think the trade off between security and ease of use is often imaginary |
| 00:16 | <caitp> | it's more like security -> ease of use -> privacy |
| 00:16 | <zewt> | well, if you're not going to explain why you think the vast majority of users in the world should be severely inconvenienced, then I'm moving on |
| 00:16 | <boogyman> | how do you define "new login", because most places I know do not default their "internet" icons to launch in private mode. |
| 00:17 | <zewt> | and yeah the browser inspector is still unusable in chrome ... it can attach to the browser window, but it won't actually inspect things like tabbrowser |
| 00:17 | <zewt> | in firefox, rather |
| 00:17 | <boogyman> | zewt: identity theft is a huge inconvenience. |
| 00:17 | <caitp> | and I'm sure bruce schneier or someone has written endless articles about how you can actually get quite good security which is easy to use, just at the expense of depending on third parties like Apple or Facebook |
| 00:17 | <zewt> | non-sequiturs are also inconvenient |
| 00:18 | <boogyman> | how was my statement not relevant? |
| 00:18 | <zewt> | incidentally, both chrome and FF let you open windows that don't store any info ("incognito window", "private window") with a single hotkey, so "i don't want to go into settings and disable things" is a non-argument too |
| 00:20 | <boogyman> | zewt: again not for the spec, but tell that to chrome on android devices. it remembers url history. |
| 00:21 | <zewt> | and that's an argument to email google and ask for a private browsing mode in android, not for anything else |
| 00:35 | <Hixie> | boogyman: so wait, back up. what are you worried about will happen with these shared computers? |
| 00:39 | <boogyman> | having any of my information stored by the browser or site that i do not authorize. |
| 00:43 | <caitp> | I think it's a fair point, that the next billion or 2 billion people on the net might not all have the technical know-how to cover their tracks when they need to, or might otherwise not have an opportunity to do that, and this can lead to breaches of privacy |
| 00:43 | <caitp> | which is a different kind of security violation, but it's not irrelevant |
| 00:45 | <caitp> | I don't think you can really solve that problem at the W3C or WHATWG though, that's something individual applications and browser vendors need to worry about, and is probably not a real argument against autofill |
| 00:46 | <Hixie> | boogyman: well, stored by the browser is up to the browser and how you configure it. stored by the site, if you don't want the site to store your information, good luck. :-) |
| 00:46 | <Hixie> | boogyman: doesn't seem to have much to do with autofill though |
| 00:48 | <caitp> | it would be good if you could create a law by which all user agents had to abide, which ensured that it was easy to understand and configure privacy settings |
| 00:48 | <boogyman> | auto-fill is a post storage concern. If the UA did store the data, it could then auto complete(fill) those same fields. |
| 00:48 | <caitp> | and magically ensured that all users knew about them and their importance |
| 00:51 | <caitp> | but as good as that might be, it's probably not something feasible in the real world |
| 00:52 | <zewt> | (keep laws out of browsers used by people in every country) |
| 00:56 | <zewt> | well, fixed up the broken tab bar, time for the address bar... |
| 00:56 | <SamB> | zewt: how's your status bar doing? |
| 00:57 | <zewt> | i don't have one of those. heh |
| 01:01 | <zewt> | https://zewt.org/~glenn/blah.png getting there |
| 01:38 | <zewt> | oh jesus, the address bar animates around |
| 01:43 | <SamB> | zewt: OUUUCH |
| 01:43 | <SamB> | I can't *wait* for australis to hit ESR |
| 01:54 | <zewt> | https://zewt.org/~glenn/blah2.png well, good enough for now |
| 05:01 | <zewt> | wonder which tab in firefox is making my cpu spin up constantly |
| 05:01 | <zewt> | mysteries |
| 09:10 | <darobin> | quick question for the webidl2.js interface: what's a good name for a type that can take another type as a parameter? (cc tobie) |
| 09:10 | <darobin> | e.g. Promise<Foo> or sequence<Bar> |
| 09:10 | <darobin> | parametrised type? |
| 09:12 | <tobie> | We need that because some specs (*cough* ServiceWorkers *cough*) are extending the Promise type e.g.: ResponsePromise<any> |
| 09:13 | <darobin> | and it would be nice if what you get in the AST matched something that people can vaguely understand |
| 09:14 | <tobie> | note that ResponsePromise<any> isn't supported by WebIDL atm, though. |
| 09:15 | <tobie> | (no idea what the plan is) |
| 09:20 | <darobin> | tobie: http://en.wikipedia.org/wiki/Generic_programming might be the right answer |
| 09:21 | <darobin> | though all I read about this is about Generic classes being parametrised with a type (or variants thereof) so I reckon the "parametrized" instinct might be correct |
| 09:22 | <darobin> | JakeA: re the "if there's an appcache with the SW" question, how about if instead of your option we require the UA to pull out a robotic arm and stab the developer in the face? |
| 09:22 | <JakeA> | haha |
| 09:25 | <tobie> | that's going to be hard to write tests for. |
| 09:25 | <JakeA> | darobin: There's a robotic arm in one of our hardware labs with the sticker "Warning: This machine will not only kill you, it will cause great pain as it does so" |
| 09:27 | <darobin> | tobie: I'm getting several people saying "generic" |
| 09:27 | <darobin> | tobie: also, it'd be nice to have a test for e.g. Promise<Promise<sequence<DOMStrig>>> |
| 09:27 | <darobin> | JakeA: hahaha, that's pretty cool |
| 09:28 | <tobie> | it would be nice indeed. |
| 09:29 | <tobie> | OK, I'll add such a test. |
| 09:30 | <darobin> | tobie: do you mind also s/parametrized/generic/? |
| 09:30 | <tobie> | so it would be: { generic: true, genericType: "Promise" }? |
| 09:30 | <darobin> | the AST is horrible already, if we can make it a little more readable |
| 09:30 | <darobin> | yeah, that WFM |
| 09:31 | <tobie> | don't make it look like "parametrized" was my idea. :P |
| 09:31 | <darobin> | I guess we don't need generic: true if we have genericType, though |
| 09:31 | <darobin> | heh |
| 09:31 | <darobin> | I did tell you it was the first thing that popped up :) |
| 09:31 | <darobin> | but I'm happy with whatever you come up with |
| 09:32 | <tobie> | yeah we could have: { generic: null } and {generic: "Promise" } |
| 09:32 | <darobin> | that WFM |
| 09:32 | <tobie> | ok. |
| 09:32 | <darobin> | thanks a lot! |
| 09:32 | <tobie> | np |
| 09:46 | <annevk> | SimonSapin: http://stackoverflow.com/questions/2050973/what-encoding-are-filenames-in-ntfs-stored-as |
| 09:48 | <SimonSapin> | thanks annevk, but that doesn’t really answer my question |
| 10:04 | <jgraham> | Hmm, I thought generic(s) was the language feature enabled by something that could be parameterised over types rather than the name for the thing itself |
| 10:05 | <jgraham> | But maybe I am wrong |
| 10:06 | <jgraham> | (and that Foo<T> where Foo and T are types implied that Foo is a parameterised type) |
| 10:09 | <jgraham> | Hmm, but wikipedia seems to use "generic type" so ignore me |
| 10:11 | <darobin> | jgraham: I sort of thought that but basically walked the same path you just did |
| 11:21 | <tobie> | likewise. |
| 11:22 | <tobie> | when we have Foo<Bar> , Foo's the Generic type and Bar's the parameterized type, correct? |
| 11:23 | <tobie> | s/correct/do we agree/ |
| 11:23 | <tobie> | ^ jgraham, darobin |
| 11:24 | <darobin> | tobie: hmmm, I'm not sure that's the correct terminology, or in fact that there *is* a correct terminology that holds across the board |
| 11:24 | <darobin> | why do you need the distinction? |
| 11:24 | <tobie> | For the README. :) |
| 11:25 | <tobie> | Promise<any> => { generic: "Promise", idlType: "any" } reads kind of weird tbh. |
| 11:26 | <tobie> | But oh well. |
| 11:35 | <annevk> | I don't think it's generic at the moment |
| 11:35 | <annevk> | There's sequence<T> and Promise<T> |
| 11:38 | <tobie> | annevk: great use of `generic` in the above sentence. |
| 11:38 | <tobie> | annevk: agree WebIDL doesn't support that at present. But SW requires it. |
| 11:39 | <annevk> | tobie: I might be missing something, what does SW require? |
| 11:39 | <tobie> | ResponsePromise<T> |
| 11:40 | <tobie> | I'm not advocating for this, btw. Just pointing it out. |
| 11:40 | <annevk> | Ah subclassing. Subclassing is not supported by IDL basically |
| 11:40 | <tobie> | agreed. |
| 11:40 | <annevk> | We need Team Domenic(tm) for that |
| 11:40 | <tobie> | Question is: will it? |
| 11:40 | <tobie> | K. |
| 11:40 | <annevk> | Yeah, once we align with ES6, @@create will be sprinkled around the DOM |
| 11:40 | <annevk> | Implications unforeseen |
| 11:41 | <tobie> | Well, in the meantime, the parser supports that more generic syntax for generics. |
| 11:41 | <tobie> | that is, once darobin pulls in https://github.com/darobin/webidl2.js/pull/15 |
| 11:42 | <annevk> | cool |
| 11:48 | <darobin> | tobie: and merged it is |
| 11:48 | <darobin> | shipping now |
| 11:49 | <tobie> | awesome. ty. |
| 11:50 | <darobin> | tobie: and npm published as 2.0.6 — thanks a bundle! |
| 11:52 | <tobie> | Yes. Now only [EnsureUTF16] needs fixing. |
| 11:57 | <annevk> | tobie: so did you see my latest question in that bug? |
| 11:58 | <annevk> | tobie: I think if everyone agrees that UTF16String means code units in, scalar values out, we should move ahead and use that as a type |
| 11:58 | <annevk> | tobie: and add a typedef to DOMString for now |
| 11:58 | <tobie> | I did see the question. Didn't understand most of your premises, though. :( |
| 11:58 | annevk | seems the amount of tabs tobie uses, wonders how he copes |
| 11:59 | tobie | doesn't |
| 12:16 | <zcorpan> | jgraham: fyi http://dev.w3.org/csswg/cssom-view/#the-features-argument-to-the-open()-method |
| 12:23 | <darobin> | tobie: re appcache, it might indeed be a good idea to campaign to phase it out once SW becomes broadly available |
| 12:23 | <jgraham> | zcorpan: That seems exactly equivalent to what's in the HTML spec (every actual action is optional), so it's rather unfortunate that it doesn't live there. It also doesn't seem to actually match UAs (c.f. https://developer.mozilla.org/en-US/docs/Web/API/Window.open ) |
| 12:26 | <zcorpan> | jgraham: i recall seeing different behavior when testing it (unsurprisingly), so i specified what i thought was most useful |
| 12:26 | <zcorpan> | jgraham: what in particular did you have in mind not matching UAs? |
| 12:28 | <jgraham> | zcorpan: Well it seems to have fewer features and a different default behaviour (I'm just comparing to the MDN page) |
| 12:29 | <erlehmann> | signing web content via pgp has probably been brought up several times, any idea why it was not successful? http://daten.dieweltistgarnichtso.net/src/http-content-pgp-signature/ |
| 12:30 | <jgraham> | e.g. based on the Gecko bug report I assume that "" is treated like no value passed, but "null" implies the default when passing a value which include e.g. scrollbars=no |
| 12:31 | <erlehmann> | annevk some time ago i had a proposal that media elements in html could be addressed using media fragments. would this require changes in the URL spec? http://daten.dieweltistgarnichtso.net/src/media-fragments-html-polyfill/ |
| 12:32 | <zcorpan> | jgraham: ok, thx. yeah the spec doesn't have such "default" behavior |
| 12:33 | <zcorpan> | i see now that both chrome and firefox open a new tab for empty features but a popup for non-empty |
| 12:37 | <jgraham> | Yeah, this seems to be pretty nasty and confusing :( |
| 12:39 | <zcorpan> | jgraham: i looked through the list in MDN and didn't see any feature name that i want to put in the spec. but let me know if something is needed for compat |
| 12:43 | <jgraham> | zcorpan: Well I guess people are relying on specific features, maybe for intranet apps. So the default behaviour should match and there should be some escape hatch for using the other tokens, I guess |
| 13:11 | <SimonSapin> | erlehmann: The URL spec provides a string for the fragment, that string could be parsed as a media fragment or as something else. They seem pretty independent |
| 13:18 | <erlehmann> | SimonSapin the point is that my polyfill introduces the concept of a sub-fragment. but other specs already have this, so it probably makes sense to specify this on an HTML level, no? |
| 13:18 | <SimonSapin> | what’s a sub-fragment? |
| 13:19 | <erlehmann> | SimonSapin see the example at http://daten.dieweltistgarnichtso.net/src/media-fragments-html-polyfill/ |
| 13:19 | <erlehmann> | it links to http://daten.dieweltistgarnichtso.net/src/media-fragments-html-polyfill/#audio&t=8 |
| 13:19 | <erlehmann> | which means „the resource embedded by the element with the id audio at time 8“ |
| 13:21 | <SimonSapin> | Hum, maybe that should be in HTML near http://whatwg.org/C#scroll-to-fragid , but I don’t think it needs any change in the URL spec |
| 13:21 | <erlehmann> | or http://daten.dieweltistgarnichtso.net/src/media-fragments-html-polyfill/#video&t=00:20 |
| 13:21 | <erlehmann> | the video at time 00:20 |
| 13:29 | <zewt> | well, media fragments are only for media resources (like an actual image or video), right? it's a lot more complex if you want to do it to html, where the fragment is in use |
| 13:31 | <zewt> | sounds like a case for the ##key=value thing that was talked about a few weeks ago |
| 13:35 | <erlehmann> | SimonSapin sorry |
| 13:36 | <erlehmann> | connection was lost |
| 13:36 | <erlehmann> | SimonSapin did you see my last messages about http://daten.dieweltistgarnichtso.net/src/media-fragments-html-polyfill/#video&t=00:20 signifying the video element at time 00:20? |
| 13:37 | <zewt> | erlehmann http://krijnhoetmer.nl/irc-logs/whatwg/20140514#l-633 |
| 13:37 | <erlehmann> | thx |
| 13:37 | <SimonSapin> | erlehmann: yes. Did you see mine? http://krijnhoetmer.nl/irc-logs/whatwg/20140514#l-626 |
| 13:38 | <erlehmann> | yes, zewt, something like http://example.org#video##t=00:20 would probably result in even less collisions with actual content |
| 13:38 | <zewt> | specifically, it allows authors to have hash urls that by design are compatible with ##stuff (not that it would happen automatically, of course) |
| 13:38 | <erlehmann> | though i have gone through content already and the ampersand followed by letters followed by an equals sign is really rare |
| 13:39 | <erlehmann> | SimonSapin http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/080689.html |
| 13:39 | <zewt> | i've done it personally, so i doubt it |
| 13:39 | <erlehmann> | > Also, img elements could certainly benefit from spatial media fragments. |
| 13:40 | <erlehmann> | zewt in ids of elements? |
| 13:40 | <zewt> | i often use urls like http://foo.com/server/path?server=1&query=2#client/path?client=1&query=2 |
| 13:40 | <erlehmann> | zewt http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/080703.html |
| 13:41 | <erlehmann> | zewt so you have then an element with id „client/path?client=1&query=2” ? |
| 13:41 | <zewt> | where "server/path?server=1&query=2" and "client/path?client=1&query=2" are logically equivalent and parsed the same way, except the former is for the server's use and the latter is for script use |
| 13:41 | <zewt> | no, of course not, it's for history API-based scripts |
| 13:41 | <erlehmann> | sounds exceedingly brittle |
| 13:41 | <erlehmann> | well, then we have no conflict |
| 13:42 | <zewt> | nope, works perfectly fine |
| 13:42 | <erlehmann> | conflict only would be if there is a collision |
| 13:42 | <zewt> | there's a conflict because i might have a client query key named "t", which could suddenly trigger a video to seek or something |
| 13:43 | <erlehmann> | zewt only if you have a video that has an id! |
| 13:43 | <erlehmann> | that is the whole point of my proposal |
| 13:43 | <erlehmann> | take http://example.com/server/path?server=1&query=2#client/path?client=1&query=2&t=3 |
| 13:43 | <zewt> | a lot of assumptions, and it prevents the use of your thing with client-side queries, which is exactly something the ##thing is meant to allow |
| 13:43 | <erlehmann> | then you would need to have a video with the id of 'client/path?client=1' for anything to go haywire |
| 13:44 | <erlehmann> | can you point me to the ## thing? |
| 13:44 | <erlehmann> | i just want a simple thing to link to media on web pages. this is currently *not* possible |
| 13:44 | <zewt> | it was a long and noisy discussion that i probably should have summarized on the list |
| 13:45 | <zewt> | (one sec, i summarized it on irc at the time, searching for it) |
| 13:45 | <erlehmann> | i am not at all interested in javascript. i just want to conflicts |
| 13:45 | <erlehmann> | no conflicts |
| 13:45 | <erlehmann> | and a simple declarative way to say „this video on that page at that time“ |
| 13:46 | <erlehmann> | HEY LOOK AT THAT KITTEN |
| 13:46 | <erlehmann> | something that currently needs js which is implemented differently every single time |
| 13:46 | <erlehmann> | or stuff like „hey, look at her face here on this page“ |
| 13:46 | <zewt> | we shouldn't be introducing features that "aren't interested in javascript" |
| 13:46 | <erlehmann> | oh you |
| 13:46 | <erlehmann> | read that again. *i* am not interested in javascript. |
| 13:47 | <erlehmann> | the feature should surely not prevent its use |
| 13:47 | <zewt> | which implies "i don't care if this feature works with JS" |
| 13:47 | <erlehmann> | wrong |
| 13:47 | <erlehmann> | it implies “i don't want a feature that needs js” |
| 13:47 | <zewt> | ... what needs js? |
| 13:48 | <zewt> | the point is allowing browser features in the fragment to be compatible with scripts that also use the fragment (not for browser features to require JS when they don't have to) |
| 13:49 | <erlehmann> | because we already have an incompatible mess of scripts that forward to a point in time of an embedded media resource |
| 13:52 | <erlehmann> | sorry, network |
| 13:53 | <zewt> | the ## proposal is essentially: http://foo.com##key1=value2##key2=value, or http://foo.com#anything##key1=value1##key2=value2, probably parsed as "search for ##key1= in the hash, the value is everything until the next # or the end of string" (doesn't need to be anything fancier than that, I think) |
| 13:54 | <erlehmann> | zewt doesn't that ensure that private semantics are used? |
| 13:54 | <zewt> | the main use case at the time was http://foo.com##text=hello ("find the first string "hello" and jump to it") |
| 13:54 | <zewt> | erlehmann: what do you mean? |
| 13:54 | <erlehmann> | ah, i misunderstood it probably. |
| 13:54 | <erlehmann> | private semantics, that people “invent“ keys |
| 13:54 | <erlehmann> | like with hashbangs |
| 13:54 | <zewt> | it's intended to be used for browser features like these, while allowing users to put their own stuff in the hash like I do (without them colliding) |
| 13:55 | <erlehmann> | i see |
| 13:55 | <caitp> | lets not encourage making uris even less uniform and more stupid |
| 13:55 | <caitp> | please |
| 13:55 | <erlehmann> | i see users putting “their own stuff” in the hash as something evil |
| 13:55 | <caitp> | they're bad enough as it is |
| 13:55 | <zewt> | eg. if I have http://foo.com#activeTab=settings, the two can coexist: http://foo.com#activeTab=settings##text=hello |
| 13:55 | <erlehmann> | what caitp says |
| 13:55 | <zewt> | caitp: right, this is meant to give some uniformity to custom hash stuff (it can't enforce it, but it gives an option) |
| 13:57 | <zewt> | erlehmann: well, i couldn't disagree more :) |
| 13:57 | <zewt> | but that's probably too long a discussion for now as I need to head to work |
| 13:57 | <caitp> | people already don't really understand uris, and abuse them in all sorts of bizarre ways that they were never intended for |
| 13:57 | <zewt> | but people putting data in the hash is a common, accepted practice, supported by the web (History.pushState) and it's not going away |
| 13:57 | <caitp> | it doesn't need another abuse vector @_@ |
| 13:57 | <erlehmann> | yeah, what caitp says |
| 13:58 | <erlehmann> | this recent “haha, privacy is bad enough, lets give more fingerprinting options” is something like that |
| 13:58 | <erlehmann> | “the web is broken, lets break it more!” |
| 13:58 | <zewt> | alright, this conversation is turning rhetorical rather than informative so I'm headed to work now :) |
| 13:59 | <TabAtkins> | erlehmann: Not really. The fingerprinting thing is "We're already broken almost completely, and are very unlikely to fix it in any meaningful way, so more breaking doesn't hurt anything.". |
| 14:00 | <zewt> | (though it does seem a little weird to say "putting data in the hash is evil and abusive" alongside "i want to encode video timestamps in the hash" is a very confusing pair) |
| 14:00 | <zewt> | (that was a fascinating sentence structure) |
| 14:00 | <TabAtkins> | It's an aspect that hits a maximum brokenness and then doesn't get more broken, unlike other things. |
| 14:00 | <caitp> | don't irc while you drive, zewt |
| 14:00 | <caitp> | jeeze man |
| 14:01 | <zewt> | irc has the effect of sucking people back in and making them late for work :P |
| 14:01 | <erlehmann> | TabAtkins i know, but i think it is really a bad thing to inform untrusted software of how much resources it can afford to waste regardless. |
| 14:02 | <TabAtkins> | erlehmann: As argued by multiple other people, you can already figure this out roughly with a pretty easy stress-test. |
| 14:04 | <erlehmann> | TabAtkins i think one should not make it easier. |
| 14:04 | <erlehmann> | OTOH, maybe you don't think that the linux OOM killer is a pretty good idea. |
| 14:04 | <erlehmann> | because if an application wants to “stress test” the memory subsystem, it will be terminated |
| 14:05 | <TabAtkins> | Shrug. It *is* a useful piece of information. |
| 14:05 | <erlehmann> | what's your stance on that? |
| 14:05 | <erlehmann> | and that i think not. i think it is something that encourages wasteful programming. |
| 14:05 | <erlehmann> | and user differentiation. i have already seen web pages that tell me to get a new graphics card. |
| 14:05 | <erlehmann> | which makes the web less universal |
| 14:06 | <caitp> | if people had to be competent kernel developers to write web applications, the web would be a lot tinier |
| 14:06 | <erlehmann> | “this web pages needs at least 4 cores” |
| 14:06 | <erlehmann> | caitp it is not about kernel developers. it is about app developers |
| 14:06 | <TabAtkins> | I have some webapp that benefits from parallelization. It's silly to spawn up more workers than a comp can possibly use; it'll just mean I waste more time in scheduling. |
| 14:06 | <erlehmann> | as soon as you find out that there *is* an OOM killer, you try to allocate the least amount of memory reasonably possible |
| 14:06 | <erlehmann> | lest your app is killed |
| 14:07 | <erlehmann> | TabAtkins that's quite true. though my core uno machine only becomes notably less responsive when load is >200 |
| 14:07 | <erlehmann> | so kudos to the scheduling people |
| 14:08 | <erlehmann> | (yes, two zeros) |
| 14:08 | <erlehmann> | TabAtkins may i ask why “use all available resources” is important in your case? |
| 14:09 | <erlehmann> | instead of having a baseline and then going all linear growth / exponential backoff from that? |
| 14:09 | <TabAtkins> | Because it's simpler and more likely to get right immediately. It's definitely not as good as dynamic scaling, but is simpler. |
| 14:10 | <erlehmann> | TabAtkins so what would happen if something like your page is opened in two tabs? |
| 14:10 | <erlehmann> | both spawn maximum workers? |
| 14:11 | <TabAtkins> | Yeah, probably. |
| 14:11 | <TabAtkins> | I mean, the thing in back is gonna get scaled back by the browser anywya. |
| 14:11 | <erlehmann> | well, then it sounds to me that the “give me an integer for concurrency” proposal is simple and more likely to be horribly wrong |
| 14:11 | <erlehmann> | because if it is simple, people will use it |
| 14:12 | <TabAtkins> | More likely to be right than guessing an arbitrary number, which is what most people do today. |
| 14:12 | <erlehmann> | and advice might be “spawn the number of workers that navigator.concurrency” gives |
| 14:12 | <erlehmann> | instant scheduler hell. |
| 14:12 | <TabAtkins> | The options are: (1) guess, (2) use what the browser tells you, or (3) implement dynamic perf scaling. |
| 14:12 | <TabAtkins> | The first two are way easier, and (2) is better than (1). |
| 14:12 | <erlehmann> | maybe (3) can be made easier |
| 14:13 | <caitp> | it would help if people stopped thinking of concurrency as multithreading |
| 14:13 | <TabAtkins> | Everyone keeps suggesting that we can invent things that make (3) and other more complex multi-core scheduling easier. But nobody's produced such a thing, so shrug. |
| 14:14 | <caitp> | ideally you shouldn't have to care how many processing units you have to decide how many coroutines you need |
| 14:15 | <caitp> | because they shouldn't be related |
| 14:15 | <erlehmann> | TabAtkins i think the difference is that some people (me included) think that more deliberation is going to produce a better outcome than immediate action. |
| 14:16 | <erlehmann> | TabAtkins there is precedent for gcd-style stuff in js https://github.com/skylar/node-tasks/blob/master/examples.js |
| 14:17 | <TabAtkins> | And you're more than welcome to deliberate and develop such a thing so we can replace it. In the meantime, replacing the "just guess a number" approach is a benefit, simplifies something you can already do, and can be done on every other platform. |
| 14:19 | <erlehmann> | why not have a call that instantiates a worker and then provides a return value to say if it is safe to instantiate another? |
| 14:19 | <erlehmann> | or something? |
| 14:19 | <erlehmann> | hmm |
| 14:19 | <caitp> | TabAtkins, if workers were more like goroutines or even rust tasks, (which they already are, sort of, in an API sense), it becomes much less of a problem, because you don't necessitate a new thread or process |
| 14:19 | <erlehmann> | i'm pulling that out of my ass and should really not comment on that. i am not qualified. |
| 14:19 | <caitp> | and you don't have to worry as much about how many simultaneous jobs you can run |
| 14:19 | <caitp> | they may or may not be simultaneous, it's not important |
| 14:20 | <TabAtkins> | erlehmann: How is that not equivalent to just providing a number of workers you can instantiate up front? |
| 14:20 | <TabAtkins> | caitp: Yeah, even lighter-weight routines are nice, but they're not what Workers are. |
| 14:21 | <caitp> | but they could be |
| 14:21 | <erlehmann> | TabAtkins it encourages dynamic scaling |
| 14:21 | <caitp> | web developers don't need pthreads |
| 14:21 | <caitp> | ensuring that they're heavyweight creates this problem and doesn't necessarily benefit people |
| 14:21 | <TabAtkins> | erlehmann: Devs would just quickly gen everything they need until they get a false return value. Identical to getting the number up-front and generating the number they need. |
| 14:22 | <TabAtkins> | caitp: Sometimes you do need heavier threads. |
| 14:22 | <caitp> | sometimes, but what if you need them and only have a single core machine |
| 14:22 | <erlehmann> | i think the distinction between threads and coroutines is pretty arbitrary |
| 14:22 | <caitp> | but you still have two tasks you want to run concurrently |
| 14:22 | <TabAtkins> | caitp: Well they get scheduled against each other then. Ah well. |
| 14:23 | <caitp> | I mean, you could let the OS do the scheduling for you, but then you have the cost of context switching between them |
| 14:23 | <caitp> | and that's not very helpful is it |
| 14:24 | <caitp> | the browser has this knowledge, and it can decide to split things across 1, 2, 4, 8 or N jobs, the developer shouldn't have to care. even if they think they need to care, they probably don't |
| 14:26 | <erlehmann> | what caitp says |
| 14:26 | <erlehmann> | if they think they have to care, there should be an api to group workers that should be run in parallel |
| 14:26 | <jgraham> | TabAtkins: AFAICT the arguments in favour of .hardwareConcurrency simultaneously assume that you can just rely on the scheduler to cover you when you spin up N workers on an N core machine and M cores are either unlike the other cores, or are running some other tasks, and assume that the scheduler can't cover you if you just guess that "8" is probably |
| 14:26 | <jgraham> | TabAtkins: AFAICT the arguments in favour of .hardwareConcurrency simultaneously assume that you can just rely on the scheduler to cover you when you spin up N workers on an N core machine and M cores are either unlike the other cores, or are running some other tasks, and assume that the scheduler can't cover you if you just guess that "8" is probablyQuery matches in addon-sdk/Makefile.in Line Code Snippet |
| 14:26 | <jgraham> | Hmm |
| 14:27 | <zewt> | parse error, redo from start |
| 14:27 | <jgraham> | that "4" or "8" is probably an OK value |
| 14:28 | <TabAtkins> | Not quite for the latter one. It's that we can improve over just guessing "8"; for machines with less useful cores, you can use the smaller number and avoid contending with the scheduler overhead unnecessarily. |
| 14:28 | <TabAtkins> | (Computer's about to die, so I'll probably check out.) |
| 14:30 | <jgraham> | An improvement that is likely to be just as wrong in many cases seems like a very margianal improvement indeed |
| 14:31 | <TabAtkins> | Luckily it's a very marginal cost as well. |
| 14:34 | <zewt> | when one implementor says "we'll just cap it to 8 [and screw over people with powerful computers]" it makes one skeptical, heh |
| 14:35 | <caitp> | exactly what are you doing in your web app that you need 10+ proper threads? |
| 14:36 | <zewt> | what? any task that's CPU-bound and parallelizes well ("reencode lots of files from MP3 to Vorbis", etc) |
| 14:37 | <jgraham> | (I also note that 1 worker = one thread is not required anywhere) |
| 14:38 | <caitp> | it's not required, but it is pretty much hinted at |
| 14:38 | <jgraham> | (and that's not how presto implements it, for example) |
| 14:38 | <zewt> | yeah, that should be treated as an implementation detail |
| 14:39 | <caitp> | the spec says that workers are heavyweight, and can be pretty much expected to be OS threads |
| 14:39 | <zewt> | no sense creating lots of system threads if they're I/O-bound workers that sit around waiting for messages a lot |
| 14:39 | <zewt> | the spec is occasionally mistaken |
| 14:39 | <caitp> | in other words no scheduling algorithm is specified and it's up to the host platform |
| 14:39 | <caitp> | unless the browser comes up with something on its own, which may or may not be adequate |
| 14:41 | <zewt> | the spec doesn't distinguish between the "OS" and the "browser" in any real way, as far as I know, they're all just implementation details |
| 14:42 | <caitp> | i'm not saying the web workers spec should tell browsers how to schedule microtasks or anything, but it would probably be good if browsers were encouraged to implement them |
| 14:43 | <zewt> | what detectable behavior do you think is underspecified? |
| 14:44 | <zcorpan> | caitp: workers don't have to be heavyweight though. i think the impl in presto was lightweight, but then it also didn't take advantage of multiple cores |
| 14:44 | <caitp> | it's not that they have to be heavyweight |
| 14:44 | <caitp> | but the spec sort of says "they're probably heavyweight, they're allowed to be heavyweight" |
| 14:44 | <zcorpan> | yeah |
| 14:45 | <caitp> | and as a result, they likely are OS threads |
| 14:45 | <zewt> | i'd expect browsers to have a small pool of real threads, and to schedule workers on them, so it would use multiple cores but also allow limiting the number of real threads and not taking whole threads for blocking workers |
| 14:45 | <Domenic> | Normatively workers are "a separate thread or process or equivalent construct" |
| 14:45 | <caitp> | welcome to chromium where you have entirely different processes all over the place |
| 14:46 | <zewt> | not using multiple real threads is lame and poor implementation quality, but the spec shouldn't try to prevent it (if browsers want to pretend that each tab only gets one CPU, they can do that) |
| 14:47 | <jgraham> | Domenic: "equivalent construct" is a lot of leeway |
| 14:49 | <zewt> | Domenic: i don't think a phrase starting with "i.e." can be considered normative, heh |
| 14:49 | <Domenic> | zewt: I think "i.e." can; "e.g." cannot. |
| 14:50 | <zewt> | more practically, i'm not sure what detectable behavior we're talking about that we think is wrong or underspecified |
| 14:50 | <jgraham> | I'm not sure I think that anything is wrong or underspecified |
| 14:51 | <caitp> | I don't think you want the spec to encourage applications to care about how many cores they have available |
| 14:51 | <caitp> | just IMO |
| 14:52 | <caitp> | the browser should care, but script contexts not so much |
| 14:52 | <zewt> | are you referring to the "are workers threads" discussion, or are you talking about something else? |
| 14:52 | <caitp> | I'm referring to the "integer telling you how many cores you have" thing |
| 14:52 | <zewt> | okay, context change marker needed :) |
| 14:53 | <zewt> | i'm very unconvinced about that feature too |
| 14:54 | <zewt> | (not to say I'm totally convinced against it, either) |
| 14:55 | <caitp> | in my mind, once you start going down that road, before you know it you've got WebIDL mapping 1:1 with pthreads |
| 14:55 | <caitp> | and nobody wants that |
| 14:55 | <Domenic> | asm.js people want that |
| 14:56 | <zewt> | sounds like a bit of a giant leap |
| 14:56 | <caitp> | they think they want that, they don't really |
| 14:56 | <Domenic> | no, literally, e.g. epic games wants to be able to compile their pthread-using C++ to JS |
| 14:56 | <zewt> | that stuff has always seemed like impractical nonsense to me |
| 14:57 | <caitp> | I think it is okay to say "hint that this worker probably wants to have its own OS thread" |
| 14:57 | <zewt> | why would you need to do that? |
| 14:57 | <caitp> | because maybe you're Epic Games or whoever |
| 14:57 | <zewt> | sorry, that does help explain what we're talking about now |
| 14:58 | <Domenic> | yeah, this is a different discussion, i was jumping off of your full pthread-API idea |
| 14:58 | <zewt> | but it seems like we're far away from "scripts want to know how many threads to use" |
| 14:58 | <caitp> | it's all related |
| 14:58 | <Domenic> | web workers, even as heavyweight threads, are so far from pthreads |
| 14:58 | <caitp> | so, there's a distinction between concurrency and parallelism, do you agree |
| 14:58 | <caitp> | concurrent tasks may or may not be run in parallel |
| 14:58 | <zewt> | they're synonyms, so no |
| 14:58 | <caitp> | they're not actually synonyms |
| 14:58 | <Domenic> | i am not really interested in a first-principles schooling on concurrency vs. parallelism, so count me out. |
| 14:59 | <caitp> | people mistake them for synonyms, but they're not |
| 14:59 | <zewt> | yeah i have things i'd rather be doing |
| 14:59 | <caitp> | that's fine, but it's worth learning about when you have time |
| 15:00 | <zewt> | than "take two words that every english speaker uses interchangeably and assign subtle extra meanings to them that nobody has used since their college class on threading fifteen years ago" |
| 15:01 | <caitp> | well, getting too philosophical about it isn't really worth doing |
| 15:02 | <caitp> | but the point is, you have N things you want to do, and you want to do them roughly simultaneously to meet some end |
| 15:02 | <caitp> | you might do them in parallel, or you might do them in sequence a little bit of each at a time |
| 15:02 | <caitp> | both are concurrent |
| 15:03 | <caitp> | the distinction, ideally, does not matter to the developer |
| 15:03 | <zewt> | not sure how that matters here |
| 15:04 | <caitp> | it matters because when you stop caring about parallelism vs concurrent, you stop needing to worry about the hardware limits of your platform |
| 15:05 | <caitp> | the browser allocates your task somewhere, whether on the current thread or some new thread, and you're none the wiser |
| 15:05 | <caitp> | that's how it should be, invisible to the web developer |
| 15:05 | <zewt> | sounds very academic; in practice if you start far more processes than CPUs you pay a cost of extra overhead |
| 15:05 | <caitp> | because the web developer does not know or care whether she's running her task on a different core or not, she doesn't need to care how many cores there are |
| 15:06 | <caitp> | right, so the browser will be clever and not start more threads than it thinks are appropriate |
| 15:06 | <zewt> | if you have an embarassingly parallel problem to solve (eg. "do a bunch of work to each of 1000 files") which can scale to any number of CPUs, and you want your program to work well on both 2-CPU machines and 128-CPU machines, you don't want to just start 128 processes, since the 2-CPU machine will have a ton of extra overhead as a result |
| 15:07 | <zewt> | currently the browser has no idea what the threads are for, so it has no way of knowing what to do |
| 15:07 | <caitp> | you're a web application, you aren't going to try and do the work that a 128-processor machine will do |
| 15:07 | <caitp> | it's not realistic |
| 15:08 | <zewt> | for example, if each worker is processing one file, then the ideal thing for the browser to do in that particular case is to run two workers at a time, and just queue the others and not do any work on them |
| 15:08 | <caitp> | I'm a microtask, for my current turn through my event loop, I'm doing this much work, and taking this long |
| 15:09 | <caitp> | the browser keeps track of this information, and uses it to schedule how long I run |
| 15:09 | <caitp> | if I do a lot of work, maybe I get moved to a new thread |
| 15:09 | <caitp> | if I stop doing a lot of work, maybe I join the main thread |
| 15:09 | <caitp> | it's not super relevant |
| 15:09 | <caitp> | we can do the math and sort it out |
| 15:09 | <jgraham> | caitp: Most browser engines can't suspend scripts midway through execution, so that idea doesn't work |
| 15:10 | <caitp> | you mean chopping up a turn through the event loop |
| 15:10 | <caitp> | yes, that would take some work |
| 15:10 | <jgraham> | Presto could |
| 15:11 | <zewt> | jgraham: if browsers are putting workers on a single thread and can't suspend them, that sounds like a big bug |
| 15:11 | <caitp> | if you're running V8's jit compiled code on the main thread, you might have a hard time stopping it |
| 15:11 | <zewt> | if one worker going while(true); can stop other workers from ever running |
| 15:12 | <gsnedders> | zewt: There's a reason why Presto was the only one that could suspend and did workers on a single thread :) |
| 15:12 | <caitp> | course, it doesn't have to be hard to stop it, that could change |
| 15:12 | <gsnedders> | caitp: Carakan's JIT had no effect. Essentially it could suspend at any point GC could run. Which is plenty of places. |
| 15:12 | <jgraham> | zewt: I don't know that there is any combination of browser that does multiple workers per thread and can't suspend |
| 15:12 | <gsnedders> | I think. |
| 15:13 | <jgraham> | It's just that there is only one that does multiple workers per thread |
| 15:13 | <jgraham> | and it isn't actively developed |
| 15:13 | <caitp> | which is too bad, because that's really the right way to do it |
| 15:13 | <gsnedders> | Except that can't have been it. Because how would that handle while(true);... oh well, I forget |
| 15:16 | <caitp> | anyways yeah, it's a bit of work for jit compiled script, but I think it would be good to encourage implementations to do that, instead of exposing all of the pthreads nonsense to web developers |
| 15:16 | <caitp> | not that workers are a bad thread api |
| 15:17 | <caitp> | if you're going to have heavyweight threads, web workers aren't a bad approach |
| 15:17 | <gsnedders> | Maybe we could stop on any backedge too, idk? |
| 15:17 | <jgraham> | I think it would be a *lot* of work to allow that, mainly in the dom code rather than in the js engine |
| 15:18 | <jgraham> | And it's not really clear that it helps with the fundamental problem |
| 15:18 | <caitp> | the fundamental problem of doing lots of things? |
| 15:18 | <jgraham> | In fact it might well make it worse (by trashing the cache) |
| 15:18 | <caitp> | oh probably |
| 15:19 | <caitp> | but I mean, context switches between OS threads aren't really free either |
| 15:19 | <gsnedders> | I don't think there was any complexity in the DOM? The big problem was the cost of reflowing too often. |
| 15:19 | <gsnedders> | Because nobody else would reflow during JS execution. |
| 15:19 | <jgraham> | gsnedders: I think there was |
| 15:19 | <gsnedders> | But someone who has current access to Presto is probably better to speak to than the two of us. :P |
| 15:19 | <jgraham> | But you would have to ask bratell or jl or someone |
| 15:20 | <gsnedders> | idk, I never touched the DOM code much |
| 15:20 | <zcorpan> | jgraham: i can't get the response writer thing to work. the resource never finishes loading |
| 15:21 | <jgraham> | zcorpan: Are you setting a content-length header? |
| 15:21 | <zcorpan> | hmm. nope |
| 15:21 | <jgraham> | zcorpan: You either need to set a content-length header of make sure that the connection gets closed after the response finishes |
| 15:22 | <jgraham> | which you can do by setting response.close_connection = True |
| 15:23 | <zcorpan> | content-length worked. thanks |
| 15:23 | <jgraham> | OK. Are the docs wrong? This changed when we enabled HTTP/1.1 |
| 15:24 | <jgraham> | It looks like they are |
| 15:24 | <zcorpan> | the example in https://github.com/w3c/wptserve/pull/24 doesn't do either at least |
| 15:24 | <mathiasbynens> | http://validator.nu/ is down |
| 15:27 | <zcorpan> | hsivonen: MikeSmith: ^ |
| 15:32 | <hsivonen> | mathiasbynens: thanks. It's up again now. |
| 15:32 | <mathiasbynens> | hsivonen: thanks! |
| 16:07 | <JonathanNeal> | Is there anything like http://api.jquery.com/closest/ coming into native JS? |
| 16:10 | <jgraham> | JonathanNeal: I don't think anyone is working on that |
| 16:14 | <Domenic> | that would be nice |
| 16:14 | <Domenic> | it is a kind of shitty name though |
| 16:14 | <Domenic> | .ancestor(selector) might work better |
| 16:35 | <darobin> | Domenic: .ancestor(selector) would sound to me more like jQuery's .parents(selector) |
| 16:35 | <Domenic> | darobin: singular vs. plural seems to be the key here |
| 16:35 | <Domenic> | .ancestors vs. .ancestor |
| 16:36 | <darobin> | Domenic: mmmm, I'm not so sure — I mean they do rather different things |
| 16:36 | <darobin> | or rather, I take your point, but that sort of difference in behaviour for just one "s" scares me |
| 16:36 | <darobin> | (not to say that closest() is great either) |
| 16:48 | <zewt> | in this case i'd say "closest" is a good name just because it's the one people are alreay familiar with (that and there's no well-known tree structure term for it) |
| 16:48 | <zewt> | i often roll that function myself, and I call it "closest" too |
| 16:48 | <Domenic> | zewt: you don't think "ancestor" is a well-known tree struture term? |
| 16:49 | <zewt> | Domenic: it's wrong, because this.closest() can return this |
| 16:49 | <zewt> | this isn't an ancestor of this |
| 16:49 | <Domenic> | ah, it can? I've never actually used that. |
| 16:49 | <Domenic> | in that case I agree .closest() sounds best. |
| 16:49 | <zewt> | yeah, and i often depend on that behavior |
| 16:50 | <Domenic> | http://dom.spec.whatwg.org/#trees "inclusive ancestor" heh |
| 16:51 | <zewt> | for example, container.addEventListener("click", function(e) { var actualTarget = e.target.closest(".button"); }, true); |
| 16:52 | <zewt> | where the .button might actually also be the target |
| 16:52 | <Domenic> | (doesn't currentTarget work for that?) |
| 16:53 | <zewt> | if you have <div class=container><div class=button><lots of stuff/></div></div> and you click somewhere inside "lots of stuff", <div class=button> is nothing special to the event |
| 16:53 | <zewt> | so it just means "see if we clicked a .button, or something nested inside a .button (we don't care which)" |
| 16:55 | <Domenic> | Ah yeah, I guess this is usually abstracted away from me by jQuery et al's event delegation |
| 16:56 | <Domenic> | $('.container').on('click', '.button', function (e) { /* e.currentTarget is always the .button */ }) |
| 17:40 | <JonathanNeal> | Domenic: ancestor suffers the same problem as contains https://developer.mozilla.org/en-US/docs/Web/API/Node.contains |
| 17:41 | <JonathanNeal> | It implies that it does not match itself. |
| 17:41 | <Domenic> | JonathanNeal: yeah, scroll up a bit :) |
| 17:42 | <JonathanNeal> | I read, but I thought it was worth bringing up a related method and quantifying it a bit more. |
| 17:44 | <JonathanNeal> | I just posted https://github.com/jonathantneal/closest I rather niavely ask people to write a spec if they think it deserves to be a real DOM method. I wish I could provide better direction. Can you think of a way to provide more constructive direction? |
| 17:46 | <JonathanNeal> | *naively |
| 17:50 | <Domenic> | I'm not sure what you're asking. |
| 17:51 | <Domenic> | the spec is probably one line, e.g. some slightly-better phrased version of "return the first inclusive ancestor of element" |
| 17:52 | <Domenic> | (The better-phrasing would come in re: making sure "first" is well-defined.) |
| 17:52 | <SamB> | innermost? |
| 17:52 | <Domenic> | just needs to be something already defined in the DOM standard |
| 17:52 | <Domenic> | not sure if there's an ordering on inclusive ancestors |
| 17:53 | <Domenic> | "that is last in tree order" might work |
| 17:59 | <JonathanNeal> | If any of you can think of one that is sympathetic with the existing DOM, would you ping me when you share it? I’ll update the documentation. What I want to do in the README is tell people “If you want to see this in a real DOM standard, do the following:” |
| 18:01 | <Domenic> | the answer to that is "convince annevk to add it and convince implementers to implement it." |
| 18:01 | <Domenic> | as always. |
| 18:30 | <jcgregorio> | gah, I wasn't logged in when I submitted: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25716 |
| 18:30 | <jcgregorio> | in case anyone wants to update the bug to list me as the reporter |
| 18:33 | <smaug____> | jcgregorio: I don't think you can change the reporter in bugzilla |
| 18:34 | <jcgregorio> | smaug____: OK, thanks |
| 21:28 | <zewt> | dear world: if your documentation contains the phrase "Alice wants to", please step away and let somebody else write the documentation |
| 21:28 | <zewt> | (thanks) |
| 21:29 | <odinho> | But if the alternative is no documentation? |
| 21:30 | <zewt> | i'd almost take no documentation over getting a headache reading about some make-believe Alice when i'm trying to read technical docs |
| 21:34 | <jgraham> | If your documentation contains "Alice wants to" you are either doing cryptography, or trying to make your software seem as complex as crypto |
| 21:34 | <odinho> | Yeah. Alice and Bob. |
| 21:35 | <zewt> | in this instance it's Amazon API docs, some of which is silly complex |
| 21:35 | <jgraham> | Hurrah, time for an early xkcd http://xkcd.com/177/ |
| 21:36 | <zewt> | (though this particular API is probably the simplest amazon API I've ever seen--read a URL from inside a VM, it spits out your instance's ID) |
| 22:48 | <aretecode> | In CSS, what is the term for the definition "The group of all Rule Set(s)" ? |
| 22:54 | <estellevw> | block? |
| 22:56 | <caitp> | in the CSSOM or something else? |
| 23:11 | <aretecode> | Yes, caitp |
| 23:11 | <aretecode> | estellevw, like `Rule Set Block` ? |
| 23:27 | <zewt> | grr, firefox has been chewing a whole CPU and spinning my fans up nonstop since that last update |
| 23:33 | <jgraham> | zewt: If you can isolate the problem at all, report a bug |
| 23:34 | <jgraham> | It is working fine for me at least |
| 23:38 | <zewt> | it's probably some tab causing it, and binary searching my dozens of tabs would be tedious |
| 23:38 | <zewt> | (same tab set as before the update where it didn't happen, though) |
