| 08:39 | <annevk-cloud> | back |
| 09:42 | <xxtjaxx> | How do you guys handle ad/content tracking scripts in your webpages I've got a site here that has them interspersed with the normal content. First idea in my head was putting it at the bottom of the page so it runs after the initial content is loaded and the site can be used. Are theere trackers out there that explicitly *want* to be at the top of the page? |
| 10:55 | <annevk> | So with <img lazyload>, how much do we need src-*? |
| 10:56 | <annevk> | It seems it allows for putting <img> in the markup and adjusting things with <script> |
| 11:00 | <jgraham> | Hmm, I think you just came up with an idea I like even less than all the other ones |
| 11:01 | <jgraham> | Forcing the actual list of images into a script doesn't seem good from any point of view |
| 11:01 | <jgraham> | Apart from "we don't have to have this discussion" |
| 11:02 | <Ms2ger> | That's a pretty big plus |
| 11:03 | <annevk> | Geofencing seems pretty interesting: http://lists.w3.org/Archives/Public/www-archive/2013Nov/att-0007/W3C_TPAC_Breakout_Geolocation_November_2013.pdf |
| 11:03 | <annevk> | jgraham: they could be in data-* with a fallback in src |
| 11:04 | <annevk> | jgraham: and then in five years we study what's out there |
| 11:05 | jgraham | doesn't quite understand geofencing but feels aggrieved that it doesn't involve swords |
| 11:06 | <annevk> | From what I'm told the idea is that you download some information about the building you're in and then it can somewhat accurately tell you whether you're in or out, what floor, what hallway, what room, etc. |
| 11:07 | <jgraham> | annevk: Well you are sort of presuming a solution there "use data-*". The only question is what people will put in the data-*. But at this stage they will probably just copy one of the existing proposals according to personal preference |
| 11:07 | <jgraham> | So I'm not sure how much we learn |
| 11:07 | <annevk> | And then applications can for instance decide not to work if you're in the wrong room (although how secure you can make that, not sure)... |
| 11:07 | <annevk> | jgraham: we'll learn how much it's used, how much variety people require, etc. |
| 11:08 | <jgraham> | It would be nice if there was some way to extend HTML to allow richer attribute types without killing compat. But I don't think it's possible |
| 11:08 | <jgraham> | annevk: Seems kind of like punting on the problem. And I don't think that will make anyone happy. In fact I think that we are perhaps past the point where implementors will agree to do that |
| 11:09 | <jgraham> | But go ahead and suggest it |
| 11:13 | <annevk> | Well it seems some form of lazyload will happen. But I'm not touching that thread. |
| 11:15 | <jgraham> | The src-N thread? Or the lazyload one? |
| 11:21 | <annevk> | The former, discussed the latter in person with the WG. |
| 11:23 | <jgraham> | I don't mind throwing myself to the wolves if you think it is actually a sensible idea |
| 11:27 | <annevk> | Well, I think we have little data and lots of problem solving. And it seems lazyload addresses the scanner problem. |
| 11:34 | <zcorpan> | annevk: http://html5.org/tools/web-apps-tracker?from=8288&to=8289 is empty |
| 11:34 | <annevk> | Bah |
| 11:37 | <annevk> | zcorpan: "fixed" |
| 11:37 | <zcorpan> | thx |
| 12:13 | <MikeSmith> | greetings comrades |
| 12:14 | <MikeSmith> | back in Japan, on a train headed back to my shack |
| 12:16 | <wilhelm_> | Yoyo! |
| 12:17 | <wilhelm_> | I'm in your neighbourhood now. |
| 12:17 | <wilhelm_> | Nishi-Shinjuku 3-6. |
| 12:32 | <MikeSmith> | wilhelm_: oh wow |
| 12:32 | <MikeSmith> | cool |
| 12:33 | <wilhelm_> | Natasha and I have a tentative date on top of the Park Hyatt tomorrow, for one glass there. Feel free to join. (c: |
| 12:33 | <MikeSmith> | ok will try |
| 12:40 | <zcorpan> | new DOMParser().parseFromString("\uBBEF\u3CBF\u7979\u3E2F","text/xml") - interesting case (from bjoern on es-discuss) |
| 12:40 | <zcorpan> | wonder if innerHTML suffers from that kind of insanity as well |
| 12:45 | <zcorpan> | parses into a Text node in gecko |
| 13:30 | <jochen__> | ls |
| 13:30 | <jochen__> | :-/ |
| 13:31 | <jgraham> | . |
| 13:31 | <jgraham> | .. |
| 13:32 | <Ms2ger> | What kind of ls prints . and .. by default? |
| 13:33 | <jgraham> | The irc ls |
| 13:33 | <jgraham> | Of course |
| 13:45 | <Ms2ger> | new DOMParser().parseFromString("\uBBEF\u3CBF\u7979\u3E2F","text/xml") |
| 13:45 | <Ms2ger> | Whyyyyy |
| 13:46 | <Ms2ger> | Looks like it doesn't work in Chrome |
| 13:50 | <jgraham> | Where is that from? |
| 13:50 | <Ms2ger> | Backscroll |
| 13:51 | <Ms2ger> | And Bjoern, unsurprisingly |
| 13:51 | <jgraham> | Ah, right, missed the backscroll |
| 13:51 | <jgraham> | I don't know why it wouldn't work, really :) |
| 13:52 | <jgraham> | (OK, I guess I do) |
| 13:52 | <Ms2ger> | I thought I did |
| 13:52 | <Ms2ger> | Then I looked at the code and didn't |
| 13:53 | Ms2ger | tries a debugger |
| 14:07 | Ms2ger | runs into "This code was bogus when I found it. -- hsivonen" |
| 14:15 | <annevk> | smaug____: you might find https://www.w3.org/Bugs/Public/show_bug.cgi?id=20322 interesting |
| 14:17 | <smaug____> | looking... (and hoping the 3G connection doesn't die ) |
| 14:20 | <hsivonen> | I moved html5.validator.nu, validator.nu, bugzilla.validator.nu and parsetree.validator.nu to new VMs. Please let me know if I broke something. (DNS might take up to 24 hours to update.) |
| 14:21 | <annevk> | hsivonen: I'm back in London if there's anything you still need me to look at |
| 14:21 | <hsivonen> | annevk: no immediate need. the charset stuff hasn't progressed in a few days due to higher-priority stuff |
| 14:22 | <annevk> | I like how the charset stuff is going |
| 14:22 | <hsivonen> | (such as this server move before the old servers are eaten by doom) |
| 14:22 | <annevk> | localization mess is now sorted in Gecko it seems |
| 14:22 | <hsivonen> | annevk: for fallback, not for detectors |
| 14:23 | <hsivonen> | annevk: also, apparently not on B2G |
| 14:23 | <annevk> | so B2G doesn't use that code at all? |
| 14:23 | <hsivonen> | annevk: if you have a B2G device with a recent mozilla-central image, you could test |
| 14:23 | <hsivonen> | annevk: I don't have a device but I believe B2G Gecko always runs as en-US |
| 14:24 | <hsivonen> | I tested today that Android now works |
| 14:24 | <hsivonen> | which is progress |
| 14:24 | <annevk> | I think I only have an en-US image |
| 14:26 | <hsivonen> | maybe there's another device around the office? |
| 14:26 | <hsivonen> | anyway, you probably have a better chance of testing this on B2G than I do |
| 14:27 | <hsivonen> | I'm thinking of dropping detectors that aren't enabled by default for any locale when I move the charset menu to a JSM |
| 14:27 | <hsivonen> | if that makes it through review, that is |
| 14:37 | <Ms2ger> | zcorpan, thanks for the review |
| 14:37 | <Ms2ger> | s |
| 14:38 | <annevk> | hsivonen: makes sense |
| 14:38 | <zcorpan> | Ms2ger: welcome. i haven't received any chocolate yet, though :-| |
| 14:43 | <jgraham> | zcorpan: I was going to get some and bring it to China. But that didn't happen. So I guess it will be by mail and/or next time I am in Sweden |
| 14:43 | <hsivonen> | Interesting how Apache feels like legacy software after dealing with nginx |
| 14:43 | <hsivonen> | maybe part of it is just the config syntax |
| 14:44 | <zewt> | nginx config syntax is painfully ad hoc |
| 14:44 | <zewt> | "variables! except you can't use them consistently, and some uses randomly crash" |
| 14:44 | <zcorpan> | Ms2ger: hmmm. http://w3c-test.org/web-platform-tests/master/dom/nodes/Comment-constructor.html times out in blink. the last test |
| 14:45 | <hsivonen> | zewt: doing redirects with anything but the full original request URL is quite annoying in nginx, though |
| 14:46 | <hsivonen> | zewt: Apache's config format seems to have grown in an even more ad hoc fashion |
| 14:46 | <zewt> | also nginx doesn't support the proxy header saying whether the request came in on http or https (don't remember the name), which is a pretty massive gap |
| 14:46 | <zewt> | yeah |
| 14:46 | <zcorpan> | jgraham: ok cool :-) |
| 14:47 | <hsivonen> | zewt: solution, redirect from http to https in nginx, use HSTS, assume that everything came in vie https :-) |
| 14:48 | <hsivonen> | s/vie/via/ |
| 14:49 | <zewt> | heh, when i was looking into that header, i found that ... the creation of internal redirects in nginx is completely hardcoded |
| 14:52 | <zcorpan> | Ms2ger: ok so the iframe test looks unreliable as the load event might be fired before the listener gets registered |
| 14:53 | <zcorpan> | Ms2ger: can you fix that in a new PR, e.g. by creating the iframe element in the script? |
| 15:12 | <Ms2ger> | zcorpan, gah, I thought I'd considered that |
| 15:13 | <Ms2ger> | Looks like I didn't |
| 15:19 | <Ms2ger> | zcorpan, https://github.com/w3c/web-platform-tests/pull/438 |
| 15:22 | <zcorpan> | thx |
| 15:23 | <Ms2ger> | Np, sorry I didn't catch it |
| 15:25 | <jgraham> | Hmm, so having a test set a sleep of 1000s seems to be problematic |
| 15:26 | <jgraham> | Since it keeps the thread alive even though the browser moves on |
| 15:26 | <jgraham> | Which in turn keeps the web server alive |
| 15:26 | <jgraham> | Which hangs my test runner |
| 15:26 | <jgraham> | At least until it finishes |
| 15:26 | <jgraham> | (I think) |
| 15:27 | <jgraham> | Obviously I can reduce the timeout, but I wonder if there is a generally good solution |
| 15:35 | <zcorpan> | sleeping for 1000s seems like something tests shouldn't be doing. is that the only problem or is it also a problem with tests that set a reasonable timeout and then move on earlier (e.g. because the test failed)? |
| 15:38 | <jgraham> | Well the problem is that as long as the thread is alive the server won't exit |
| 15:39 | <jgraham> | So a test that hangs for 10s but fails before that, and happens at the end of the run, will still cause a pointless 10s wait |
| 15:41 | <jgraham> | I should perhaps move the server into a process rather than a thread and just kill it at the end |
| 15:49 | <zcorpan> | yeah |
| 17:15 | <Hixie_> | MikeSmith: inner base, i think |
| 17:16 | <MikeSmith> | Hixie_: thanks |
| 17:18 | <Hixie_> | TabAtkins: btw, i would caution against assuming that "RICG and a lot of authors" is necessarily representative of "average authors". |
| 17:19 | <Hixie_> | TabAtkins: also, it's not clear to me that the average author is necessarily good at designing good languages. it's often the case that users aren't good at UX, and it seems to me the same applies with authors and language design. |
| 17:19 | <dglazkov> | good morning, Whatwg! |
| 17:22 | <marcosc> | Hixie_: I don't think that's being disputed (about language design). I don't think the RICG folks are designing the language... they are just saying, "yeah, I could use that. Seems ok and kinda makes sense." Remember, we left it for Tab and John to design the language. |
| 17:22 | <marcosc> | The RICG has no input there |
| 17:22 | <marcosc> | Same with srcset. We left that to you. |
| 17:22 | <Hixie_> | sure. i'm just saying that tab's arguing that the RICG likes it therefore it must be good design, and that that doesn't follow. |
| 17:23 | <Hixie_> | (srcset was mostly hober's design, i just thought it was good) |
| 17:25 | <marcosc> | Sure, but same applies. I think Tab would also agree... I'm not sure what would be the best way to ascertain what the "best" design is. I thought of running a "challenge" in the past, where devs would be asked to solve a problem using the different options and then see what they get right/wrong etc. |
| 17:25 | <marcosc> | I can't think of another way to validate this |
| 17:25 | <Hixie_> | that's how we designed microdata |
| 17:26 | <marcosc> | do you think we could try that out? |
| 17:26 | <Hixie_> | if you have the money... |
| 17:26 | <marcosc> | oh, we don't need to do all the eye tracking stuff |
| 17:26 | <marcosc> | that's overkill, me thinks |
| 17:27 | <marcosc> | but say, we have 10 different problems |
| 17:27 | <Hixie_> | at a minimum you need a qualified usability researcher to run the study |
| 17:27 | <Hixie_> | and they cost money |
| 17:27 | <marcosc> | I married one :) |
| 17:27 | <Hixie_> | you'd need an independent one :-) |
| 17:28 | <marcosc> | dammit! now I need to get a divorce! |
| 17:28 | <marcosc> | :) |
| 17:28 | <Hixie_> | that would definitely not help make her independent :-) |
| 17:29 | <marcosc> | I think she is quite capable of conducting the research independently. She is not testing me. |
| 17:29 | <Hixie_> | well, if you can get her to do it, that's certainly the best way to evaluate languages and APIs |
| 17:29 | <marcosc> | ok, will talk to her about it and see if we can come up with some unbiased way of testing this |
| 17:31 | <jgraham> | To be fair you don't *need* all of that stuff |
| 17:32 | <jgraham> | It isn't obviously true that doing nothing is better than doing something suboptimal |
| 17:32 | <Hixie_> | all what stuff? |
| 17:33 | <jgraham> | An independent, qualified, usability researcher |
| 17:33 | <Hixie_> | well, without one anyone who disagrees with the results will just think they were bad because the researcher screwed up somehow |
| 17:34 | <Hixie_> | so it won't help get people on the same page |
| 17:34 | <jgraham> | That seems like argument by authority :) |
| 17:34 | <Hixie_> | and it won't help improve the language if the person desigining it is one of those who disagrees with the results |
| 17:35 | <Hixie_> | what does? |
| 17:35 | <jgraham> | People believing a study because the person that carried it out is an "expert" |
| 17:36 | <Hixie_> | they'd believe the results were sound because it was executed in a competent fashion, not because of the authority of the researcher. |
| 17:36 | <jgraham> | If you do a study and then disagree with the results and so ignore them, all you wasted was some time |
| 17:37 | <Hixie_> | time is the single most valuable resource we have |
| 17:37 | <jgraham> | If they are qualified to judge whether the study was done in competent fashion, they are also qualified to design the study themselves |
| 17:37 | <Hixie_> | not really sure what you're arguing here :-) |
| 17:38 | <Hixie_> | i'm just saying that if you have people who disagree on the quality of a design, and you want to get objective data to convince one group or another, and you get data that's trivially dismissed, you have made no progress on your original problem. |
| 17:38 | <jgraham> | I think my point is that having an expert to help you do the study is nice, but if you design a study and do it without one, that isn't obviously going to be worse than doing nothing at all |
| 17:38 | <jgraham> | In fact it may be better if you do a good job |
| 17:39 | <Hixie_> | if you just want data for your own personal, rather than to convince others, then yeah, for sure, anything is better than nothing. |
| 17:39 | <Hixie_> | if you want to convince others, then i think nothing would be better than a study that will be dismissed by some of the people you're trying to convince, because it can actually make the arguments even more bitter. |
| 17:40 | <jgraham> | Well I don't think it is clear that other people will reject your conclusions because you lacked expertise |
| 17:40 | <jgraham> | Indeed these things often go the other way (people believe flawed studies) |
| 17:40 | <jgraham> | see also: almost all benchmarks |
| 17:41 | <Hixie_> | benchmarks are a great example, where the browsers who do well on flawed benchmarks think they're good benchmarks, and the other browsers think the benchmarks are a sign that the other browser vendor is evil. |
| 17:42 | <jgraham> | I think browser engineers generally agree on the dubious value of many benchmarks. Their PR departments may disagree, and the public certainly does. |
| 17:42 | <jgraham> | So the people that you need to convince are convinced despite a methodology that all the experts agree sucks |
| 17:43 | <Hixie_> | depends who you are trying to convince :-) |
| 17:43 | <Hixie_> | i think if you did a flawed study that showed srcset was better than src-n, tab would point out (correctly!) that it was a flawed study, and not change his mind about srcset not being any good (quite justifiably!) |
| 17:43 | <Hixie_> | and we wouldn't be any further along |
| 17:45 | <jgraham> | That depends on him pointing out specific flaws in the study. If he could do that you could correct them |
| 17:46 | <Hixie_> | i think you underestimate the difficulty in not biasing results in a study |
| 17:47 | <jgraham> | It is also true that people are naturally skeptical of results that support a particular agenda coming from entities pushing that agenda e.g. Microsoft publishing studies about the awesomeness of Windows. So, sure, if you have nailed your colours to a particular mast and then come out with "data" supporting that conclusion you might have difficulties |
| 17:47 | <Hixie_> | we actually did have something like this already for html. for example, someone once did record a user using an AT to show that longdesc="" was useful. |
| 17:47 | <jgraham> | But there is no reason that you have to do that |
| 17:47 | <Hixie_> | and the a11y guys and i came to diametrically opposite conclusions from that video |
| 17:47 | <Hixie_> | (it wasn't intended to be a study, granted) |
| 17:47 | <marcosc> | I guess the idea would be to get stakeholders to fist agree on the study before running it |
| 17:48 | <jgraham> | You can, for example, get the relevant parties to review the methodology in advance |
| 17:48 | <marcosc> | exactly |
| 17:48 | <jgraham> | I am well aware of the difficulties of doing studies |
| 17:48 | <jgraham> | I am also aware that even "experts" often screw up |
| 17:49 | <jgraham> | So having an expert is not a guarantee that your method is not flawed |
| 17:49 | <Hixie_> | jgraham: a large part of the difficulty of operating such studies is actually in how you interact with the subject, which isn't something you can plan in advance and is something that takes a lot of training. |
| 17:49 | <Hixie_> | but anyway |
| 17:49 | <Hixie_> | feel free to go ahead with an unqualified researcher :-) |
| 17:49 | <jgraham> | Hixie_: It seems unlikely, in this case, that you would have an actual lab. Instead you would try to run something over the internet |
| 17:51 | <marcosc> | yeah, that's what I was thinking too |
| 17:52 | <marcosc> | get it on A List Apart or one of the large design sites |
| 17:52 | <jgraham> | (there is a nice example of the way that experts screw up in http://www.lhup.edu/~dsimanek/cargocul.htm Search for "maze") |
| 17:53 | <jgraham> | And FWIW I can certainly see any number of ways to screw up this kind of experiment |
| 17:53 | <jgraham> | I don't think that means it isn't worth trying, within the constraints of the avalliable resources though |
| 17:54 | <Hixie_> | just, don't be surprised if the result is that people dismiss the study because it's flawed, is all i'm saying. |
| 17:55 | <Hixie_> | i do think such studies, if performed competently, are the best way to design languages |
| 17:55 | <Hixie_> | but i think that if performed incompetently, they can be trivially used to justify any design that people want, regardless of the actual quality |
| 17:56 | <Hixie_> | heck even if performed competently, people still dismiss the results |
| 17:57 | <Hixie_> | see e.g. the microdata studies, vs RDF people |
| 17:57 | <jgraham> | Well the alternative is that people use theoretical arguments and gut feelings to justify any design that they want, so it's not obvious that the approach where you try to gather some data is worse on average |
| 17:57 | <Hixie_> | we weren't trying to convince the RDF guys, we were just trying to find results ourserves for designing microdata, but basically anyone who disagrees with microdata's design just dismisses the studies as flawed. |
| 17:57 | <Hixie_> | (which isn't unreasonable, we haven't put the videos up) |
| 17:58 | <marcosc> | the study was a little bit... problematic... ;) |
| 17:58 | <Hixie_> | jgraham: the only way in which it could be worse is that it changes the arguments from "i think it looks better" vs "i think it looks worse" to "i think this study says it is better" vs "i think you are misinterpreting the study" |
| 17:59 | <marcosc> | but let's not go there again :) |
| 17:59 | <Hixie_> | marcosc: how so? |
| 17:59 | <marcosc> | I posted my rationale back when you did the study. The sample size was way too small, you changed the experiment half way through |
| 17:59 | <Hixie_> | jgraham: (and i think the second set is worse because it tends to be more bitter) |
| 17:59 | <Hixie_> | jgraham: but certainly it doesn't have to end up worse, i agree |
| 18:00 | <jgraham> | Hixie_: You are assuming that no one will change their opinion based on a study. That seems unreasonably pessimistic |
| 18:00 | <Hixie_> | jgraham: i'm just saying some people won't, or will use the study to back up their opinion regardless of whether it does or not. but sure, some people hopefully would not be so biased. |
| 18:01 | <marcosc> | Hixie_: that's always the risk - but maybe involving them from the beginning might help. |
| 18:01 | <Hixie_> | marcosc: i don't think that criticism makes any sense in the context of what we were studying, but ok |
| 18:02 | <Hixie_> | (it was a usability study to try to find a good design; that's exactly how you run those for optimal effect) |
| 18:02 | <marcosc> | [citation needed] is all I'm saying |
| 18:02 | <Hixie_> | (that's different from a survey, or other such study, where you're trying to get statistically significant data) |
| 18:02 | <jgraham> | marcosc: The small sample sizes are normal for UX studies. So if you think that the variance in people's behaviour is high enough that a bigger sample might have produced a totally different result, you certianly shouldn't be convinced by any study involving a UX expert |
| 18:03 | <Hixie_> | marcosc: citation: http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ |
| 18:04 | <Hixie_> | marcosc: but i'm not a qualified usability researcher, we had someone who is qualified run those |
| 18:05 | <Hixie_> | anyway, time to head to the office. bbl. |
| 18:05 | <jgraham> | Hixie_: (fwiw that article is at face value hard to understand because it's not really clear how the numbers are defined. I assume the real article might clear things up) |
| 18:06 | <jgraham> | (and I guess one could argue that language design could be quantatively different from the kind of UI design Nielsen studied) |
| 18:07 | <jgraham> | (it's hard to know if that's a strong argument or not) |
| 18:07 | <marcosc> | It could be |
| 18:08 | <marcosc> | also, it expects an iterative testing cycle |
| 18:08 | <marcosc> | so it's more for UX refinement, not so much to draw conclusions from |
| 18:08 | <jgraham> | So I guess I can find possible reasons to doubt the microdata study, but I still think that we should take the results seriously because on average I think that there will be better designs if we do that kind of thing and take the results seriously than if we don't |
| 18:10 | <jgraham> | marcosc: That isn't the point it makes about iterative designs though |
| 18:10 | <jgraham> | It suggests that unless you iterate your design you run the risk of leaving some problems unadressed with a small study |
| 18:10 | <jgraham> | Which is obviously true |
| 18:10 | <marcosc> | yes, that's what I was trying to say |
| 18:10 | <jgraham> | It doesn't say that if you don't iterate your design you will actively make things worse |
| 18:11 | <marcosc> | but with the responsive images stuff, we are interested in both: compare which one is more usable, iterate to improve the design of at least 1 |
| 18:11 | <jgraham> | (and Hixie did iterate a bit, which you also complained about) |
| 18:12 | <marcosc> | yes, he iterated after only 2. I think he should have concluded the study before iterating |
| 18:13 | <jgraham> | I assume that Google weren't prepared to pay for two rounds of study |
| 18:13 | <marcosc> | yeah, probably not |
| 18:13 | <jgraham> | So there is a reasonable question of whether that was a better approach than not iterating at all |
| 18:14 | <jgraham> | But again, it isn't clear what the "right" answer is |
| 18:14 | <marcosc> | it's also interesting to see, given that it's been a decade since Nielsen research was published, if it still holds up |
| 18:14 | <jgraham> | and it isn't at all clear that doing this study was worse than doing nothing at all |
| 18:14 | <jgraham> | That seems much less interesting |
| 18:14 | <jgraham> | I mean I don't have any good reasons it wouldn't |
| 18:14 | <jgraham> | Do you? |
| 18:14 | <marcosc> | The Nielsen stuff has been very criticized before. |
| 18:15 | <jgraham> | Well that's different |
| 18:15 | <jgraham> | If the original study was just wrong |
| 18:15 | <jgraham> | Which is possible ofc (c.f. my earlier point about expertise not guaranteeing much) |
| 18:15 | <jgraham> | So yes, it would be interesting to see if others reproduced it |
| 18:16 | <marcosc> | http://www.measuringusability.com/blog/five-history.php |
| 18:19 | <marcosc> | Anyway, we will see how the discussion on WHATWG plays out... if we get agreement on a solution, we might not need to run the study |
| 18:29 | <TabAtkins> | annevk-cloud: <img lazyload> + script is almost exactly identical to <img fake-src> + script. It's not an acceptable solution, as it doesn't interact with the preloader, which is the entire point of all of this. |
| 22:38 | <Hixie_> | pet peeve about english: the construction "bla bla bla a a a a a, b b b b b b, c c c c c c, and d d d d d bla bla bla bla" has no obvious grammatical way to distinguish the end of the "d" phrase from the start of the end "bla" phrase. |
| 22:39 | <Hixie_> | case in point, the space between "dev" and "equal" on the last comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=11984 |
| 22:43 | <TabAtkins> | Hixie_: In some cases you can grammatically add a comma after the last entry, which indicates a pause as you leave the list and reenter the normal flow of the sentence. |
| 22:43 | <TabAtkins> | But I don't think it would quite work in this case. Best to rephrase so you're not embedding a list in the middle of a phrase, which is easy to do in your case. |
| 22:44 | <astearns> | yeah, that needs to have 'giving equal voting power to' before the list, and a comma at the end of the list |
| 22:44 | <TabAtkins> | Yup. |
| 22:44 | <Philip`> | Hixie_: Splitting a single concept across two ends of a sentence is always going to be awkward - merge all the blas together, like "...the majority result when giving equal voting power to a, b, and c, since ..." |
| 22:45 | <Philip`> | (Oh, what everyone else said) |
| 22:45 | <TabAtkins> | Basically, humans are terrible at center-embedding in the first place, and our languages don't tend to have constructs to make it less awkward. |
| 22:45 | <TabAtkins> | (I mean, really terrible. Our brains literally cannot parse more than 2 or so levels of center embedding without resorting to explicit tracing and level tracking, at which point you're diagramming the sentence rather than reading it.) |
| 22:58 | <TabAtkins> | Where's the most correct Events spec? Not D3E, is it? |
| 23:07 | <Hixie_> | yeah, you can rephrase it, but english should just support that natively. :-) |
| 23:07 | <Hixie_> | TabAtkins: events infrastructure, or specific events? |
| 23:07 | <TabAtkins> | Latter. |
| 23:07 | <TabAtkins> | Former is WHATWG DOM, I know. |
| 23:08 | <Hixie_> | things like mouse events are best described by d3e, but it leaves a lot to be desired, sadly |
| 23:08 | <Hixie_> | it's mostly spec-by-example |
| 23:58 | <Hixie_> | if someone with IE could show me a screenshot of http://goo.gl/CxK0ic that'd be awesome |