| 00:12 | <Hixie> | othermaciej: so for bug 11239 you want me to play a game of guesswork where i guess what the wg wants, provide a diff, get shouted at by the a11y guys, then try to guess again, rince repeat? |
| 00:13 | <Hixie> | othermaciej: because that's what i tried with 10066 and that wasn't any fun. |
| 00:13 | othermaciej | has to look up which bugs those are |
| 00:13 | <Hixie> | 10066 is the aria one |
| 00:14 | <TabAtkins> | You could try just asking what they want before making the edit. You'll still get yelled at by the a11y guys (same as last time), but at least it's less work for you. |
| 00:14 | <Hixie> | 11239 is the drawFocusRect one |
| 00:14 | <Hixie> | TabAtkins: i tried, and i didn't understand any of the answers |
| 00:14 | <TabAtkins> | Sigh, yeah. |
| 00:15 | <othermaciej> | if you just post a diff to the bug (11239) and mail the list that you have done so, I will do my best to run interference and keep any shouting in check |
| 00:15 | <othermaciej> | e.g. if people complain about things other than being inconsistent with the decision |
| 00:16 | <othermaciej> | for example if anyone complains about the decision itself |
| 00:16 | <othermaciej> | you can also make up something reasonable, check it in, and just press your luck, but that seems to have slightly higher odds of resulting in flamage |
| 00:17 | <Hixie> | yeah so what i want is for you to tell me what to change |
| 00:17 | <Hixie> | the CP is incoherent, and the decision is a vague change to the CP |
| 00:17 | <Hixie> | there's just no way i want to play this game |
| 00:18 | <othermaciej> | if I were to do that, I would want to make a diff and post it to the WG first to avoid getting flamed myself, and that will probably both be lower quality and take considerably longer |
| 00:23 | <Hixie> | i wouldn't want a diff, just a bullet point list of what needs changing |
| 00:23 | <Hixie> | i honestly have no idea what i'm supposed to change at this point |
| 00:23 | <Hixie> | the CP is incoherent and the decision is vague |
| 04:28 | <AlexNRoss> | Okay, I would like to confirm something and would like link references for an answer, I can't find a solid answer on this. |
| 04:29 | <AlexNRoss> | Using HTML5 DTD with XHTML mark-up. Should the HTTP and meta content-type be text/html or application/xhtml+xml ? |
| 04:29 | <AlexNRoss> | I've heard conflicting stories. |
| 04:30 | <AlexNRoss> | Using text/html with XHTML DTD is incorrect, but with HTML5 it is DTD-less. |
| 05:35 | <hober> | AlexNRoss: there is no HTML5 DTD. |
| 07:21 | <hsivonen> | Let's see if Gruber mentions http://www.webm-ccl.org/ at all... |
| 07:26 | <erlehmann> | hsivonen, i wonder what gruber, pritlove et al are going to say if at some time in the future people use webm. it may be fun to watch. |
| 07:27 | <roc> | you mean other than Youtube |
| 07:27 | <roc> | ? |
| 07:35 | <erlehmann> | roc, like when / if it becomes obvious that apple fails by not supporting it. |
| 07:35 | <roc> | you never get satisfaction from people like Gruber, they'll never admit they were wrong |
| 07:36 | <roc> | you can only ignore them and move on |
| 07:42 | <erlehmann> | roc, so what do their followers say then? |
| 07:51 | <hsivonen> | erlehmann: Gruber's followers probably don't mind the selectiveness of the stories that appear |
| 07:52 | <hsivonen> | Gruber has very insightful posts when the insightfulness aligns with Apple's strategy |
| 07:54 | <hsivonen> | e.g. http://daringfireball.net/2010/08/getting_there_from_here says it like it is |
| 07:58 | <roc> | except "Flash is never going to decrease in popularity so long as all web browsers support it. " is not true |
| 08:03 | <hsivonen> | roc: it seems to me it's quite close to true. The popularity of Flash comes from being easy to author for, so even if users hated it but Adobe didn't feel the need to retarget their tools to browser native features, Flash could stick around thanks to the authoring tools |
| 08:04 | <roc> | maybe |
| 08:04 | <roc> | but the open Web is starting to pass Flash in capability |
| 08:04 | <roc> | especially with Microsoft coming up to speed |
| 08:05 | <roc> | an unequivocal prediction that "Flash is never going to decrease in popularity so long as all web browsers support it." cannot be justified IMHO |
| 08:05 | <hsivonen> | roc: I also think that Danish banks would continue to require Java for login regardless of browser capabilities forever unless popular computing enviroments that simply don't have Java wake them up |
| 08:06 | <roc> | that may be true, but it's a different prediction |
| 08:06 | <roc> | "Some sites may keep requiring Flash as long as all Web browsers support it" is almost certainly true |
| 08:07 | <hsivonen> | roc: fair enough |
| 08:08 | <hsivonen> | roc: my point about Java is that there will be important sites using plug-ins when there's absolutely no good reason to do so if there is an opportunity to do so |
| 08:08 | <hsivonen> | roc: so to stop that kind of hostility against users, the opportunity needs to be taken away |
| 08:09 | <hsivonen> | because a single user opting not to install something doesn't have leverage |
| 08:09 | <hsivonen> | so users who don't want bad software need to unionize somehow |
| 08:10 | <hsivonen> | getting an iOS device is like joining an anti-Flash union |
| 08:10 | <hsivonen> | with the collateral damage of also joining an anti-Firefox union and an anti-Opera union |
| 08:13 | <roc> | hsivonen: do you think we should not be working on Flash support for Firefox-Android? |
| 08:13 | <hsivonen> | roc: probably not |
| 08:14 | <hsivonen> | roc: at least I'm unhappy that while we don't have it, the PR line is "not supported yet" and not just "it's not supported" |
| 08:14 | <hsivonen> | roc: if we go get it, I sure hope it defaults to tap-to-activate |
| 08:15 | <hsivonen> | I wish plug-in support in Firefox in general defaulted to click-to-activate |
| 08:15 | <hsivonen> | in the case of Flash for the resource usage annoyance |
| 08:15 | <hsivonen> | in the case of everything else for the attack surface |
| 08:17 | <hsivonen> | what's more likely these days: that a user wants to use a Java applet or that a user got Java as a side effect of something else and is being subjected to an exploit in an outdated JRE? |
| 08:17 | <roc> | gotta go, but two things that worry me more than Flash right now are the locked iOS ecosystem and Webkit monoculture on mobile |
| 08:17 | <hsivonen> | roc: those are bad things, too |
| 08:25 | <jgraham> | What is worrying is the number of people who actively promote the idea of a WebKit monoculture |
| 08:29 | <hsivonen> | jgraham: yeah. and it's sad that some of those people were against a Trident monoculture |
| 08:34 | jgraham | idly wonders if anyone has considered a Apache-style license for the spec |
| 09:09 | <jgraham> | Hixie: Did PMS start magiaclly working BTW? I don't see a problem but I might not be using the right settings |
| 09:11 | <hsivonen> | jgraham: Ragnarök runs the script that does w('FAIL') here: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/950 |
| 09:11 | <hsivonen> | jgraham: I believe it shouldn't per spec |
| 09:13 | <zcorpan> | innerHTML sets the 'already executed' flag? |
| 09:16 | <hsivonen> | zcorpan: yes |
| 09:16 | <hsivonen> | "If the parser was originally created for the HTML fragment parsing algorithm, then mark the script element as "already started". (fragment case)" |
| 09:18 | <jgraham> | I have a feeling we have a generic bug about changinf script.src causing scripts to reexecute |
| 09:19 | <jgraham> | Alhough 11.10 doesn't FAIL so maybe a regression |
| 09:19 | jgraham | will investigate |
| 09:19 | <jgraham> | hsivonen: BTW your chosen style for escaping </script> is rather hard to read :) |
| 09:21 | <hsivonen> | jgraham: thanks |
| 09:21 | <hsivonen> | jgraham: the escaping style is the simplest rule that's also safe |
| 09:22 | <hsivonen> | or rather, the simplest rule that's safe and that passes JSLint |
| 09:24 | <jgraham> | It is harder to read than "<" + "/script>" and much moreso than "<\/script>" although I guess JSLint would complain about the letter |
| 09:24 | <jgraham> | *latter |
| 09:24 | <zcorpan> | i just do <\/script> |
| 09:25 | <hsivonen> | zcorpan: how do you escape <!--? |
| 09:25 | <zcorpan> | <\!-- |
| 09:25 | <hsivonen> | zcorpan: ok. I'm pretty sure JSLint hates that one |
| 09:26 | <zcorpan> | i don't use jslint :) |
| 09:26 | <hsivonen> | zcorpan: also, I was unable to work out from the spec if \! is conforming or not |
| 09:27 | <hsivonen> | the ES spec isn't particularly clear on program text conformance |
| 09:27 | <zcorpan> | it parses in all browsers, so if the spec has a problem with it, i'll say it's the spec's problem, not mine :) |
| 09:27 | <jgraham> | Really I am only concerened about JSLint or similar when they point out errors that could easilly tuen into bugs |
| 09:28 | <jgraham> | Since <\/script> is used in some of the worst javascript on the planet, I surmise that it must be pretty hard to screw it up |
| 09:29 | <hsivonen> | jgraham: I use \u003C, because I try to practice what I preach and I try to preach things that pass JSLint so that I don't need to deal with fanmail telling me that what I preach doesn't work with what Crockford preaches |
| 09:30 | <hsivonen> | but now I get feedback asking me to use syntaxt that doesn't pass JSLint |
| 09:31 | <hsivonen> | (your feedback isn't the first instance) |
| 09:32 | <zcorpan> | does it pass jshint? |
| 09:32 | <hsivonen> | no idea |
| 09:33 | <hsivonen> | also, jshint has configurability |
| 09:33 | <zcorpan> | Line 1var foo = '<\!--'; |
| 09:33 | <zcorpan> | Bad escapement. |
| 09:33 | <zcorpan> | boo |
| 09:34 | zcorpan | files a bug |
| 09:40 | <zcorpan> | argh. github ate my bug |
| 09:40 | <zcorpan> | i hate typing the same thing twice |
| 09:43 | <zcorpan> | and now github ate my backslashes |
| 09:45 | <zcorpan> | https://github.com/jshint/jshint/issues/141 |
| 10:10 | <jgraham> | I wonder is someone will object to Ms2ger reviewing hsivonen's tests |
| 10:10 | <jgraham> | *if |
| 10:26 | <jgraham> | zcorpan: If you added Hixie to the CC of your websockets email it isn't obvious |
| 10:29 | <zcorpan> | uh. lemme check |
| 10:29 | <zcorpan> | Cc: "hybi⊙io" <hybi⊙io>, "Ian Hickson" <ian⊙hc> |
| 10:30 | <jgraham> | Oh |
| 10:30 | <jgraham> | OK |
| 10:30 | <zcorpan> | i think the hybi list is eating Cc or something |
| 10:31 | <zcorpan> | i noticed it didn't show up emoller as cc with the original email either |
| 10:31 | <jgraham> | In that case I will stop trying to QA the assertions in your mail about recipients :) |
| 10:32 | <zcorpan> | heh |
| 11:38 | <MikeSmith> | jgraham: in http://krijnhoetmer.nl/irc-logs/whatwg/20110426#l-35 |
| 11:38 | <MikeSmith> | what is "pms"? |
| 11:52 | <jgraham> | MikeSmith: http://pimpmyspec.net/ |
| 11:53 | <jgraham> | MikeSmith: It's a frontend to Anolis |
| 11:53 | <MikeSmith> | yeah, I know |
| 11:53 | <MikeSmith> | just didn't make the connection to the abbreviation |
| 11:53 | <MikeSmith> | so is it working now? |
| 11:53 | <jgraham> | With a tendency to get upset if things get slow |
| 11:53 | <MikeSmith> | ah |
| 11:53 | <MikeSmith> | OK |
| 11:55 | <jgraham> | Yeah, I don't really know if it is working now. But often it can be a problem if the W3C or WHATWG sites are slow because it times out trying to generate the issue markers |
| 11:55 | <MikeSmith> | oh |
| 11:55 | <MikeSmith> | that's probably what it was yesterday |
| 11:55 | <MikeSmith> | W3C site was having some load problems |
| 11:56 | <MikeSmith> | Philip`: btw, http://www.w3.org/Bugs/Public/show_bug.cgi?id=12539 |
| 13:02 | <Philip`> | MikeSmith: Hmm, I think I'm using the lxml HTML parser which might be what's causing that |
| 13:03 | <MikeSmith> | Philip`: oh |
| 13:03 | <MikeSmith> | the parser, not the serializer? |
| 13:04 | <MikeSmith> | I'm running the splitter with the html5lib-serialiser option |
| 13:04 | <MikeSmith> | because I think I ran into other borkedness if I don't use that use that option |
| 13:05 | <MikeSmith> | and I think I'm not using the html5lib-parser option because it makes the script run much slower |
| 13:05 | <MikeSmith> | when run on the HTML5 spec |
| 13:06 | <MikeSmith> | but I guess I can try that now and see if it fixes it |
| 13:06 | <Philip`> | Without --html5lib-parser it'll use lxml which I presume may parse ⟨ into U+2329, and then the html5lib serialiser will output 〈 |
| 13:06 | <MikeSmith> | yeah |
| 13:07 | <Philip`> | Probably the most robust solution would be to not use "⟨" in the spec |
| 13:07 | <MikeSmith> | true that |
| 13:07 | <MikeSmith> | but not much I can do about that |
| 13:07 | <Philip`> | (rather than hacking some solution into the splitter, or forcing the splitter to be very slow) |
| 13:08 | <MikeSmith> | earthquake |
| 13:08 | <Philip`> | Someone can ask Hixie to change it, I guess :-) |
| 13:08 | <MikeSmith> | sure |
| 13:09 | <MikeSmith> | but I guess I tend to assume if Hixie is doing something a certain way, he's got a well-considered reason |
| 13:09 | <MikeSmith> | but maybe that's not always the right assumption… |
| 13:28 | <zcorpan> | file a spec bug |
| 13:32 | <zcorpan> | oh there was a spec bug |
| 13:40 | <karlcow> | http://www.webm-ccl.org/ |
| 13:40 | <karlcow> | "By joining the CCL, member organizations likewise agree to license patents they may have that are essential to WebM technologies to other members of the CCL." |
| 13:40 | <karlcow> | ? |
| 14:05 | <hsivonen> | hmm. validator.nu is having a DNS outage |
| 14:47 | <matjas> | what should <img src=foo><base href="http://example.org/blah/"><img src=foo> do? |
| 14:48 | <matjas> | (re: http://html5.org/tools/web-apps-tracker?from=5710&to=5711) |
| 14:49 | <matjas> | I’ve made a simple test case: http://mathiasbynens.be/demo/base but implementations greatly differ |
| 14:49 | <hsivonen> | matjas: both images should resolve to http://example.org/blah/foo |
| 14:49 | <matjas> | hsivonen: Firefox gets it right then |
| 14:49 | <hsivonen> | matjas: of course :-) |
| 14:49 | <matjas> | as the only browser |
| 14:50 | <hsivonen> | whoa. I thought we specced Chrome's behavior |
| 14:50 | <matjas> | Most browsers display 1-2 |
| 14:50 | <matjas> | Even IE6 |
| 14:50 | <matjas> | IE7, 8 and 9 just ignore the base and display 1-1 |
| 14:50 | <matjas> | Same goes for IE10pp1, if that’s any indication |
| 14:50 | <hsivonen> | hmm. was the spec change based on incorrect data about Chrome's behavior? |
| 14:51 | <matjas> | I don’t know, there’s no bug ID and I’m unaware of the history here |
| 14:52 | <hsivonen> | matjas: Firefox had behavior close to IE6. Then in the Firefox 4 product cycle, it changed to then-spec, which was similar to IE7 through 10 |
| 14:52 | <hsivonen> | then both spec and Firefox were changed and, IIRC, they supposedly changed to match Chrome |
| 14:53 | <matjas> | Woah. |
| 14:55 | <hsivonen> | abarth: see above. what's going on here? |
| 14:55 | <hsivonen> | has Chrome changed since September or did I mistest back then? |
| 15:05 | <zewt> | wouldn't doing that cause browsers to start fetching and rendering a resource with the original base, then have to cancel and switch to the correct one? |
| 15:53 | <zewt> | FF4 is racy with using <base> like that: if it's already started loading an image with the original base, it does not *reload* it if it sees a <base> later |
| 15:53 | <zewt> | (tested it because I was wondering if it would--because if it did that would have weird implications for eg. <img onload>) |
| 15:56 | <abarth> | hsivonen: not sure |
| 16:49 | <MikeSmith> | hmm |
| 16:50 | MikeSmith | wonders when "the figure element has no text node descendants other than inter-element whitespace, and no embedded content descendant other than the img element" qualifying language got added to the criteria for the figcaption exception |
| 16:53 | <MikeSmith> | hsivonen: dunno if you are still around today but that bit there really complicates implementation of alt-text checking |
| 16:55 | <MikeSmith> | though I guess it would be pretty straightforward to check with schematron/xpath |
| 17:00 | <jgraham> | Is there some specific distinction between "support" and "advocate" that I am missing |
| 17:00 | <jgraham> | ? |
| 17:01 | <webben> | jgraham: where? |
| 17:01 | <gsnedders> | advocate implies actually trying to convince others? |
| 17:03 | <jgraham> | "I expect poll survey from Apple representatives would support an MIT license" vs "we have yet to have somebody specifically advocate for [the MIT license]" |
| 17:03 | <webben> | ah |
| 17:06 | <zewt> | advocating takes more work than supporting :) |
| 17:06 | <TabAtkins> | Even if you charitably assume that's what's meant, CC0 definitely has advocates. |
| 17:09 | <jgraham> | The question is whether merely having supporters rather than advocates should be sufficient to exclude an option from the poll |
| 17:09 | <jgraham> | That seems like an insane policy in a consensus driven environment |
| 17:09 | <jgraham> | (which maybe licensing discussions aren't but still) |
| 17:11 | <jgraham> | It is quite easy to imagine that there are people who can live with the MIT that cannot live with CC0 but prefer an Option X license and people who cannot live with an Option X license, can live with MIT, but prefer CC0 |
| 17:12 | <jgraham> | It seems Apple may be an example of the former and Mozilla of the latter |
| 17:12 | <jgraham> | Note: *may* |
| 17:13 | <jgraham> | Obviously I don't actually know what these organisations will say |
| 19:12 | <Hixie> | hsivonen, matjas: actually that's not quite right (re <base>) |
| 19:13 | <Hixie> | hsivonen, matjas: what matters is the <base> *when the image url is resolved*, which is typically when the element is created, and so the two images would have different URLs |
| 19:13 | <matjas> | What exactly? Tell me more :) |
| 19:14 | <matjas> | Yeah, that’s what I had expected to be honest |
| 19:14 | <Hixie> | hsivonen, matjas: see "update the image data" in the spec and note that nothing causes that to trigger when the base url changes |
| 19:15 | <matjas> | http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data |
| 19:15 | <matjas> | So Firefox 4 is in fact wrong |
| 19:15 | <matjas> | And most browsers are already doing it right (incl. IE6) |
| 19:15 | <matjas> | That makes sense. |
| 19:15 | <zewt> | matjas: fyi, http://zewt.org/~glenn/test-firefox-racy-base/ |
| 19:16 | <Hixie> | if you look at the source of the spec you'll notice it mentions this in a comment often |
| 19:17 | <zewt> | sort of a strange mechanism to have within body (though it makes sense in head), seems like it would have been cleaner as an attribute, eg. <div base=url><img src=file.jpg></div> so it's scoped |
| 19:17 | <matjas> | zewt: Interesting. |
| 19:17 | <Hixie> | <base> isn't allowed in body |
| 19:17 | <Hixie> | but we still have to define how it works |
| 19:17 | <Hixie> | when people do it anyway |
| 19:18 | <zewt> | either it's defined and allowed or defined to do nothing (and so disallowed), defining something and then saying it's disallowed doesn't make much sense :) |
| 19:19 | <Hixie> | sure it does |
| 19:19 | <matjas> | zewt: http://www.w3.org/TR/html-design-principles/#support-existing-content |
| 19:19 | <Hixie> | there are many things that have stupid behaviours due to legacy error handling that we have to define that way but that we say are non-conforming because the results are crazy and confusing |
| 19:23 | <zewt> | when something is defined and compliant browsers are required to support it, it's just sort of meaningless to then call it "non-confirming"; it sounds like you're using "non-conforming" to mean something in the spirit of "deprecated" in other contexts (without the implication that it'll be removed), which is more along the lines of "we recommend against using this", but not "this isn't allowed" |
| 19:26 | <hsivonen> | Hixie: is there a reason why base URL changes don't trigger img re-resolution? |
| 19:27 | <zewt> | hsivonen: that seems like really nasty behavior |
| 19:27 | <Hixie> | when i specced that, or suggested that i would, vendors were uniform in telling me that that was way too much complexity and that they wouldn't implement it |
| 19:27 | <Hixie> | (if you actually follow the implications through it is quite painful) |
| 19:28 | <zewt> | you'd end up making a bunch of requests to bogus URLs before the base changes, showing image errors, firing onerror (or perhaps loading the wrong image entirely) ... |
| 19:29 | <hsivonen> | zewt: with speculative loading, there's always an opportunity to fetch the wrong images |
| 19:29 | <zewt> | yeah, but that would do it for the entire page up to that point |
| 19:30 | <hsivonen> | Hixie: anyway, it seems that bz, I and possibly sicking too looked at the spec and failed to realize that the spec didn't mean to make <base> affect earlier <img>s |
| 19:31 | <hsivonen> | Hixie: so clearly, the spec failed to work well for random access |
| 19:31 | <hsivonen> | Hixie: might be worthwhile to put a Note about this in the spec |
| 19:32 | <Hixie> | hsivonen: where does the spec say that anything should happen? |
| 19:32 | <Hixie> | hsivonen: i considered making the non-requiremente explicit, that's why the spec has the statement about it not having an effect commented out everywhere it would be relevant |
| 19:33 | <Hixie> | hsivonen: but making that explicit would be a massive amount of extra material with minimal benefit since it would only help a dozen people, each once |
| 19:34 | <Hixie> | hsivonen: if you have a suggestion for a specific note to add to the spec e.g. in the <base> section I'm happy to do that too, but I couldn't come up with a readable yet correct note |
| 19:34 | <jgraham> | As someone who might be one of those dozen, I like the idea of it being explicit |
| 19:35 | <jgraham> | :) |
| 19:35 | <Hixie> | well file a bug saying what you want |
| 19:53 | <otherarun> | Does anyone know why XHR2 defines mechanisms for inflating and deflating a DOMString? Why was that deemed necessary? |
| 20:31 | <Hixie> | jgraham: still getting xml errors, fwiw |
| 20:31 | <Hixie> | jgraham: let me know if you need the output |
| 20:32 | <Hixie> | othermaciej: why are we adding caretBlinkRate as a method to the 2D Canvas object? |
| 20:32 | <Hixie> | that makes no sense |
| 20:32 | <Hixie> | shouldn't it be an attribute on Navigator or Window or something? |
| 20:33 | <othermaciej> | Hixie: that's what the proposal said, and no one proposed putting it somewhere different |
| 20:33 | <Hixie> | i proposed not having it at all |
| 20:33 | <Hixie> | which seems better than having it on canvas |
| 20:34 | <Hixie> | and clearly you were ok with changing what people proposed |
| 20:34 | <Hixie> | since you did |
| 20:34 | <othermaciej> | I would guess a separate change to move the API somewhere more central would probably not be a problem |
| 20:35 | <Hixie> | also wtf is up with this ridiculous example i'm supposed to put in |
| 20:41 | <jgraham> | Hixie: The output would be nice. Or the exact URL you are loading |
| 20:46 | <TabAtkins> | I suspet it's the "canvascarseldecision20110426.html" file attached to Richard's email in the "Re: CP is incoherent..." thread. |
| 20:48 | <Hixie> | TabAtkins: he meant the xml error, different thing :-) |
| 20:48 | <TabAtkins> | Ah, never mind. |
| 21:15 | <roc> | caretBlinkRate??? |
| 21:21 | <othermaciej> | roc: if Mozilla is unwilling or unable to implement such a thing, that would be relevant information |
| 21:29 | <roc> | where is caretBlinkRate being proposed? |
| 21:33 | <Philip`> | roc: http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/att-0129/HTML_Canvas_2DContext20110415.html via http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection via http://lists.w3.org/Archives/Public/public-html/2011Apr/0271.html |
| 22:11 | <Hixie> | jgraham: still broken |
| 22:40 | <Hixie> | othermaciej: why does this api change drawFocusRing() to draw the focus ring even if you give it an element that isn't focused? (the CP checks the ancestor chain as well) |
| 22:42 | <othermaciej> | Hixie: that I do not know - I guess I should have read the text and diffed it against the spec instead of just relying on the bullet points |
| 22:42 | <othermaciej> | one thing I can imagine is a single element may be focused but you want to draw focus rings around all the pieces; but that doesn't really make sense, you could just construct a path like that in the first place |
| 22:45 | <TabAtkins> | Basically, it seems like when the issue is "you should design an API for this", the decision process is extremely ill-suited, as it requires people to bundle up the "I think this is an area we should cover" with a specific API design. |
| 22:45 | <Hixie> | that the system is broken is clear |
| 22:46 | <TabAtkins> | Well, I mean it's *extra* broken when the issue needs API design work. |
| 22:46 | <TabAtkins> | Because you have people with no API design skills being forced to design an API so that they have a precise description of the desired change. |
| 22:46 | <karlcow> | http://marcdrummond.com/xhtml/2011/04/26/when-standards-go-awry |
| 22:46 | <TabAtkins> | And then that precise API is required to be pulled into the spec. |
| 22:47 | <Hixie> | it's not just api design skills that are lacking. i presume i'm supposed to fix grammatical mistakes but i've no idea what this sentence that i'm supposed to add is trying to say: "If the given element is focused or a descendant of the element with focus, draws a focus ring around the current path, following the platform conventions for focus rings." |
| 22:48 | <TabAtkins> | That's clear to me (I dunno if it's sensical in context). |
| 22:48 | <Hixie> | oh, wait, i think i understand what it's saying |
| 22:48 | <Hixie> | it's just overly long |
| 22:48 | <Hixie> | ok |
| 22:50 | <Hixie> | this api doesn't make sense |
| 22:50 | <Hixie> | what happens if someone just calls drawFocusRing() but nothing else? |
| 22:50 | <Hixie> | does it not magnify the focused element? |
| 22:59 | <richardschwerdtf> | because some applications manage focus for their children |
| 22:59 | <richardschwerdtf> | what does not make sense is the fact that your existing api falls through when someone draws custom focus rings and a special system setting is not set to draw a focus ring a certain way |
| 23:00 | <richardschwerdtf> | when that happens NO magnifier gets notified of the change |
| 23:00 | <richardschwerdtf> | if you had read the change proposal you would have seen the bug. |
| 23:01 | <richardschwerdtf> | candrawcustom is stupid anyway. |
| 23:02 | <richardschwerdtf> | all you need to do is set up your drawing path before making the call and if the system has not configured a specific drawing style drawfocusring simply draws it the way the author has specified. |
| 23:04 | <TabAtkins> | yo, richardschwerdtf, while you're here, can I request that you send your emails as plaintext instead of HTML? Your emails are distractingly and sometimes unreadably styled. |
| 23:04 | <richardschwerdtf> | how do you mean? |
| 23:05 | <richardschwerdtf> | are you wanting to have monospaced fonts? |
| 23:05 | <TabAtkins> | Your emails are HTML. Your editting system sets custom font and size, and occasionally color, which makes it hard for me to rea. |
| 23:05 | <richardschwerdtf> | Lotus Notes. - I will see what I can do, sure |
| 23:06 | <richardschwerdtf> | thanks for letting me know |
| 23:06 | <TabAtkins> | The color thing is really bad - occasionally the text is black or dark blue, which is unreadable in my Gmail theme of green-text-on-black |
| 23:06 | <TabAtkins> | Cool. |
| 23:06 | <richardschwerdtf> | wow. that would dreadful |
| 23:07 | <TabAtkins> | Yeah. It's often hard to tell whether your text is 'black' or 'automatic' in most GUI editors, unless you manually check the text color. |
| 23:07 | <richardschwerdtf> | I updated to a new version of Notes this past week. so, something must have been enabled i did not notice. |
| 23:08 | <TabAtkins> | Nah, this is something that's always been true. |
| 23:08 | <richardschwerdtf> | hmm. ok |
| 23:08 | <TabAtkins> | Like I said, the color thing doesn't always happen; it's occasional. The font/size thing, though, is always true, and somewhat randomly inconsistent - one email will be slightly larger font-size for no reason I can tell. |
| 23:09 | <richardschwerdtf> | ugh. that is distracting. - sorry |
| 23:09 | <TabAtkins> | It's cool. Most email editors can be told to send plaintext instead of HTML. That makes everything easy, because then there's no way for accidental styling to creep in. |
| 23:11 | <richardschwerdtf> | digging into notes now |
| 23:11 | <aho> | emails should be plain text |
| 23:12 | <TabAtkins> | aho: I'm of the opinion that email readers should be like RSS readers, and just strip/ignore styles from the document. |
| 23:13 | <aho> | my email client is configured to show messages as plain text |
| 23:13 | <aho> | images are also not shown :> |
| 23:13 | <TabAtkins> | Gmail used to have a lab to do that, but they removed it. >_< |
| 23:14 | <Philip`> | TabAtkins: That'd break the reading of some emails that only differentiate quoted text by style |
| 23:14 | <TabAtkins> | Philip`: People who do that should be shot. Simple. ^_^& |
| 23:14 | <aho> | another problem solved :) |
| 23:15 | <richardschwerdtf> | tab, just send you an email let me know if it came out alright |
| 23:15 | <TabAtkins> | It's still being sent as HTML. |
| 23:15 | <richardschwerdtf> | ugh |
| 23:15 | <richardschwerdtf> | ok |
| 23:16 | <TabAtkins> | And, because email readers are lowest-common-denominator, it's styled with <font>. ^_^ |
| 23:18 | <richardschwerdtf> | yes. I chose plain text for internet email. need to dig further. |
| 23:25 | <zewt> | heh, my #1 problem with gmail is there's no way to restrict what people can do with fonts, particularly font size |
| 23:25 | <zewt> | people on yahoo mail in particular seem to like sending mails in 35pt |
| 23:26 | <TabAtkins> | YES |
| 23:26 | <TabAtkins> | argh |
| 23:26 | <zewt> | which isn't really their fault--I tried searching to find out how to reset it (to give one of them a hint), and I couldn't even figure it out |
| 23:26 | <wilhelm> | mutt sucks, but at least it got that part right. (c: |
| 23:26 | wilhelm | is an unhappy mutt user. |
| 23:27 | <heycam> | isn't every mutt user an unhappy mutt user? :) |
| 23:28 | <wilhelm> | I would think so. (Not that the alternatives are any better. Email sucks. :) |
| 23:38 | <hober> | gnus ftw :) |
| 23:44 | <wilhelm> | hober: As an atheist, I'm keeping a safe distance from the Church of Emacs. (c: |
| 23:48 | <TabAtkins> | Darn, why is our EventSource implementation broken? Now I know why I couldn't ever get it to work. |
| 23:49 | <TabAtkins> | It just polls the page for you. If you hold the connection open and send data incrementally, there'll never be a 'message' event. |
| 23:49 | <TabAtkins> | That's kinda useless. |