| 04:31 | Hixie | tries to work out why photobooth won't start if you have no physical monitor plugged in |
| 04:31 | <jacobolus> | anyone know exactly which browsers treat --!> as a comment end? |
| 04:31 | <Hixie> | and why if you start it while a monitor is plugged in, and then take the monitor out, the preview window goes white, but you can still take pictures |
| 04:32 | jacobolus | noticed hsivonen's note that his parser doesn't do it yet, but that apparently it's supported elsewhere |
| 05:24 | <MikeSmith> | jacobolus: hsivonen raised and HTML WG bugzilla bug for that, did you see it? |
| 05:24 | <MikeSmith> | I think he has a link to a mozilla bug report |
| 05:24 | MikeSmith | goes looking |
| 05:25 | <MikeSmith> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=7089 |
| 05:25 | <MikeSmith> | Gecko bug https://bugzilla.mozilla.org/show_bug.cgi?id=502984 |
| 05:25 | <MikeSmith> | Site: http://www.erc.gov.ph/ |
| 05:27 | <jacobolus> | MikeSmith: so do all major browsers support that? |
| 05:27 | <jacobolus> | i.e. close the comment when they see --!> |
| 05:28 | <jacobolus> | (I guess I could test out a bunch of them.... but I thought someone might know) |
| 05:29 | <MikeSmith> | jacobolus: I don't know myself. I guess the way to be sure is to test it and see what you get |
| 05:29 | <jacobolus> | ok |
| 05:29 | <MikeSmith> | but based on hsivonen comments there, it seems like that do |
| 05:29 | <MikeSmith> | *they do |
| 05:35 | <jacobolus> | FF 2&3, & Safari 4 do, but Opera doesn't seem to |
| 05:35 | <jacobolus> | maybe I should file an opera bug |
| 05:37 | <jacobolus> | (though they probably know this, w/ annevk &c. paying attention) |
| 05:52 | <jacobolus> | oh wow, the opera behavior is odd indeed |
| 05:52 | <jacobolus> | if it only finds --!>, then it treats it as a comment ending |
| 05:52 | <jacobolus> | but if there's --> anywhere later, it'll use that as the end of the comment |
| 05:53 | <jacobolus> | swallowing anything in between |
| 05:53 | <jacobolus> | so adding a comment way down the page completely changes rendering |
| 05:53 | <jacobolus> | I guess I will file that bug |
| 06:01 | <jacobolus> | for any opera devs here, bug 258698 |
| 06:07 | <jacobolus> | example html that causes this behavior in latest Opera 10 preview: http://pastie.textmate.org/542877 |
| 06:30 | <jacobolus> | (hsivonen/Hixie: you might be interested in that... dunno) |
| 08:08 | <Philip`> | jacobolus: If I remember correctly, if it reaches EOF with an unclosed comment then it re-parses and closes the comment on the first >, or something like that |
| 08:09 | <jacobolus> | huh. well I can put in multiple 'fake' comments and they work fine |
| 08:09 | <jacobolus> | but as soon as I add a real one, even way down the page, they all break |
| 08:09 | <jacobolus> | you could be right that that's the behavior. I'll test a bit |
| 08:10 | <jacobolus> | Philip`: huh, you seem to be right |
| 08:10 | <jacobolus> | so they probably already had this as a bug |
| 08:11 | <jacobolus> | sadly, the database is closed... |
| 08:13 | <jacobolus> | yeah, it seems to eat everything up to the first > it finds, if it can't find a --> |
| 08:13 | <jacobolus> | which means that it tends to eat some opening tag |
| 15:32 | <jgraham> | http://detexify.kirelabs.org/classify.html |
| 15:36 | <gsnedders> | jgraham: cool |
| 16:59 | <gsnedders> | takkaria: yt? |
| 17:00 | <takkaria> | gsnedders: sort of |
| 17:00 | <gsnedders> | takkaria: How long did it take to get to Roxen? |
| 17:00 | <takkaria> | hmm |
| 17:01 | <gsnedders> | (and back) |
| 17:01 | <takkaria> | maybe two hours there, one hour back |
| 17:01 | <gsnedders> | hmm, so I could go today |
| 17:01 | <takkaria> | I stopped and took photos lots though |
| 17:01 | gsnedders | heads off |
| 17:10 | gsnedders | looks out of window one final time and sees huge dark clouds towards Roxen… |
| 17:18 | <gsnedders_> | Just getting cloudier and cloudier |
| 17:47 | <jgraham> | So I am wondering about implementing the new table character data stuff in html5lib |
| 17:47 | <Philip`> | Sounds like a good idea to me |
| 17:48 | <jgraham> | It seems like it might be nice to return all character data from the tokenizer together rather than special casing whitespace in some circumstances |
| 17:48 | <jgraham> | So all the logic about whitespce being special would be on the treebuilder side |
| 17:49 | <jgraham> | But I'm not sure if this is just crazy talk or not |
| 17:50 | jgraham | wonders what hsivonen does |
| 18:39 | <Simetrical> | So <!doctype html> actually triggers different behavior from old doctypes, it seems? |
| 18:39 | <Simetrical> | That's . . . bad? |
| 18:39 | <Philip`> | Simetrical: Depends which old doctypes you mean |
| 18:39 | <Simetrical> | Well, I'm working on switching Wikipedia from XHTML 1.0 Transitional to HTML 5. |
| 18:40 | <Simetrical> | When I switch the doctype, rendering breaks. |
| 18:40 | <Simetrical> | That will make things *much* more complicated. |
| 18:40 | <Simetrical> | I had thought that the doctype was chosen specifically so it would trigger standards mode in all browsers, but it seems that's not quite the case. |
| 18:40 | <Simetrical> | Hmm. |
| 18:40 | <Philip`> | Simetrical: If I'm reading the table on http://hsivonen.iki.fi/doctype/ properly, XHTML 1.0 Transitional is "Almost Standards" |
| 18:40 | <Simetrical> | Yeah, I just read that too. |
| 18:40 | <Philip`> | (and <!doctype html> is "Standards") |
| 18:41 | <Simetrical> | Okay, I'm going to have to come up with a test case here. |
| 18:41 | <Simetrical> | Because I'm seeing the rendering break in Chrome. |
| 18:41 | <Simetrical> | I'll figure out what's going on. |
| 18:41 | <Philip`> | Hopefully there shouldn't be that many differences between almost-standards and standards |
| 18:41 | Philip` | doesn't remember exactly what the differences are, though |
| 18:41 | <Simetrical> | Oh, I see. |
| 18:42 | <Simetrical> | Hmm. |
| 18:42 | <Philip`> | Oh, http://hsivonen.iki.fi/doctype/ already talks about Almost Standards |
| 18:42 | <Simetrical> | Current MediaWiki doctype: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">; |
| 18:42 | <Philip`> | "which implements the vertical sizing of table cells traditionally and not rigorously according to the CSS2 specification" |
| 18:43 | <Simetrical> | It looks like the doctype change is switching three browsers from "almost standards" to "standards". |
| 18:43 | <Simetrical> | Specifically including . . . all recent browsers. |
| 18:43 | <Philip`> | That sounds correct |
| 18:44 | <Simetrical> | So more changes will be required to ensure that pages continue to render correctly. |
| 18:44 | <Simetrical> | Ugh. Okay. |
| 18:44 | <Philip`> | Sounds like image-in-table is about the only difference |
| 18:45 | <Philip`> | https://developer.mozilla.org/en/Images%2c_Tables%2c_and_Mysterious_Gaps etc |
| 18:45 | <Simetrical> | We have some of those, I guess, but that's not the difference I'm seeing. |
| 18:45 | <Philip`> | Hmm, what difference are you seeing? |
| 18:46 | <Philip`> | or maybe it's better to wait for a test case :-) |
| 18:46 | <Simetrical> | Well, look at any page of Wikipedia in the default skin. The whole nav bar thing on the left below the logo gets pushed down below the end of the page in Chrome 3 with an HTML 5 doctype. |
| 18:51 | <Philip`> | Hmm, same in Safari 4.0 |
| 18:54 | <Simetrical> | But not Firefox 3.5. |
| 18:56 | <Philip`> | Nor Opera |
| 18:57 | <Philip`> | Might be some kind of WebKit bug |
| 18:57 | <Simetrical> | If it breaks the site for all Safari users, that means we can't switch the doctype right now. |
| 18:57 | <Simetrical> | I'm trying to make a minimal test case. |
| 18:59 | <Philip`> | There's approximately zero benefit in changing the doctype, so it doesn't seem worth hurting users |
| 18:59 | <Philip`> | though I suppose it's nice to make browsers do Standards instead of Almost Standards |
| 19:00 | <Simetrical> | Well, the idea is to actually deploy valid HTML 5, which means switching the doctype. |
| 19:00 | <Simetrical> | My understanding is that the point of the HTML 5 doctype is to make sure that old content will work. |
| 19:01 | <Philip`> | I think the point is to make old content work the same as if it used an old Standards mode doctype (e.g. XHTML Strict), and also to be as short as possible |
| 19:02 | <Simetrical> | Aha. |
| 19:02 | <Simetrical> | You know, it might be WebKit-specific JavaScript hacks in MediaWiki itself. |
| 19:02 | <Philip`> | If there wasn't quirks mode, then HTML5 would probably have no doctype at all |
| 19:02 | <Simetrical> | Yes, agreed. |
| 19:02 | <Philip`> | Hmm, that's possible |
| 19:02 | <Simetrical> | Okay, bingo. |
| 19:03 | <Simetrical> | wikibits.js is the problem. |
| 19:03 | Philip` | has tried playing with the CSS briefly and couldn't see what the problem was |
| 19:03 | <Simetrical> | I just started removing chunks of the head and body. |
| 19:03 | <Simetrical> | When I removed the script tags the problem stopped. |
| 19:03 | <Philip`> | Hooray for browser sniffing :-) |
| 19:03 | <Simetrical> | Yeah. :( |
| 19:06 | <Simetrical> | I'm not sure it's the browser sniffing . . . |
| 19:10 | <Simetrical> | Bingo, KHTMLFixes.css. |
| 19:16 | <Philip`> | Excellent, IE silently rejects EOT fonts if the Font Family Name is not a prefix of the Full Font Name |
| 19:17 | <Philip`> | (even though an equivalent font works perfectly well in the rest of Windows) |
| 19:17 | <Philip`> | s/font/TTF font/ |
| 19:48 | <Simetrical> | Okay, Wikipedia HTML 5 deployment back on track. |
| 19:59 | <Simetrical> | Serving a five-year-old CSS fix for KHTML to modern WebKit development versions = epic fail. |