| 06:30 | <annevk> | MikeSmith: but that symlink will be created in environments where there is Python 2, no? |
| 06:30 | <annevk> | What's this brevity bug? :-) |
| 06:31 | <MikeSmith> | annevk: dunno how it works but I have no /usr/bin/python2 on my OS X machine |
| 06:31 | <MikeSmith> | annevk: the last bug there I think |
| 06:32 | <MikeSmith> | oh no I guess one of the others |
| 06:32 | <MikeSmith> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12837#c10 I guess |
| 06:32 | <MikeSmith> | > I'm confused as to what you want me to do here. Can you elaborate? |
| 06:33 | <annevk> | Hmm, comment 0 and comment 1 seem pretty elaborate |
| 06:45 | <MikeSmith> | it seems #!/usr/bin/env python2.7 is probably what I should use |
| 07:15 | <annevk> | Hixie: are you still getting errors when trying to tweet? |
| 08:25 | <mathiasbynens> | annevk: to patch Poodlebleed, add `SSLProtocol All -SSLv2 -SSLv3` to your Apache config |
| 08:25 | <annevk> | mathiasbynens: I don't have control over that |
| 08:27 | <hsivonen> | annevk: maybe you could convince dreamhost not to care about IE6 whose admin can't be bothered to check the TLS 1.0 checkbox anymore |
| 08:27 | <annevk> | mathiasbynens: however, with SNI being required, it doesn't seem like connecting over SSLv3 will work |
| 08:27 | <hsivonen> | annevk: that's an even better point to make to dreamhost |
| 08:28 | <annevk> | hsivonen: yeah I guess I could at least ask |
| 08:28 | <hsivonen> | (although I suppose it also means it's not actually a security risk) |
| 08:28 | <annevk> | Yeah, unless they support SNI over SSLv3 but I doubt that's actually possible |
| 08:29 | <hsivonen> | even China isn't orange anymore on this map: https://www.modern.ie/en-us/ie6countdown |
| 08:30 | <hsivonen> | I wonder why Ireland and Estonia are "unknown" on that map |
| 08:36 | <annevk> | Interesting how this poses problem for Mozilla's servers as we still want to serve Firefox downloads to IE6 |
| 08:37 | <ondras> | dpes the poodle affect you in this particular scenario? |
| 08:37 | <ondras> | *does |
| 08:37 | <ondras> | I mean, who cares about secure cookies when downloading firefox from ie6? |
| 08:44 | <annevk> | ondras: yeah, the argument is that integrity is not affected, indeed |
| 08:44 | <annevk> | ondras: it's still not ideal of course |
| 08:45 | <annevk> | hmm, ssllabs.com is down, how convenient |
| 08:46 | <hsivonen> | ondras: the main problem is that people who look at mozilla.org to mimic the config assuming it's the best practice may not realize that the servers on the path to Firefox download are a special case, because they need to work with legacy browsers that are used to download Firefox |
| 08:48 | <annevk> | I recently learned we have https://wiki.mozilla.org/Security/Server_Side_TLS though it should really be on MDN |
| 08:49 | <ondras> | hsivonen: okay; perhaps the exception (allowing ssl3) can be added just for the download domain(s) ? |
| 08:50 | <hsivonen> | ondras: see the three levels on the page annevk mentioned above |
| 08:52 | <ondras> | just looking at them |
| 08:52 | <ondras> | well I would just turn sslv3 off, enabled that on download domains and note the real reason in the relevant config file |
| 08:52 | <ondras> | *noted |
| 08:56 | <mathiasbynens> | annevk: I use SNI and my server supported SSLv3 (i.e. `openssl s_client -connect mths.be:443 -ssl3` worked until I patched it this morning) |
| 08:57 | hsivonen | disabled SSLv3 before it was cool |
| 08:57 | <annevk> | mathiasbynens: can you connect like that to whatwg.org or annevankesteren.nl? |
| 08:57 | <mathiasbynens> | the h in hsivonen stands for hipster |
| 08:57 | <mathiasbynens> | annevk: yep, both |
| 09:08 | <annevk> | mathiasbynens: I wonder how that works then |
| 09:09 | <annevk> | mathiasbynens: when I run that line for annevankesteren.nl I get a certificate from sni.dreamhost.com |
| 09:09 | <annevk> | mathiasbynens: which is clearly bogus |
| 09:10 | <mathiasbynens> | same for whatwg.org |
| 09:11 | <annevk> | mathiasbynens: so then it doesn't actually work |
| 09:11 | <mathiasbynens> | well, it should still be disabled, but I appreciate that’s a Dreamhost TODO |
| 09:12 | <annevk> | No disagreement there, but that you cannot use SSLv3 to connect to an SNI domain seems like enough of a safeguard |
| 09:13 | <annevk> | mathiasbynens: did you disable TLS 1.0 as well? |
| 09:14 | <mathiasbynens> | annevk: no, should I? |
| 09:15 | <annevk> | mathiasbynens: https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility |
| 09:16 | <mathiasbynens> | ah, right, my current server hardware is too old to support TLS 1.2 for some reason, will migrate to a better one soon |
| 09:19 | <annevk> | oh |
| 09:26 | <hsivonen> | I wonder if the EME bugs twirl filed are on his own behalf or on behalf of the TAG |
| 09:28 | <annevk> | That the distinction still matters is sad |
| 09:28 | <annevk> | But a lot of WGs appreciate arguments from authority :-( |
| 09:29 | <annevk> | Maybe that's badly phrased. They seem to prefer reasonable arguments from a recognized authority over the same arguments from an unrecognized authority |
| 09:30 | <zcorpan_> | is it OK that https://www.w3.org/Bugs/Public/show_bug.cgi?id=24691 is a UA-defined timeout? |
| 09:30 | <hsivonen> | I'm mainly curious if those bugs reflect the thinking of TAG members more broadly |
| 09:30 | <hsivonen> | the bug about presenting the license to the user doesn't make much sense for the use cases driving EME |
| 09:31 | <hsivonen> | the bug about platform segmentation is pretty much a generic anti-DRM bug |
| 09:31 | <annevk> | hsivonen: I would expect anything outside https://github.com/w3ctag/spec-reviews/blob/master/2014/10/eme.md to be twirl personally |
| 09:32 | <annevk> | zcorpan_: prolly not okay long term, but for now it might be fine |
| 09:32 | <hsivonen> | annevk: OK, looks like the TAG is opposed to the fundamental premise of EME then |
| 09:33 | <annevk> | zcorpan_: I suspect you wouldn't want to kill the SharedWorker before the task where load is dispatched is run in the new environment |
| 09:34 | <zcorpan_> | annevk: what about if the new document navigates before that? |
| 09:35 | <annevk> | zcorpan_: keep it alive? until cross-origin of course |
| 09:36 | <zcorpan_> | hmm. then i guess UA-defined is ok |
| 09:41 | <hsivonen> | so the TAG basically wants standardized royalty-free DRM |
| 09:41 | <hsivonen> | when even the codec the DRM-using services want to use isn't RF (H.264) |
| 09:55 | <foolip> | hsivonen, annevk, where can I read the latest about TAG vs. EME? |
| 09:55 | <darobin> | hsivonen: while there I'd have thrown in a pony — you never know |
| 09:56 | <darobin> | foolip: some pointers http://lists.w3.org/Archives/Public/www-tag/2014Oct/0066.html |
| 09:56 | <hsivonen> | foolip: I was reading https://github.com/w3ctag/spec-reviews/blob/master/2014/10/eme.md which annevk pasted |
| 10:03 | <wilhelm> | I'm wondering how font sizes are most commonly specified on the web (em, px, %). Do any browser vendors have data on that? |
| 10:04 | <MikeSmith> | w3cmemebot, please process http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/0181.html |
| 10:04 | <wilhelm> | Or a corpus that can be grepped for 'font-size'. |
| 10:09 | <zcorpan_> | wilhelm: simons-mbp:webdevdata.org-2013-09-01-201332 zcorpan$ find . -type f -print0 | xargs -0 -P 4 -n 40 grep -Eio "font-size\s*:\s*[a-z0-9.%-]+" >> ../font-size.txt |
| 10:11 | <wilhelm> | Ahh, I didn't know about that corpus. Thank you very much! |
| 10:12 | <zcorpan_> | it doesn't include external css but might be good enough anyway |
| 10:21 | <zcorpan_> | wilhelm: total font-sizes: 889057. px: 552165. em: 30154. %: 39637. keyword: 120. inherit: 679. unitless: 22 |
| 10:22 | <zcorpan_> | wilhelm: rem: 537 |
| 10:22 | <zcorpan_> | wilhelm: pt: 199834 |
| 10:23 | <zcorpan_> | wilhelm: (vw|vh|vmin|vmax): 0 |
| 10:25 | <zcorpan_> | other units are also ~0 |
| 10:28 | <smaug____> | annevk: what is utterly broken? |
| 10:28 | <smaug____> | in D3E/default action |
| 10:28 | <smaug____> | it does explicitly say that click is special |
| 10:29 | <annevk> | smaug____: the whole isTrusted thing |
| 10:31 | <smaug____> | I'm missing something |
| 10:34 | <wilhelm> | zcorpan_: Wonderful! Thank you. |
| 10:34 | <zcorpan_> | wilhelm: np |
| 10:39 | <wilhelm> | zcorpan_: Is there any plan to make external styles and scripts part of the corpus, or is that deemed out of scope? |
| 10:40 | <MikeSmith> | in kenji's serviceworker comments what is MVP |
| 10:40 | <annevk> | smaug____: it doesn't actually define anything |
| 10:41 | <annevk> | MikeSmith: minimal viable product |
| 10:42 | <MikeSmith> | annevk: is that some google term or do other browser projects use it? |
| 10:43 | <wilhelm> | MikeSmith: It's a Silicon Valley startup term. |
| 10:43 | <annevk> | MikeSmith: I hadn't seen it in use before, but http://en.wikipedia.org/wiki/Minimum_viable_product |
| 10:44 | <darobin> | it's not just Valley-talk, it's actually a reasonably useful notion |
| 10:50 | <wilhelm> | zcorpan_: These numbers are remarkably interesting. pt is surprisingly common (22%), and % (4.5%) is more popular than em (3.4%). |
| 10:51 | <darobin> | that strikes me as weird |
| 10:52 | <darobin> | I mean, there's so much outreach info about using em out there... |
| 10:52 | <wilhelm> | You mean em is surprisingly low? |
| 10:52 | <darobin> | I reckon just looking at HTML is probably skewing the results |
| 10:52 | <darobin> | yes |
| 10:52 | <annevk> | darobin: gives you an idea of the reach of the outreach |
| 10:52 | <darobin> | plus, who the fuck uses pt? |
| 10:53 | <annevk> | darobin: DTP? |
| 10:53 | <wilhelm> | I didn't expect it to be any higher. The only surprise here is pt. |
| 10:53 | <MikeSmith> | MVT Minimum viable team http://en.wikipedia.org/wiki/Minimum_viable_product#Minimum_viable_team I like that notion a lot better |
| 10:54 | <darobin> | annevk: just including frameworks should change those numbers |
| 10:54 | <darobin> | DTP? |
| 10:54 | <wilhelm> | Desktop publishing. |
| 10:54 | <darobin> | oh |
| 10:54 | <darobin> | I'd be surprised it had this much of an impact, really |
| 10:55 | <darobin> | I strongly suspect that relying on HTML only will heavily skew results towards sites that make massive use of the style attribute |
| 10:55 | <darobin> | and those aren't representative |
| 10:55 | <darobin> | it likely skews towards newsletters copied to the Web |
| 10:55 | <darobin> | which are all sorts of wrong |
| 10:56 | <wilhelm> | Indeed. We'll need the external stylesheets to draw clear conclusions. |
| 10:57 | <wilhelm> | Context: I'm writing an article making the case that it doesn't matter what CSS unit you prefer. Use whatever you want. |
| 10:59 | <jgraham> | It's nice to know that the web-dev wirld can still be dtriven to turmoil by subjects as weighty as the optimum choice of units |
| 11:00 | <wilhelm> | Elaborate techniques are developed to appease the CSS unit deities. |
| 11:02 | <wilhelm> | Resulting in wonderful stylesheets with 1.42857143em line-heights, 0.0625rem borders and 41.66666667% wide columns. |
| 11:04 | <darobin> | wilhelm: isn't the only traditional consideration interaction with text zoom? |
| 11:04 | <wilhelm> | Yes. |
| 11:07 | <wilhelm> | And then added argument that "if everything is based on ems, your site will magically resize if you enlarge the text". |
| 11:07 | <darobin> | yeah, that doesn't work |
| 11:07 | <wilhelm> | In other words, you've just spent two man-days replicating page zoom. |
| 11:07 | <darobin> | plus, you don't want that for all graphical items |
| 11:07 | <darobin> | the best approach is a mix of both IMHO |
| 11:08 | <wilhelm> | Rummaging through old discussions, I found this gem: http://lists.w3.org/Archives/Public/www-style/1995Dec/0004.html |
| 11:08 | <wilhelm> | There was a magnification property in an early CSS draft. |
| 11:09 | <wilhelm> | Which would scale up everything. Text, images. |
| 11:09 | <darobin> | heh |
| 11:09 | <darobin> | old stuff is golden |
| 11:09 | <wilhelm> | This seems to be the first coherent argument in favour of ems, too: http://lists.w3.org/Archives/Public/www-style/1997Nov/0078.html |
| 11:10 | <darobin> | HTML 2 had urn="" as an attribute to links, and HTML 3.0 had md="" to do resource integrity checks :) |
| 11:11 | <wilhelm> | My personal opinion is this: CSS pixels are great. Use them. Text zoom can safely be killed, now that web sites have sensible breakpoints with different styles for different viewport widths. |
| 11:12 | <darobin> | that's an interesting take |
| 11:12 | <wilhelm> | "Small screen" and "400% zoom" are two sides of the same coin. |
| 11:12 | <darobin> | but.... |
| 11:12 | <darobin> | "now that web sites have sensible breakpoints with different styles for different viewport widths" *cough* |
| 11:13 | <darobin> | too many still don't |
| 11:13 | <wilhelm> | Don't they? Do anyone actually build web pages today that don't look okay on small screens? |
| 11:13 | <wilhelm> | Legacy sites are a different story, of course. |
| 11:14 | <darobin> | people still do yes |
| 11:15 | <darobin> | hopefully fewer and fewer |
| 11:15 | <darobin> | that said, I guess the people who don't also don't read your advice :) |
| 11:15 | <wilhelm> | Nor the advice to use ems for everything, because accessibility. |
| 11:16 | <darobin> | in fact, I wonder if they read anything |
| 11:16 | <jgraham> | wilhelm: You don't use the web on a small screen device, I see |
| 11:18 | <wilhelm> | This is the crux of my argument. Authors didn't care about best practices. So browsers needed to make things work anyway. Hence text zoom is hidden away, in favour of the full page zoom. |
| 11:19 | <wilhelm> | Thanks to shiny new devices, not advocacy, authors care about small screens now. That gives us accessibility for free. Accidently. |
| 11:20 | <wilhelm> | jgraham: I do. And most new content works fine on small screens. |
| 11:21 | <zcorpan_> | wilhelm: how do you know it works fine because the site uses sensible breakpoints vs uses UA sniffing or so? |
| 11:22 | <wilhelm> | zcorpan_: Valid point. My evidence is anecdotal. |
| 11:26 | <wilhelm> | More research is needed here. But that doesn't change my suggested best practice. (c: |
| 11:31 | <wilhelm> | I do wonder how we ended up with text zoom instead of magnification. Time to find some ancient browsers. |
| 11:38 | <darobin> | wilhelm: in a world in which everyone is doing fixed layout, you want text zoom |
| 11:38 | <wilhelm> | darobin: As in, one stylesheet, assuming a 1024px wide monitor? |
| 11:39 | <darobin> | wilhelm: yes |
| 11:39 | <darobin> | which was the norm until not that very long ago |
| 11:39 | <darobin> | I'm sure quite a few people still do that |
| 11:39 | <darobin> | also: table layouts |
| 11:40 | <wilhelm> | It doesn't work very well in practice, though. Merely increasing the font size without changing the containing blocks tends to break things. |
| 11:40 | <wilhelm> | The authors who don't read best practices isn't going to test for that. |
| 11:45 | <wilhelm> | You can make it work by making the size of the containing block depend on the font size. But then you've just reimplemented page zoom. |
| 11:46 | <darobin> | wilhelm: those layouts typically scaled vertically relatively okay; but yes — I'm not defending that as an approach, just pointing out the mechanics that led there |
| 11:51 | <MikeSmith> | annevk: so the CH-Context: serviceworker thing didn't go in right? |
| 11:51 | <MikeSmith> | *, right? |
| 11:52 | <wilhelm> | Yes. Also, until IE7, text zoom was blocked on any page with font size defined in px. There were plenty of good reasons for the best practices back then. |
| 11:52 | <annevk> | MikeSmith: https://github.com/slightlyoff/ServiceWorker/commit/9445ff71ee97be11716c3d93a51e29da2b213678 seems suspicious |
| 11:52 | <MikeSmith> | yeah that's what I was just looking at |
| 12:00 | <wilhelm> | I'm really impressed by Microsoft. These old browsers still run on their latest operating system. |
| 12:01 | jgraham | assigns wilhelm to review all their pending test submissions |
| 12:02 | wilhelm | runs away. |
| 12:08 | <ato> | There are about 5 kloc of WebDriver tests needing review if you have the time. |
| 12:09 | <MikeSmith> | win 18 |
| 12:12 | <Manishearth> | annevk: Any update on the XHR request termination bug I filed? |
| 12:12 | <annevk> | Manishearth: not yet, sorry |
| 12:12 | <Manishearth> | np, just checking that you had gotten pinged ;P |
| 12:12 | <annevk> | Manishearth: are you blocked on it? |
| 12:13 | <Manishearth> | annevk: Not really. mukilan has an unfinished fix for it that he can't push until we figure out how it should actually work |
| 12:14 | <annevk> | Manishearth: okay, will try to get to it today; XHR has a couple of other outstanding bugs that would be good to finally fix |
| 12:14 | <Manishearth> | annevk: thanks! :D |
| 12:21 | <wilhelm> | Text zoom seems to have been in Internet Explorer since version 1, predating their CSS implementation. |
| 12:23 | <wilhelm> | cwilso: Can you recall if the CSS 'magnification' property was ever disussed at Microsoft back in 1995? It's in a CSS draft that autumn, and then disappears. |
| 12:36 | <annevk> | wilhelm: was it renamed to 'zoom'? |
| 12:39 | wilhelm | blinks. |
| 12:39 | <wilhelm> | I didn't know about that one. Seems to have been implemented in IE5.5. |
| 12:40 | <annevk> | Manishearth: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27033#c2 |
| 12:41 | <darobin> | wilhelm: the zoom property is essentially used as a workaround for some IE bugs (I forget which, old stuff) |
| 12:42 | <wilhelm> | darobin: Indeed, I see scattered references to it. |
| 12:42 | <jgraham> | That's not really the *point* of it though :) |
| 12:42 | <darobin> | wilhelm: you'll find it used in frameworks and such; possibly reset style sheets |
| 12:42 | <darobin> | anything that basically papers over issues for you |
| 12:42 | <darobin> | jgraham: from a webdev pov it pretty much is :) |
| 12:43 | <darobin> | ah, yes, makes display: inline-block work right |
| 12:43 | <Ms2ger> | hasLayout, eh |
| 12:43 | darobin | doesn't even want to know how that was implemented in such a way that this has an impact |
| 12:45 | <tobie> | zoom: 1 actually triggers box layout on IE |
| 12:47 | <tobie> | for ref: http://www.satzansatz.de/cssd/onhavinglayout.html |
| 12:47 | <zcorpan_> | Hixie: why does <script> and <style> say that unknown MIME type parameters in type="" means unsupported? https://www.w3.org/Bugs/Public/show_bug.cgi?id=27057 |
| 12:47 | <darobin> | ah, sad sad memories flowing back in :) |
| 12:48 | <zcorpan_> | zoom:1 |
| 12:48 | <zcorpan_> | used a bit back in the day :-) |
| 12:49 | <wilhelm> | So IE did have the basis for a built-in full page zoom by year 2000, but didn't expose any such feature until IE7. |
| 12:50 | <tobie> | wilhelm: I don't recall that was the problem with IE < 7 |
| 12:50 | <MikeSmith> | "being defined by guess-the-spec-text-we-should-have-and-see-what-sticks" |
| 12:50 | <tobie> | wilhelm: wasn't the issue just that IE didn't have proper text zoom when using pixel-based fonts? |
| 12:51 | <wilhelm> | tobie: IE wouldn't resize fonts set in px. |
| 12:51 | <tobie> | right |
| 12:52 | <wilhelm> | Browsers have slowly hidden away the text zoom in favour of the full-page zoom. Opera in 1996, IE i 2006, Firefox in 2007, Safari in 2008. |
| 12:52 | <wilhelm> | I'm trying to wrap my head around the history here. (c: |
| 12:52 | <zcorpan_> | i think old ie also had a bug with font-size set in em. text zoom would multiply the ems in the ancestor chain, or some such. % worked correctly |
| 12:52 | <tobie> | wilhelm: don't do that to yourself |
| 12:53 | <zcorpan_> | might explain why % is high for font-size |
| 12:54 | <wilhelm> | zcorpan_: Ah, indeed. IE3 would also treat "3em" as "3px". There were plenty of issues. NS4 had its own stack of them. |
| 12:54 | <zcorpan_> | wilhelm: *that's* before my time |
| 12:54 | <wilhelm> | :D |
| 12:55 | <darobin> | please don't mention NS4 |
| 12:55 | <darobin> | I *still* cringe |
| 12:55 | <zcorpan_> | darobin: NS4 NS4 NS4 NS4 |
| 12:55 | <darobin> | GAAAAAAH |
| 12:55 | <darobin> | GAAAAAAaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAaaaaaaaaaaaaaaAAH |
| 12:55 | <annevk> | NN4? |
| 12:55 | <darobin> | IIRC IE3 would treat 3whatever as 3px |
| 12:55 | darobin | cries |
| 12:55 | <wilhelm> | I'll make a t-shirt for you by TPAC. With NS4 on it. |
| 12:56 | darobin | sobs louder and louder |
| 12:56 | <darobin> | you.... you wouldn't joke like that if you'd been there |
| 12:56 | <wilhelm> | I was there. Jokes make it hurt less. |
| 12:56 | <darobin> | <LAYER> |
| 12:58 | <wilhelm> | tobie: Since I'm back to building web stuff instead of browsers, I encounter large amounts of cargo cult best practices every day. This archeology has a purpose! |
| 13:00 | <tobie> | wilhelm: do you actually mean you're DOGFOODING WEB TECH!??!!? |
| 13:00 | <jgraham> | Well not really |
| 13:01 | <jgraham> | It's only dogfood if you're also involved in building it |
| 13:01 | <jgraham> | Otherwise it's just eating someone else's crap |
| 13:01 | <wilhelm> | Hey, web development today is fantastic. |
| 13:02 | <zcorpan_> | pop quiz: how many tags were there in "HTML Tags"? |
| 13:02 | <zcorpan_> | (the thing from 1991) |
| 13:04 | <wilhelm> | "Few". |
| 13:04 | <zcorpan_> | i want a number :-) |
| 13:06 | <darobin> | mmmm |
| 13:06 | <darobin> | 12? |
| 13:06 | <darobin> | (complete guess) |
| 13:07 | <jgraham> | zcorpan_: As far as I can tell from reading it "infinity" |
| 13:07 | <jgraham> | Although it's a bit vauge |
| 13:07 | <zcorpan_> | jgraham: not counting NOT CURRENTLY USED things. also reading it is cheating |
| 13:08 | wilhelm | cheated. |
| 13:08 | <jgraham> | zcorpan_: Oh, well if you're going to introduce arbitary rules :) |
| 13:08 | <zcorpan_> | correct is 21 |
| 13:09 | <darobin> | it's refreshing to see that the second is "Not good SGML" already |
| 13:09 | <tobie> | jgraham: I'm reassured. I thought someone was actively dogfooding this, thus refuting my claim that no one ever does. |
| 13:09 | <jgraham> | The second is actually marked "obsolete" |
| 13:10 | <zcorpan_> | this was a question on a teambuilding at opera. iirc i was off by 1 by trying to remember and count the tags :-) |
| 13:10 | <jgraham> | I'm not sure if that qualifies under zcorpan_'s underspecified rules of entry |
| 13:10 | <wilhelm> | 21, plus some crazy <hp1> tags? What were those? |
| 13:11 | <jgraham> | So I count 20 |
| 13:11 | <darobin> | wilhelm: the ancestors of <b>, <i>, etc |
| 13:11 | <jgraham> | Did I miscount or are obsolete tags included, but not currently used tags aren't? |
| 13:12 | <darobin> | wilhelm: see http://info.cern.ch/hypertext/WWW/MarkUp/Future.html |
| 13:12 | <zcorpan_> | i included nextid when counting |
| 13:12 | <jgraham> | (I think it's more interesting that there are, depending on how you read it, an infinite number) |
| 13:13 | <darobin> | <HP19879879>this matters</> |
| 13:13 | <annevk> | Does each event loop have a networking task source? |
| 13:13 | <wilhelm> | Aw, the "Bad HTML" chapter is such a nice peek into the future. |
| 13:14 | <annevk> | It's still not clear to me how exactly those things interact |
| 13:14 | <annevk> | Anyone? |
| 13:17 | <zcorpan_> | annevk: an event loop is either owned by a browsing context or a worker, and both of those can queue thing on the networking task source. afaict |
| 13:17 | <annevk> | zcorpan_: wouldn't I have an event loop and then queue a task on its networking task source? |
| 13:18 | <zcorpan_> | annevk: i don't really follow the question |
| 13:19 | <annevk> | zcorpan_: say Fetch is passed in an event loop to queue tasks on, Fetch wants these tasks to belong to the networking task source obviously, how does it come together? |
| 13:20 | <cwilso> | Wilhelm: no, magnification was not seriously discussed in Microsoft IE in 1995. (I was the only one working on CSS in '95). Zoom was the first MS adventure in that direction, as darobin said. |
| 13:21 | <MikeSmith> | "Can you please stop trying to guess spec text and explain what behavior you're after and why?" |
| 13:21 | <Ms2ger> | MikeSmith, context? |
| 13:21 | <zcorpan_> | annevk: i still don't follow :-( |
| 13:22 | <MikeSmith> | not a thing you'd expect to be having to say to a spec writer |
| 13:22 | <MikeSmith> | Ms2ger: looking back at https://github.com/slightlyoff/ServiceWorker/issues/356 |
| 13:22 | <MikeSmith> | comment https://github.com/slightlyoff/ServiceWorker/issues/356#issuecomment-48703488 from bz |
| 13:22 | <wilhelm> | cwilso: Thanks! |
| 13:23 | <wilhelm> | cwilso: Was there any particular rationale behind the "don't resize fonts set in px" bug/feature back then? |
| 13:23 | <annevk> | zcorpan_: as you said, an event loop belongs to a document or worker environment |
| 13:23 | <annevk> | zcorpan_: Fetch belongs to neither |
| 13:24 | <annevk> | zcorpan_: so Fetch is passed an event loop it can queue tasks on |
| 13:24 | <zcorpan_> | annevk: ah. ok. |
| 13:25 | <annevk> | zcorpan_: perhaps "queue a task to X on Y's event loop using the networking task source" |
| 13:25 | <MikeSmith> | Ms2ger: "Uh.. no. URLs of documents are immutable (modulo document.open). Performing a navigation creates a new document!" etc |
| 13:25 | Ms2ger | mumbles |
| 13:25 | <annevk> | MikeSmith: I thought that changed with pushState() |
| 13:25 | <annevk> | MikeSmith: hmm |
| 13:26 | <zcorpan_> | annevk: and then we have ping="" that needs to outlive the browsing context |
| 13:26 | <zcorpan_> | along with sendBeacon and maybe <img> |
| 13:28 | <zcorpan_> | annevk: but yeah if you have a reference to the right browsing context or worker just use its event loop |
| 13:28 | <annevk> | zcorpan_: the question was what language to use |
| 13:29 | <annevk> | zcorpan_: not entirely clear how sendBeacon and ping="" would work I guess |
| 13:29 | <annevk> | zcorpan_: perhaps in that case no tasks will be queued |
| 13:29 | <annevk> | zcorpan_: and for all other cases we rely on the document to terminate existing fetches |
| 13:33 | <zcorpan_> | annevk: <img> shouldn't be terminated, at least not when it's created in onunload/onbeforeunload or so. iirc |
| 13:33 | <zcorpan_> | poor man's sendBeacon |
| 13:36 | <mathiasbynens> | “With SSLv3 on its way out the door, we need to stop calling it SSL and start saying TLS #poodle” – https://twitter.com/webtonull/status/522379727840223232 |
| 13:41 | <annevk> | mathiasbynens: already started doing that \o/ |
| 13:52 | <darobin> | I'd never noticed that HTML 4.01 had shipped on Christmas Eve |
| 14:03 | <annevk> | Ooh, Chromium has shipped the Encoding API |
| 14:04 | <annevk> | nice |
| 14:17 | <zcorpan_> | Hixie: caniuse now uses whatwg urls for html stuff (but not workers/websockets i think) |
| 14:30 | <mathiasbynens> | holy shit, facebook.com disabled SSLv3 |
| 14:31 | mathiasbynens | wonders what their IE6 stats looked like until now |
| 14:48 | <annevk> | mathiasbynens: there's no indication they enable/disable SSLv3 conditionally? Or redirect IE6 users? |
| 14:53 | <cwilso> | wilhelm: Yes. We didn't want to zoom all sizes - because remember, most screens were 72-96dpi at the time - so resizing an image by 13% would be ugly (we also couldn't afford interpolation at the time). And once you set a font size in px, you were probably aligning it carefully with other elements on the page - also set in px. |
| 14:53 | <cwilso> | wilhelm: In retrospect, not the best choice. But even in 2004, during IE7, I had a serious argument about how zooming should work with the developer. |
| 14:55 | <wilhelm> | cwilso: This is very interesting. What were the positions in the argument? |
| 15:06 | <mathiasbynens> | annevk: how would you disable SSLv3 conditionally? I’m testing this with a raw `nmap` command |
| 15:07 | <mathiasbynens> | annevk: also tested in IE6 and all you get is an IE error page |
| 15:12 | <wilhelm> | mathiasbynens: I'm hoping TLS will be the last nail in the coffin for the most ancient browsers. We recently blocked out all users of IE on XP on a major project. In my own locale, the last holdouts are the hospitals. |
| 15:14 | <wilhelm> | MikeSmith: Which reminds me, validator.w3.org doesn't like our TLS version either. validator.nu seems fine. |
| 15:14 | <wilhelm> | MikeSmith: http://validator.w3.org/check?uri=https%3A%2F%2Fsnl.no |
| 15:27 | <Domenic> | zcorpan: nice on the caniuse |
| 15:33 | <annevk> | mathiasbynens: not sure, depends on what's in the TLS handshake I guess, haven't really looked into that |
| 15:45 | <MikeSmith> | wilhelm: use http://validator.w3.org/nu/ instead of http://validator.w3.org/ |
| 16:05 | <cwilso> | wilhelm: Essentially, I was arguing zooming should work like it does today in Chrome - it zooms all sizes, but the viewport's apparent size decreases. |
| 16:06 | <cwilso> | wilhelm: the developer was arguing for a "layout zoom" - where you keep the layout static, and you always get scrollbars. |
| 16:08 | <wilhelm> | cwilso: Yes, indeed. Coupled with some good media queries, I believe that gives the optimal experience today. |
| 16:11 | <wilhelm> | Works the same way in IE11 now, at least. |
| 16:12 | <wilhelm> | cwilso: Was the new (IE7) zoom thought of as a replacement of the old text size controls, or something in addition to them? |
| 16:13 | <cwilso> | wilhelm: yeah, I eventually won the argument (in IE8, maybe). It was originally in addition to them. We finally got rid of the size changes, I think. |
| 16:16 | <wilhelm> | cwilso: Thanks again for your answers! I'm trying to understand the history of font sizes in browsers, and this has been very helpful. |
| 16:17 | <cwilso> | wilhem: np. |
| 16:40 | <Hixie> | zcorpan: so that ;e4x=1 doesn't get run |
| 16:40 | <Hixie> | zcorpan: neat, did you send them a patch? |
| 16:40 | <zcorpan> | Hixie: yes |
| 16:41 | <Hixie> | neat |
| 16:48 | <zcorpan> | Hixie: unknown params get run for http content-type anyway. and gecko that does something with params and has supported e4x ignores params in script type |
| 16:49 | <Hixie> | <script> ignores http content-type entirely |
| 16:50 | <Hixie> | anyway, if you have a test showing the spec is buggy, file a bug :-) |
| 16:51 | <annevk> | <script> doesn't ignore with the header that enforces MIME types |
| 16:51 | <annevk> | that header is gaining traction |
| 16:51 | <annevk> | unfortunately named as it is |
| 16:52 | <Hixie> | oh well i don't spec that at all, so... |
| 16:52 | <Hixie> | (nobody's been able to explain to me what it does) |
| 16:56 | <annevk> | https://mimesniff.spec.whatwg.org/ makes an attempt |
| 16:57 | <annevk> | not sure if accurate |
| 16:58 | <Ms2ger> | I wonder if WorkerGlobalScope.clearInterval's argument needs to be optional |
| 16:58 | <zcorpan> | Hixie: this area is inconsistent in browsers and I'd like to make it more consistent. i haven't found anything that parses params but doesn't ignore unknown params |
| 17:00 | <annevk> | zcorpan: can't we move to an enum for <script type>? |
| 17:00 | <annevk> | in fact, I thought it was an enum |
| 17:01 | <annevk> | Oh god, I should stop running ssllabs.com on banks |
| 17:01 | <annevk> | That's just depressing |
| 17:01 | <Domenic> | hahaha |
| 17:32 | <Hixie> | zcorpan: yeah. we should probably rework that anyway to add type=module or whatever ends up happening for ES6 |
| 17:32 | <Hixie> | though now that modules are out of ES6 (?) i'm not sure what the state of that is |
| 17:34 | <annevk> | Domenic: you could var ex = new DOMException; ex.name = ...; throw ex |
| 17:34 | <annevk> | Hixie: modules are in, loader is out, I think |
| 17:34 | <Hixie> | what's a module without a loader? |
| 17:35 | <annevk> | I just read the summary of changes, haven't actually looked in detail |
| 17:37 | <zcorpan> | annevk: what about canPlayType? |
| 17:38 | <annevk> | zcorpan: I don't think all "MIME type" situations need identical solutions |
| 17:39 | <annevk> | zcorpan: that is, either full MIME type parse, or enum, is my current thinking, with a slight preference to the latter whenever possible |
| 17:39 | <zcorpan> | annevk: don't disagree |
| 17:39 | <annevk> | https://mimesniff.spec.whatwg.org/ is making an attempt at specifying full MIME type parse, but have not reviewed it |
| 18:01 | <Domenic> | annevk: nope, .name is a getter |
| 18:27 | <Hixie> | good news everyone! |
| 18:27 | <Hixie> | HTML5 is done. |
| 18:27 | <Hixie> | http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ |
| 18:27 | <Hixie> | guess i can mark the 223 open bugs as WORKSFORME |
| 18:27 | <Hixie> | and i guess i should revert all the changes i made in the last few months that the w3c hasn't picked up yet |
| 18:28 | <Sample> | sweet. it's HTML6 from here on out |
| 18:28 | <Sample> | =P |
| 18:29 | <boogyman> | now, lets just get the marketers to stop using the reference |
| 18:30 | <Domenic> | if a spec has a version number you know it's not serious |
| 18:31 | <terinjokes> | Domenic: this is why the Sticker Constructor Spec has a draft number: https://github.com/terinjokes/StickerConstructorSpec/releases/tag/draft-0 ;) |
| 18:36 | <wilhelm> | Hixie: Congratulations! How did you manage to finish it 8 years ahead of schedule? |
| 18:47 | <Sample> | "My starting point for this discussion is that, now that HTML5 is done ..." that is quite the statement |
| 18:52 | <annevk> | Hixie: BufferSource is defined in IDL |
| 18:52 | <Domenic> | ... or do you mean SourceBuffer ... |
| 19:18 | <Domenic> | I still want some kind of fuzzy-matching search within multipage html |
| 19:37 | <MikeSmith> | 4:24am JST |
| 20:37 | <boogyman> | darobin: stylesheets intended for print media would use pt. |
| 20:38 | <terinjokes> | are psuedo elements at the root and on * the same? |
| 20:48 | <gsnedders> | hsivonen, MikeSmith: what does a parser need API-wise to be used as a the basis of a conformance checker? |
| 20:48 | <Ms2ger> | boogyman, ha. haha. |
| 20:48 | <boogyman> | ? |
| 20:48 | <gsnedders> | BTW, what's the typical viewing distance of printed media? |
| 20:49 | <gsnedders> | boogyman: you do know how pt is defined in CSS? |
| 20:49 | <boogyman> | I'm sure I did at one point. |
| 20:50 | <gsnedders> | Oh, apparently it does allow the physical units to match up with physical measurements still |
| 20:50 | <gsnedders> | and recommends that for print and other high-resolution devices |
| 21:01 | <TabAtkins> | terinjokes: No. Pseudo-elements on root are, well, pseudo-elements on root. On *, they're on all elements. |
| 21:01 | <TabAtkins> | Did you mean the difference between `::before` and `*::before`? Those are indeed the same. |
| 21:02 | <TabAtkins> | boogyman: pt and px have a fixed ratio, so it doesn't matter what you use. |
| 21:05 | <MikeSmith> | gsnedders: a conformance checker basically just needs the parser to, well, expose the parsed document |
| 21:06 | <MikeSmith> | gsnedders: beyond that, for use with a conformance checker, it should be an error-reporting parser that does actually report anything that the spec defines as a "parse error" |
| 21:07 | <MikeSmith> | gsnedders: as Henri's parser does |
| 21:08 | <MikeSmith> | gsnedders: as far as the nature of the API, it doesn't matter what kind of API it is except it ideally should be a streaming API that doesn't require constructing a representation of the entire document and keeping it in memory |
| 21:10 | <MikeSmith> | gsnedders: e.g., a SAX API, as the vnu code uses |
| 21:12 | <MikeSmith> | gsnedders: so, concretely, if you're working on implementing a document parser I recommend you have it provide a SAX API or some whatever other kind of API that exposes the actual parse events/tokens |
| 21:24 | <terinjokes> | TabAtkins: that's what I meant, yes |
| 21:42 | <Hixie> | say i have changes to lots of files in my local copy of some remote git repo |
| 21:42 | <Hixie> | i want to do the equivalent of "svn up; svn commit foo.txt" |
| 21:42 | <Hixie> | am i right that there's just no way to do this anywhere near as easily in git? |
| 21:43 | <terinjokes> | Hixie: best I can think of is using git-stash |
| 21:43 | <wilhelm> | Unless you have conflicts: git pull; git commit foo.txt |
| 21:43 | <wilhelm> | If you expect conflicts, yes, git stash. Then you can resolve those later. |
| 21:44 | <Hixie> | stash won't work as far as i can tell because i've already commited all the changes locally |
| 21:44 | <TabAtkins> | Oh, then just pull and rebase. |
| 21:44 | <TabAtkins> | git pull --rebase |
| 21:44 | <Hixie> | it's the push part i'm having trouble with |
| 21:44 | <TabAtkins> | That pulls in all the foreign history, and moves your commits to *after* all the foreign commits. |
| 21:45 | <TabAtkins> | Then you can push, because your repo will then be consistent and mergeable. |
| 21:45 | <Hixie> | if i push then i'll push all the changes |
| 21:45 | <Hixie> | i only want to push the changes to foo.txt |
| 21:46 | <TabAtkins> | Oh! Never done that before. |
| 21:46 | <TabAtkins> | Pretty sure that's a lot more complex, because your history is a bunch of changes to all the files. |
| 21:46 | <TabAtkins> | You'd need to do some history rewriting, I think. |
| 21:46 | <Hixie> | i hate git so much |
| 21:46 | <TabAtkins> | Stop trying to use subversion in git? |
| 21:46 | <jgraham> | What? If you committed all the changes why would you expect it to be easy to create a state that you didn't commit? |
| 21:47 | <Hixie> | it's trivial in subversion |
| 21:47 | <jgraham> | If that's true it seems fundamentally broken |
| 21:47 | <TabAtkins> | jgraham: subversion doesn't actually have local history, so there's nothing to rewrite. |
| 21:47 | <jgraham> | TabAtkins: Right, so the difference here is "I committed the changes" |
| 21:47 | <jgraham> | Which you can't do in subversion |
| 21:48 | <Hixie> | "broken" or "easy", whichever you prefer, the point is i can do it easily in subversion and not in git :-P |
| 21:48 | <TabAtkins> | Pushing to a remote repo is the moral equivalent of sending a bunch of patch files. |
| 21:48 | <TabAtkins> | Yeah. |
| 21:48 | <Hixie> | "svn up" is also easier in svn, since it doesn't require you to move your changes out of the way, it just updates you |
| 21:48 | <Hixie> | the only reason i would need to commit or stash in git is to be able to pull |
| 21:48 | <Hixie> | which is so weird |
| 21:48 | <jgraham> | That just isn't true |
| 21:48 | <wilhelm> | So in svn, you'd leave the uncommited files scattered about in this scenario? |
| 21:49 | <wilhelm> | What would happen with upstream changes to those files? |
| 21:49 | <Hixie> | they get merged in |
| 21:49 | <TabAtkins> | Hixie just got really used to subversions data model (or relative lack of it), and is still having a lot of trouble adapting to Git being more restrictive (and hasn't yet learned all the *good* things that come from that). |
| 21:49 | <wilhelm> | Now, _that_ is broken. :D |
| 21:49 | <jgraham> | Yeah, that sounds terrifying |
| 21:50 | <Hixie> | why is that terrifying |
| 21:50 | <Hixie> | it's perfect |
| 21:50 | <jgraham> | Modifying your local files under you without a commit to roll back to if things go wrong? |
| 21:50 | <wilhelm> | So that would put you in a completely unknown state you can't recover from? |
| 21:50 | <Hixie> | why would things go wrong |
| 21:50 | <wilhelm> | Because upstream changes were silly, and now they're in your file. |
| 21:51 | <jgraham> | Umm, because merges are complicated |
| 21:51 | <Hixie> | obviously if there's a conflict it won't merge them, just like with git if you rebase |
| 21:51 | <wilhelm> | Which you can't throw away, because you'd lose your work. |
| 21:51 | <TabAtkins> | From what I can tell, Hixie, your preferred model can be (terribly) grafted to Git if you just never commit, and always stash before pulling (and stash pop after). |
| 21:51 | <TabAtkins> | And then only commit individual files immediately before you want to push them. |
| 21:51 | <Hixie> | yeah seems that way |
| 21:51 | <jgraham> | Yeah you can do that |
| 21:52 | <jgraham> | But it will make children cry |
| 21:52 | <wilhelm> | Yes. Sounds very wrong. But doable. |
| 21:52 | <TabAtkins> | It should be obvious why this is terrible to those who use Git properly. ^_^ |
| 21:52 | <Hixie> | in any case... |
| 21:53 | <Hixie> | if i have three commits that are entirely unrelated |
| 21:53 | <Hixie> | and i want to commit a specific one |
| 21:53 | <Hixie> | how do i bring that specific one to the point where i can commit it? |
| 21:53 | <Hixie> | git rebase something? |
| 21:53 | <TabAtkins> | Go back to the last master commit. Branch. Cherry-pick the one commit you want. |
| 21:53 | <wilhelm> | You want to _push_ a specific one? All commits are commits. There is no difference between your local repo and the remote. |
| 21:53 | <TabAtkins> | Then push that branch. |
| 21:53 | <Hixie> | wilhelm: er right, push, not commit |
| 21:53 | <jgraham> | Yeah, I'm with wilhelm; your requirements don't make sense as written |
| 21:53 | <jgraham> | Ok |
| 21:54 | <Hixie> | "commit" is the word sensible people use for what you kids call "push" |
| 21:54 | <TabAtkins> | You push history in git, not commits |
| 21:54 | <wilhelm> | Old people these days! |
| 21:54 | <Hixie> | "save" is the word for locally commiting |
| 21:54 | <Hixie> | :-P |
| 21:54 | <wilhelm> | So. Broken. |
| 21:54 | <TabAtkins> | Nah, just translation difficulties. |
| 21:55 | <Hixie> | i can't believe i have to create a branch just to push a damn file |
| 21:55 | <Hixie> | that's so absurd |
| 21:55 | <TabAtkins> | Hixie learned Subperanto as a child, the rest of us are native Gitish speakers. |
| 21:55 | <wilhelm> | Taking a step back, why do you need to cherrypick like this? |
| 21:55 | <wilhelm> | What's the use case? :P |
| 21:55 | <MikeSmith> | Hixie: branches are super-cheap in git |
| 21:55 | <TabAtkins> | Hixie: Again, you're chafing under the different data model, and suffering from a bad case of Blub Syndrome. |
| 21:55 | <Hixie> | MikeSmith: branches are super expensive cognitively for me |
| 21:56 | <MikeSmith> | Hixie: branches are the normal idiomatic best-practice way everybody does work in git |
| 21:56 | <TabAtkins> | Branch is just a pointer in git. ^_^ |
| 21:56 | <Hixie> | MikeSmith: since now i have to keep track of the working copy state, the commited state in each branch, and the remote state |
| 21:56 | <TabAtkins> | It's a pointer to some particular commit in the tree. |
| 21:56 | <Hixie> | MikeSmith: instead of just the local state and the remote state, as in svn |
| 21:56 | <TabAtkins> | If you commit regularly like you should in Git, you don't keep track of working copy state. |
| 21:56 | <TabAtkins> | You commit before switching. |
| 21:56 | <sgalineau> | trying to use one source control system as if it were another guarantees some form of a bad time |
| 21:56 | <Hixie> | wilhelm: i have some changes i need to make locally to use the code, but i want to contribute a patch that is unrelated to those changes |
| 21:56 | <wilhelm> | No. The state is apparent from your commits. So every time you "save", that state has a name. |
| 21:57 | <MikeSmith> | Hixie: that might be because you're cognitively/concpetually thinking of branches in the svn/cvs conceptual model |
| 21:57 | <TabAtkins> | Hixie: Oh, for that, you probably just want to branch from the last foreign commit, and then manually copy your changes over. |
| 21:57 | <MikeSmith> | Hixie: ah yeah still I get your point yeah |
| 21:57 | <TabAtkins> | Then commit and push those changes. |
| 21:58 | <TabAtkins> | After it's accepted, you can kill the branch and rebase your main branch on it. |
| 21:58 | <MikeSmith> | Hixie: one thing is, your workflow works really well if you're not collaborating with anybody else. but it seems like it falls apart completely the minute you add one other collaborator |
| 21:59 | <wilhelm> | Either that, or those files shouldn't be in version control like that. That problem arises every time someone puts a configuration file with actual configuration in it into version control, at least. |
| 21:59 | wilhelm | has purged database passwords from repos a few times too many. |
| 21:59 | <Hixie> | wilhelm: these are local patches i need to make because i'm porting the code to a platform the upstream code isn't intended for |
| 22:00 | <wilhelm> | Oh. |
| 22:00 | <Hixie> | wilhelm: but meanwhile i want to contribute a fix to some of the code that isn't platform-specific |
| 22:00 | <MikeSmith> | anyway I fully agree that git is not winning any beauty contests as a far as being easy to use, or at least easy to learn |
| 22:00 | <Hixie> | in svn, i can do this easily with literally just "svn commit <filename>" |
| 22:01 | <Hixie> | it doesn't seem unreasonable to me |
| 22:01 | <Hixie> | nor like something that should fail to work with multiple people |
| 22:01 | <TabAtkins> | That's definitely "branch and do your patch there, so it doesn't interact with your main history". |
| 22:02 | <wilhelm> | It comes with the unreasonable part that your repo will be littered with random changes of varying origins. :D |
| 22:02 | <MikeSmith> | Hixie: you could do that just by working through a UI that immediately makes all your commits in the repo you want to push to |
| 22:02 | <MikeSmith> | Hixie: e.g., the github Web UI |
| 22:03 | <MikeSmith> | then you're never actually making changes locally, you'd just pull them when you need to build locally or whatever |
| 22:04 | <jgraham> | Hixie: There is no such thing as a "local patch". There are commits on local branches, commits on remote branches, branches that have been merged to master, and branches that have not. But it's all commits |
| 22:04 | <Hixie> | jgraham: so many things to keep track of |
| 22:04 | <jgraham> | Hixie: No, there's just commits |
| 22:04 | <wilhelm> | Yes. Changes == commits, with a name and date. |
| 22:05 | <jgraham> | Instead of commits + random context-free patch files |
| 22:05 | <TabAtkins> | jgraham: Well, you can produce patch files, but their only use is to email to someone else so they can apply it locally and commit it themselves. |
| 22:06 | <Hixie> | i'm saying "A,B is simpler than A,B,C,D,E", and you're saying "A,B,C,D,E is simple enough" |
| 22:06 | <jgraham> | Yeah, but the point is that git enables repository-centric development, whereas svn prevents it |
| 22:06 | <jgraham> | Hixie: No |
| 22:07 | <TabAtkins> | Hixie: Sure, but it's only simpler because you're working with a weaker model. You're chafing against a stronger model without yet understanding the *benefits* of the stronger model. |
| 22:07 | <jgraham> | I don't think it's actually more complicated |
| 22:07 | <TabAtkins> | jgraham: Well, SVN's data model, at it's core, can be seen as a degenerate form of git's data model. |
| 22:08 | <TabAtkins> | Once you build over that model, both become complicated in non-subset/superset ways, but still. |
| 22:08 | <jgraham> | I think you are neglecting the hidden complexity of svn not supporting many workflows, so having to hack around then with things like patch files |
| 22:08 | <roc> | it is more complicated once you start dealing with the index/stash/cache :-) |
| 22:08 | <wilhelm> | Change always involves some friction, even between equivalent complexity. |
| 22:08 | <roc> | and local tracking of remote branches |
| 22:08 | <jgraham> | roc: The staging area is one of several things that git gets right and hg gets wrong |
| 22:08 | <TabAtkins> | YES |
| 22:09 | <roc> | no |
| 22:09 | <sgalineau> | lol |
| 22:09 | <Ms2ger> | no |
| 22:09 | <jgraham> | Making it explicit and avaliable for all opereations is so much better than having it work magically for add and delete but not being allowed to edit it |
| 22:09 | <TabAtkins> | Sigh, mozillians. |
| 22:09 | sgalineau | had no idea IRC source control chatter could be popcorn-worthy |
| 22:09 | <jgraham> | Hence mq |
| 22:09 | <roc> | The staging area can be useful, but git forces you to learn it before you can do anything, which is wrong. |
| 22:10 | <Hixie> | jgraham: i think you are neglecting the hidden complexity of supporting many workflows |
| 22:10 | <sgalineau> | roc: really? I never used it but use git every day |
| 22:10 | <TabAtkins> | Ehhh, you can go a long while just using `git commit -am` (and remember `git add .` when you add new files) and not care about the staging area. |
| 22:10 | <roc> | sgalineau: so you never use "git add" and just use "git commit -a" all the time? |
| 22:10 | <jgraham> | roc: Less wrong than having "hg commit" just commit any random changes in your working directory |
| 22:10 | <TabAtkins> | I *mostly* use -a. |
| 22:10 | <sgalineau> | roc: f, i somehow thought you were talking about stashing. NEVER MIND. |
| 22:11 | <Hixie> | "random" changes? |
| 22:11 | jgraham | always uses -p except in certian well-defined circumstances |
| 22:11 | <sgalineau> | roc: but otherwise, mostly use -a yes |
| 22:11 | <TabAtkins> | jgraham: I mostly work in self-contained units, so I dont' need to partial-add very often. ^_^ |
| 22:12 | <Hixie> | (btw it doesn't help that the git documentation is worthless) |
| 22:12 | <jgraham> | TabAtkins: I do it to be sure I did in fact work in a self-contained unit and to increase the chance that I'll remember something that's missing by reading the patch again |
| 22:12 | <wilhelm> | So it's you guys who keep commiting .DS_Store files? :P |
| 22:12 | <jgraham> | Hixie: The git documentation is great. It just helps if you already understand git before reading it ;) |
| 22:12 | <roc> | TabAtkins: if you're not comfortable blindly adding files with "git add ." (which you probably aren't if you're new to git), then you have to know about the staging area. |
| 22:13 | <roc> | because you do "git add foo.c" and then you wonder why "git diff" doesn't show you that file. |
| 22:13 | <TabAtkins> | jgraham: Ah, I just diff if I'm not sure, but whatever works for you. |
| 22:13 | Ms2ger | still randomly forgets to commit or add stuff |
| 22:13 | <sgalineau> | which doc are we talking about? I thought http://git-scm.com/doc was useful |
| 22:13 | <TabAtkins> | https://marklodato.github.io/visual-git-guide/index-en.html is still a great doc too. |
| 22:14 | <Hixie> | how do you refer to "the last thing i checked out from the upstream repo" in git? |
| 22:14 | <sgalineau> | yes. Git Immersion was decent as well |
| 22:14 | <Hixie> | assuming HEAD refers to "the last thing i commited locally" |
| 22:14 | <Ms2ger> | origin/master? |
| 22:14 | <jgraham> | Hixie: origin/master, typically. or @{u} |
| 22:14 | <jgraham> | @{u} is the upstream of the current branch |
| 22:14 | <TabAtkins> | (Assuming that the upstream branch is called "master" as well, which it usually is.) |
| 22:15 | <Hixie> | thanks |
| 22:15 | <Hixie> | you'd think this would be documented somewhere on git-checkout got git-branch |
| 22:15 | <roc> | the git man pages are terrible |
| 22:15 | <jgraham> | (fun quiz question: how do you do the same in mercurial) |
| 22:15 | <wilhelm> | Hixie: To me, it sounds like you're still thinking "commits are expensive, and a big deal", and that's where a non-trivial part of the friction comes from. |
| 22:15 | <roc> | but that's partly because the git command-line syntax they're documenting is terrible |
| 22:16 | jgraham | is rather sure that the terribleness of the git command line syntax is something that "everyone knows" rather than something that's actually true |
| 22:16 | <Hixie> | wilhelm: i'm not thinking anything is expensive except having to type commands |
| 22:17 | <roc> | e.g. variously using the terms "index", "stash", "staging area" and "cache" to refer to the same thing |
| 22:17 | <Hixie> | wilhelm: if it takes me 10 minutes per command i have to type in, one command is cheaper than 4 commands is cheaper than 12 commands. |
| 22:17 | <TabAtkins> | Anything to do with rev-parse is pretty terrible. |
| 22:18 | <jgraham> | Yeah, rev-parse is obviously half-finished |
| 22:18 | <TabAtkins> | My 99% command set is `git pull --rebase`, `git push`, `git stash`, `git stash pop`, `git commit -am "foo"`, `git add -p file.txt` |
| 22:18 | <Domenic> | also lots of branching |
| 22:19 | <wilhelm> | I rarely do anything sufficiently complicated to notice the so-called horrible command-line UI of git. |
| 22:19 | <TabAtkins> | I don't branch as often as I should, but yeah. |
| 22:19 | <roc> | TabAtkins: no "git rebase -i"? |
| 22:19 | <sgalineau> | TabAtkins: no git checkout/git merge? |
| 22:19 | <TabAtkins> | roc: I rarely have to go interactive. |
| 22:19 | <roc> | no "git add remote ..."? |
| 22:19 | <roc> | no |
| 22:19 | <TabAtkins> | sgalineau: rebasing > merging. I don't branch very often. |
| 22:19 | <Domenic> | ff merges only |
| 22:19 | <roc> | "git branch -D all_the_stupid_local_branches_I_have_to_create_to_merge_stuff_in_github"? |
| 22:19 | <TabAtkins> | roc: Handled by git cloning automatically. I've had to do that before, but only by copy/pasting from tutorials. |
| 22:20 | <wilhelm> | roc: Rarely any of the above. |
| 22:20 | <sgalineau> | 10 people in a room, 14 ways to use git |
| 22:20 | <TabAtkins> | Most of my git work is on repos where I push straight to master. ^_^ When I do work on PR-based repos, I branch more. |
| 22:21 | <wilhelm> | My repos have half a dozen people in them, the biggest one apparently with 57 feature branches. Perhaps it's time for a spring cleaning. |
| 22:21 | <sgalineau> | TabAtkins: I always branch for a bug fix since it might not be done by the time i need to go back to the main branch |
| 22:21 | <sgalineau> | for instance |
| 22:21 | <TabAtkins> | sgalineau: Yeah, that's what I should do more. |
| 22:22 | <TabAtkins> | I get bitten every once in a while due to not doing that, and then having to branch and mess with history after. |
| 22:23 | <roc> | that reminds of a classic piece of absurd git syntax: "git checkout -b foo" to create a branch. Because using "git branch" to create a branch containing your current changes would be too obvious. |
| 22:24 | <sgalineau> | roc: +1 I still type git branch foo half the time |
| 22:25 | <roc> | I was sort of hoping that my initial dislike of git would dissipate once I learned it properly. I was wrong. |
| 22:25 | <Hixie> | http://damowmow.com/playground/git-notes |
| 22:25 | <Hixie> | svn commit foo.txt seems to be equivalent to 7 lines of git commands |
| 22:26 | <sgalineau> | that's what svn commit does? |
| 22:26 | <Hixie> | as far as i can tell, in git terms, yes. |
| 22:26 | <Hixie> | in svn terms, it just commits your changes to that file to the repo |
| 22:27 | <sgalineau> | afaik git commit takes a file name as argument. now confused. |
| 22:28 | <roc> | Hixie: I think you can replace those lines with "git add foo.txt # add foo.txt changes to the index" "git commit -m <msg>" "git push" |
| 22:28 | <jgraham> | I… can't tell what kind of confused workflow you have to be using to end up with that mess of commands |
| 22:28 | <Hixie> | sgalineau: "git commit" doesn't have an equivalent in svn, since svn doesn't have a local repo. |
| 22:28 | <wilhelm> | You forget the part where you accidently nuke your uncommited changes in your svn repo. |
| 22:28 | <sgalineau> | Hixie: ah, yes, duh |
| 22:29 | <sgalineau> | Hixie: still, roc's alternative sounds like what I'd expect |
| 22:29 | <jgraham> | roc: So¸ as best I can tell the problem is that Hixie has already committed the changes and now wants to undo those commits and push some different commits to upstream |
| 22:29 | <sgalineau> | Hixie: I don't get why it needs to create the foo branch and ditch it |
| 22:29 | <jgraham> | I don't know *why* he thinks he wants to do this |
| 22:29 | <MikeSmith> | jgraham: I know I'm preaching to the choir but mq is just such a horrible hack, and so painful to use. It makes any of the git hassles in comparison look like .. not hassles. I say that after having used it by choice for some significant time. And yeah it's not a required thing but it seems to be worflow you inevitably end up with in practice in a lot of mercurial scenarios. |
| 22:30 | <Hixie> | roc: that assumes your branch doesn't have other changes on it |
| 22:30 | <roc> | Hixie: no it doesn't. |
| 22:30 | <Hixie> | jgraham: i explained why earlier. |
| 22:30 | <sgalineau> | Hixie: those changes aren't lost... |
| 22:30 | <MikeSmith> | anyway, I'm trying to decide whether in this conversation to give more of my votes to Hixie's "why would things go wrong" or sgalineau "had no idea IRC source control chatter could be popcorn-worthy" |
| 22:30 | <TabAtkins> | roc: You *do* create a branch with `git branch`. But `git checkout` is how you *switch* branches. |
| 22:30 | <Hixie> | roc: then i don't understand it |
| 22:31 | <roc> | Hixie: it assumes you haven't already done a "git commit". |
| 22:31 | <sgalineau> | sounds like that's the problem |
| 22:31 | <roc> | basically when you map svn into git, you would only ever do a "git commit" just before a "git push" |
| 22:31 | <wilhelm> | This conversation feels a lot like RDMBS<->NoSQL arguments. One side ensures predictable, consistent data. The other is "easier". |
| 22:31 | <Hixie> | roc: what's the difference between "that assumes your branch doesn't have other changes on it" and "that assumes you haven't already done a "git commit"" ? |
| 22:31 | <TabAtkins> | Hixie: If you're *actually* using git as svg (no local commits), then `svn commit foo.txt` is just `git add foo.txt; git commit; git push` |
| 22:31 | <roc> | right |
| 22:31 | <Hixie> | i'm not trying to use git as svn |
| 22:32 | <Hixie> | i'm trying to use git as git, as everyone always says i should |
| 22:32 | <Hixie> | :-) |
| 22:32 | <TabAtkins> | You're doing *half* SVN, in which case your request doesn't make a lot of sense within the data model. |
| 22:32 | <roc> | yeah |
| 22:32 | sgalineau | shudders at half SVN |
| 22:32 | <roc> | you can't use git like svn half the time and some other way half the time, in the same repo. |
| 22:32 | <Hixie> | (is there some way to figure out what remote branch git push will use by default?) |
| 22:32 | <TabAtkins> | But you can do it by copying the file into a buffer, branching from origin/master, pasting the buffer contents into the file you want, then commiting it and pushing. |
| 22:32 | <Hixie> | roc: i'm not trying to |
| 22:34 | <MikeSmith> | Hixie: "git remote" with no args I think |
| 22:34 | <Hixie> | wtf. I'm in dir a/b/c and I do "git diff origin/master" and it tells me that I have a change in d/e/f. I cd d, do the same thing, no changes. |
| 22:34 | <Hixie> | MikeSmith: that just says "origin" |
| 22:34 | <Hixie> | which i don't think is a branch? |
| 22:34 | <TabAtkins> | Saying "I want to push a file" is indeed using half SVN. "files" aren't meaningful units in the git data model. |
| 22:35 | <Hixie> | TabAtkins: that's not half-svn. it's half-filesystem maybe. |
| 22:35 | <TabAtkins> | Which svn is closer too, yes. |
| 22:35 | <Hixie> | TabAtkins: the reality is i have one file with changes in it and i need to commit it. |
| 22:35 | <Hixie> | TabAtkins: that's just the situation, it's not an attempt to fit it to any model. |
| 22:35 | <TabAtkins> | And the answer that we've continually told you is "branch and put the changes there". |
| 22:36 | <Hixie> | right, which is seven commands |
| 22:36 | <Hixie> | instead of hte one in svn |
| 22:36 | <Hixie> | that's all i'm saying :-) |
| 22:36 | <Ms2ger> | The branch-commit-merge model doesn't make much sense if you're the only one editing |
| 22:36 | <roc> | TabAtkins: I pretty much always use "git checkout" to create branches, because it handles the two cases I care about and "git branch" doesn't. Namely: "create and switch to a branch where I can commit the changes I have already made to the working area" and "make a local branch tracking this remote branch and check it out so I can rebase and test it before merging" |
| 22:36 | <jgraham> | Finding out the upstream of the current branch is slightly hard. git remote -v does it, or git rev-parse --abbrev-ref @{u} |
| 22:36 | <MikeSmith> | Hixie: no I was wrong. I tried adnd I see "git remote" shows a list of all remotes |
| 22:37 | <jgraham> | s/remote/branch/ |
| 22:37 | <MikeSmith> | yeah |
| 22:37 | <Domenic> | FWIW I really find having a visual and manipulable representation of the tree to help me. E.g. https://www.dropbox.com/s/yxo8syn97lcvani/Streams%20git.png?dl=0 |
| 22:37 | <TabAtkins> | roc: Right, you usually want to combine branch creation and checkout. No disagreement ehre. |
| 22:37 | <jgraham> | s/-v/-vv/ |
| 22:37 | <Hixie> | -v and -vv don't give me a branch name as far as i can tell |
| 22:37 | <TabAtkins> | Domenic: github provides a visual tree view. |
| 22:38 | <Hixie> | git rev-parse --abbrev-ref @{u} works |
| 22:38 | <jgraham> | Hixie: git branch -vv? |
| 22:38 | <Hixie> | oh, i missed that edit |
| 22:38 | <Domenic> | TabAtkins: sure but the whole point is to get a view of local vs. remote, and see the local tree evolve as you do things to it, before deciding what to push upstream |
| 22:38 | <Hixie> | jgraham: thanks |
| 22:38 | <TabAtkins> | Ah, kk. |
| 22:38 | <TabAtkins> | I guess you work with more complicated things than me. ^_^ |
| 22:38 | <roc> | "git checkout" makes sense for the latter case, since I am actually checking something out. "git checkout" for the first case never actually checks out anything, so it's stupid. |
| 22:39 | <TabAtkins> | roc: It checks out the new branch. I don't understand your confusion. |
| 22:39 | <roc> | it doesn't modify the working area. |
| 22:39 | <TabAtkins> | It so happens that the index is the same in the new and old branch, but your branch pointer is different (so your commits will hit a different area). |
| 22:40 | <TabAtkins> | Yeah? Working area changes are never affected by a checkout, unless the histories are different in the files that have been edited. |
| 22:41 | <TabAtkins> | (In which case it wants you to commit or stash or what-have-you, so you can the existing mechanisms to handle possible conflicts.) |
| 22:42 | <roc> | "git checkout -b foo" never modifies the working area, it just manipulates branches. It should therefore be a "git branch" command. |
| 22:43 | <TabAtkins> | roc: `git checkout` *never* messes with changes you've made in your working area. |
| 22:43 | <roc> | not true |
| 22:43 | <roc> | "git checkout foo.c" replaces the working area's copy of foo.c with the index copy |
| 22:44 | <TabAtkins> | Oh, sorry, yeah, a checkout of a *file* does that. A checkout of a branch doesn't. |
| 22:44 | <TabAtkins> | checkout is overloaded a bit. |
| 22:44 | <roc> | I think I win |
| 22:44 | Ms2ger | gives roc a medal |
| 22:44 | <TabAtkins> | ...no? Not unless you think `git checkout foo` (to a branch named foo) should *also* be changed to a `git branch` command. |
| 22:44 | <roc> | no |
| 22:44 | <TabAtkins> | Then I don't understand at all. |
| 22:45 | <roc> | "git checkout foo" modifies the working area; it leaves your changes intact but rebases them to branch "foo" |
| 22:45 | <TabAtkins> | Because `git checkout -b foo` is precisely `git branch foo; git checkout foo` |
| 22:45 | <TabAtkins> | Yes. |
| 22:45 | <TabAtkins> | And so does git checkout -b, it's just that the (non-modified) parts of the working areas are identical, because the new and old branch point to the same commit. |
| 22:47 | <roc> | I think "git branch foo" should check out the branch. It's hardly useful as is. |
| 22:47 | <TabAtkins> | Again, checkout -b is *solely* a concatentation of a branch and a checkout command, for convenience. Whether that belongs under the aegis of `branch` or `checkout` seems relatively arbitrary, but neither is "wrong", because it's *literally* those two commands. |
| 22:47 | <TabAtkins> | I wouldn't disagree there, to be honest. `checkout` has overloaded meanings, and branch creation is rare enough that needing a flag to say "create branch foo" would be fine. |
| 22:48 | <roc> | "git checkout" could just go away, or be reduced to the "check out a file" function. |
| 22:48 | <TabAtkins> | But then we're talking about moving syntax around, not judging an existing piece of syntax based on other existing syntax. ^_^ |
| 22:48 | <roc> | it's part of the overcomplexity of git. |
| 22:49 | <roc> | overloaded commands, and commands with the wrong names. |
| 22:49 | <roc> | a new git user wants to create a branch for some changes they've made; they read the "git branch" man page but that's not enough. It could be enough. |
| 22:50 | <TabAtkins> | All right, but that's the story of every successful technology, and I don't think anything is immune to getting things wrong in its history. |
| 22:50 | <Hixie> | i don't think git is old enough to use that excuse yet |
| 22:51 | <TabAtkins> | It's 9 years old! |
| 22:51 | <roc> | Mercurial is much better designed (as of now; until recently it lacked important features). |
| 22:52 | <jgraham> | It still lacks important features! |
| 22:52 | <jgraham> | (see my pop quiz above) |
| 22:52 | <Hixie> | 9 years old is not enough to be able to claim that basic suckage is just the result of being successful |
| 22:52 | <TabAtkins> | And I disagree about better designed, but I'd be willing to chalk that up to Blub for the sake of getting back to work. ^_^ |
| 22:52 | <roc> | I think because at the beginning they focused on making simple things simple whereas git jumped straight to the Linus use-cases which committed them to a lot of ill-thought-out syntax early. |
| 22:53 | <roc> | yeah |
| 22:53 | <TabAtkins> | Hixie: Any age is enough when you get a popularity blow-up. It crystallizes decisions that should really have more thought put into them. |
| 22:53 | <roc> | lunchtime |
| 22:54 | <TabAtkins> | Ahhhhh, the more features someone used of Bert's preprocessor, the more of a pain-in-the-ass it is to convert to Bikeshed. |
| 22:54 | <TabAtkins> | (I assume the same is true of Bikeshed to anything else, of course.) |
| 22:54 | <TabAtkins> | But nobody actually *used* Bert's features, except Bert and jdaggett. :( |
| 22:55 | <MikeSmith> | Hixie: in other news while it's on my mind, I want say, I think we lost the fight a long time ago on discouraging use of meta@http-equiv="X-UA-Compatible" and making it a conformance error. See, e.g., bootstrap docs saying, 'To be sure you're using the latest rendering mode for IE, we strongly recommend including [meta@http-equiv="X-UA-Compatible"]' and we've lost on making it a useful conformance error. And now the validator reporting it as such is ju |
| 22:56 | <MikeSmith> | Hixie: so should I file a bug or what |
| 22:57 | <Hixie> | MikeSmith: :-( |
| 22:57 | <MikeSmith> | yeah it sucks |
| 22:57 | <Hixie> | MikeSmith: so what are we saying, it should be part of the boilerplate like the doctype? |
| 22:57 | <gsnedders> | MikeSmith: a SAX API that throws a fatal parse error when it hits content that needs buffering? |
| 22:57 | <Hixie> | MikeSmith: what does IE do if you don't include it? |
| 22:57 | <wilhelm> | Hixie: On poorly configured systems the user may not have control over, go into IE8 mode and break everything. |
| 22:58 | <gsnedders> | Hixie: depends on configuration, whether the site is in the internet or intranet zone… |
| 22:58 | <gsnedders> | Hixie: by default internet zone is latest, intranet zone was originally IE7 mode but I think that's changed? |
| 22:58 | <wilhelm> | gsnedders: "Intranet" is fuzzy, in that case. |
| 22:58 | <Hixie> | jesus wept |
| 22:58 | <gsnedders> | I don't remember how Windows defines "Intranet"! |
| 22:59 | <gsnedders> | I'm just using the term it does! :P |
| 22:59 | <MikeSmith> | Hixie: not sure what IE does but in practice all the boilerplate from boostrap etc include it, and best-practice/how-to guides all say to include it. So I guess that means we're really stuck with it now |
| 22:59 | <Hixie> | fantastic |
| 22:59 | <Hixie> | yeah, file a bug |
| 22:59 | <Hixie> | i guess we require it? :-P |
| 22:59 | <Hixie> | with IE=edge ? |
| 22:59 | <MikeSmith> | Hixie: meta viewport is another we're stuck with but at least that's valid now |
| 23:00 | <Hixie> | we should clearly require that one too, with width=device-width or whatever it is |
| 23:00 | <MikeSmith> | Hixie: yeah |
| 23:00 | <MikeSmith> | anyway I'll file a bug |
| 23:00 | <MikeSmith> | and lord have mercy on me |
| 23:01 | <wilhelm> | gsnedders: I removed that line from a publicly available customer site recently. Worked fine everywhere I tested. Bam, it broke on all their internal machines in some horrible Citrix environment. |
| 23:01 | <MikeSmith> | gsnedders: yes, a SAX API that throws a fatal parse error when it hits content that needs buffering? |
| 23:01 | <MikeSmith> | 07:57 Hixie: MikeSmith: what does IE do if you don't include it? |
| 23:01 | <MikeSmith> | oofs |
| 23:01 | <gsnedders> | wilhelm: that's why you shouldn't have customers |
| 23:02 | <gsnedders> | wilhelm: (on the other hand I like income) |
| 23:02 | <wilhelm> | But.. they pay our salaries. |
| 23:02 | <MikeSmith> | gsnedders: ideally with an option for buffered non-streaming parsing for those that want to opt-in to that |
| 23:02 | <gsnedders> | MikeSmith: people are starting to more seriously try and build on top of html5lib |
| 23:03 | <MikeSmith> | gsnedders: and to be clear, not a fatal parse error for the document, but just fatal for that part of the tree |
| 23:03 | <gsnedders> | MikeSmith: that sounds horrible to implement :( |
| 23:03 | <MikeSmith> | gsnedders: If you know what I mean. That's how Henri's parser handles it |
| 23:03 | <MikeSmith> | gsnedders: well, Henri did it. So we have an existence proof |
| 23:04 | <gsnedders> | MikeSmith: is that even a conforming option per spec? I thought the options were stop parsing or continue per spec? |
| 23:04 | <MikeSmith> | dunno |
| 23:04 | <gsnedders> | MikeSmith: well, I'm not questioning plausiblity, just niceness :) |
| 23:04 | <gsnedders> | MikeSmith: what makes a streaming parser better, though? ability to cope with larger docs? |
| 23:05 | <MikeSmith> | gsnedders: at least for henri's implementation it emits a messaging saying basically "I'm giving up on checking this part of the tree. [There may be errors in it but I'm not able to report them because that would require non-streaming parsing, which I'm not set to do right now.]" |
| 23:06 | <MikeSmith> | gsnedders: performance |
| 23:06 | <MikeSmith> | and the ability to hook it into a pipeline and check things in parallel |
| 23:07 | <gsnedders> | MikeSmith: which are the non-streaming cases? AAA, foster parenting? AAA seems to be hard to mark the right part of the tree, off-hand |
| 23:07 | <MikeSmith> | can run multiple checks in parallel fed from the same parse events |
| 23:07 | <MikeSmith> | gsnedders: yeah AAA and foster parenting |
| 23:08 | <MikeSmith> | gsnedders: and I don't know how Henri handled it but I think it does mark the right part of the tree |
| 23:08 | <gsnedders> | MikeSmith: It's Henri's code, I don't doubt it does. :) |
| 23:09 | <MikeSmith> | heh |
| 23:10 | <MikeSmith> | anyway, the model of being able to use multiple SAX contenthandlers in parallel is really powerful for implementing a checker, and just makes a lot of things much easier/doable |
| 23:11 | <gsnedders> | well you should always be able to implement something that multiplies events |
| 23:11 | <gsnedders> | given a normal singular SAX handler |
| 23:12 | <MikeSmith> | yeah I just mean the benefit of SAX, of exposing a SAX API |
| 23:13 | <MikeSmith> | but more generally exposing any kind of parse-event API at all is a win for this kind of use case (checkers) |
| 23:14 | <MikeSmith> | and in practice, "exposing any kind of parse-event API" pretty much just means SAX |
| 23:15 | <MikeSmith> | *means just use SAX, because it's sane and nobody has come up with anything that's radically better |
| 23:58 | <johan16> | hoi |
