| 00:03 | <Hixie> | Philip`: yt? |
| 00:06 | <Hixie> | eh nm |
| 00:06 | <Hixie> | well |
| 00:06 | <Hixie> | when you get back, could you add some tests to http://philip.html5.org/demos/html/charset-parsing/ ? |
| 00:06 | <Hixie> | specifically: |
| 00:07 | <Hixie> | <meta http-equiv="content-type" content="text/html; charset='...'"> |
| 00:07 | <Hixie> | <meta http-equiv="content-type" content='text/html; charset="..."'> |
| 00:07 | <Hixie> | <meta http-equiv="content-type" content='text/html; test="; charset="..."'> |
| 00:08 | <Hixie> | <meta http-equiv="content-type" content='text/html; test="test"; charset="..."'> |
| 00:08 | <Hixie> | <meta http-equiv="content-type" content='text/html; test="; charset=...'> |
| 00:08 | <Hixie> | <meta http-equiv="content-type" content='text/html; test="test"; charset=...'> |
| 00:09 | <Hixie> | <meta http-equiv="content-type" content="text/html; test='; charset=..."> |
| 00:09 | <Hixie> | <meta http-equiv="content-type" content="text/html; test='test'; charset=..."> |
| 00:10 | annevk | wonders why JB didn't join the FTF himself |
| 00:10 | <Philip`> | Hixie: Hello |
| 00:10 | <Hixie> | hello |
| 00:10 | Philip` | updates his list |
| 00:12 | <annevk> | heh, your file names are hex numbered |
| 00:15 | <Philip`> | Hixie: Updated |
| 00:15 | <Philip`> | annevk: Oops, that was unintentional |
| 00:15 | <Philip`> | I think I intended %02d, but I wrote %02x |
| 00:16 | <Hixie> | Philip`: thanks |
| 00:16 | <annevk> | would %03d be three digits? |
| 00:16 | <Philip`> | Hmm, my default font isn't great at distinguishing " and '' |
| 00:16 | <Hixie> | something seems to be wrong |
| 00:16 | <Philip`> | annevk: Yes (zero-padded) |
| 00:17 | <Philip`> | Hixie: Could you be slightly more specific? |
| 00:17 | <Hixie> | i'm trying to figure out what is wrong :-) |
| 00:17 | <Philip`> | Do you just have a vague sense of unease, and no idea what the problem is? |
| 00:17 | <hober> | annevk: IIRC, at the time, it was believed that ((both wgs should have chairs on the ftf) xor (neither wg should have chairs on the ftf)) |
| 00:17 | <Hixie> | the lines appear to be duplicated |
| 00:18 | <Hixie> | rom the first <meta charset="text/html; charset=iso-8859-1">: not utf-8 to the end seems to just be a duplication of the earlier set |
| 00:18 | Philip` | notes that he gets a lot of "service temporarily unavailable" when loading the charset page in IE, but that's Dreamhost's fault |
| 00:18 | <Hixie> | nevermind |
| 00:18 | <Hixie> | cache problem |
| 00:19 | <Philip`> | Ah |
| 00:19 | <Philip`> | I added the new ones kind of near the top, so all the others got renumbered |
| 00:19 | <annevk> | hmm, seems that implementations simply scan for "charset=" |
| 00:20 | <Hixie> | ok webkit is clearly just doing that, indeed |
| 00:20 | <Hixie> | IE, not so much |
| 00:20 | <annevk> | Opera and Firefox seem to be doing that too |
| 00:21 | <annevk> | (that's the two I tested, I didn't check IE or WebKit) |
| 00:21 | <Hixie> | firefox uses the same algorithm on charset="" as content="" |
| 00:21 | <Hixie> | webkit does what html5 says |
| 00:21 | <Hixie> | for charset="" |
| 00:22 | <Hixie> | opera freaked out on me the first time, let's try again |
| 00:22 | <Hixie> | ok yeah opera's scrollbar can't handle that page, wtf |
| 00:22 | <annevk> | "<meta charset="text/html; charset=utf-8">: not utf-8 " is what I get in Firefox |
| 00:22 | <Hixie> | opera does the same as webkit except it checks the http-equiv attribute |
| 00:22 | <Hixie> | what build? |
| 00:23 | <annevk> | "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031504 Minefield/3.0b5pre" |
| 00:23 | <Hixie> | weird |
| 00:24 | <Hixie> | also weird, IE8 supports charset='...' but not charset="...", the latter of which is the only valid one... |
| 00:24 | <annevk> | so my Firefox builds seems to have a different algo for charset= |
| 00:25 | <annevk> | I think both Opera and IE check http-equiv |
| 00:27 | <Hixie> | there are now three occurances of the term "willful violation" in the spec |
| 00:30 | <annevk> | spec lawyers rejoice |
| 00:32 | <Dashiva> | If you violate a should for a valid reason, is it still considered a violation? |
| 00:35 | <annevk> | nope |
| 00:39 | <annevk> | http://signified.com.au/a-poem-element-for-html5/ |
| 00:41 | MikeSmith | awakens and confronts long scrollback buffer for #whatwg in irc client |
| 00:42 | <annevk> | MikeSmith, we don't have membership fees, we just want all your time :) |
| 00:44 | <Dashiva> | MikeSmith: I could bring in a comic chat client to make amusing comic strip representations of the logs |
| 00:51 | MikeSmith | completes reading of scrollback |
| 00:52 | MikeSmith | records data point: 6 hours of #whatwg scrollback took about 5 minutes to read |
| 00:54 | <Hixie> | so about 1 minute an hour |
| 00:54 | <Hixie> | not bad |
| 00:55 | <Philip`> | Took much longer for us to write all that |
| 00:55 | <MikeSmith> | annevk: re: time -- I find that the time I choose to invest in #whatwg discussions and reading usually pays better returns than time I'm obligated to spend on some other things |
| 00:56 | <MikeSmith> | Dashiva: yes, comic chat client, please.. could recruit the Wizard and/or Magic Fairy to do that, maybe |
| 00:57 | <Dashiva> | Microsoft already made it, many years ago |
| 00:57 | <MikeSmith> | cheers to Microsoft for that |
| 01:02 | <MikeSmith> | btw, 'twas I that suggested to Erik Wilde that he join the HTML WG and post his thoughts on fragments IDs |
| 01:02 | <MikeSmith> | though I do recognize the heinous-ness of xpointer will prevent it from being practical for this case |
| 01:06 | <MikeSmith> | and on the topic of joining the HTML WG and public-html list, questions I get from people now and then are, Can I get the list messages in digest form, or do you have a "no mail" option, or [some other way that they can avoid getting all the list mail but still remain in the group] |
| 01:06 | <MikeSmith> | I'm not sure what is the right thing to tell people |
| 01:07 | <Hixie> | "join the whatwg list, it has both of those options" |
| 01:08 | <MikeSmith> | Hixie: yeah, I always tell people that anyway |
| 01:08 | <Hixie> | :-) |
| 01:10 | <MikeSmith> | about public-html, I usually say, Good opportunity/test-case for you to learn about the client-side filtering capabilities in your mail client .. or to switch to a mail client that has good filtering |
| 01:33 | <MikeSmith> | http://lists.w3.org/Archives/Public/www-archive/2008May/0056.html |
| 01:33 | <MikeSmith> | saved for re-use later |
| 01:33 | <MikeSmith> | my "boilerplate response about mailing-list traffic volume" |
| 01:33 | <MikeSmith> | which took roughly 15 minutes for me to think up and write |
| 01:35 | <MikeSmith> | longer that I thought it would, but 15 minutes less than it will take me next time I get the same question |
| 01:36 | <MikeSmith> | I guess I should put that (in another form) up on the HTML WG website somewhere |
| 01:38 | <jacobolus> | MikeSmith: I'm not sure “you'll get tons of spam, and it will be a good life/technical lesson to deal with it” is really so compelling |
| 01:51 | <MikeSmith> | jacobolus: patches welcome |
| 01:54 | <jacobolus> | MikeSmith: how about “each email on the list contains a pearl of wisdom which will brighten your life: if you find the amount of traffic overwhelming, it will only be because you are insufficiently appreciative of your good fortune” |
| 01:58 | <MikeSmith> | jacobolus: about pearls of wisdom, I already have a site for automatically dispensing those: |
| 01:58 | <MikeSmith> | http://logopoeia.com/wisdom/ |
| 01:58 | <jacobolus> | whoa! Our DNA was altered to conceal the cosmic secret of timbral magnetism raster mathematics. |
| 02:00 | <jacobolus> | 5 steps include: “Memorize homeopathic law,” and “Make time law your guide.” |
| 02:00 | <jacobolus> | I want to know what “homeopathic law” and “time law” are, so I can follow these |
| 02:14 | <MikeSmith> | so I think I have come to terms with twitter and found what is for me at least a way to use it productively that doesn't require a lot of time: |
| 02:14 | <MikeSmith> | http://twitter.com/sideshowbarker |
| 02:16 | <MikeSmith> | mainly as a personal+social bookmarking mechanism |
| 02:31 | <Hixie> | anne and mjs should read para2 of http://lists.w3.org/Archives/Member/w3c-html-cg/2008AprJun/0082.html |
| 02:32 | <Hixie> | pity that the guy anne cited above on poems doesn't buy my line that <p> is defined as meaning "stanza" |
| 02:43 | <Dashiva> | cg? |
| 02:49 | <Hixie> | coordination group |
| 09:07 | <hsivonen> | what's the relationship of the proposed zip: URI scheme and the existing jar: URI scheme? |
| 09:11 | <annevk> | jar: opens up the ZIP file and then does addressing while zip: would be an internal thing afaict |
| 09:17 | <Hixie> | othermaciej, annevk: para 2 of http://lists.w3.org/Archives/Member/w3c-html-cg/2008AprJun/0082.html |
| 09:18 | <othermaciej> | awesome |
| 09:18 | <annevk> | yeah, I read that before I want to bed |
| 09:19 | <annevk> | I also wrote something in this channel "/me wonders why JB didn't join the FTF himself" |
| 09:19 | <Hixie> | ah |
| 09:23 | <othermaciej> | I need to turn my list of possible architectural consistency principles into some sort of draft |
| 09:24 | <othermaciej> | I have so much (English) writing to do |
| 09:24 | <othermaciej> | also need to justify our ES4 votes |
| 09:24 | <othermaciej> | and reply on Hixie's thread about forward-compatible syntax for ES4 |
| 09:24 | <othermaciej> | and call bullshit on chris wilson's security comments |
| 09:24 | <othermaciej> | ugh |
| 09:24 | <othermaciej> | gonna be a long weekend |
| 09:24 | <Hixie> | you're not supposed to do this stuff on the weekend |
| 09:25 | <Hixie> | you're supposed to run pedestrians down in GTA4 on the weekend |
| 09:25 | <othermaciej> | but I don't have time to get anything done during the week |
| 09:25 | <Hixie> | ah well |
| 09:25 | <Hixie> | neither do i |
| 09:25 | <othermaciej> | the wonders of management |
| 09:25 | <othermaciej> | actually I coded a lot this week |
| 09:25 | <othermaciej> | but making JavaScript run really fast is actually kind of fun |
| 09:27 | <Hixie> | is JS execution a bottleneck on the web? |
| 09:27 | <roc> | yes |
| 09:27 | <Hixie> | i thought dom calls were by far the bottleneck in js execution |
| 09:28 | <roc> | sometimes they are |
| 09:28 | <Hixie> | interesting |
| 09:28 | <roc> | that's the great thing about the Web. everything's a bottleneck, depending on what you look at |
| 09:29 | <Hixie> | heh |
| 09:30 | <othermaciej> | Hixie: both can be |
| 09:30 | <othermaciej> | our DOM has somewhat less room to speed it up |
| 09:30 | <othermaciej> | at least the core DOM |
| 09:30 | <MikeSmith> | so what good benchmarking mechanisms are there for measuring DOM performance? |
| 09:30 | <MikeSmith> | I know about those for measuring JS perf |
| 09:31 | <othermaciej> | I don't know if any are great |
| 09:31 | <annevk> | entities are safe for now, nice! |
| 09:31 | <othermaciej> | this is a clean microbenchmark: http://www.hixie.ch/tests/adhoc/perf/dom/artificial/core/001.html |
| 09:31 | <MikeSmith> | othermaciej: thanks |
| 09:31 | <othermaciej> | testing the non-querySelector non-XPath mode of JS selector libraries is a more realistic use pattern |
| 09:31 | <othermaciej> | though one we are hoping to obsolete |
| 09:32 | <othermaciej> | quirksmode.org also has some DOM perf tests but not rolled up nicely |
| 09:32 | <Hixie> | the ones in http://www.hixie.ch/tests/adhoc/perf/dom/real-world/ should be better, they're based on actual web sites |
| 09:32 | <othermaciej> | (all differnet ways of building a table DOM - amusingly innerHTML wins in every browser) |
| 09:34 | <Hixie> | someone really should make a job out of comparing browsers on a suite of benchmarks on reference hardware with care to making the tests fair, and then publishing hte results in graphical form regularly |
| 09:34 | <othermaciej> | doing one operation (with the same args) a bunch of times may not be representative of DOM performance generally speaking |
| 09:34 | <Hixie> | true |
| 09:34 | <othermaciej> | since caching means that mixed operations are often a tougher workload |
| 09:35 | <othermaciej> | Hixie: that would be nice - I am not enjoying resorting to making our own benchmarks |
| 09:35 | <MikeSmith> | holy god |
| 09:35 | <othermaciej> | but the market for independent browser benchmarks seems to have died |
| 09:35 | <Hixie> | yeah |
| 09:35 | <MikeSmith> | othermaciej: I can see why you might prefer that benchmark :) |
| 09:35 | <othermaciej> | also a lot of the perf/dom/real-world tests are really repaint tests |
| 09:36 | <othermaciej> | MikeSmith: if you compared WebKit to other browsers on that, I think the results it shows are real - we have done quite well since before we ever saw that benchmark |
| 09:36 | <Hixie> | a lot of the real world dom work relies on painting |
| 09:36 | <MikeSmith> | othermaciej: wow |
| 09:36 | <Hixie> | but yes, those tests are just a start |
| 09:36 | <MikeSmith> | extremely impressive |
| 09:36 | <othermaciej> | Hixie: sure, repaint performance is really important |
| 09:37 | <othermaciej> | separating things is kind of nice, at least for browser developers, though I am not sure what level of perf info granularity is interesting to content authors or end users |
| 09:38 | <othermaciej> | MikeSmith: this is the quirksmode test I was thinking of: http://www.quirksmode.org/dom/innerhtml.html |
| 09:38 | <othermaciej> | (his posted numbers are old though you gotta try it yourself) |
| 09:39 | <MikeSmith> | othermaciej: thanks |
| 09:51 | <othermaciej> | Hixie: I can also tell you that on mobile devices JS execution is even more likely to be the bottleneck in web page performance (though not as much as the network itself) |
| 09:53 | <MikeSmith> | othermaciej: that's interesting.. why is that? |
| 09:53 | <MikeSmith> | why in particular on mobile |
| 09:53 | <MikeSmith> | because CPU-bound? |
| 09:54 | <MikeSmith> | othermaciej: and by "more" you mean specifically vs. DOM performance? |
| 09:54 | <roc> | cpus are slow |
| 09:54 | <othermaciej> | well I can't tell you that much about the mobile device I know most about, but yes, the CPUs tend to be less powerful |
| 09:54 | <Hixie> | othermaciej: interesting |
| 09:54 | <roc> | and they don't speculate well |
| 09:54 | <othermaciej> | ARM has practically no branch prediction |
| 09:54 | <Hixie> | that explains all the wild rumours |
| 09:54 | <othermaciej> | what wild rumors? |
| 09:55 | <Hixie> | about the iphone! |
| 09:55 | <roc> | the JS performance work we did for Firefox 3 sped up mobile by a greater factor than on PCs |
| 09:55 | <MikeSmith> | dual-core iPhone coming |
| 09:55 | <othermaciej> | there was a rumor that JS is slow on the iPhone? |
| 09:55 | <Hixie> | if they speculated better, the rumours would have been more accurate! |
| 09:55 | <MikeSmith> | heh |
| 09:55 | <roc> | hoho |
| 09:55 | <roc> | don't give up your day job |
| 09:56 | MikeSmith | just now gets Hixie joke.. (I'm slow on teh uptake) |
| 09:56 | Hixie | goes back to rejecting suggestions |
| 09:56 | <roc> | cool, he took my advice! |
| 09:57 | <Hixie> | i wish screen sharing on mac didn't turn the host's screen back on |
| 09:58 | <Hixie> | i want to change the music my mac mini is playing without turning on the massive light that is the screen |
| 09:58 | <Hixie> | since the lights are off in the room |
| 09:58 | <roc> | I'm a little bit afraid that CPUs might migrate to lots of dumb cores, with minimal speculation, no out-of-order, no wide-issue. That would really suck for JS performance |
| 09:58 | <roc> | but I don't think Intel thinks much about JS performance |
| 09:59 | <annevk> | they prolly should... |
| 10:00 | <Hixie> | well, given JS' importance in the coming years, whoever _does_ think about it may end up having an advantage |
| 10:00 | <othermaciej> | that would suck for performance of any language that is not easily parallelizable |
| 10:00 | <othermaciej> | which is... almost all of them |
| 10:00 | <othermaciej> | the hardware people are going multicore because they can't make the cores much faster any more, at least not to the same degree |
| 10:00 | <roc> | it sucks less for languages where you can do more in the compiler |
| 10:00 | <othermaciej> | not cause they think any software people love inventing how to parallelize |
| 10:01 | <othermaciej> | it's certainly not great for C |
| 10:01 | <roc> | and it sucks more for languages where compilation depends on generating fast paths padded with lots of predictable guard code |
| 10:01 | <othermaciej> | it might be ok for Java since Java loves to spawn a hojillion threads |
| 10:02 | MikeSmith | is reminded by this conversation of Knuth recent interview comments on multicore architecture - http://www.informit.com/articles/article.aspx?p=1193856 |
| 10:02 | <othermaciej> | branches are already the hot spots in most x86 code (well at least code that doesn't die from register pressure) |
| 10:02 | <othermaciej> | I doubt intel plans to make it worse |
| 10:02 | <othermaciej> | multicore is just the harware guys giving up on moore's law |
| 10:02 | <roc> | no |
| 10:02 | <othermaciej> | no one is ballsy enough to try to build, say, an async CPU |
| 10:02 | <roc> | Moore's law is still giving them transistors |
| 10:02 | <othermaciej> | well ok, moore's law as popularly misunderstood |
| 10:02 | <othermaciej> | they have more transistors but can't turn them into more serial speed |
| 10:03 | <roc> | yeah. |
| 10:03 | <roc> | Moore's law never applied to heat dissipation |
| 10:04 | <Hixie> | an async cpu? |
| 10:04 | <othermaciej> | you can build logic without a clock |
| 10:04 | <othermaciej> | but it's very hard to get right |
| 10:04 | <othermaciej> | taking out all the clock lines and the need for synchronization can make it much faster though |
| 10:04 | <othermaciej> | (in theory) |
| 10:05 | <othermaciej> | without more power dissipation (since you took out all the wires to spread the clock signal around the chip) |
| 10:05 | <othermaciej> | maybe memristors will make a good low-power substrate for logic somehow |
| 10:08 | <roc> | we may end up with chips with hundreds of billions of transistors, but if you turn on more than 5% of them the computer melts |
| 10:09 | <roc> | which would make application-specific hardware feasible |
| 10:09 | <roc> | JS hardware |
| 10:09 | <roc> | mmmmmm |
| 10:10 | <othermaciej> | I'm sure that will be even more successful than the Java CPU |
| 10:10 | <roc> | hehe |
| 10:12 | <Hixie> | othermaciej: hm, interesting |
| 10:17 | <Philip`> | I think I've heard of some ARM CPU that can execute JVM bytecode directly - does anybody use that? |
| 10:19 | <takkaria> | there was an async ARM multiprocessor system for a while called Hydra |
| 10:19 | <hsivonen> | annevk: yes, HT is suggesting dispatch on nodeName |
| 10:20 | <annevk> | lol |
| 10:21 | <annevk> | the podcast Marcos and I made on this is live now, http://standardssuck.org/aria-in-html5 |
| 10:21 | <annevk> | it's too long and probably too boring to watch, but it was fun to make :) |
| 10:23 | <Lachy> | ha! nice response to the comment on youtube http://www.youtube.com/watch?v=tr0ra5hbFfo |
| 10:29 | <annevk> | "Views: 209" I don't really buy that |
| 10:31 | Lachy | couldn't stop watching it ;-) |
| 10:32 | <Hixie> | anything there i don't know already? :-) |
| 10:33 | <annevk> | Hixie, I don't think so |
| 10:37 | gsnedders | expects there are quite a few nice bits in it, but he can't be bothered to watch it |
| 10:38 | <gsnedders> | (I have an exam starting in 2.3 hours) |
| 11:00 | Hixie | dons his asbestos suit again |
| 11:00 | <hsivonen> | annevk: there's no cabal! |
| 11:05 | <othermaciej> | Hixie: on the other hand, allowing any vendor to extend the platform is how we ended up with <img> and <canvas> |
| 11:06 | <annevk> | "and suggesting that XML could somehow be replaced by HTML is like saying that JSON could somehow be replaced by Python." hmm |
| 11:06 | <othermaciej> | (but I am not gonna get into the extensibility debate) |
| 11:06 | hsivonen | notes that some people prefer using python over json for configuration files |
| 11:06 | <othermaciej> | (and I'm not sure I really want to cite <canvas> as a positive example) |
| 11:06 | <annevk> | othermaciej, <canvas> is the reason Apple now proposes stuff before implementing |
| 11:07 | <othermaciej> | ok lemme put it this way |
| 11:07 | <Hixie> | othermaciej: <img> was proposed to the community first |
| 11:07 | <annevk> | though maybe I don't need to tell you that :) |
| 11:07 | <Hixie> | othermaciej: <canvas> was a mitigated disaster |
| 11:07 | <othermaciej> | <canvas> sucks in details, but unlike <marquee> it does not suck in its very concept |
| 11:07 | <othermaciej> | it would be nice if it were better but it isn't in the "should not even exist" category |
| 11:07 | <hsivonen> | othermaciej: you are being culturally insensitive |
| 11:08 | <othermaciej> | hsivonen: to IE developers? |
| 11:08 | <Hixie> | othermaciej: <canvas> as a technology is fine. as an example of how we want the language extended process-wise, it's a terrible example. |
| 11:08 | <hsivonen> | othermaciej: no, to Chinese Web authors |
| 11:08 | Philip` | wonders why so many people with high-profile sites still choose to use <marquee> if it sucks |
| 11:08 | <Hixie> | othermaciej: we're still dealing with the effects of decisions apple made without consulting with the community |
| 11:08 | <Hixie> | othermaciej: e.g. the lack of a Path object |
| 11:09 | <othermaciej> | really? a Path object is easy to add |
| 11:09 | <othermaciej> | the parts of <canvas> that suck are the things that are terrible but that can't be taken away |
| 11:09 | <othermaciej> | however, if Apple had tried to follow W3C process, <canvas> would not exist |
| 11:09 | <Hixie> | adding a path object would likely either result in duplication of a chunk of the api or a very odd api |
| 11:09 | <othermaciej> | WHATWG process is certainly more conducive to stuff actually happening |
| 11:10 | <Hixie> | othermaciej: but anyway |
| 11:10 | <othermaciej> | Hixie: it's not uncommon for graphics context APIs to both have an implicit context path and explicit paths |
| 11:10 | <othermaciej> | (that is in fact how CoreGraphics works for instance) |
| 11:10 | <Hixie> | othermaciej: even if canvas was a brilliant example of perfection, it's still the case that we don't want individuals and vendors unilaterally extending text/html without community involvement |
| 11:10 | <Philip`> | othermaciej: Maybe that's because they all had the same lack of foresight when designing the initial API, and then had to remain backward compatible? :-) |
| 11:11 | <Hixie> | heh |
| 11:11 | <othermaciej> | no, it's just convenient to have an implicit path |
| 11:11 | <othermaciej> | same as it is convenient to be able to draw a rect directly, even though you could use lineTo |
| 11:12 | <othermaciej> | I don't think the implicit path is an API flaw |
| 11:12 | <othermaciej> | lack of explicit paths is an (easily rectified) API flaw |
| 11:13 | <othermaciej> | transforms affecting the creation of the implicit path is just plain weird but I can't remember if that is our fault or Mozilla's ultimately |
| 11:13 | <annevk> | I wonder what happens with a WG vote |
| 11:13 | <annevk> | on that issue |
| 11:14 | <hsivonen> | annevk: the WG votes to do something that has not been shown to be doable |
| 11:14 | <othermaciej> | globalAlpha / globalCompositeOperation is not a great design (better to push and pop transparency layers) |
| 11:15 | <othermaciej> | the fact that strokeStyle and fillStyle take random assortments of objects, some of which may be strings but none of which may be a CSSOM color is pretty daft |
| 11:15 | Philip` | still likes transforms affecting path creation, because otherwise it's impossible to do things like stoked ellipses |
| 11:15 | <hsivonen> | I'd love to see a vote where voting Yes required supplementing the vote with a concrete proposal |
| 11:15 | <annevk> | hsivonen, yeah, I'm not really sure how the numbers turn out, but I think people will request namespaces |
| 11:16 | <Philip`> | s/stoked/stroked/ |
| 11:16 | <Hixie> | supplementing the vote with a concrete proposal is easy and such proposals have been put forward many times |
| 11:16 | <Hixie> | supplementing the vote with a concrete WORKING proposal is what would be interesting |
| 11:16 | <Hixie> | but i've no idea how to require that |
| 11:17 | <Philip`> | Require each proposal to be shipped in a web browser with at least 1% market share before you're allowed to vote 'yes' with that proposal |
| 11:17 | <othermaciej> | that's a harsh requirement |
| 11:19 | <Hixie> | haha |
| 11:19 | <Hixie> | that'd be awesome |
| 11:19 | <annevk> | otoh, you need to have some buy in from implementors |
| 11:19 | <hsivonen> | I wonder if data-* could be supported using NVDL or if I need to escape outside of schemas |
| 11:19 | <othermaciej> | anyway, I am certainly not a fan of unilateral extensions as the first option |
| 11:19 | <othermaciej> | and in WebKit the only area where we have had any recently afaik is CSS |
| 11:19 | <Hixie> | vendor-prefixed ones in css are ok, given css's fallback model |
| 11:19 | <Hixie> | and you are working with the csswg on those |
| 11:19 | <annevk> | RB continues misunderstanding how namespaces work |
| 11:20 | <hsivonen> | does anyone know if NVDL has a human-readable (non-ISO) spec too? |
| 11:20 | <Hixie> | at least, insofar as they are letting you work with them |
| 11:20 | <annevk> | he's a fine example of why we should keep them outside of HTML :) |
| 11:20 | <hsivonen> | annevk: indeed |
| 11:20 | hsivonen | doesn't like ISO drafting rules |
| 11:21 | <annevk> | hsivonen, oh schemas don't have part of attribute name wildcards? |
| 11:21 | annevk | foresees trouble getting data-* into SVG |
| 11:21 | <hsivonen> | annevk: RELAX NG doesn't |
| 11:22 | <hsivonen> | annevk: RELAX NG allows you to wildcard the whole attribute or the local name but not part of the local name |
| 11:22 | <annevk> | data-* is one of the things I hope everyone implement quickly and we can advocate a lot |
| 11:23 | <annevk> | so that people start switching over and we get less issues introducing new attributes |
| 11:24 | hsivonen | wonders what ISO specs *aren't* fast-tracked |
| 11:25 | <Philip`> | C++? |
| 11:25 | <hsivonen> | perhaps |
| 11:27 | <hsivonen> | comparing OASIS and ISO versions of RELAX NG specs is a great example of how ISO makes specs unapproachable |
| 11:28 | <hsivonen> | bah. I'm just going to write a SAX filter that throws data-* out |
| 11:30 | <hsivonen> | I wonder how to best expose the filter in the generic UI... |
| 11:32 | <hsivonen> | I wonder if I should model data-* as a magic namespace |
| 11:33 | hsivonen | decides to unify namespace dropping code and data-* dropping code |
| 11:34 | <hsivonen> | no doubt this will make people scream |
| 11:36 | hsivonen | temporarily undoes the decision |
| 11:38 | <hsivonen> | because that would allow data-* on non-HTML elements as a side effect |
| 11:39 | <hsivonen> | generic is hard |
| 11:41 | <Lachy> | is allowing data-* on non-HTML elements necessarily a bad thing? |
| 11:41 | <hsivonen> | Lachy: not if I can blame it on Hixie :-) |
| 11:41 | <hsivonen> | Lachy: currently I can't AFAICT |
| 11:42 | <Lachy> | it's not really that much different from allowing aria-* on generic elements |
| 11:42 | <annevk> | i'd like data-* to be generic like aria-* |
| 11:42 | <Hixie> | there is one major difference |
| 11:42 | <hsivonen> | Lachy: I don't allow aria-* on generic elements |
| 11:42 | <Hixie> | in that no spec allows it yet :-) |
| 11:42 | <annevk> | though maybe we should have some more experience with data-* first |
| 11:42 | <hsivonen> | Lachy: and technically the two are *very* different in V.nu |
| 11:42 | <Lachy> | Hixie, that's only a minor barrier to get across |
| 11:43 | <annevk> | putting it in the spec is, dealing with the storm of comments might be more tough |
| 11:43 | <hsivonen> | as of ARIA 1.0, the aria-foo attributes can be finitely enumerated |
| 11:43 | <hsivonen> | the data-* attributes cannot, because they are countably infinite |
| 11:43 | <Lachy> | filing such comments in the 'ignore' folder is an effective way to deal with them |
| 11:45 | <hsivonen> | also, aria-foo is more sensitive to validation than just throwing away, which is basically what data-* needs |
| 11:45 | <annevk> | I don't like that MathML strips whitespace and such in attributes |
| 11:46 | <hsivonen> | annevk: as implemented, it doesn't |
| 11:46 | <hsivonen> | annevk: spec bug, IMO |
| 11:46 | <hsivonen> | annevk: V.nu deliberately violates the MathML spec here |
| 11:49 | <annevk> | are they fixing it? |
| 11:49 | <Hixie> | see mail from david just now |
| 11:49 | <Hixie> | wait |
| 11:50 | <Hixie> | what do you mean it strips whitespace? |
| 11:50 | <Hixie> | during parsing? |
| 11:52 | <annevk> | Hixie, type=" checkbox " is not a checkbox in HTML, for similar constructs in MathML that would be a "checkbox" |
| 11:53 | <hsivonen> | according to spec that is--not according to Gecko |
| 11:54 | <hsivonen> | annevk: I got the impression they didn't want to fix the spec |
| 11:58 | <Hixie> | annevk: ah |
| 11:58 | <Hixie> | how silly |
| 11:59 | Hixie | reads the mail in his AAA-Productivity folder |
| 11:59 | <Hixie> | there was nothing there that my life would have been worse if i had missed reading it |
| 11:59 | <Hixie> | glad my filters are still working well |
| 11:59 | <annevk> | is that like really good or is it some vague remark to accessibility? |
| 12:00 | <annevk> | ah, guess that explains it :) |
| 12:00 | <othermaciej> | I assume it is a hack for a mail client that insists on alphabetizing IMAP folders or something |
| 12:00 | <Hixie> | it's a carefully named folder |
| 12:01 | <annevk> | othermaciej, then you'd have used ZZZ-x :) |
| 12:01 | <Lachy> | I don't see an aaa-productivity folder on whatwg.org/issues/ - what's in it? |
| 12:01 | <Hixie> | which fully shows the importance i place on its contents |
| 12:01 | <Hixie> | in case someone should stumble across it one day |
| 12:01 | <Hixie> | i wouldn't want them insulted |
| 12:01 | <othermaciej> | heh |
| 12:02 | <Hixie> | Lachy: all mail sent from: or to: someone who sends, ah, very important e-mails |
| 12:02 | <Hixie> | and who causes people to send even more important e-mails |
| 12:03 | <roc> | I'm pretty sure we trim whitespace when interpreting MathML attributes |
| 12:03 | <roc> | at least in most cases |
| 12:09 | <hsivonen> | roc: http://lists.w3.org/Archives/Public/www-math/2007Dec/0008.html |
| 12:10 | <hsivonen> | roc: I haven't retested with Firefox 3 |
| 12:11 | <Hixie> | 2188 e-mails to go |
| 12:11 | <Hixie> | i guess i'll do that tomorrow |
| 12:11 | <Hixie> | bed time no |
| 12:11 | <Hixie> | w |
| 12:11 | <annevk> | tomororw, huh? hah |
| 12:12 | <annevk> | g'night |
| 12:12 | <roc> | hsivonen: oh well |
| 12:15 | <Hixie> | kittens, why are you all still arguing this aria- thing |
| 12:16 | hsivonen | isn't |
| 12:16 | annevk | is not a kitten |
| 12:17 | <annevk> | but yeah... |
| 12:17 | <othermaciej> | you should just give up and join the Cult of the Sacred:Colon |
| 12:18 | <othermaciej> | don't worry about why:you are using:it, just use:it every:where |
| 12:18 | <annevk> | it:starts making:sense null:now |
| 12:18 | <Hixie> | anne: i meant "kittens" as a word of exasperation, not a reference to you :-P |
| 12:18 | <Hixie> | like people say "jesus" |
| 12:18 | <Hixie> | anyway |
| 12:18 | <annevk> | i know :D |
| 12:18 | <Hixie> | really going to bed now :-) |
| 12:18 | <Hixie> | nn |
| 12:18 | <othermaciej> | me too |
| 12:19 | <annevk> | see you guys tonight |
| 13:53 | Philip` | notices that he has zero pages using ⟨ or ⟩ |
| 14:38 | <Lachy> | http://my.opera.com/core/blog/selectors-api |
| 14:38 | <Lachy> | that was posted yesterday. It's Opera's new blog for the Core department |
| 14:42 | Dashiva | pokes Lachy with a [] instead of new Array() |
| 14:44 | <Lachy> | both work |
| 14:44 | <Lachy> | Is there a reason to prefer [] over new Array();? |
| 14:44 | <Philip`> | But one is horrifically ugly |
| 14:44 | <MikeSmith> | Lachy: is this hardcore or softcore? |
| 14:44 | <Lachy> | which one? |
| 14:44 | <MikeSmith> | or slowcore? |
| 14:45 | <MikeSmith> | Lachy: nuttin' ... was just making a dumb joke |
| 14:45 | <Dashiva> | Lachy: new Array is slower, longer, and error-prone when the array is initialized to contain a single number |
| 14:45 | <MikeSmith> | Lachy: you work for Lars-Erik? |
| 14:45 | <Philip`> | Lachy: The one that doesn't look like Perl or Python |
| 14:46 | <Lachy> | MikeSmith, Wilhelm is my manager |
| 14:47 | <Lachy> | Lars Erik is the manager of the whole core dept. I think |
| 14:48 | <Lachy> | Philip`, anything that doesn't look like Perl has to look good :-) |
| 14:48 | <Philip`> | Lachy: There really needs to be a link from the individual posts back to the blog's front page |
| 14:48 | <Philip`> | (like making the heading image be a link back) |
| 14:49 | <Philip`> | (Also pretty much every other Opera blog has that same stupid usability bug) |
| 14:49 | <Lachy> | there are a lot of things that my.opera needs to improve. I'll pass that onto the appropriate people |
| 14:49 | <Dashiva> | That's because it's the default, probably :) |
| 14:51 | <Philip`> | Dashiva: I thought I remembered hearing that new Array(...) was significantly faster than [...] (in Firefox) |
| 14:51 | <Lachy> | I changed new Array() to []. |
| 14:52 | <Lachy> | hmm. I think I need to write a test to see which one really is faster. |
| 14:52 | <Philip`> | var t=new Date();for(var i=0;i<100000;++i)var z=[i,i,i,i,i,i];alert(new Date()-t) |
| 14:53 | <Philip`> | var t=new Date();for(var i=0;i<100000;++i)var z=new Array(i,i,i,i,i,i);alert(new Date()-t) |
| 14:53 | <Philip`> | In Firefox 3, the former takes 270ms, the latter takes 130ms |
| 14:53 | <Philip`> | but unless you're initialising a hundred thousand arrays you're not going to notice the difference so you should use [...] because it's so much prettier |
| 14:54 | <Philip`> | The same code in Opera 9.5 is the other way around, taking 430ms and 540ms |
| 14:56 | <Philip`> | In Safari 3.0 it's 160ms/130ms |
| 14:58 | <Philip`> | In IE6 it's roughly 950ms for both |
| 14:58 | <Philip`> | If you really care about performance, nobody uses Opera so you should use new Array() |
| 14:58 | Dashiva | wonders if Philip` forgot about IE |
| 14:59 | <Philip`> | ? |
| 14:59 | <Dashiva> | IE7 is faster with [] than new Array |
| 15:00 | <Philip`> | Oh |
| 15:01 | <Dashiva> | And for a proper test, you have to check with 0 and large_number_value initial values too :) |
| 15:01 | MikeSmith | finally actually reads Lachy's Selectors API writeup at Opera core blog |
| 15:01 | <MikeSmith> | Lachy: nice article |
| 15:01 | <MikeSmith> | short but sweet |
| 15:01 | <Lachy> | thanks |
| 15:02 | <Philip`> | In IE7 on totally different hardware, both take about 1600ms |
| 15:02 | <Philip`> | Dashiva: Do you have evidence for your claim? :-) |
| 15:03 | <MikeSmith> | Lachy: is this the first public acknowledgment of the Selectors API support in Opera? |
| 15:04 | <Philip`> | Lachy: I think the first sentence in that article is too complex and hard to parse, but otherwise it looks good :-) |
| 15:05 | <Lachy> | Philip`, I don't see any problems with "The Selectors API specification currently being worked on within the WebAPI working group at the W3C defines DOM APIs designed to make it possible to select elements within the document using Selectors." |
| 15:05 | <Lachy> | would it work better if there were commas placed in it at appropriate places? |
| 15:06 | <MikeSmith> | The Selectors API specification (currently being worked on within the WebAPI working group at the W3C) defines DOM APIs designed to make it possible to select elements within the document using Selectors. |
| 15:06 | <Philip`> | Maybe "The Selectors API specification, currently being ... at the W3C, defines DOM APIs that make it possible ..." |
| 15:07 | <Lachy> | fixed |
| 15:09 | <Philip`> | I'd probably s/designed to make it possible/that make it possible/ too because there's too many verbs at the moment :-) |
| 15:09 | <Philip`> | but I could just be wrong |
| 15:09 | <Philip`> | Anyway, the commas solve the problem where I misparsed the first half of the sentence when first reading it |
| 15:12 | <Philip`> | "Our implementation also partially supports the namespace resolver features" - is there any information on how partial that is? |
| 15:13 | <Lachy> | I can't remember what ours is missing. |
| 15:16 | <Lachy> | actually, I think, as currently specced, it fully supports the NSResolver |
| 15:17 | <Lachy> | the only issue is that our implementation doesn't deal with DOM modifications by the resolver according to the spec, but that's due to the fact that I haven't determined what to do about that yet |
| 15:17 | <Lachy> | although, please file bugs if you find them |
| 15:22 | Philip` | finds a site which gives an ASP NullReferenceException if he tries to log in with Opera 9.2, but works fine in 9.5 |
| 15:24 | <Philip`> | (which is kind of annoying because I don't want to use 9.5 yet) |
| 15:33 | <Philip`> | Oh, whoops, it was only failing in Opera 9.2 because I disabled referrer logging there |
| 15:54 | <annevk> | Despite the flaws, Ubuntu is quite nice. Installed it within 30 minutes on a new PC and it seems that my mom is able to use it :) |
| 15:55 | <annevk> | It complained about something related to the wireless card and drivers, but that worked so I'm not really sure what it was about... |
| 15:55 | <annevk> | Maybe they are "not free" |
| 16:14 | Philip` | wonders if installing Ubuntu from CD experiences the problems with OpenSSL |
| 16:14 | <mpt> | Philip`, yes, please make installing updates the first thing you do after restarting |
| 16:15 | <mpt> | We will have new CD images Real Soon Now |
| 16:17 | <Philip`> | (Fortunately I only have one Ubuntu server which is older than that bug so its keys are fine, and an Ubuntu VM image which is probably affected but is only run locally and accessed with serial-console-over-UDP instead of SSH) |
| 17:33 | <MikeSmith> | done. |
| 17:33 | <MikeSmith> | http://dev.w3.org/html5/pubnotes/ |
| 17:33 | <MikeSmith> | up to date, as of r1687 today |
| 17:34 | <MikeSmith> | corrections/additions welcome |
| 17:34 | Philip` | wonders what HTML5 has to do with pubs |
| 17:34 | <MikeSmith> | heh |
| 17:35 | <MikeSmith> | I will take a rest f2f a while now |
| 17:35 | <Philip`> | "It primarily document changes" - documents |
| 17:37 | <Philip`> | "You can find the source for the current version of this document in the [W3C source repository]." - that links to the latest version, not to the source or to a source repository browser |
| 17:37 | <MikeSmith> | Philip`: document/documents changes made |
| 17:39 | <Philip`> | "In the “Conformance checkers” subsection, the text of a statement was updated to now read (added text highlighted:" - missing ')' |
| 17:39 | <MikeSmith> | Philip`: source link fixed |
| 17:40 | <Philip`> | Validators complain because you need something like <blockquote><p><q>... and are missing the <p>, I think |
| 17:41 | <MikeSmith> | missing paren now added |
| 17:41 | <Philip`> | It might be kind of nice if the references to spec sections were links |
| 17:41 | <MikeSmith> | Philip`: yeah, I need to fix that blockquote part |
| 17:41 | <MikeSmith> | karl pointed out the validity problem |
| 17:42 | <MikeSmith> | the source is in text/html and validates as HTML5 fine |
| 17:42 | <MikeSmith> | problem is that I need to transform it to XHTML per W3C pubrules |
| 17:42 | <MikeSmith> | I will make turn the references to spec sections into links tomorrow |
| 17:42 | <Philip`> | <code class="element">embed</code> has kind of ugly blue-on-blue styling - might be nice to use the same styles as the spec |
| 17:44 | <MikeSmith> | yeah, I can switch that styling any time |
| 17:44 | <MikeSmith> | spec just uses orangered for everything |
| 17:45 | <Philip`> | The comma in "Section 2.2, Elements" looks unnatural to me - a colon or dot would seem more normal. (But I'm just being very picky, so feel free to ignore me ;-) ) |
| 17:47 | <hsivonen> | annevk: I liked particularly the second half of the first episode of standards suck |
| 17:48 | <Philip`> | MikeSmith: "Some changes were made Within the “Dynamic markup insertion in XML” subsection in this section" - s/W/w/ |
| 17:48 | <hsivonen> | annevk: just curious: what kind of decision process did you have for choosing the video host? |
| 17:49 | <hsivonen> | annevk: in particular, did you knowingly reject blip.tv? |
| 17:49 | <MikeSmith> | Philip`: yeah, I will probably globally replace the comma thing |
| 17:50 | <MikeSmith> | Philip`: made W->w change |
| 17:50 | <Philip`> | MikeSmith: "A placeholder for a “URLs” subsection was added, with editorial notes about what its intended will be." - lack of grammar near end of sentence |
| 17:50 | <Philip`> | or lack of a word or something |
| 17:50 | MikeSmith | thinks he probably meant to put "intended purpose" |
| 17:51 | <MikeSmith> | made it "intended purpose" |
| 17:53 | <Philip`> | "the phrase “valid browsing context name” was emended to become" - I've never heard the word "emend" before :-) |
| 17:55 | <MikeSmith> | Philip`: yeah, any alternatives to that word welcome |
| 17:55 | <gsnedders> | MikeSmith: corrected? |
| 17:55 | <MikeSmith> | it is any actual real dictionary word |
| 17:56 | <gsnedders> | MikeSmith: improved, becoming |
| 17:56 | <MikeSmith> | "refined" is probably best |
| 17:57 | gsnedders | isn't a very good thesaurus |
| 17:57 | <MikeSmith> | but I think I used "emend" to avoid overuse of "refined" |
| 17:58 | <Philip`> | MikeSmith: "In this section, an statement was added" s/n// |
| 17:58 | <gsnedders> | Philip`: that leaves "I this section, an statement was added" |
| 17:59 | <Philip`> | gsnedders: No, these are context-sensitive regexps that only match in the intended location |
| 17:59 | <gsnedders> | Philip`: Ah. |
| 18:00 | <Philip`> | gsnedders: They are not mechanically computable, but that's okay because we're not computers |
| 18:01 | <MikeSmith> | Philip`: an->a changed |
| 18:04 | <Philip`> | MikeSmith: "This section concerns elements used to mark up content at the “text level” (as opposed to the “sectioning” or “grouping” levels." - missing ')', brain stack overflow |
| 18:05 | <MikeSmith> | Philip`: :) fixed |
| 18:07 | <MikeSmith> | one thing, I call the DOM formalisms "interface definitions" throughout.. most of the time, seems like we just call each instance of those "an IDL" .. which I've never really liked and which I don't think casual readers are going to understand |
| 18:08 | <Philip`> | MikeSmith: It might be helpful to group changes, e.g. the removal of automatic cross referencing results in a lot of elements having "In this section, the following statement was removed completely: “the title attribute has special semantics on this element when used with the dfn element”." |
| 18:08 | <Philip`> | which is kind of repetitive, and not immediately obvious that it's repetitive because it's always the same change |
| 18:08 | <MikeSmith> | Philip`: yeah, I thougt about that, but it sorta comes to a high-level choice of either grouping them by related change or grouping them by section |
| 18:09 | <MikeSmith> | ... and it seemed like strict grouping by section would be easier |
| 18:09 | <MikeSmith> | ... and I'm lazy so I went with that |
| 18:09 | <Philip`> | so perhaps all the later elements should just say "Affected by the <a href=#xref-removal>removal of automatic cross referencing</a>" and point back at the bit in dfn |
| 18:10 | <MikeSmith> | OK, yeah, that might work better |
| 18:10 | <Philip`> | Primarily grouping by section seems good; it just might be nice in a few places to cut across that sectioning system |
| 18:11 | <MikeSmith> | true, yeah |
| 18:11 | <Philip`> | (The SVN logs are there for people who want things grouped by changes) |
| 18:13 | <takkaria> | MikeSmith: nice changelog! |
| 18:14 | <Philip`> | "the difficulties of attempting to mark up edits that cross implied paragraphs" occurs twice in adjacent sections, which seems unnecessarily repetitive; perhaps the first paragraph's parenthetical comment could be removed |
| 18:16 | <Philip`> | "The prefatory text for one of the examples was updated to read:" - that's another word I don't think I've ever heard before :-p |
| 18:17 | <Philip`> | (That's not a bad thing, since it gives me a chance to expand my vocabulary :-) ) |
| 18:17 | <MikeSmith> | takkaria: thanks |
| 18:17 | <MikeSmith> | Philip`: "introductory text" is maybe less pedantic |
| 18:18 | <Philip`> | "* an iframe name, ... * an iframe sandbox, ..." - that should probably say "attribute" somewhere |
| 18:19 | <Philip`> | Also that list is missing '.'s at the ends of sentences |
| 18:20 | <Philip`> | and "conformance criteria were added in relation to behavior when the sandboxed plugins browsing context flag is set" is missing a capital letter and '.' which makes it inconsistent with the rest of its list |
| 18:20 | <MikeSmith> | Philip`: was intentional not to refer to with "attribute" .. to mean that those are abstract characteristics associated with the iframe |
| 18:20 | <MikeSmith> | ... but perhaps that doesn't make much sense |
| 18:23 | <Philip`> | MikeSmith: Ah, that sounds reasonable |
| 18:23 | <Philip`> | MikeSmith: "This specification does not define a mechanism for interacting with third-party handlers, as it is expected to be user-agent-specific. Some UAs might opt to support a plugin mechanism such as the Netscape Plugin API; others may use remote content convertors or have built-in support for certain types." |
| 18:23 | <MikeSmith> | Philip`: I fixed the punctuation/caps stuff |
| 18:23 | <Philip`> | ^ that text was modified a bit, e.g. to remove the spelling errors, not just moved |
| 18:23 | <Philip`> | (and pubnotes has the old pre-modified version) |
| 18:23 | <MikeSmith> | OK |
| 18:24 | <MikeSmith> | I guess that was changed in the last few days |
| 18:24 | <Philip`> | (which confused me since I was looking for the spelling error in the spec and couldn't find it) |
| 18:24 | <MikeSmith> | will grabe the latest |
| 18:25 | <MikeSmith> | Philip`: you mean the text in 3.12.4 ? |
| 18:25 | <Philip`> | "In the “User interface” subsection, an instance of the phrase “if scripting is disabled” was changed to read, “if the media element is without script." - missing closing quote |
| 18:25 | <MikeSmith> | the "embed element" section? |
| 18:25 | <Philip`> | MikeSmith: Yes |
| 18:26 | <MikeSmith> | oK |
| 18:26 | <MikeSmith> | I think I will remove those blockquote excerpts from the embed section |
| 18:26 | <MikeSmith> | and just refer to them instead |
| 18:27 | <MikeSmith> | fixed the missing quote char |
| 18:31 | <Philip`> | "The text of the section was revised to remove references to the colSpan and rowSpan DOM attributes and to instead reference the headers DOM attribute." - not sure what the exact changes were, but I'd guess it should be "also" rather than "instead" |
| 18:32 | <Philip`> | "the conformance requirements for the td and th elements now state they they implement interfaces that inherit from that interface" - s/they they/that they/ |
| 18:35 | <MikeSmith> | Philip`: change "headers" part to "and to add references to" |
| 18:35 | <MikeSmith> | "they they"->"that they" fixed |
| 18:36 | <Philip`> | "(Note that the “XXX4“ name is simply a placeholder; it is not intended that the method will be implemented with that literal name.)" - that's a shame :-( |
| 18:36 | <MikeSmith> | heh |
| 18:37 | <MikeSmith> | I am reasonably sure that if I didn't put that, somebody would post a message saying, What is it with the name of this XXX4 method? |
| 18:37 | <Philip`> | "The word “origin” was replaced by “value” in the sentence that now reads, “If the scheme is ‘file’, then the user agent may return a UA-specific value”, some instances of the phrase “the same as the origin” were refined to read “equal to the origin”." - should that be a semicolon before the "some"? |
| 18:39 | <MikeSmith> | Philip`: made it a separate list item now |
| 18:40 | <Philip`> | "the addition of a statements related to the source browsing context" - s/s// |
| 18:40 | <Philip`> | or s/a // or whatever |
| 18:41 | <Philip`> | "The following not was added: The above algorithm is a willful violation of the HTTP specification." - s//e/ unless someone already mentioned that one |
| 18:41 | <Philip`> | "Also in he “Storing name/value pairs” subsection" - s//t/ |
| 18:41 | <MikeSmith> | "a statements" fixed |
| 18:42 | <MikeSmith> | not->note fixed already |
| 18:42 | <Philip`> | "This section remains largely unchanged, though some significant changes were made to to — among those, the following:" - to to? |
| 18:43 | <Philip`> | "In the subsection that defines the “” link type, a statement was added that Only one link is created for the set of one or more “up” keywords and, if present, the “index” keyword." - is that really meant to be “”? |
| 18:43 | <MikeSmith> | toot toot fixed |
| 18:45 | <MikeSmith> | Philip`: "" link type should have been "UP" .. fixed that |
| 18:45 | <Philip`> | "asyncronous" |
| 18:46 | <MikeSmith> | "asyncronous" fixed |
| 18:46 | <Philip`> | "the range “U+0030 DIGIT ZERO .. U+0039 DIGIT NINE” as added" - s/as/was/ |
| 18:47 | <Philip`> | "statement were added" |
| 18:49 | <MikeSmith> | "as added" fixed |
| 18:49 | <Philip`> | "to include named character references commonly used in MathML documents" - they're not "commonly used", they're just "potentially used" or "supported" or something |
| 18:50 | <MikeSmith> | "statement were" fixed |
| 18:51 | <MikeSmith> | Philip`: OK, I guess I will change that to "for potential use in MathML" |
| 18:51 | <Philip`> | Hixie: Section 10 (#no) says "This section is non-normative." but then 10.4 gives normative requirements |
| 18:51 | <BenMillard> | MikeSmith, I remember asking about a "no mail" option last year: http://lists.w3.org/Archives/Public/public-html/2007Jun/thread.html#msg1011 and http://lists.w3.org/Archives/Public/public-html/2007Jul/thread.html#msg77 |
| 18:52 | <MikeSmith> | made it "of potential use" |
| 18:52 | <MikeSmith> | BenMillard: so what was the resolution of that? |
| 18:52 | <BenMillard> | MikeSmith, it seems W3C doesn't think you can participate in a group unless you are on the mailing list |
| 18:52 | <MikeSmith> | BenMillard: I guess that kind of makes sense |
| 18:53 | <Dashiva> | You could always sign up with an address you don't read mail for ;) |
| 18:53 | <BenMillard> | MikeSmith: written another way, it seems W3C thinks you can only participate if you are on the mailing list |
| 18:53 | <Philip`> | MikeSmith: Oh, I think I got to the end |
| 18:53 | <MikeSmith> | Philip`: cool. how long did it take? |
| 18:53 | Philip` | checks his IRC history |
| 18:54 | <Philip`> | Um, too long :-p |
| 18:54 | <MikeSmith> | heh |
| 18:54 | <MikeSmith> | ~70mins maybe |
| 18:54 | <Philip`> | (More than an hour, though not entirely with full concentration) |
| 18:54 | <MikeSmith> | and you know this material pretty well already |
| 18:54 | <hsivonen> | looks like Marcos walked right into a bikeshed with widget: :-( |
| 18:55 | <MikeSmith> | Philip`: so I reckon it would be a good 90-minute read for somebody not familiar with it |
| 18:55 | <MikeSmith> | hsivonen: yeah, dunno that he knew what he'd be in for |
| 18:55 | <Philip`> | MikeSmith: If they're trying to read and understand all of it, that sounds about reasonable |
| 18:55 | <MikeSmith> | ... I should have thought about it & warned him |
| 18:57 | <MikeSmith> | Philip`: thanks much |
| 18:58 | <Philip`> | MikeSmith: I'm not going to bother checking whether you missed any changes, but it looks quite comprehensive, so hopefully it will be helpful to people :-) |
| 18:59 | <Philip`> | MikeSmith: It'd be nice to summarise the high-level changes, for lazy people, like "Added support for inline MathML in the HTML syntax" and "Added simple text drawing API to <canvas>" etc |
| 18:59 | <BenMillard> | MikeSmith, it's certainly exhaustive. I think very few people will read all of it, or even any significant portion of it, but I can well imagine people skimming through to find out the history of their pet issue(s) |
| 19:00 | <MikeSmith> | Philip`: annevk did that already in a separate doc, so I will just make the build script pull that out from cvs and include it |
| 19:00 | <MikeSmith> | BenMillard: yeah, that's the use case |
| 19:00 | <MikeSmith> | mainly |
| 19:01 | <Philip`> | MikeSmith: Ah, right |
| 19:01 | <MikeSmith> | though annevk summary list is missing a few things that ought to be in it, I think |
| 19:02 | <MikeSmith> | ... though I can't think of specifically what at the moment |
| 19:02 | <BenMillard> | MikeSmith, annevk's doc has been updated during this month, so maybe what was missing has been added now? |
| 19:03 | <BenMillard> | (for the record, talking about this doc: http://dev.w3.org/html5/html4-differences/ I take it?) |
| 19:03 | <MikeSmith> | BenMillard: saw the latest a couple days back and remember not seeing something i thought should be there |
| 19:03 | <BenMillard> | ah, ok |
| 19:26 | <hsivonen> | so it seems data-* is the first feature Hixie has introduced that RELAX NG is really bad at *allowing* |
| 19:27 | <hsivonen> | After pondering this, I think I'm going to make the preset HTML5 schemas magic and fake it |
| 19:27 | <hsivonen> | So I think at this point, I'm not going to expose this feature to custom schemas |
| 19:30 | <hsivonen> | hendry: where did you get an instance of the Iris browser to run? is it shipping with some device already? |
| 20:58 | <takkaria> | nice, a post from the IE team wanting to implement HTML5 behaviour in at least a bit of their parser |
| 21:37 | <Lachy> | takkaria, it's unfortnate he missed the part in the spec where the answer is clearly spelled out for them |
| 21:37 | <Lachy> | it took me just a few minutes to find the appropriate section talking about the stack of open elements. |
| 21:38 | <Philip`> | That only helps if you know you're looking for the stack of open elements |
| 21:38 | <Philip`> | which is not an obvious thing to know when you're trying to work out what happens when a script changes its ancestor nodes |
| 21:38 | <Lachy> | Philip`, he should have. Hixie told him to look at that section http://blogs.msdn.com/ie/archive/2008/04/23/what-happened-to-operation-aborted.aspx#8423021 |
| 21:41 | <takkaria> | Lachy: it is unfortunate, but it's still dialogue |
| 21:42 | <Lachy> | yeah, it's certainly good that they're trying to fix it. |
| 21:59 | Hixie | replies to travis |
| 22:03 | <takkaria> | Lachy: my main point being, they're asking *before* they implement rather than after |
| 22:05 | <Hixie> | as far as i can tell they're asking after they tried and failed :-) |
| 22:19 | <Lachy> | Hixie, that's a really good explanation. Maybe you should consider adding it to the spec to illustate how the algorithm works. |
| 22:21 | <Hixie> | hm, good idea |
| 22:23 | <Lachy> | and a similar example for the adoption agency algorithm would help too |
| 22:23 | <Hixie> | yeah i plan on adding diagrams and stuff once the section is stable |
| 22:25 | <takkaria> | in SVG, I would hope :P |
| 22:36 | <annevk> | hsivonen, I'd have to ask Marcos. I don't really know |
| 22:36 | <annevk> | I hope we start publishing the original files as well as I don't have Flash :) |
| 22:40 | <annevk> | first spec I managed to get to CR involves namespaces: http://www.w3.org/TR/2008/CR-css3-namespace-20080523/ |
| 22:40 | <annevk> | I hope everyone appreciates the irony just as much as I do |
| 23:37 | <annevk> | Lachy, don't argue with RB |
| 23:38 | <annevk> | Lachy, web standards 101 :) |
| 23:38 | <Lachy> | annevk, I know. I just couldn't resist |
| 23:39 | <Lachy> | I'm sorry |
| 23:39 | <Lachy> | But I like how his only response was to claim that he didn't make the assumption, which he clearly must have given his claims |