| 00:41 | <annevk> | fuck XML: http://www.starbucks.com/menu/drinks/tazo-tea/chai-latte (use Opera) |
| 00:46 | <Rik`> | annevk: this is not the time to drink coffee ! |
| 00:47 | <annevk> | I was attempting to do some background reading for my short post :) |
| 00:47 | <Rik`> | annevk: btw, why do you think image fallback is useless ? |
| 00:48 | <annevk> | it seems like way too complex feature for the gain it gives you |
| 00:48 | <annevk> | serving up lots of different images; do you see yourself doing it? |
| 00:48 | <Rik`> | yes |
| 00:48 | <Rik`> | I'm actually doing it on my not really up to date resume |
| 00:49 | <annevk> | because? |
| 00:49 | <Rik`> | I wish I could serve SVG and then PNG |
| 00:50 | <annevk> | it seems a new feature is too late to solve that problem |
| 00:50 | <Rik`> | this one |
| 00:50 | <Rik`> | but what about new image formats ? |
| 00:50 | <annevk> | I think we can handle a new image format every ten years without much trouble |
| 00:52 | <Rik`> | I think it makes it harder to introduce new image formats |
| 00:52 | <Rik`> | none of the jpeg alternatives as been widely used |
| 00:52 | <Rik`> | or apng/mng |
| 00:53 | <annevk> | APNG just does not have wide enough adoption yet |
| 00:53 | <Rik`> | like SVG |
| 00:54 | <Rik`> | when a new format is introduced, you have to wait for complete interoperability to use it |
| 00:54 | <annevk> | APNG has fallback |
| 00:54 | <Rik`> | with fonts, video and audio, you don't need that |
| 00:54 | <annevk> | I think the situation with font formats is not very nice either |
| 00:55 | <Rik`> | if I'm doing a throbber, I need the animation |
| 00:55 | <Rik`> | so I would like to use APNG for maximum quality and GIF as a fallback |
| 00:56 | <Rik`> | the only problem that I know with fonts is that IE doesn't know how to parse format() |
| 00:56 | <annevk> | I'm somewhat skeptical people would go through all that trouble |
| 00:56 | <annevk> | Some people would, sure, but most? |
| 00:57 | <Rik`> | I think it's quite important regarding the interest for web performance |
| 00:57 | <annevk> | E.g. with <video> the situation seems to be H264 or Flash :/ |
| 00:58 | <annevk> | Though YouTube does do the honorable thing there, admittedly |
| 00:58 | <Rik`> | this is only because contents are already encoded in H264 |
| 00:58 | <annevk> | I think there's more interesting things to focus on... Like styling form controls. |
| 00:59 | <Rik`> | oh yes, |
| 00:59 | <annevk> | Anyway, should really be sleeping now :) |
| 00:59 | <Rik`> | without coffee :) |
| 01:00 | <annevk> | or tea, yes :) |
| 01:49 | <heycam> | "Apologies for cross-posting"? maybe don't do that then... |
| 01:49 | <othermaciej> | it wasn't even a proper cross-post |
| 01:50 | <heycam> | yeah, it's worse than a proper cross-post |
| 01:50 | <heycam> | made me realise how many w3c lists i'm subscribed to though :o |
| 01:54 | smaug____ | got that email 14 times |
| 02:02 | <MikeSmith> | http://twitter.com/#!/brianleroux/status/15936952956096512 "While V8 is fast it has no access to the Android APIs without authoring bridge code. Rhino reflects. This is nice and fast." |
| 02:03 | <MikeSmith> | maybe I'll write write Java bindings to V8 |
| 02:12 | <MikeSmith> | oh, that wouldn't do anything to help that problem |
| 02:12 | <MikeSmith> | so maybe I won't do it after all |
| 02:14 | <MikeSmith> | heycam: do you use mercurial patch queues much? |
| 02:18 | <heycam> | MikeSmith, yeah, but I'm no pro |
| 02:18 | <heycam> | just simple uses so far |
| 02:20 | <MikeSmith> | I've been catching up on validator bugs lately, and with getting it more up to date with the spec -- adding the track element and such |
| 02:20 | <MikeSmith> | meanwhile. I have stuff in my workspace that I'm not ready to push to the main validator repo |
| 02:23 | <heycam> | sounds like a reasonable thing to use queues for |
| 02:23 | <MikeSmith> | but would like to have it in a repo other than just my local workspace, and maybe versioned while I'm working on it, so I can roll back if I need to |
| 02:23 | <MikeSmith> | heycam: do you push your patch queues to somewhere, or do you just maintain them in your local workspace repo? |
| 02:24 | <heycam> | MikeSmith, just in my local workspace repo. I have wanted to push them somewhere though, so that my current unfinished patches are viewable/fetchable from elsewhere. |
| 02:24 | <MikeSmith> | yeah |
| 02:25 | <heycam> | MikeSmith, I suspect that involves having the patch queue being versioned and then somehow pushing that periodically. |
| 02:25 | <MikeSmith> | yeah |
| 02:25 | <Rik`> | why not use branches ? |
| 02:25 | <MikeSmith> | heycam; bitbucket has some features to facilitate that |
| 02:26 | <heycam> | aha |
| 02:26 | <heycam> | Rik`, could well be that branches support this better |
| 02:26 | <MikeSmith> | Rik`: yeah, branches are certainly be a way |
| 02:26 | <heycam> | I'm learning hg purely by using it in the ways mozilla people do |
| 02:26 | <MikeSmith> | I'm just trying to figure out if this mercurial patch queue thing is a better way for my case or not |
| 02:26 | <heycam> | which might not be the "canonical" way... |
| 02:27 | <heycam> | MikeSmith, I can't compare it to anything else then, sorry :) |
| 02:27 | <MikeSmith> | the mozilla docs on it are nice |
| 02:27 | <MikeSmith> | heycam: I noticed your name on the mozilla tutorial page about using queues |
| 02:28 | <heycam> | MikeSmith, I must've made some exceptionally minor edit to the page last :-) |
| 02:28 | <MikeSmith> | the caveats on that page should be in the main upstream docs for the patch-queue feature |
| 02:29 | <MikeSmith> | the stuff about, "Be very careful because this feature can cause you to lose changes" or whatever |
| 02:30 | <MikeSmith> | "You can destroy work with MQ. MQ puts you in a position where you're doing fairly complicated stuff to your uncommitted work. Certain operations make it easy to lose work. Watch your step. |
| 02:30 | <MikeSmith> | https://developer.mozilla.org/en/Mercurial_queues |
| 02:30 | <heycam> | MikeSmith, yeah it seems like good advice |
| 02:30 | <MikeSmith> | yeah |
| 02:30 | <MikeSmith> | and it's great that it's right at the top of the page |
| 02:33 | <MikeSmith> | othermaciej: fyi about HLink - http://www.w3.org/html/wg/wiki/HLink |
| 02:40 | <david_carlisle> | MikeSmith: that was dull, can't I have a tracker issue or a poll or anything? |
| 02:40 | <MikeSmith> | heh |
| 02:42 | <MikeSmith> | david_carlisle: hey, when you think you might have that schema published? |
| 02:43 | <MikeSmith> | or deployed in W3C space, I mean |
| 02:46 | <david_carlisle> | There was some grumblings about calling it a mathml2 schema. Would it cause you problems if I called it mathml3-restricted, or something? |
| 02:46 | <david_carlisle> | I'd have done it before probably except there wore some day job things supposed to be done before, er now:-) |
| 02:47 | <david_carlisle> | s/wore/were/ |
| 02:47 | <MikeSmith> | david_carlisle: yeah, I saw the comment from Robert Miner |
| 02:47 | <MikeSmith> | I don't mind what it's called |
| 02:48 | <david_carlisle> | OK will rebuild it under that name and pass it by the group this weekend (I'll cc you) |
| 02:48 | <MikeSmith> | OK |
| 02:50 | <MikeSmith> | I suppose in the validator UI we are probably going to keep it labeled as MathML 2.0 |
| 02:50 | <MikeSmith> | "MathML 2.0 subset of MathML 3.0" is kind of long for a label |
| 02:51 | <david_carlisle> | Could w3c validator (at least) also have an option to use full mml3. IE9+mathplayer will be able to support pretty much all of mml3, and while the restricted schema is useful to warn the limits of interoperabilty, seems a bit harsh not to let people see the full version is in fact valid |
| 02:51 | <MikeSmith> | It could, sure |
| 02:52 | <MikeSmith> | but I don't work on the main validator |
| 02:52 | <MikeSmith> | only indirectly, on just the HTML5 facet |
| 02:52 | <david_carlisle> | must admit i've only used validator.nu recently:-) |
| 02:52 | <david_carlisle> | is the main one still nsgmls/dtd based? |
| 02:52 | <MikeSmith> | validator.nu lets you check against arbitrary relaxng schemas already |
| 02:53 | <MikeSmith> | yeah, it is |
| 02:53 | <MikeSmith> | long in the tooth |
| 02:53 | <david_carlisle> | so am i |
| 02:53 | <MikeSmith> | heh |
| 02:54 | <MikeSmith> | there really has been only one person working on the validator for the last couple years |
| 02:54 | <MikeSmith> | Ville Skyttä |
| 02:54 | <MikeSmith> | and he's done some good stuff |
| 02:54 | <MikeSmith> | and fixed a lot of bugs |
| 02:54 | <othermaciej> | MikeSmith: interesting; I couldn't tell from skimming the HLink draft how it differed from XLink |
| 02:55 | <MikeSmith> | othermaciej: I've never really read through it |
| 02:55 | <MikeSmith> | the interesting thing about it to me was the whole background on it |
| 02:56 | <MikeSmith> | I think the HTML WG at the time had reviewed the XLink spec, and given the XLink group comments on it -- asked for changes to bring it in line with their work on XHTML2 |
| 02:56 | <MikeSmith> | and the changes were never made |
| 02:56 | <MikeSmith> | so, they decided not to adopt it |
| 02:56 | <MikeSmith> | and came up with HLink instead |
| 02:57 | <MikeSmith> | and then TAG apparently told them they had to use XLink instead |
| 02:57 | <david_carlisle> | the old html grp repeatedly asked that xlink not have fixed attribute names so it could be used for existing html attributes, but that got turned down in favour of xlink:href etc |
| 02:57 | <MikeSmith> | and they said No |
| 02:57 | <MikeSmith> | ah, OK |
| 02:58 | <david_carlisle> | same problem with xml:id really, it;s Ok in theory for a new language but a pain to have to break an existing use if id, just to use it |
| 02:58 | <MikeSmith> | yep |
| 02:58 | <MikeSmith> | anyway, the HLink case is a precedent for groups not just adopting a Rec because its a Rec |
| 02:58 | <MikeSmith> | or because they're told to |
| 02:58 | <othermaciej> | it is certainly interesting in that light |
| 03:29 | <david_carlisle> | james c again on being friendly to html5: http://blog.jclark.com/2010/12/more-on-microxml.html |
| 03:42 | MikeSmith | reads |
| 12:13 | <annevk> | oh, missed out on responding to http://www.w3.org/2002/09/wbs/40318/issue-118-objection-poll/results |
| 12:13 | <annevk> | rel values prolly require some further study anyway\ |
| 12:48 | <hsivonen> | http://lists.w3.org/Archives/Public/public-html-xml/2010Dec/0002.html |
| 12:49 | <hsivonen> | the HTML-XML task force is getting started |
| 13:05 | <annevk> | nice opening message |
| 13:05 | <annevk> | oh, and good luck :) |
| 13:25 | <jgraham> | annevk: No more depressing stories about schiphol, please |
| 13:25 | <jgraham> | Supposed to be flying through there Monday |
| 13:26 | <jgraham> | Being trapped in Sweden over Christmas sounds too awful for words |
| 13:34 | <jgraham> | hsivonen: That TF has membership by private invitation? |
| 13:42 | <hsivonen> | jgraham: yeah |
| 13:45 | <jgraham> | Sad |
| 13:47 | <bga_> | https://chrome.google.com/extensions/detail/bfjhgapggdjickppeacklbnlgkkckibl |
| 13:48 | Philip` | continues to hate opaque URLs |
| 20:25 | <Darxus> | I would love to see wikipedia style references in HTML5. You put your reference in <ref></ref>s immediately after your quotation or something, it gets replaced with automatically numbered <sup>[1]</sup>, and at the bottom of the page you include a <references /> where all the contents of the refs are listed. |
| 20:25 | <Darxus> | Didn't see anything about that possibility being discussed in some brief googling... |
| 20:25 | <Darxus> | Footnotes... |
| 20:26 | <Darxus> | Much easier than http://dev.w3.org/html5/spec/Overview.html#footnotes |
| 20:31 | <Philip`> | Darxus: I think it's been discussed several times, which is why that section was added to the spec |
| 20:32 | <Darxus> | Philip`: That seemed likely. Do you know of any records of the discussion? |
| 20:33 | <Philip`> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-April/014485.html |
| 20:34 | <Darxus> | Thank you. |