| 00:53 | <aho> | TabAtkins_, plain text data region? |
| 00:53 | <aho> | that xmp thing? |
| 01:49 | <koalayumyum> | Anyone here used the html5 boilerplate? |
| 01:50 | <paul_irish> | i have. |
| 01:50 | <koalayumyum> | ah ha =] |
| 01:50 | <paul_irish> | ;) |
| 01:51 | <koalayumyum> | I'm havin an issue with the .ir class on a site I'm working on...perhaps I'm not implementing it correctly...would you mind taking a look? |
| 01:51 | <paul_irish> | sure. come over to #html5 and we can dig into it there |
| 01:52 | <koalayumyum> | ok, thanks |
| 03:21 | <Sonja> | can most browsers handle something like <img src="foo.svg" height="36" width="234"> nowadays? or must i still resort to a png that doesn't gracefully react to Ctrl-plus and Ctrl-minus |
| 03:23 | <m0> | Nice -hyphenate-limit-{before,after} is now implemented in WebKit! |
| 07:46 | <annevk> | guess it's time to write WHATWG Weekly |
| 07:57 | <foolip_> | gsnedders, jgraham, would either/both of you care to have a look at http://code.google.com/p/html5lib/issues/detail?id=178 ? |
| 08:13 | <annevk> | congratulations Lachy! |
| 08:53 | <annevk> | Led Zeppelin win |
| 08:54 | <zcorpan> | hsivonen: i'm having a bit of trouble reading the text on your site. could you try to increase the line-height slightly please? |
| 08:54 | <hsivonen> | zcorpan: is Opera still picking the wrong font file? |
| 08:54 | <annevk> | so far I have |
| 08:54 | <annevk> | Web Notifications |
| 08:54 | <zcorpan> | hsivonen: dunno |
| 08:54 | <annevk> | Purging Link Relations |
| 08:55 | <annevk> | leading with Shelley Powers volunteering |
| 08:55 | <annevk> | and a bunch of shorts from the WHATWG list |
| 08:55 | <jgraham> | Led Zepplin? |
| 08:55 | <annevk> | guess I should check the HTML WG list |
| 08:55 | <zcorpan> | hsivonen: don't think so, looks the same in firefox |
| 08:55 | <annevk> | jgraham, album IV |
| 08:56 | <hsivonen> | oh, nice. Opera has fixed its font selection. |
| 08:57 | <hsivonen> | I wonder which line-height I should use. |
| 08:57 | <zcorpan> | hsivonen: a line-height of 1.4 or 1.5 makes it easier to read for me |
| 08:57 | <zcorpan> | (unitless) |
| 08:59 | <jgraham> | annevk: Now I have both a headache and the drums from "When the Levee Breaks" in my head |
| 08:59 | <jgraham> | annevk: But still, awesome album :) |
| 08:59 | <hsivonen> | zcorpan: how about now? (1.25) |
| 09:00 | <jgraham> | foolip: Interesting bug |
| 09:03 | <zcorpan> | hsivonen: still too little for me |
| 09:03 | <annevk> | :) |
| 09:05 | <hsivonen> | hmm. 1.4 feels a bit too much of a jump for me |
| 09:05 | <foolip> | jgraham, is it easy to run html5lib directly from the hg repo to try out some fixes? |
| 09:07 | <jgraham> | foolip: Once you have a clone? Yes |
| 09:08 | <jgraham> | either cd into the python directory and import html5lib |
| 09:08 | <jgraham> | Or setup a virtualenv or so and do python setup.py develop |
| 09:08 | <jgraham> | and it will be the installed version in the whole virtualenv |
| 09:09 | <foolip> | haven't ever used virtualenv, does it have any benefits over the first option? |
| 09:09 | <jgraham> | Not really in this case |
| 09:09 | <jgraham> | In general, it is The Right Thing To Do |
| 09:09 | <jgraham> | if you are writing python |
| 09:13 | <foolip> | jgraham, so does my hypothesis about the bug seem right? |
| 09:19 | <jgraham> | foolip: It seems that something is going wrong when we try to clone the token to reconstruct the active formatting element |
| 09:20 | <jgraham> | Or maybe when we insert the attribute |
| 09:20 | <jgraham> | In any case it seems very odd to have getcontext()< as the attribute name |
| 09:20 | <annevk> | ok |
| 09:20 | <annevk> | gonna post now |
| 09:20 | <jgraham> | foolip: BTW you know that you can just pass a string in to the parser, right? |
| 09:21 | <foolip> | jgraham, yes, but it didn't reproduce then |
| 09:21 | <jgraham> | No need for a file |
| 09:21 | <foolip> | or I just guessed the wrong syntax |
| 09:22 | <foolip> | is it not html5lib.parse("<p><code x<=foo></code></p>", treebuilder="lxml") ? |
| 09:23 | <annevk> | http://blog.whatwg.org/weekly-web-notifications |
| 09:24 | <annevk> | either I missed something or not much happened |
| 09:24 | <jgraham> | foolip: That is scary |
| 09:25 | <jgraham> | I can reproduce it only reproducing with file input |
| 09:26 | <jgraham> | annevk: You should have mentioned hsivonen's investigation into loading about:blank I guess |
| 09:28 | <annevk> | added to shorts |
| 09:32 | jgraham | wonders what to think about the W3C license |
| 09:32 | <jgraham> | + suggestion |
| 09:33 | <annevk> | no replies to any of the events emails |
| 09:33 | <annevk> | guess I have to wait until tomorrow |
| 09:46 | hsivonen | sighs at http://www.w3.org/Bugs/Public/show_bug.cgi?id=11637#c2 |
| 09:48 | <annevk> | bureaucracy is painful |
| 09:50 | <annevk> | though it can also be funny |
| 09:50 | <annevk> | the other day I saw this exposition in Sweden: http://www.newyorker.com/online/blogs/photobooth/2010/06/bureaucratics.html |
| 09:52 | <zcorpan> | abarth: "and |
| 09:52 | <zcorpan> | the non-origin cookies are returned in the Origin-Cookie header |
| 09:52 | <zcorpan> | field." -- s/Origin-// |
| 09:57 | <annevk> | wait what |
| 09:57 | <annevk> | I thought the HTML WG test suite was under the MIT license? |
| 09:58 | <jgraham> | annevk: No |
| 09:58 | <annevk> | when was that decision reverted? |
| 09:59 | <hsivonen> | annevk: was there ever a decision? |
| 09:59 | <annevk> | http://dev.w3.org/html5/tests/license.txt |
| 09:59 | <hsivonen> | ooh. interesting |
| 09:59 | <jgraham> | wtf |
| 09:59 | <jgraham> | http://dvcs.w3.org/hg/html/file/1c140e17afb5/tests/resources/testharness.js has BSD/W3C |
| 10:00 | hsivonen | feels sorry for whoever has to bother lawyers about sorting that out |
| 10:00 | <jgraham> | http://www.w3.org/html/wg/wiki/Testing/Submission/ |
| 10:00 | <annevk> | well, it's not going to be me |
| 10:00 | <annevk> | at least not anytime soon |
| 10:01 | hsivonen | is guessing it's going to be jgraham |
| 10:01 | jgraham | hopes he doesn't have to bother lawyers |
| 10:01 | <jgraham> | But the prospects look bad :( |
| 10:02 | <jgraham> | Maybe I can make MikeSmith do it! |
| 10:02 | <jgraham> | <laugh type=evil> |
| 10:04 | zcorpan | puts <laugh> on the list of formatting elements and injects a bunch of <p>s in the input stream |
| 10:05 | <annevk> | guess I should fix EventSource tests today |
| 10:05 | <annevk> | :/ |
| 10:05 | <zcorpan> | annevk: it's better than fixing websocket tests, i bet |
| 10:06 | <jgraham> | zcorpan: <laugh> is a void element |
| 10:06 | <annevk> | what I hate most is all the different servers and setups and keeping it all in sync |
| 10:06 | <zcorpan> | jgraham: bummer |
| 10:06 | <jgraham> | Also I think even lawyers might be better than updating websockets tests |
| 10:06 | <zcorpan> | heh :/ |
| 10:06 | <jgraham> | Although that might just be optimisim on my part |
| 10:07 | <annevk> | lawyers delayed WHATWG work for six months or so |
| 10:07 | <annevk> | sorting out the two-line copyright license |
| 10:08 | <zcorpan> | there was no whatwg work for six months because of the license? |
| 10:10 | <annevk> | pretty sure |
| 10:10 | <jgraham> | Well yes, and the "option 3" thing that has taken years and looks dangerously like it has field of use restrictions |
| 10:10 | <annevk> | before SVN I'm afraid |
| 10:16 | <zcorpan> | must have been in 2004 before i got involved |
| 10:16 | <annevk> | yeah, after the summer or so |
| 10:17 | <annevk> | I think |
| 11:01 | <annevk> | so, time to drop the "living standard" label and proceed without labels? |
| 11:02 | <jgraham> | And also the HTML label? |
| 11:02 | <jgraham> | ("living standard" is just a description, it's not a label) |
| 11:03 | <annevk> | you wouldn't call "working draft" or "candidate recommendation" a label? |
| 11:04 | <jgraham> | Well they have formal status |
| 11:04 | <jgraham> | They are names for states |
| 11:04 | <annevk> | all the same to me |
| 11:04 | <jgraham> | "living standard" is purely descriptive |
| 11:04 | <annevk> | and we don't need it |
| 11:05 | <jgraham> | No, we also don't need any non-normative text |
| 11:05 | <jgraham> | But it has value |
| 11:06 | <annevk> | i don't think this has and I thought the plan was to get rid of it |
| 11:06 | <jgraham> | I think it is very successful in conveying to people the model that is being used |
| 11:07 | <jgraham> | You can tell it works because people are objecting to the model |
| 11:07 | <jgraham> | Their objections are largely nonsense |
| 11:07 | <jgraham> | But that's not generally because they don't understand the model |
| 11:08 | <jgraham> | But becuase they don't understand the implications correctly |
| 11:09 | <annevk> | why convey something that just causes confusion? |
| 11:09 | <jgraham> | It doesn't cause confusion |
| 11:09 | <annevk> | yes it does |
| 11:09 | <jgraham> | No, people's broken idea of how web specs work causes confusion |
| 11:09 | <annevk> | see the >100 comments on the post announcing the phrase |
| 11:10 | <jgraham> | The phrase is helpful in conveying the actual model |
| 11:10 | <jgraham> | Those 100+ comments were, by and large, not people confusion about our intentions for maintaining HTML going forward |
| 11:11 | <jgraham> | They were people confused into thinking that the model we will use will cause all sorts of bad side effects |
| 11:11 | <jgraham> | The right approach to clearing up that confusion is not to make it less obvious what the model is |
| 11:11 | <jgraham> | But to make it more obvious that all the bad stuff either won't happen or doesn't matter |
| 11:12 | <annevk> | it makes more sense to me to convey the model by practice than markety terms |
| 11:12 | <jgraham> | The model has been in practice since 1994 or so |
| 11:12 | <annevk> | not really |
| 11:13 | <jgraham> | It's just that even the people practising it thought they weren't |
| 11:13 | <annevk> | o_O |
| 11:13 | <jgraham> | Well except the bit where you actually write down what you are doing |
| 11:13 | <jgraham> | Rather than just doing random stuff |
| 11:14 | <jgraham> | I mean, in practice, since 1994 HTML has been unversioned for implementors. Authors have had to determine compatibility by looking at what UAs support rather than spec versions they conform to |
| 11:14 | <annevk> | you should get a blog for these essays |
| 11:14 | <annevk> | and I should get some sleep :) |
| 11:15 | <annevk> | but first eventsource |
| 11:16 | <jgraham> | Anyway, I think that changing the name every two weeks only has bad effects |
| 11:16 | <jgraham> | And what we have is fine |
| 11:24 | <annevk> | That went somewhat easier than anticipated although still quite a bit of work. |
| 11:46 | <annevk> | DOM Level 3 Events introduces new hasFeature usage |
| 11:46 | <annevk> | grmbl |
| 11:56 | zcorpan | has complained about that in his partial dom3events review |
| 11:57 | <annevk> | oh, then I duplicated your effort |
| 12:26 | <smaug____> | argh , even more PutForwards in the spec |
| 12:29 | <annevk> | it's used quite a lot |
| 12:31 | <smaug____> | apparently with dropzone too, which is quite bizarre. |
| 12:31 | smaug____ | needs to propose something better |
| 12:36 | <annevk> | down to 850 emails |
| 12:36 | <annevk> | maybe I should try to get down to 500 before I leave |
| 12:38 | <smaug____> | annevk: vacation? |
| 12:40 | <annevk> | 3 months to South America starting March 15 |
| 12:41 | <smaug____> | Doesn't sound too bad :) |
| 12:43 | <annevk> | Yeah, I'm quite excited :) |
| 13:05 | <smaug____> | oh, it is not just the dropzone which need some work, but the whole new d&d |
| 14:05 | <speakman> | is this channel for html5 usage questions? |
| 14:09 | <erlehmann> | speakman, no, go to #html5 |
| 14:16 | <MikeSmith> | erlehmann: um, I don't think most people here would have any problems with speakman asking html5 usage questions here |
| 14:21 | <karlcow> | Qt was not cute enough for Nokia. |
| 14:39 | <erlehmann> | MikeSmith, probably. but speakman asked explicitly for a usage question channel and isn't #html5 the more appropriate answer then? |
| 14:44 | <speakman> | Didn't know about #html5. Sounds like a more appropriate channel. :) |
| 14:46 | <krijnserver> | -_- |
| 14:46 | <krijnserver> | Is HTML5 done yet? |
| 14:47 | <krijnserver> | Can I use it already? |
| 14:47 | <Moo-_-_> | krijnserver: you can use it already |
| 14:47 | <Moo-_-_> | krijnserver: however, you need to specify which subset of HTML5 you use |
| 14:47 | <Moo-_-_> | krijnserver: All modern browsers support at least some of the HTML5 features |
| 14:47 | <krijnserver> | Hm, interesting |
| 14:48 | <erlehmann> | krijnserver, no and yes. |
| 14:48 | <Moo-_-_> | krijnserver: http://html5readiness.com/ |
| 14:51 | <annevk> | Moo-_-_, erlehmann, krijnh is trolling you |
| 14:51 | <krijnh> | I'm pulling a ppk |
| 14:51 | <Moo-_-_> | annevk: ah. it was not instantly obvious. wouldn't be the first person asking the question :) |
| 14:51 | <erlehmann> | annevk, OH NOES. MY COGNITIVE RESOURCES. |
| 14:51 | Moo-_-_ | pours some tar and feathers on krijnh |
| 14:52 | <annevk> | well well... he runs the IRC logs |
| 14:52 | <annevk> | guess that gives him some trolling privileges :) |
| 14:52 | <krijnh> | And you know it! |
| 15:02 | <annevk> | sure sounds like this will lead to "stable standards" http://lists.w3.org/Archives/Public/public-geolocation/2011Mar/0007.html |
| 15:12 | <zewt> | ew |
| 15:13 | <zewt> | referencing RFCs instead of w3 specs for that reason seems ... borderline absurd |
| 15:16 | <annevk> | the IDL one is the "best" |
| 15:39 | <zcorpan> | annevk: yay progress! |
| 15:40 | <zcorpan> | "Let's drop the reference to WebIDL and replace it with prose that requires the same things" |
| 15:50 | <hsivonen> | zcorpan: where's the quote from? |
| 15:50 | <hsivonen> | is this some Process stuff around spec maturity? |
| 15:50 | jgraham | is quite scared hsivonen is reading his mind |
| 15:51 | <jgraham> | OI was literallyu jsut about to type that |
| 15:51 | <zcorpan> | it's not a quote, but a translation of the trailing part of http://lists.w3.org/Archives/Public/public-geolocation/2011Mar/0007.html |
| 15:52 | <hsivonen> | zcorpan: that's so very sad |
| 15:58 | <karlcow> | The intent of this rule is to avoid a normative reference to a content which might be dropped in the future. |
| 15:59 | <jgraham> | karlcow: If webidl gets dropped we have much bigger problems |
| 15:59 | <karlcow> | Not webidl. |
| 15:59 | <karlcow> | a specific feature of webidl |
| 16:00 | <jgraham> | karlcow: By induction the only way one can avoid that is to not use webidl at all |
| 16:00 | <karlcow> | The normative reference is usually to say, This feature in my spec X has a dependcy on the feature of the spec Z. |
| 16:01 | <jgraham> | And if spec A depends on feature X of WebIDL and WebIDL changes the meaning of X we likely want A to inherit the change anyway |
| 16:01 | <karlcow> | jgraham: It's why encouraging smaller orthogonal specs with their own track was helping in this situation. Easier to fast forward. |
| 16:01 | <karlcow> | btw, I'm not saying it is good or not. I'm explaining the context of it. |
| 16:02 | <karlcow> | Process and specifications have their story telling and history :) |
| 16:02 | <karlcow> | jgraham: yep |
| 16:02 | <karlcow> | I think there is something to alleviate this issue |
| 16:02 | <karlcow> | let me try to find. |
| 16:02 | <jgraham> | karlcow: Well yes I understand that there is a reason in theory for the process. But I don't think it matches the reality |
| 16:03 | <karlcow> | jgraham: it doesn't match the current reality anymore. |
| 16:03 | <karlcow> | to read Deleuze about Jurisprudence and Legal systems. |
| 16:04 | <jgraham> | Arguably it never matched the reality. But that is angels on the head of a pin stuff |
| 16:04 | <karlcow> | here there are different strategies for normative references http://www.w3.org/TR/qaframe-spec/#ref-define-practice |
| 16:04 | <jgraham> | The important point is that specs now shouldn't be crippled by process issues |
| 16:05 | <karlcow> | one of them is the one adopted by Unicode |
| 16:05 | <karlcow> | Where character sets will evolve in the future |
| 16:05 | <zcorpan> | it's also not a requirement in the Process document, but just a "typically" statement |
| 16:06 | <karlcow> | jgraham: "specs now shouldn't be crippled by process issues" this time it is you which is out of reality. Written or not, in human transactions there are always process. This is exactly what human communications are. |
| 16:06 | <karlcow> | http://www.w3.org/TR/2005/REC-charmod-20050215/#sec-RefUnicode |
| 16:07 | <karlcow> | An example of referencing future version. |
| 16:07 | <jgraham> | *crippled* |
| 16:07 | <jgraham> | Rewiting a chunk of text purely to avoid a preocess issue, thereby potentially causing problems down the line === crippling |
| 16:07 | <karlcow> | I'm not on geolocation list, but if you want to chime in. It is possible to make a reference to WebIDL in a generic way by clearly stating it what the reference means. |
| 16:10 | <karlcow> | so basically, in summary, people have a tendency to make the W3C process stricter than it is. The W3C process basically says here there is a risk, explain to people, so they have the right expectations when reading this piece. That's all. |
| 16:14 | <hsivonen> | karlcow: sounds like "the Team Disease" :-/ |
| 16:14 | karlcow | doesn't know what is the team disease |
| 16:15 | <hsivonen> | karlcow: people who have been on the W3C Team rationalize W3C stuff not to be as bad as it looks even after leaving the Team |
| 16:15 | <hsivonen> | (the term is not my invention, FWIW) |
| 16:16 | <karlcow> | Because it is not that bad, but you might have different opinion :) it is ok. |
| 16:23 | <MikeSmith_> | if you all talking about the problem the restriction that specs can't normatively reference drafts/specs that aren't already at PR, then fwiw, that seems to me to clearly be a major process bug that needs to be fixed |
| 16:23 | <MikeSmith_> | seems blazingly obvious to me |
| 16:24 | <karlcow> | MikeSmith: it is not a true bug. It can be fixed. But it is authorized to link a future reference of a technology :) |
| 16:24 | <zewt> | well it does seem to make sense that a finalized spec shouldn't reference a spec that isn't finalized ... but the solution seems to be simply "wait for the spec you need to reference to be finished" |
| 16:24 | <karlcow> | been there, done that. |
| 16:24 | <MikeSmith> | karlcow: it is a true bug, in that we all know it's a problem, but despite that, we've not fixed it |
| 16:25 | <MikeSmith> | zewt: in some worlds that might make sense, but in the real world it doesn't |
| 16:25 | <karlcow> | Nope. People are saying it is a problem, and that it is absolutely forbidden. :) |
| 16:25 | <MikeSmith> | exactly |
| 16:25 | <karlcow> | which is not true |
| 16:25 | <MikeSmith> | it's a people problem |
| 16:25 | <MikeSmith> | it's a people bug |
| 16:26 | <MikeSmith> | we need to fix some people, frankly, in order to get that bug fixed |
| 16:26 | <karlcow> | ahaha |
| 16:26 | <zewt> | clearly, embedding snippets from other specs and referencing old RFCs instead of W3 specs to work around it is worse than any other possible end result, heh |
| 16:26 | karlcow | has a big smile |
| 16:27 | <Philip`> | I guess the problem is the expectation that new technologies are built on a solid foundation, when actually the foundations of web technologies are terrible and full of holes |
| 16:27 | <MikeSmith> | bingo |
| 16:27 | <MikeSmith> | pretending otherwise is… pretending |
| 16:27 | <MikeSmith> | and pretending is traditionally more the province of the IETF |
| 16:27 | <Philip`> | And it's evidently okay to build on terrible foundations, because the web still pretty much works |
| 16:27 | <hsivonen> | Web specs are only as stable as the software implementing them |
| 16:28 | <hsivonen> | and the software keeps getting changed all the time |
| 16:28 | <MikeSmith> | Philip`: same old "worse is better" vs "the right thing" |
| 16:28 | <hsivonen> | but some parts of the software are still stable in practice |
| 16:28 | <MikeSmith> | yeah, ture |
| 16:28 | <MikeSmith> | *true |
| 16:28 | <MikeSmith> | most APIs are quite stable |
| 16:28 | <MikeSmith> | because, well, otherwise we have madness |
| 16:29 | <hsivonen> | the concept of Origin is pretty stable for http URLs. less so for data: URLs |
| 16:30 | karlcow | is trying to find an example of a technology which is stable… and can't find. Which makes "foundations of web technologies are terrible and full of holes" kind of moot. It is not the right argument |
| 16:31 | <zewt> | define stable :) |
| 16:31 | <zewt> | a word with many different meanings |
| 16:31 | <karlcow> | zewt: exactly |
| 16:31 | <zewt> | principally "works reliably" vs. "doesn't change" |
| 16:32 | <MikeSmith> | stability is something very different from "foundations of web technologies are terrible and full of holes" |
| 16:32 | <zewt> | (generally the latter when talking about specs, of course) |
| 16:32 | <MikeSmith> | that "foundations of web technologies are terrible and full of holes" comment wasn't about stability |
| 16:33 | <karlcow> | it is a truism. |
| 16:33 | <Philip`> | I suppose the WHATWG has a similar attitude problem in expecting two interoperable implementations of a whole spec and a comprehensive test suite, because that's the only way to ensure a spec is good quality - in practice that's never going to happen for HTML5 and it's a waste of time pretending we'll ever reach that point, so it'd be better to give up on the quality goal and focus on optimising limited resources |
| 16:34 | <MikeSmith> | Philip`: it's imaginable that we can arrive at some other metrics for deciding when a particular technology is recommendable as "ready for widespread adoption in production sites" (or whatever) |
| 16:35 | <MikeSmith> | that is, short of the " two interoperable implementations of a whole spec and a comprehensive test suite" metric |
| 16:36 | <karlcow> | same ol' discussions for the last few centuries :) |
| 16:36 | <MikeSmith> | really? |
| 16:36 | <MikeSmith> | I don't remember a whole lot of discussion about that previously |
| 16:36 | <jgraham> | Philip`: The WHATWG *has* given up on that goal, effectively |
| 16:36 | karlcow | is sending his copy of Thomas Kuhn to MikeSmith |
| 16:36 | <MikeSmith> | jgraham: yeah, well |
| 16:37 | jgraham | isn't quite sure why Kuhn is relevant but is pretty sure it wasn't two centuries ago |
| 16:37 | <karlcow> | The issue is people searching for purity. The rules or the spirit of the rules |
| 16:37 | <Philip`> | jgraham: I thought there was still the idea within the WHATWG that the snapshot subset of HTML that the W3C calls HTML5 will meet that criteria in 2022, and that people should be working towards that goal |
| 16:38 | <MikeSmith> | jgraham: the "WHATWG" may have implicitly given up on that goal. But since there's not any actual way of measuring what the "WHATWG" actually thinks, that's something else that pretty much impossible to measure |
| 16:39 | <annevk> | karlcow, smaller orthogonal specs hardly exist |
| 16:39 | <karlcow> | about the double implementation report as a foolish guarantee, I have already written about that. http://www.w3.org/wiki/ImplementationReport |
| 16:39 | <karlcow> | The inconsistency raises a question: does this table prove interoperability between the products? We find that only Feature 1 and Feature 2 are implemented across the three products; only 40% of the specification FooML has reached widespread interoperability. |
| 16:39 | <karlcow> | Is FooML at a good point or at a bad point? Can we improve things? Can we use better metrics for improving implementations? |
| 16:39 | <jgraham> | Well yes, I guess i have falled into the lazy intellectual trap of ascribing notions to "the WHATWG" even when it has no cohesive existence |
| 16:39 | <annevk> | karlcow, the web is intertwined |
| 16:39 | <annevk> | karlcow, people better get used to it |
| 16:40 | <jgraham> | Philip`: Maybe |
| 16:40 | <karlcow> | annevk: yes you are right. The physics, the biology, the cooking, everything is intertwined. Another truism. |
| 16:40 | <karlcow> | This discussion doesn't make sense. |
| 16:40 | <jgraham> | Philip`: I subscribe to the view that testing parts of the spec that are getting implemtation is valuable in continuously increasing interoperability and that arbitary timelines aren't that useful |
| 16:41 | <jgraham> | I don't know if that matches what anyone else thinks |
| 16:42 | <jgraham> | I guess dates have some value in giving people a sense of urgency |
| 16:42 | <MikeSmith> | jgraham: fwiw, it matches what I think too |
| 16:42 | <MikeSmith> | I think it's absurd that we aren't doing more formal testing at this point |
| 16:43 | <jgraham> | In the sense that the HTML5 testsuite is very post-hoc? |
| 16:43 | <zewt> | jgraham: dates 15 years in the future don't do that so much, though... :) |
| 16:43 | <MikeSmith> | jgraham: yeah, but not just that |
| 16:44 | <karlcow> | MikeSmith: it might be absurd, but it illustrates a reality. Not that many people like testing stuff. Not very rewarding with regard to the social group for many people. :) |
| 16:44 | <MikeSmith> | but it would seem in general that we all have a bit of ass-backwards way of doing feature development that's not in line with common, modern best practices in software development |
| 16:45 | <MikeSmith> | karlcow: developers who write application code don't like testing stuff either |
| 16:45 | <karlcow> | yep |
| 16:45 | karlcow | nods |
| 16:46 | <MikeSmith> | but they do test-driven development because they know that if they don't, they're just pushing off the costs til later, and of course increasing risk of bugs |
| 16:46 | <zewt> | depending heavily on the environment, language, etc |
| 16:46 | <MikeSmith> | sure |
| 16:47 | <zewt> | not really possible to write tests for stuff until late in the game anyway, since you need implementations to ... test the tests |
| 16:47 | <karlcow> | I'm not under the feeling that a majority of devs do test-driven, without entering into another overrated debate about dev methodologies |
| 16:47 | <wilhelm> | A lot of testing work is happening within the organizations of each browser vendor, I presume. But it takes effort to share tests. An effort well worth the investment, presumably. (c: |
| 16:47 | Philip` | thinks "test-driven development" is something very specific that he's pretty much never seen anyone do in practice |
| 16:47 | <Philip`> | (i.e. you write tests first, and then write the code to make them pass) |
| 16:48 | <Philip`> | (Seems much more common to write code and tests in parallel, or the tests slightly after, in my (very limited) experience) |
| 16:48 | <zewt> | that sounds up there in terms of real-world unreasonable as "assurance" |
| 16:48 | <zewt> | way too expensive |
| 16:49 | <Philip`> | (and even more common to not write tests at all) |
| 16:49 | <MikeSmith> | Philip`: yeah, well, it's like religion. like somebody asking Mark Twain if he had something against Christians, and him saying, no, he'd just never actually met one yet. |
| 16:49 | <zewt> | in the real world, with most development, tests don't actually always pay for themselves, heh |
| 16:49 | <wilhelm> | zewt: That depends on the complexity on the problem you're solving. When adding new APIs to the OperaWatir test framework, we actually wrote tests before the implementation. |
| 16:49 | <wilhelm> | That's a quite trivial software project compared to a web browser, though. |
| 16:50 | <zewt> | well, yeah--and in most development, you don't actually know precisely where you're going when you start, anyway |
| 16:50 | <MikeSmith> | zewt: that's true of any creative endeavor |
| 16:50 | <zewt> | yeah, but not all development (or every subsection of development) is creative |
| 16:50 | <MikeSmith> | I think it is |
| 16:51 | <MikeSmith> | I think it is fundamentally creative |
| 16:51 | karlcow | on this good words will go cut the creative daikon for lunch |
| 16:51 | <wilhelm> | When implementing moderately stable web specs, you do know where you're going. We write tests and the running code at the same time here – with different people doing each part. |
| 16:52 | <zewt> | do you have poor hapless interns writing test code |
| 16:52 | <wilhelm> | They're not interns. (c; |
| 16:52 | <zewt> | extra hapless, then |
| 16:53 | <wilhelm> | One full-time tester per two developers. |
| 16:53 | <wilhelm> | Approximately. |
| 16:53 | <MikeSmith> | historically, hapless interns writing test code eventually turn into experiencec QA engineers and valuable test-case writers |
| 16:53 | <MikeSmith> | or even spec writers |
| 16:53 | <zewt> | writing test code seems more like a high-level QA job than development |
| 16:54 | <zewt> | though, perhaps with the advantage that the people developing the software will hate you less than a typical QA staff :P |
| 16:54 | <zewt> | QA results based on reproducable tests that I can run myself? yes please |
| 16:55 | <wilhelm> | If it can be automated, it must be. (c: |
| 17:08 | <MikeSmith> | wilhelm: amen |
| 17:10 | karlcow | - daikon is being cooked |
| 17:32 | <MikeSmith> | heh http://twitter.com/#!/brianleroux/status/44811140668198912 |
| 17:33 | <MikeSmith> | "Client wants 5 extra devs on project in final week before SXSW. I wish Fred Brooks was a super hero I could invoke with a heartfelt plea." |
| 17:33 | <zewt> | when in doubt, throw a half dozen new people on project at last minute |
| 17:33 | <zewt> | what could possibly go wrong? |
| 17:35 | <karlcow> | it reminds me last year nightmares. |
| 17:37 | <karlcow> | The business of Web development/Web agencies is flawed at many levels. Saturated market, low prices, lack of Web culture inherited from the publicity/marketing world. :/ |
| 17:52 | <foolip_> | jgraham, care to commit my change for http://code.google.com/p/html5lib/issues/detail?id=169 or make me committer so I can do it myself? |
| 17:54 | <jgraham> | foolip_: philip⊙fo? |
| 17:56 | <foolip_> | jgraham, right |
| 17:57 | <zewt> | ... is that foo lip or fool ip? :P |
| 17:57 | <foolip_> | that's philip with s/phi/foo/, so the former I guess |
| 17:58 | <foolip_> | jgraham, do you ever do any kind of code review for html5lib? |
| 17:58 | <foolip_> | or just commit and hope for the best? |
| 17:58 | <jgraham> | foolip_: Sometimes we go "oh my sainted lord what is this crap" |
| 17:58 | <jgraham> | Does that count? |
| 17:59 | <foolip_> | hehe, absolutely |
| 17:59 | <jgraham> | I guess occasionally we use different curses too |
| 17:59 | <jgraham> | But basically, so far we haven't bothered |
| 18:00 | <foolip_> | ok, I'll just apply common sense and colorful curses |
| 18:00 | <jgraham> | If you would like anything reviewed please ask |
| 18:01 | <foolip_> | sure |
| 18:01 | <jgraham> | And if you commit things that use \ to extend long lines I will have to use my full palette of curse colours |
| 18:01 | <zewt> | python? :P |
| 18:01 | <jgraham> | ;) |
| 18:01 | <jgraham> | zewt: Yeah |
| 18:01 | <zewt> | i've spent way too much time trying to "fix" people who have been tainted by PEP-8 :| |
| 18:02 | <zewt> | let's wrap at 80 columns, because anything more won't fit on my 14" CRT |
| 18:02 | <jgraham> | foolip_: (for style issues, basically try to look like the rest of the file. But I guess that is obvious) |
| 18:02 | <foolip_> | yep |
| 18:02 | <jgraham> | zewt: No, that is good and right |
| 18:02 | <foolip_> | one good thing about python is that it doesn't allow for as much variation and "styles" as some languages |
| 18:02 | <jgraham> | zewt: I often have two windows open side-by-side for example |
| 18:03 | <zewt> | doesn't really matter, the world doesn't end if your editor has to wrap a line here and there :) |
| 18:03 | <jgraham> | People who insist on using all the horizontal space on their dual 30" monitors when there are multiple nice places to wrap the line are very annoying |
| 18:03 | <foolip_> | watch out zewt, people with strong opinions about source code formatting are amusing :) |
| 18:04 | <zewt> | foolip_: probably everyone in here has strong opinions on such things :) |
| 18:04 | <jgraham> | Hmm, looks like the html5lib bugs have been building up a bit |
| 18:04 | <zewt> | i'll wrap if and where it makes sense, but I won't mangle code to force it |
| 18:04 | <jgraham> | I should give it some love |
| 18:07 | <foolip_> | hmm, what does mercurial do you try to push a commit while your repo is out of date? |
| 18:07 | <foolip_> | does it even do rebase? |
| 18:08 | <annevk> | you do hg pull and then hg update |
| 18:08 | <annevk> | and then hg commit -m "merge" if it merged cleanly |
| 18:08 | <annevk> | or some such |
| 18:09 | <jgraham> | foolip_: You can enable rebase in the config |
| 18:10 | <jgraham> | and do hg pull --rebase |
| 18:10 | <foolip_> | jgraham, thanks |
| 19:04 | <foolip_> | jgraham, what's the proper way to run all the python tests? |
| 19:04 | <foolip_> | the runtest.sh script is a lie |
| 19:17 | <karlcow> | http://lists.w3.org/Archives/Public/public-web-and-tv/2011Mar/thread.html |
| 19:17 | <karlcow> | 1 message about meeting |
| 19:17 | <karlcow> | 12 messages about IPR |
| 19:17 | <karlcow> | 1 message about techno |
| 19:18 | <karlcow> | the web and TV thing will show culture clashes for a little bit while. |
| 20:12 | <AryehGregor> | Anyone have suggestions on non-obfuscated execCommand() users I could look at? |
| 20:13 | <miketaylr> | https://github.com/search?type=Code&language=javascript&q=execCommand&repo=&langOverride=&start_value=1&x=24&y=22 :) |
| 20:16 | <jgraham> | foolip_: In theory python runtests.py should do it |
| 20:17 | <jgraham> | Note that some tests will fail today |
| 20:17 | <jgraham> | Since the tests evolve independenly |
| 20:45 | <foolip_> | jgraham, filed http://code.google.com/p/html5lib/issues/detail?id=179 about all the things that are broken about tests |
| 20:47 | <jgraham> | foolip_: Looks like I bitrotted some of the stuf when I had a cleanout |
| 20:47 | <jgraham> | that shell script should die |
| 20:47 | <foolip_> | shall I just remove it? |
| 20:47 | <jgraham> | Yes |
| 20:48 | <jgraham> | simplejson shouldn't be in the support package, you should have to install it |
| 20:48 | <jgraham> | although we should use the built-in json where possible |
| 20:48 | <jgraham> | the potscript files are freaking me out |
| 20:48 | <jgraham> | *postscript |
| 20:48 | <jgraham> | I hope that is just random |
| 20:50 | <foolip_> | you've never seen them? |
| 20:51 | <jgraham> | No |
| 20:53 | <annevk> | awesome Hixie |
| 20:53 | <annevk> | gonna create those tomorrow |
| 21:35 | <AryehGregor> | Wordpress supports WYSIWYG of some type, right? Does anyone know of an existing Wordpress blog with public WYSIWYG comments enabled? |
| 21:35 | <AryehGregor> | Hmm, or maybe it only allows WYSIWYG for editors, not commenters? |
| 21:36 | <gsnedders> | For editors, AFAIK |
| 21:36 | <Peter`> | gsnedders: thanks for the list! |
| 21:36 | <AryehGregor> | Hmm, do I have a login at blog.whatwg.org? |
| 21:37 | <gsnedders> | Peter`: np |
| 21:39 | <AryehGregor> | Ah, looks like it uses TinyMCE, maybe. |
| 21:40 | <gsnedders> | IIRC it does |
| 21:42 | <AryehGregor> | Blech, DOS line-endings? |
| 21:43 | <AryehGregor> | Oh, no, it has a mix. Nice. |
| 21:47 | bfrohs | loves line-endings |
| 21:50 | <zewt> | i don't believe your lies |
| 21:50 | <zewt> | are you going to tell us you like time zones and legacy charsets, too |
| 21:50 | <Ms2ger> | Yes |
| 21:51 | <bfrohs> | Yes, I love them all /sarcasm |
| 21:53 | <AryehGregor> | Okay, so it looks like the big projects all just avoid execCommand() and roll their own editors. |
| 21:53 | <AryehGregor> | For good reason, needless to say. |
| 22:04 | <TabAtkins> | Oh man, if so, can we just drop execCommand? |
| 22:04 | <AryehGregor> | No. |
| 22:05 | <AryehGregor> | I mean, go ahead and try to convince implementers if you like. |
| 22:05 | <AryehGregor> | But no. |
| 22:05 | <annevk> | and if we make it work it might actually be useful |
| 22:05 | <AryehGregor> | Yeah, that's the thing. |
| 22:05 | <AryehGregor> | No one uses it because it's so horribly inconsistent between browsers. |
| 22:05 | <AryehGregor> | If not for that, it would be useful. |
| 22:05 | <AryehGregor> | Although it could probably also do with being more flexible. |
| 22:08 | <bfrohs> | Thing I wish execCommand had was formatinline (inline version of formatblock) |
| 22:08 | <AryehGregor> | Yeah, that sounds like a good feature to add. |
| 22:09 | <AryehGregor> | Although it will be more complicated than formatBlock for sure. |
| 22:09 | <AryehGregor> | (if you want it to work sensibly) |
| 22:10 | <bfrohs> | Yeah, the lack of that feature caused me a lot of headaches awhile back when working on a basic wysiwyg editor |
| 22:11 | <zewt> | "modern" editors in javascript are invariably such a headache to use... |
| 22:11 | <zewt> | too magic, which means glitchy |
| 23:55 | <Hixie> | jgraham: anne's 6 month estimate is 6 times too long, but yeah, figuring out the original copyright notice took a month of me speaking to laywers |
| 23:56 | <Hixie> | jgraham: that's why i didn't make any effort at solving the patent problem |