| 00:00 | <Hixie> | o_O |
| 00:01 | <gavinc> | I think I have to remove some variables (using JQuery) and make this test case just use XHR, but seriously WTF |
| 00:45 | <Hixie> | MikeSmith: component watching used to be done years ago by having a component QA and then having people watching that component QA |
| 00:45 | <Hixie> | MikeSmith: that requires account watching to be enabled, though |
| 07:57 | <zcorpan> | TabAtkins: excellent. looks correct now afaict. thanks. i'll remove the quirks from quirks mode spec |
| 10:08 | <jgraham> | Huh, why am I having so much difficulty making chrome prompt me to stay on a page by using a beforeunload event? |
| 10:16 | <zcorpan> | TabAtkins: the asyncness of CAS means that there's a race condition -- elements might be parsed before the CAS is loaded, and do their thing (like, load something) before the CAS kicks in |
| 10:17 | <zcorpan> | i think we have enough trouble with race conditions as it is |
| 10:39 | <odinho> | jgraham: Isn't that stuff disabled for those? Was some talk about it at least. |
| 10:40 | <zcorpan> | prompting to stay is the reason beforeunload exists |
| 10:41 | <odinho> | zcorpan: Maybe it was unload if that is an event. |
| 10:41 | <zcorpan> | yeah |
| 10:46 | <jgraham> | I eventually fixed up the problem |
| 10:46 | <jgraham> | Firefox doesn't seem to prompt with history.go |
| 10:46 | <jgraham> | Chrome didn't like it when I used a function from a different document as the event handler |
| 10:46 | <jgraham> | (I don't think) |
| 10:46 | <jgraham> | (which seems like a bug) |
| 10:47 | <jgraham> | Well one bug each |
| 11:00 | <jgraham> | Oh, I lied gecko didn't have that bug |
| 11:00 | <jgraham> | So now I wonder if I was doing something strange |
| 12:09 | <ruby_on_tails> | hello |
| 12:09 | <ruby_on_tails> | if i draw an arc in canvas it starts from the rightmost, how can i make it start from the top |
| 14:23 | <crankharder> | I'm having a problem with the application cache in chrome. My app cache looks like this: https://gist.github.com/3426029 Once this has been loaded, the fallback section takes over for all non-200 responses, which means that in all error conditions (4/500), my app falls back to /offline, which is not expected behavior. Should this not be happening, or is there some way to avoid it? |
| 14:25 | <crankharder> | As "/ /offline" is a typical example in the docs, I can't imagine that it is recommended to circumvent all non-200 requests while the user is online. |
| 15:12 | <jgraham> | OK, now I know what tool I need for the spec |
| 15:12 | <jgraham> | I want something that marks up bugs filed on different bits of the spec |
| 15:12 | <jgraham> | So when someone submits a bug on a specific section everyone can see it |
| 15:13 | <zcorpan> | yes, bug annotations would be great |
| 15:14 | <jgraham> | I need this so much, jsut to track bugs that *I* filed I think I will have to implement it |
| 15:15 | <zcorpan> | \o/ |
| 15:28 | <Ms2ger> | \o/ |
| 15:37 | <jgraham> | Hmm, so I guess it would be useful to remove bugs once they are closed. Which means that having bzAPI on W3C bugzilla would be rather helpful |
| 15:37 | <jgraham> | MikeSmith: ^ |
| 15:54 | <jgraham> | Hixie: Can I get the bug filing / status updating CGI scripts? |
| 16:24 | <MikeSmith> | jgraham: I wasn't aware that bugs could be removed |
| 16:24 | <Ms2ger> | MikeSmith, closed |
| 16:25 | <Ms2ger> | Then they shouldn't be listed in the in-spec annotations |
| 16:25 | <MikeSmith> | ah |
| 16:25 | MikeSmith | tries to recall previous discussions about bzAPI |
| 16:26 | <MikeSmith> | is it not already enabled? |
| 16:26 | <jgraham> | MikeSmith: Myabe? |
| 16:27 | <jgraham> | I didn't actually try, I just assumed it wasn't |
| 16:27 | <MikeSmith> | ah I think it's not |
| 16:27 | <MikeSmith> | because v1 was released in 2011 |
| 16:27 | <MikeSmith> | and we are running 3.6 from 2010 |
| 16:27 | <MikeSmith> | and it's an add-on I guess |
| 16:29 | <jgraham> | Yeah it's an addon. but it seems to be 3.6.x compatible |
| 16:29 | <jgraham> | At least for some value of x |
| 16:30 | <MikeSmith> | ok |
| 16:40 | <Ms2ger> | MikeSmith, I am told it does indeed support 3.6 |
| 16:40 | <MikeSmith> | OK |
| 17:39 | <Hixie> | jgraham left :-( |
| 17:39 | <Hixie> | oh, no, it was just a netsplit! |
| 17:39 | <Hixie> | jgraham: ping |
| 17:46 | <jgraham> | Hixie: pong |
| 17:46 | <Hixie> | jgraham: i like your idea and wish to subscribe to your newsletter |
| 17:47 | <jgraham> | Heh |
| 17:48 | <Hixie> | jgraham: the way i've been doing similar things for my internal e-mail management is that i have a cronjob that just loads each bug one at a time and compares their current state, deleting e-mails relating to bugs not assigned to me or that are not closed |
| 17:48 | <Hixie> | jgraham: and so on |
| 17:48 | <Hixie> | jgraham: seems like we can do something similar here, just walking the bug list and reading the initial description of each one to get the section ID |
| 17:48 | <Hixie> | with some local caching to avoid hammering bugzilla it should be pretty simple to do |
| 17:48 | <Hixie> | (since you can just do a query to get the buglist, and then you only need to load the new bugs, bugs can't change section) |
| 17:49 | <jgraham> | Hixie: I was thinking that you would just hook up the bug submission thing to give you the initial list of bug ids |
| 17:49 | <jgraham> | But of course if you can get it from the actual bug data that would be better |
| 17:49 | <Hixie> | yeah you can totally just grab the comments and walk through them |
| 17:49 | <Hixie> | that's how i did the cloning, e.g. |
| 17:50 | <Hixie> | (bugzilla has an xml output mode) |
| 17:50 | <Hixie> | (so there's no scraping to do) |
| 17:50 | <jgraham> | Oh, that helps |
| 17:51 | <Hixie> | for both the query results and the bug data |
| 17:51 | <Hixie> | how were you thinking of exposing the data? |
| 17:51 | <Hixie> | simplest way for me is to just call a script on your domain and have you do whatever you want |
| 17:52 | <jgraham> | Exposing in what way? In the UI? |
| 17:52 | <Hixie> | yeah |
| 17:52 | <jgraham> | I was thinkking it should be part of the status annotations |
| 17:52 | <Hixie> | that works |
| 17:53 | <Hixie> | i can provide an API for you to hook into if you want, or we can do it all server-side and just have the status things come out of the database |
| 17:53 | <Hixie> | server side meaning you push teh data straight into the database rather than on each page load |
| 17:53 | <Hixie> | API meaning in the script |
| 17:54 | <Hixie> | i guess for you it's lighter load to do it via server-side comms |
| 17:54 | <Hixie> | and let me deal with the UI |
| 17:54 | <jgraham> | Yeah, that makes sense to me |
| 17:54 | <Hixie> | k |
| 18:00 | <jgraham> | OK, I can write the code to grab the data. What do I need to do to push it into the database? |
| 18:01 | <Hixie> | have your script output the data in the form "sectionid bugid bugid bugid\nsectionid bugid bugid\nsectionid bugid" |
| 18:02 | <Hixie> | i'll provide you a secret URL to POST to that will update teh DB |
| 18:05 | <jgraham> | So each time it will provide all the bug ids, and bugs that got resolved will be removed from the db on your end? |
| 18:21 | <Hixie> | jgraham: sounds good |
| 19:06 | <Hixie> | jgraham: should i store bug IDs, or bug URLs? |
| 19:06 | <Hixie> | jgraham: because another way i could do this would be just to change the current "demos" feature to a "bugs" feature |
| 19:06 | <Hixie> | jgraham: since we don't use the "demos" feature |
| 19:06 | <Hixie> | jgraham: this would also allow other people to add bugs and stuff |
| 19:07 | <Hixie> | jgraham: i guess it's easier to just have a list of IDs and not make it editable |
| 19:13 | <jgraham> | Hixie: I think have a list of IDs and if people want to edit it they can add a string like the one that the bug script produces as a comment in the bug |
| 19:15 | <Hixie> | makes sense |
| 19:16 | <Hixie> | hopefully nobody abuses it; if they do we can always have some specific people whitelisted who can use a "cancel" magic word :-) |
| 19:33 | <Hixie> | ok 33% complete on my end: the database has a bugs table and the cgi script passes the data to the client |
| 19:33 | <Hixie> | no way to add to it yet... |
| 19:34 | <jgraham> | I guess I will finish my end tomorrow; am feeling kind of sleepy now |
| 19:34 | <jgraham> | But it is coming together |
| 19:36 | <Hixie> | cool |
| 19:37 | <Hixie> | let me know if you need any help figuring out how to get xml out and stuff, or how the schema they use works, i still remember it all from doing the cloning |
| 19:51 | <Hixie> | is it me or is today a bad spam day |
| 20:24 | <hober> | Hixie: do you manually approve ml subscriptions? |
| 22:04 | <Hixie> | hober: no |
| 22:05 | <Hixie> | hober: why? |
| 22:11 | <hober> | Hixie: just wondering. a coworker's subscription took longer than he thought it would; probably just an email hiccup |
| 22:19 | <Hixie> | hober: weird |
| 22:20 | <Hixie> | hober: the only moderation action i take is with messages > 40kb, and those i mostly only allow if they're mine :-) |
| 22:20 | <hober> | *nod* |
| 22:20 | <Hixie> | (those that aren't usually are 40kb of quoted content with top-posting, which is against the mailing list etiquette) |
| 22:21 | <Hixie> | anyone remember what the bug is where i talked about appcache having a js-driven "server"? |
| 22:21 | <Hixie> | i can't find it |
| 22:34 | <Hixie> | Truncation operations cannot be performed if the session holds an active table lock |
| 22:35 | <Hixie> | wtf |
| 22:36 | <Hixie> | well, i guess jgraham better not ever call this reentrantly |
| 23:11 | <Hixie> | jgraham: ok, server-side is done, now working on client side. |
| 23:22 | <jacobolus> | re: http://www.w3.org/TR/compositing/#blendingnonseparable |
| 23:23 | <jacobolus> | is there some reason why Photoshop’s arbitrary and idiosyncratic compositing modes are being copied? |
| 23:24 | <Hixie> | jacobolus: because the editor is from adobe? :-) |
| 23:24 | <Hixie> | (client-side done as well, now i just have to debug it all...) |
| 23:24 | <jacobolus> | Hixie: I mean, I guess this is great if someone wants to use a browser to preview PSD documents |
| 23:25 | <jacobolus> | but these blend modes are based on what could be done quickly on early-1990s computer hardware |
| 23:25 | <Hixie> | you have to ask the editor |
| 23:25 | <zewt> | many of photoshop's blending modes are useful and if they're going to put them all under a patent disclaimer then cool, go for it |
| 23:26 | <Hixie> | (i don't think rik hangs out here) |
| 23:26 | <jacobolus> | doing a sum of .30 * R + .59 * G + .11 * B, for gamma-adjusted R, G, B, is based on the primaries used in the Adobe RGB space |
| 23:27 | <jacobolus> | but only actually properly yields luminance for linear RGB, not gamma adjusted |
| 23:27 | <Hixie> | it seems unsurprising to me that a spec from someone at adobe would be based on adobe's stuff... |
| 23:27 | <zewt> | (it's also the most useful thing if you're handed a PSD from an artist using random blend modes and told to recreate it dynamically) |
| 23:28 | <jacobolus> | the word “luminance” is something that was made up by Adobe, is given several incompatible definitions in photoshop, and has no external technical meaning |
| 23:28 | <jacobolus> | and their definition of “saturation” here is also not used the same way in any other context |
| 23:28 | <zewt> | (hint: opengl uses it all over the place) |
| 23:28 | <zewt> | (also hint: complaining in here isn't going to do anything :) |
| 23:29 | <jacobolus> | opengl is also based on early-1990s photoshop? bleh. |
| 23:30 | <Hixie> | if you just want to get it off your chest, please do go on, ranting here is always welcome. :-) but as zewt says, if you want to affect the spec, your time may be better spent e-mailing the spec's editor or the lists mentioned in the spec's status section |
| 23:30 | <Hixie> | (please don't take this as a suggestion to shut up though) |
| 23:30 | <jacobolus> | :) |
| 23:31 | <jacobolus> | I guess I don't really care what goes in the spec. not like there isn't plenty of other legacy garbage in the web tech stack |
| 23:31 | <cabanier> | hey |
| 23:31 | <othermaciej> | jacobolus: I don't really fully understand blend modes or why they are separate from compositing operators |
| 23:31 | <cabanier> | you don't like the spec? |
| 23:32 | <jacobolus> | othermaciej: those two terms are synonyms in most contexts :) |
| 23:32 | <jacobolus> | othermaciej: “blend mode” is photoshop’s word for it |
| 23:32 | <othermaciej> | jacobolus: well, not in this spec or in photoshop |
| 23:32 | <othermaciej> | they are sort of orthogonal |
| 23:32 | <jacobolus> | ..? |
| 23:32 | <othermaciej> | (maybe I am wrong about photoshop) |
| 23:32 | <cabanier> | read the specification. It talks why they are different |
| 23:33 | <othermaciej> | you can have a blend mode of multiply and a compositing operator of dest-atop |
| 23:33 | <cabanier> | blending = how colors combine |
| 23:33 | <cabanier> | compositing = how you treat alpha |
| 23:33 | <Hixie> | oh hey, rik _does_ hang out here |
| 23:33 | <Hixie> | go figure! |
| 23:33 | <Hixie> | hey rik! |
| 23:33 | <cabanier> | :-) |
| 23:33 | <jacobolus> | othermaciej: fine. that's kind of irrelevant to my point, and that's a kind of idiosyncratic set of definitions, but it's no big deal |
| 23:33 | <zewt> | (also it's 2012, can we not put "1.0" at the end of spec names) |
| 23:33 | <Hixie> | jacobolus: i take it back, ranting here is productive after all :-) |
| 23:33 | <othermaciej> | a blend function takes src and dest color components as input, and gives a color (ignoring alpha) as output |
| 23:34 | <othermaciej> | so Cblended = B(Cs, Cd) |
| 23:34 | <othermaciej> | compositing functions also take into account alpha |
| 23:34 | <othermaciej> | so Ccomposited = C(Cs, As, Cd, Ad) |
| 23:34 | <othermaciej> | and if you have both, then you use the blend output as the source input to the compositing operator |
| 23:35 | <othermaciej> | which strikes me as somewhat weird |
| 23:35 | <jacobolus> | othermaciej: okay, let me rephrase my original comment then... is there some reason why Photoshop’s arbitrary and idiosyncratic compo^H^H^H^H^Hblend modes are being copied? |
| 23:35 | <cabanier> | yes |
| 23:35 | <cabanier> | they are widely implemented |
| 23:36 | <othermaciej> | jacobolus: I find the whole thing mysterious, but I am not enough of a graphics expert to know if there is a better approach to this sort of thing, or if this is the industry standard |
| 23:36 | <zewt> | jacobolus: another hint: everyone who works long in graphics (of any type, including ui) has an understanding of them |
| 23:36 | <cabanier> | PDF, Skia, coregraphics, win8 direct2d, |
| 23:36 | <cabanier> | Firefox |
| 23:36 | <cabanier> | etc |
| 23:36 | <jacobolus> | cabanier: "luminosity", "hue", "color" etc. modes are implemented all those places? |
| 23:36 | <cabanier> | they were also in the SVG spec (but were never implemented) |
| 23:36 | <jacobolus> | I find that hard to believe |
| 23:36 | <cabanier> | core graphic and win8 has them for sure |
| 23:37 | <jacobolus> | okay, apparently they're in PDF |
| 23:37 | <cabanier> | What is it that you don't like about them? |
| 23:37 | <zewt> | implemented color burn and several others in opengl a long time ago, heh https://svn.stepmania.com/svn/trunk/stepmania/Data/Shaders/GLSL/Color%20burn.frag |
| 23:37 | <jacobolus> | cabanier: they're arbitrary and produce bad results |
| 23:37 | <cabanier> | Designers already know about them |
| 23:38 | <cabanier> | standard teaching in design schools |
| 23:38 | <jacobolus> | they should have been fixed in photoshop as soon as the hardware could keep up, which was about 10 years ago |
| 23:38 | <cabanier> | jacobolus: do you have more info? Why do they produce bad results? |
| 23:38 | <jacobolus> | now unfortunately people are going to be stuck with technical choices made for the constraints of 20 years ago, into the foreseeable future |
| 23:38 | <Hixie> | like 80 character line length limits? :-D |
| 23:38 | <zewt> | Hixie: *rage* |
| 23:38 | <cabanier> | they were introduced in 98 or so |
| 23:39 | <Hixie> | zewt: but what if i want to save my code to punchcard!!!! |
| 23:39 | <cabanier> | please let me know if you have a better idea |
| 23:39 | <jacobolus> | cabanier: because .30R + .59G + .11B, when R, G, and B are gamma-adjusted sRGB, is an entirely nonsensical quantity |
| 23:39 | <zewt> | (if I see one more person writing python in 80-columns because they unquestioningly followed the drek that is PEP-8 i will launch them into space) |
| 23:40 | <gavinc> | ASCII being the most annoying, like no one thought maybe Iñtërnâtiônàlizætiøn would be important |
| 23:40 | <cabanier> | so, you don't like the non-separable ones? |
| 23:40 | <jacobolus> | they don't correspond to human vision, they don't correspond to any technical device |
| 23:40 | <jacobolus> | they're quantities made up by adobe for the constraints of early 1990s computers |
| 23:40 | <cabanier> | it's a reasonable formula. |
| 23:41 | <jacobolus> | no, it's not a reasonable formula |
| 23:41 | <cabanier> | As long as everyone implements it the same, the designer's choice will look the same |
| 23:41 | <jacobolus> | it's a formula that tells people (by the names used) that it's doing one thing, while in fact it does another |
| 23:41 | <cabanier> | there is no arguing about color math |
| 23:41 | <jacobolus> | that's great. but it sucks for all the designers involved, who end up with unintuitive dreck |
| 23:41 | <cabanier> | you think they are doing the math in their heads? |
| 23:41 | <zewt> | jacobolus: the point is that artists want something to look a certain way, and they use blend functions to achieve the look they want; that's their primary purpose |
| 23:42 | <cabanier> | they just used their tools/browsers until they like what they see |
| 23:42 | <jacobolus> | zewt: you got it. but my point is, what they want is not actually what they're getting |
| 23:42 | <zewt> | they're looking at what they're getting and going "yep. looks like what I want." which means they have what they want. that's really how it works :) |
| 23:42 | <jacobolus> | zewt: I mean, okay, in some sense that's true |
| 23:43 | <zewt> | it's the basic gap between artistic design and technical design |
| 23:43 | <cabanier> | people don't like that you muck with their colors. Adobe has made that mistake in the past. |
| 23:43 | <jacobolus> | it's a basic gap caused by shitty programming, because the dimensions involved don't correspond to human vision |
| 23:43 | <gavinc> | jacobolus: err, I don't think those are Adobe's those at least look like sRGB's numbers |
| 23:44 | <cabanier> | We've given up on most of the complex color math if you use default setting |
| 23:44 | <jacobolus> | gavinc: they're based on the primaries used by the Adobe RGB color space |
| 23:44 | <jacobolus> | gavinc: but don't make any sense for gamma-corrected components |
| 23:44 | <gavinc> | jacobolus: Are you sure? Those look like the primaries for sRGB |
| 23:44 | <jacobolus> | gavinc: yes, I'm sure |
| 23:44 | <gavinc> | jacobolus: okay :D |
| 23:45 | <jacobolus> | gavinc: the equivalents for the primaries used by sRGB would be .21 * R + .72 * G + .07 * B |
| 23:45 | <gavinc> | jacobolus: ah, yes. my mistake |
| 23:46 | <zewt> | (no, the gap between technical and artistic work is that one generally has a "right answer" and the other is entirely subjective; this applies fairly universally) |
| 23:47 | <jacobolus> | zewt: if I sat you down with image editing software that was properly based on human-relevant color dimensions, and then put you back on current software, you'd throw a fit, because there is a night and day difference |
| 23:48 | <cabanier> | jacobolus: please post on www-style if you have ideas on making the spec better. |
| 23:48 | <jacobolus> | cabanier: I think it's a lost cause |
| 23:48 | <Hixie> | were there people other than hsivonen who were against the way <template> parses into a separate doc? |
| 23:48 | <cabanier> | jacobolus: we've been there. everyone hated it |
| 23:48 | <cabanier> | jacobolus: the vast majority of people didn't understand it |
| 23:49 | <cabanier> | jacobolus: hardly anyone could print it |
| 23:49 | <jacobolus> | cabanier: basically, the quick decisions made by some guys at adobe one afternoon are destined to live on to eternity :) |
| 23:49 | <jacobolus> | what is "it"? |
| 23:49 | <jacobolus> | people didn't understand what? |
| 23:50 | <zewt> | jacobolus: maybe, maybe not--it doesn't matter because every artist I've ever worked with uses PS and expects output to be what they see |
| 23:50 | <cabanier> | jacobolus: device independent workflows. Everything icc based |
| 23:50 | <cabanier> | zewt: exactly! |
| 23:50 | <jacobolus> | cabanier: what does ICC profiles have to do with anything? |
| 23:50 | <zewt> | cabanier: btw. no vivid light? heh |
| 23:50 | <zewt> | (guess it's been a long time since I've been handed a PSD using that) |
| 23:51 | <jacobolus> | for anyone keeping score, I drew some nice diagrams and so forth at http://en.wikipedia.org/wiki/HSL_and_HSV which calls the dimensions involved in these blend modes “chroma” and “luma” |
| 23:51 | <jacobolus> | though again, those aren't ideal names |
| 23:51 | <cabanier> | zewt: I keep asking people if they want all the PS blend modes but I get no feedback |
| 23:52 | <zewt> | https://svn.stepmania.com/svn/trunk/stepmania/Data/Shaders/GLSL/Vivid%20light.frag don't recall what effect i implemented that for, though |
| 23:53 | <jacobolus> | cabanier: do you have any ins w/ people working on photoshop? can you tell them to add "exclusion" blend mode for files in CIELAB mode? |
| 23:53 | <jacobolus> | the combination of linear light mode + exclusion mode is one of the most powerful tools in photoshop (albeit entirely unused by anyone) |
| 23:54 | <gavinc> | possibly horribly wrong statement: I'm pretty sure .30R + .59G + .11B is a great deal older then anything at Adobe my memory (which has already proved faulty) is that it's from YUV used in PAL and NTSC but I may be totally wrong on that, my color math is bit a rusty and was mostly for print |
| 23:56 | <cabanier> | From the postscript (!) manual: the gray value for a given RGB value is computed according to the NTSC video standard. This standard determines how a color television signal is rendered on a black-and-white television set. |
| 23:56 | <gavinc> | Okay, NOT crazy |
| 23:56 | <cabanier> | you were right on! impressive! |
| 23:56 | <jacobolus> | gavinc: NTSC and Adobe RGB use similar primaries |
| 23:56 | <jacobolus> | not quite identical |
| 23:57 | <jacobolus> | gavinc: but that's beside the point |
| 23:57 | <jacobolus> | which is that images on the web are specified to be sRGB |
| 23:58 | <jacobolus> | and that adding linear combinations of gamma-encoded quantities yields nonsensical results |
| 23:58 | <gavinc> | okay, I think I mostly agree with that. But would need to put a great deal more color math back in my head before agreeing fully |