| 00:08 | <alyoshka> | you know,<details><legend> was more workable in IE than <details><dt><dd>, but unworkable in Firefox |
| 00:09 | <alyoshka> | I actually got <details><legend> working in IE (with a rather large chunk of Javascript) pretty reliably, except for CSS styling |
| 00:10 | <alyoshka> | though <legend> was still a bad idea |
| 00:29 | <annevk42> | Lachy, you could prolly add a note that it's intentionally invalid |
| 02:16 | <heycam> | boo, minefield nightlies don't work on Tiger any more :( |
| 02:18 | <heycam> | i guess it would've been nice for the updater to refuse to do the update... |
| 02:42 | <jwalden> | heycam: you're not the only one, although I'll be off my 10.4 machine in a few days |
| 03:14 | <heycam> | jwalden, yeah i guess everything's pushing me to buy snow leopard :/ |
| 03:27 | <othermaciej> | snowkitty is cheap, if you have an intel system |
| 03:56 | <jwalden> | and if you're already on 10.5 |
| 03:57 | <jwalden> | I'm a bit RAM-challenged lately so I kind of need a new machine anyway |
| 04:01 | <heycam> | i've got an old-ish mac mini (core duo 1.5ghz i think) |
| 04:01 | <heycam> | hopefully it takes well to SL |
| 04:01 | <heycam> | and i've heard that you can just install SL on to a blank hard disk without needing leopard |
| 09:03 | Philip` | sees http://www.ebusiness-unibw.org/wiki/Rdfa4google |
| 09:04 | <Philip`> | I wonder if they're aware that Google doesn't even parse application/xhtml+xml pages with an XML parser, never mind processing <!ENTITY definitions |
| 09:05 | <Philip`> | (Actually that's just for their normal search results, I haven't tested how their Rich Snippets thing parses XHTML pages...) |
| 09:44 | <othermaciej> | using entities in curies is, I think, more indirection than I have ever seen to produce what is ultimately an opaque identifier string |
| 09:49 | <Hixie> | heycam: make sure you have at least a gig of ram, "snowkitty" won't install on my old mac mini |
| 09:51 | <Philip`> | It's not opaque, you can dereference http://purl.org/goodrelations/v1#hasOpeningHoursDayOfWeek to find out all about it (in a non-machine-readable format at least) |
| 09:52 | <Philip`> | Oh, actually it does some kind of content negotiation so I get the non-machine-readable version, while the W3C Validator gets RDF |
| 10:06 | <heycam> | Hixie, yeah i've got 1.5GB |
| 10:25 | <Philip`> | Hmm, I was wrong about how the Rich Snippets thing parses pages, it's seemingly not the same as used for search results etc |
| 10:25 | <Philip`> | It's not the same as any proper HTML parser, or any proper XML parser, either |
| 10:26 | <Philip`> | It seems to be kind of an error-correcting XML parser - <p><p> results in nested elements, <div/> results in a closed element, α works (with no declared doctype), entities defined in doctypes are ignored |
| 10:27 | <Philip`> | and it uses the same parser for text/html and application/xhtml+xml |
| 10:31 | <Hixie> | how do you determine that it isn't the parser used for search results? |
| 10:31 | <Hixie> | (just curious, i actually don't know if it is or not) |
| 10:35 | <Philip`> | Hmm, actually I don't know |
| 10:36 | <Philip`> | I assumed I'd tested it or something, but seemingly I haven't, so I could be wrong |
| 10:36 | <Philip`> | I suppose I also assume Google wouldn't use something so unlike an HTML parser for something serious like search results |
| 10:40 | <Hixie> | you also assumed that the rdfa processing would have some relationship to the rdfa spec |
| 10:46 | <Philip`> | Sure, but that's an experimental new implementation with approximately zero users, vs a mature decade-old technology with a billion users |
| 10:46 | <Philip`> | so I still cling to hope |
| 10:54 | <Hixie> | can someone please explain to me why the server sorts this table differently if i view it chrome than if i view it in safari?: |
| 10:54 | <Hixie> | http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=HTML+WG&product=WebAppsWG&component=HTML5+Spec+bugs&component=HTML5+Spec+proposals&component=Web+Storage&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=R |
| 10:54 | <Hixie> | that's the "Bugs" link on http://damowmow.com/portal under "Daily" |
| 11:41 | <Hixie> | ok i really should go to bed |
| 11:41 | <Hixie> | nn |
| 12:43 | <hsivonen> | http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0183.html |
| 13:42 | <Dashiva> | hsivonen: IE "works" because it doesn't support XHTML, I guess? |
| 14:55 | <eighty4> | I realize this might not be the correct channel to ask this, if there's a better channel to ask in please point me to it :). When trying to validate my html5 code at http://html5.validator.nu/ I'm getting "Text run is not in Unicode Normalization Form C." errors for my åäö:s When manually retyping them in the text field for the validator the error goes away. What encoding in my document should I be using to remove this errors? |
| 14:56 | <Micheil> | eighty4: hmm... I think you should be using entities, over encoded characters |
| 14:56 | <gsnedders> | It's not the character set that is at fault, but the encoding of the character set. There are multiple ways to represent characters like å in Unicode. How you force NFC depends on what your editor is :) |
| 14:57 | <hsivonen> | eighty4: you can continue to use UTF-8. how did you create the content |
| 14:57 | <hsivonen> | ? |
| 14:57 | <eighty4> | hsivonen: coda using utf-8 |
| 14:57 | <hsivonen> | eighty4: problem with coda then |
| 14:58 | <Lachy> | eighty4, look for an option in your editor to save the document in UTF-8 with NFC normalisation. |
| 14:58 | <eighty4> | gsnedders: shouldn't a web-dev editor be setup to work properly from the start? |
| 14:58 | <eighty4> | >< stupid coda |
| 14:58 | <Lachy> | eighty4, ideally, yes. Unfortunately, not always in practice |
| 14:58 | gsnedders | wonders why it's not using NFC |
| 14:59 | <eighty4> | none of the encoding options say anything about nfc :/ |
| 15:00 | <hsivonen> | eighty4: anything about precomposed vs. decomposed? |
| 15:01 | <eighty4> | http://screencast.com/t/PlyND9jmqHT is the only related thing I can find |
| 15:02 | <eighty4> | doesn't seem to be a forum for coda. Just an email address. |
| 15:03 | <hsivonen> | eighty4: did you copy and paste the text from the FInder by any chance? |
| 15:03 | <eighty4> | hsivonen: from within coda |
| 15:05 | <eighty4> | but I guess it could be an os x problem |
| 15:05 | <hsivonen> | eighty4: try filing a bug on Coda |
| 15:05 | <hsivonen> | eighty4: this is relatively easy to get wrong with Cocoa. Apple once shipped Preview.app with a bug like this |
| 15:16 | <eighty4> | no apps seems to actually say what they use. |
| 15:22 | <eighty4> | textmate does handle it ok. Guess it's a problem with coda then. |
| 15:28 | <eighty4> | there. mail sent to the coda devs |
| 16:49 | <abarth> | Hixie: do you remember off hand how canvas tainting interacts with document.domain? |
| 16:51 | <abarth> | looks like it ignores document.domain |
| 17:01 | <annevk42> | abarth, document.domain only affects few things |
| 17:01 | <abarth> | great |
| 17:01 | <abarth> | just want to make sure i'm fixing this the right way |
| 17:02 | <annevk42> | the idea is to make document.domain not affect more than needed |
| 17:03 | <abarth> | oh, yeah, i'm definitely in favor of that |
| 17:03 | <abarth> | the current code in webkit was taking document.domain into account |
| 17:03 | <abarth> | (and also screwing up on data URLs) |
| 17:03 | <abarth> | so I'm fixing both bugs while i'm at it |
| 17:49 | <annevk42> | abarth, ah, I think I filed a bug on that once |
| 17:49 | <annevk42> | abarth, on WebKit that is |
| 17:50 | <abarth> | annevk42: well, it's about to get fixed :) |
| 19:09 | <gsnedders> | How can you simplify 9/8+x^2(9/4-3)+x^4(9/8-1) ? |