| 01:48 | <annevk> | hmm, will update html5-diff tomorrow |
| 01:48 | <annevk> | time for some water now, you know |
| 02:31 | <jwm> | does QQaalalala |
| 02:31 | <jwm> | hmm |
| 02:31 | <jwm> | heh |
| 02:31 | <jwm> | time for dinner |
| 04:07 | <othermaciej> | hi all |
| 05:02 | <roc> | TabAtkins: have you tried inspecting the shadows with some kind of screen magnifier? Preferably one that can show the actual color values of pixels? |
| 05:14 | <Viper550> | Is it me, or is the forum scrpt that whatwg uses not html-compliant? |
| 05:35 | <Viper550> | hey? |
| 05:40 | <Hixie> | Viper550: it is almost certainly not particularly good code, indeed |
| 05:41 | <Hixie> | Viper550: we didn't use the quality of the code as a deciding factor in picking the software :-) |
| 05:41 | <Viper550> | you've seen fluxbb 1.4? |
| 05:43 | <Viper550> | In case you haven't heard, its a fork of punbb 1.2 |
| 05:44 | <Hixie> | Viper550: i don't know much about forum software personally |
| 07:00 | <annevk> | you'd think Leif would have noticed I didn't reply to any comment on html5-diff since last time I made it ready and that last time I replied to age old comments |
| 07:01 | <annevk> | it is of course more interesting to assume the chairs and I ignored him, because then you can vent frustrations, even if not at all justified |
| 07:28 | <MikeSmith> | kennyluck: is Guo Fu a family name or a personal/given name? |
| 07:28 | <kennyluck> | MikeSmith: it's a word. It means "Country Father" :) |
| 07:29 | <kennyluck> | father of a country |
| 07:29 | <MikeSmith> | oh |
| 07:29 | <kennyluck> | (well, it's possible that someone has this given name, but this is kind of odd then) |
| 07:34 | <annevk> | MikeSmith, we're gonna publish tomorrow? |
| 07:34 | <MikeSmith> | annevk: yes |
| 07:34 | <annevk> | okay then |
| 07:36 | <MikeSmith> | annevk: as soon as you have your doc ready, let me know, and I will move it over to the dated TR location |
| 07:36 | <MikeSmith> | and will let the webmaster know it's ready |
| 07:37 | <annevk> | yeah, I'll go through the new comments now and see what needs changing |
| 07:59 | <abarth> | Hixie: the bit about spinning the event loop isn't who things work internally |
| 07:59 | <abarth> | Hixie: nested event loops are bad new bears |
| 08:05 | <MikeSmith> | interesting to see a Microsoft commenter on the whatwg mailing list |
| 08:06 | MikeSmith | wonders what "Live Labs / Seadragon" is |
| 08:07 | <MikeSmith> | abarth: I seem to remember hsivonen mentioning something about nested event loops recently |
| 08:07 | <MikeSmith> | in bugzilla or here |
| 08:07 | <MikeSmith> | I wonder if the context is the same |
| 08:07 | <abarth> | I think the behavior ends up being the same |
| 08:07 | <abarth> | it's just a difference in the processing model from the actual processing |
| 08:08 | <abarth> | the problem with nested event loops |
| 08:08 | <abarth> | is you get in trouble when you try to unwind them |
| 08:08 | <abarth> | because lots of stuff gets re-entered |
| 08:08 | <MikeSmith> | ah |
| 08:08 | <abarth> | that might not be expecting it |
| 08:08 | <MikeSmith> | yeah, I can imagine |
| 08:08 | <abarth> | the parser needs to be re-entrant, which makes it tricky |
| 08:09 | <abarth> | DOM mutation also needs to be re-entrant, which is really hard' |
| 08:09 | <abarth> | and the source of lots of bugs :( |
| 08:09 | <MikeSmith> | that I also can imagine |
| 08:10 | <MikeSmith> | or actually, remember |
| 08:10 | <MikeSmith> | from previous life in browser product development |
| 08:13 | <MikeSmith> | abarth: the context of your current discussion about this is the tokenizer spec? |
| 08:14 | <MikeSmith> | the closing-the-input-stream part? |
| 10:19 | <MikeSmith> | kennyluck: Murata-san is http://ja.wikipedia.org/wiki/村田真 |
| 10:19 | <MikeSmith> | and http://en.wikipedia.org/wiki/Makoto_Murata |
| 10:43 | <kennyluck> | MikeSmith: "In Mainland China, Malaysia and Singapore....vertical writing is now very rare, more so in print than in writing and signage." from http://en.wikipedia.org/wiki/Horizontal_and_vertical_writing_in_East_Asian_scripts |
| 10:43 | <kennyluck> | I guess I was wrong about novels in Mainland China. |
| 10:43 | <MikeSmith> | interesting |
| 10:48 | <annevk> | wtf is sam on |
| 11:18 | <jgraham> | annevk: See, this is why you shouldn't do things for people. They will only complain |
| 11:19 | <annevk> | yeah, before I settled on "I already had." I had a lot of other drafts |
| 11:20 | <annevk> | dealing with the HTML WG is painful |
| 11:20 | <annevk> | so I'm calling it a day for now as far as that is concerned |
| 11:21 | <annevk> | http://code.google.com/apis/maps/documentation/javascript/examples/streetview-map.html is indeed very neat hsivonen |
| 11:23 | <annevk> | hehe, Google visited my place while I was home |
| 12:00 | <gsnedders> | annevk: Unusual :P |
| 12:02 | <annevk> | http://www.w3.org/2010/06/14-ab-minutes (W3C Member-only) -- worth reading |
| 12:04 | <Omer> | Hi |
| 12:05 | <Omer> | Someone here? |
| 12:05 | <Guest45746> | Hi |
| 12:05 | <Guest45746> | Someone here? |
| 12:05 | <annevk> | better to just ask your question |
| 12:05 | <Guest45746> | ok |
| 12:06 | <Guest45746> | how i can send a message with postMessage between windows/tabs? |
| 12:06 | <annevk> | by getting a reference to the other window and invoke postMessage() on it with the correct arguments? |
| 12:07 | <Guest45746> | how i getting reference to other window? |
| 12:07 | <Guest45746> | with the same domain |
| 12:08 | <annevk> | I think you can only get a reference if it's a related browsing context |
| 12:08 | <annevk> | so if it's window.opener, or in window[x] |
| 12:09 | <Guest45746> | i can't to access to other window? |
| 12:11 | <annevk> | no |
| 12:11 | <Guest45746> | ok thanks you ill do that on the sever side |
| 12:12 | <annevk> | you can maybe sync some info using localStorage for same-origin scenarios |
| 12:12 | <annevk> | the storage event is supposed to dispatch in each tab of the same origin |
| 12:13 | <Guest45746> | what i wanted is to share the same websockets connection to all of the windows |
| 12:14 | <Guest45746> | but ill do that on the server side i dont think have anuther way |
| 12:14 | <annevk> | shared worker? |
| 12:14 | <Guest45746> | what you mean? |
| 12:15 | <annevk> | see http://www.whatwg.org/ww |
| 12:16 | <annevk> | you can share a JavaScript "thread" among several same-origin windows and then you can use sockets from that thread |
| 12:18 | <Guest45746> | so when i created one shared worker all the pages use him? |
| 12:19 | <annevk> | pretty much |
| 12:24 | <Guest45746> | thanks tou very much |
| 12:24 | <Guest45746> | :) |
| 12:24 | <Guest45746> | i understand that |
| 12:25 | <Guest45746> | ww is cross browsers? |
| 12:26 | <Guest45746> | i think its desnt but i wanna to be sure |
| 12:27 | <Guest45746> | you* |
| 12:28 | <annevk> | nothing of this is cross browser really |
| 12:30 | <Guest45746> | but its great idea :) |
| 12:32 | <jgraham> | Well it is intended to be cross browser |
| 12:32 | <jgraham> | Just need to wait for the browsers |
| 12:36 | <Guest45746> | so i can be sure its will be in the next?? |
| 12:39 | <annevk> | there's no guarantees really |
| 12:39 | <annevk> | but it's shipping in some already |
| 12:44 | <Guest45746> | you know when websockets protocol ill finished? |
| 14:15 | <annevk> | Guest45746, no |
| 14:16 | <annevk> | Guest45746, when three implementations are shipping it's prolly finished for better or worse |
| 14:39 | <jgraham> | So who is going to write the change proposal for @summary? |
| 14:52 | <Guest45746> | element.parentElement its part of html5? |
| 14:54 | <Philip`> | Guest45746: That seems to be a non-standard IE-only feature |
| 14:54 | <MikeSmith> | annevk: it's been pointed out to me that "The autobuffer attribute on media elements was renamed to preload." is mentioned twice in the diffs doc |
| 14:55 | <MikeSmith> | in section 5.1 and also in 5.2 |
| 14:55 | MikeSmith | goes to check when it actually changed |
| 14:56 | <Lachy> | jgraham, what change proposal is needed? |
| 14:56 | <Lachy> | Just a zero-edit proposal, or one that says to make it fully obsolete? |
| 14:56 | <Lachy> | or both? |
| 14:56 | <Guest45746> | so how can i get the parent |
| 14:57 | <Guest45746> | ans why chrome and safari use parentElement? |
| 14:57 | <Guest45746> | and |
| 14:57 | <Philip`> | Guest45746: Use parentNode |
| 15:00 | <jgraham> | Lachy: I would prefer both. But at least a zero-edits one that collects together all the evidence that summary is pointless or harmful |
| 15:00 | <Guest45746> | thanks now its work on firefox :) |
| 15:01 | <jgraham> | Lachy: I have no idea how one is supposed to write a change proposal in such a way that the chairs actually pay attention to the points made though |
| 15:01 | <Guest45746> | but why chrome and safari use it? |
| 15:17 | <Lachy> | jgraham, no idea either, given how they've merely counted arguments and counter arguments as balancing each other out, regardless of their technical merit |
| 15:18 | <Lachy> | but that's an issue I need to follow up with sam, as I'm still waiting for him to stop ignoring my email about the issue. |
| 15:26 | <MikeSmith> | annevk: seems like "The autobuffer attribute for media elements is now named preload" should be removed from the "Changes since 4 March 2010" list |
| 15:27 | <MikeSmith> | because that change was actually made in February |
| 15:27 | <MikeSmith> | and you already to have it listed in "Changes from 25 August 2009 to 4 March 2010" |
| 15:43 | <TabAtkins> | roc: Well, I'm screenshotting and then checking pixels in GIMP. I'd think that's close enough. |
| 15:43 | jgraham | wonders what the context for that was |
| 15:43 | <TabAtkins> | There's a www-style convo about how the *-shadow properties do/should work. |
| 15:44 | <TabAtkins> | There's disagreement about how text-shadow works *right now*, which is weird. |
| 15:45 | <Philip`> | Reverse-engineering shadow algorithms is fun |
| 15:45 | Philip` | wonders how similar CSS shadows are to canvas shadows |
| 15:46 | <TabAtkins> | canvas shadows are an exact copy of webkit's bugs in css shadows. |
| 15:47 | <TabAtkins> | Including a substantial change in shadow algorithm when the shadow blur is > 8px. |
| 15:48 | <Philip`> | Does it do the slightly weird thing with sigma=sqrt(2*blur) if blur>8 ? |
| 15:48 | <TabAtkins> | So, yes. |
| 15:48 | <Philip`> | That's not a substantial change, it's just interpreting the argument a bit differently |
| 15:48 | <TabAtkins> | It makes things weird, at least. |
| 15:48 | <TabAtkins> | smfr was complaining about it. |
| 15:49 | <Philip`> | It makes the shadow appear to scale more linearly, without big visual differences between small integers, if I remember correctly |
| 15:50 | <TabAtkins> | I was told it was a performance optimization. |
| 15:50 | <Philip`> | I assume the behaviour was inherited from CG, rather than being an intentional WebKit feature |
| 15:50 | <TabAtkins> | Yeah, I assume so. |
| 15:51 | <Philip`> | (I assume by "webkit's bugs" you meant the CG port of WebKit) |
| 15:51 | <TabAtkins> | So anyway, roc and I are disagreeing about how far Firefox's shadow extends for a 100px blur. I say 50px, based on screenshots + pixel comparisons. He says 79px, based on a screen magnifier and pixel checking. |
| 15:51 | <TabAtkins> | I dunno, I'm just paraphrasing from smfr. |
| 15:52 | <Philip`> | How can you disagree on something as objective as that? :-) |
| 15:52 | <TabAtkins> | I don't know! |
| 15:53 | <Philip`> | Just post the screenshot and say what pixel value you see at the edge of the blur |
| 15:53 | <TabAtkins> | Yeah, doing that now. |
| 15:53 | <Philip`> | and then find out it varies between different platforms or something :-) |
| 15:55 | <TabAtkins> | Well, it appears to be the same between my linux desktop and my windows laptop. |
| 15:55 | <TabAtkins> | But roc is checking on win and linux as well. |
| 15:57 | <Philip`> | With FF3.6.3 on Linux, I see (254,254,254) at 80ish pixels from the edge of the shape |
| 15:57 | <TabAtkins> | wtf |
| 15:59 | <Philip`> | You're not using Gimp's magic wand with a threshold of 15 to determine the edge of the shadow? |
| 15:59 | <TabAtkins> | No, I'm just zooming in and using the dropper to check the color manually. |
| 15:59 | <Philip`> | Ah, good :-) |
| 15:59 | <TabAtkins> | And when I did use the wand, I specifically dropped the threshold to 0. |
| 16:04 | <TabAtkins> | ...huh. |
| 16:05 | <TabAtkins> | When I do a white shadow on black, the shadow is 50px wide. +-1. When I do a black shadow on white, it's about 80px wide, like roc says. |
| 16:06 | <Philip`> | Oh |
| 16:06 | <Philip`> | (That doesn't seem surprising since it depends on the rounding) |
| 16:06 | <TabAtkins> | That's stupid. |
| 16:08 | <TabAtkins> | Oh, wait. Huh. Maybe I was just stupid? Now I'm measuring 80px for white-on-black. |
| 16:09 | <TabAtkins> | roc: So, nevermind. I think I just measured webkit's screenshot twice, rather than measuring webkit once and firefox once. |
| 16:11 | Philip` | just tried yellow on magenta, and it looks like actually it rounds up the same as it rounds down, so that's not an issue |
| 16:11 | <TabAtkins> | Yeah, rounding's not the issue. I was juggling too many screenshots at once. |
| 16:19 | <Philip`> | Hmm, why does text-shadow indicate the blur is measured in pixels? |
| 16:20 | <TabAtkins> | Where does it do so? |
| 16:21 | <Philip`> | Isn't that slightly meaningless, since the blur is theoretically infinite in size and I assume the specified size is not equal to the Gaussian sigma |
| 16:21 | <Philip`> | "text-shadow: 0 0 100px black;" |
| 16:22 | <Philip`> | (s/$/?/ in earlier question) |
| 16:22 | <TabAtkins> | The blur length specifies how far you have to go before the blur has gotten to within 1% of the full color/full transparency. Or at least, that's probably what we're specifying now. |
| 16:22 | <TabAtkins> | It is remarkably underspecified right now. |
| 16:23 | <TabAtkins> | So yeah, the blur is theoretically infinite, but the area within the threshold isn't. |
| 16:23 | <Philip`> | 1% in what colour space? |
| 16:23 | <TabAtkins> | rgb, the default css color space |
| 16:24 | TabAtkins | goes to get breakfast, bbiab |
| 16:29 | karlushi | sighs at the difficulties to share Web files with people at the offices. No interoperability for packaging between the different browsers. :(( |
| 16:30 | <Philip`> | TabAtkins: Doesn't "1% of the full color" mean you need to solve a cubic equation to work out what sigma to use for the Gaussian, or am I getting my maths all wrong? |
| 16:30 | <Philip`> | (I'm interpreting it as meaning G(x) = 0.01 as defined by http://upload.wikimedia.org/math/b/5/a/b5a3ab06a75210694218bcbd7370eea3.png) |
| 16:32 | <TabAtkins> | Philip`: I have no clue. |
| 16:32 | <TabAtkins> | But I'm certain there's a much faster approximation. |
| 16:35 | <Philip`> | So the text-shadow property will be giving an approximation of an arbitrary percentage threshold? |
| 16:36 | <Philip`> | That doesn't sound very mathematically sane :-( |
| 16:36 | <TabAtkins> | Who cares about math, we're doing webdesign. |
| 16:37 | <jgraham> | TabAtkins: Seems like a good idea to understand the maths before you specify something insane |
| 16:38 | <TabAtkins> | To be fair, it appears that the implementors who're paying attention are cool with all that anyway. |
| 16:39 | <TabAtkins> | The only question is whether a 100px blur length means that the full blur area (extending inside and outside of the unblurred shadow boundary) is 100px wide, or that the blur area must extend 100px inside and outside. |
| 16:39 | <TabAtkins> | And that's just a question of bikeshedding and convergence with sufficiently related technologies, luckily. |
| 16:40 | <Philip`> | Is canvas sufficiently related? |
| 16:40 | <Philip`> | (I think that has a mathematically reasonably sane definition of shadow rendering :-) ) |
| 16:40 | <TabAtkins> | Only insofar as canvas is literally "whatever webkit did for shadows". |
| 16:40 | <TabAtkins> | So, since we're already considering webkit, canvas just weights that slightly. |
| 16:41 | <annevk> | MikeSmith, still around? |
| 16:41 | jgraham | would have assumed that the blur length would be defined as a sigma of a given number of pixels, or something |
| 16:41 | jgraham | has no idea how it actually works though |
| 16:41 | <Philip`> | It's not precisely what Safari did, since Safari had (has?) incorrect clipping for small shadow sizes |
| 16:41 | <TabAtkins> | jgraham: Your average web author has absolutely no idea what a sigma is. |
| 16:41 | <Philip`> | (It would cut off the leftmost pixel of the shadow, in a visible way) |
| 16:41 | <jgraham> | TabAtkins: So? |
| 16:42 | <jgraham> | TabAtkins: Presumably they just adjust until they get the result they want |
| 16:42 | <TabAtkins> | So we want the blur length to mean something reasonable? |
| 16:42 | <Philip`> | TabAtkins: They just need to know that it's correlated to the apparent width of the shadow |
| 16:42 | <jgraham> | It does mean something reasonable |
| 16:42 | <Philip`> | (It can never be equal to the width since the shadow doesn't have an edge) |
| 16:43 | <jgraham> | It means that the shadow is 1/e of the maximum value at that number of pixels |
| 16:43 | <TabAtkins> | That's putting implementor interests over author interests, for little benefit to implementors and measurable downside to authors. |
| 16:43 | <jgraham> | I challenge you to measure that downside |
| 16:43 | <TabAtkins> | I did. It's -13 utilons. |
| 16:43 | <jgraham> | I don't see why an author cares if it is 1/e or 1/100 |
| 16:44 | <annevk> | MikeSmith, I fixed that and some other issues |
| 16:44 | <TabAtkins> | An author cares that the language is predictable. Saying "well, bigger numbers mean bigger shadows" is only *barely* acceptable. Ideally, the author shoudl be able to predict how large the shadow will be for a given length. |
| 16:45 | <jgraham> | The shadows will be infinitely big, apart from hardware limitations |
| 16:45 | <TabAtkins> | Now you're being pedantic. |
| 16:46 | <jgraham> | Not really :) |
| 16:46 | <jgraham> | I mean, in theory, there is no edge of the shadow. |
| 16:46 | <TabAtkins> | The measure we're planning to use on defining the "edge" of the shadow is 1% from full color/full transparency. |
| 16:47 | jgraham | would really use n sigma for integer n |
| 16:47 | <TabAtkins> | The two are interchangeable. |
| 16:47 | <TabAtkins> | Also, we dont' specify the blurring algorithm, so we can't assume a gaussian blur. |
| 16:48 | <jgraham> | I assume no one will implement a non-gaussian blur |
| 16:48 | <TabAtkins> | If you just wanted to use 3 sigma, that's fine. |
| 16:48 | <jgraham> | If they did it would be even weirder |
| 16:48 | <Philip`> | How can you specify shadowing without specifying the blurring algorithm? |
| 16:48 | <TabAtkins> | Man, I dunno. I just know there was pushback against us specifying a precise algo. |
| 16:49 | <Philip`> | That seems to be basically leaving the entire thing undefined |
| 16:49 | <TabAtkins> | Philip`: Barely. We just define the boundaries, and then say there should be a gradient of some kind. |
| 16:51 | <Philip`> | So someone could e.g. do a 100%-to-0% radial gradient around the edge of the shape, so that a tiny dot would have as bright a shadow as a large box? |
| 16:51 | <Philip`> | That doesn't sound good for interoperability |
| 16:51 | <TabAtkins> | See: pushback against specifying a precise algo. |
| 16:52 | <jgraham> | TabAtkins: It needen't bee to precise |
| 16:52 | <Philip`> | (Either people will implement things very differently, which is bad for interop, or they'll implement it the same anyway, in which case it can be specced) |
| 16:52 | <jgraham> | It should say "implementation defined approximation to a gaussian blur" or something |
| 16:53 | <jgraham> | You could argue that anything is an approximation to a gaussian of course, but that would be deliberatly perverse |
| 16:53 | <TabAtkins> | Time for conference call! |
| 16:54 | Philip` | just thinks it seems crazy to specify a rendering behaviour without actually specifying the rendering behaviour |
| 16:57 | <TabAtkins> | I agree, actually. |
| 19:00 | <hober> | whoa, emails to the whatwg list from a @microsoft.com address |
| 19:00 | <Peter-> | Apparently IE9 DP3 is pending to be released today |
| 19:01 | <Peter-> | I have noticed more Microsoft activity around various lists in the past few days |
| 19:02 | <gsnedders> | WHY THE HELL WOULD YOU SAY DON'T GIVE YOUR PASSWORD TO ANYONE… THEN SEND IT IN PLAINTEXT IN AN EMAIL!? |
| 19:02 | <gsnedders> | Sorry. |
| 19:02 | <TabAtkins> | ...? |
| 19:02 | <gsnedders> | I had a moment there. |
| 19:03 | <gsnedders> | Well, especially when dealing with organizations which have to have bank details, that makes me ueasy |
| 19:03 | <gsnedders> | *uneasy |
| 19:16 | <AryehGregor> | gsnedders, presumably they care about phishing but not MITM. |
| 19:30 | <MikeSmith> | annevk: back now & synched up the copy again |
| 19:30 | <MikeSmith> | thanks |
| 19:51 | annevk | was about to offer Mike a beer |
| 20:28 | <Philip`> | hober: Not just "a @microsoft.com address", but three in a day |
| 20:30 | <Peter-> | They posted on Canvas accessibility, a WebGL related topic and some HTML5 parser bits yesterday |
| 20:38 | <AryehGregor> | In whatwg rather than public-html? Remarkable. |
| 20:42 | <Philip`> | It's good that Microsoft is so secretive and quiet in the HTML standards groups, otherwise we couldn't have fun overanalysing their occasional utterances to try to extract patterns and trends |
| 20:46 | <MikeSmith> | Peter-: posted about Canvas accessibility? |
| 20:46 | Dashiva^2 | starts selling umbrellas to protect against falling pieces of sky |
| 20:47 | <Peter-> | MikeSmith: http://lists.w3.org/Archives/Public/public-html/2010Jun/0519.html |
| 20:47 | <Peter-> | that's on public-html |
| 20:48 | <MikeSmith> | ah yeah |
| 20:48 | <Peter-> | It would be rather odd to reply to <canvas> accessibility if they wouldn't be implementing the entire element themself.. |
| 20:48 | <MikeSmith> | stranger things have happened |
| 20:49 | <Peter-> | No argument there |
| 20:49 | <Peter-> | He is posting on behalf of the company however, while other posts mostly are on a more personal base |
| 20:51 | <AryehGregor> | My guess is that they'd like to implement it, modulo lawyers. |
| 20:51 | AryehGregor | sees no other feasible explanation. |
| 20:52 | <zcorpan_> | w3 bugzilla reached bug 10000! |
| 20:52 | <Peter-> | Four of the seven Apple disclosed patents related to canvas have yet to be published, according to http://www.w3.org/2004/01/pp-impl/40318/status#current-disclosures |
| 20:53 | <Peter-> | But IANAL. According to some larger news sites DP3 is pending for today, so that might clear things up |
| 20:55 | <Philip`> | Peter-: I believe those patents are all the same one (which is basically a description of the whole canvas API), just in different jurisdictions |
| 20:58 | <Peter-> | I did notice the US/HK/EP indicators, but the last four aren't exactly clear. It would indeed make sense |
| 21:04 | <AryehGregor> | Oh, yeah, Ben Vanik is @microsoft.com. He also seemed to be posting totally personally, which is a first for Microsoft on HTML5 lists in my experience . . . |
| 21:05 | <Peter-> | Sylvain Galineau seems to be posting a lot on subjects Microsoft isn't involved with, CSS mostly |
| 21:06 | <TabAtkins> | Well, Sylvain's been an active member of the csswg for some time. |
| 21:06 | <TabAtkins> | Microsoft is pretty active in the csswg. |
| 21:09 | <AryehGregor> | Yes, it always has been. |
| 21:09 | <TabAtkins> | Hmm, these posts by MS. Are they crossposted to htmlwg or something? |
| 21:09 | <Philip`> | No |
| 21:10 | <TabAtkins> | Interesting. I'm not seeing them for some reason, then. |
| 21:10 | <AryehGregor> | . . . why do the chairs seem to misannounce dates in public-html announcements at least 25% of the time? |
| 21:11 | <Philip`> | TabAtkins: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-June/026825.html, http://lists.whatwg.org/pipermail/implementors-whatwg.org/2010-June/000273.html, etc |
| 21:11 | <TabAtkins> | Oh, I'm not on the implementors list. That's why. |
| 21:14 | <Peter-> | Philip`: that last mail is interesting, "I encountered this bug in my own implementation." |
| 21:16 | <AryehGregor> | Why does the implementers list even exist? It only gets like three posts a month. |
| 21:16 | AryehGregor | subscribes |
| 21:17 | <Philip`> | Peter-: It seems he's one of the select bunch of people who implement HTML5 parsers just for fun :-) |
| 21:17 | <Philip`> | (An earlier mail says "to avoid misinterpretation, I am not on the IE team and do not speak for the IE team's plans") |
| 21:18 | <Peter-> | Aah, at least he's passionate about HTML then ^-^ |
| 21:19 | <AryehGregor> | Then why is he using his official e-mail address? |
| 21:19 | <AryehGregor> | MS doesn't have company policies on that? |
| 21:35 | <gsnedders> | (But what about other MS teams?) |
| 21:35 | <AryehGregor> | Maybe he's doing it for the Bing team. |
| 21:36 | <AryehGregor> | Hmm, this page renders somewhat unreadably in Chrome but is fine in Firefox. I wonder why? http://www.pcworld.com/article/168658/seven_reasons_microsofts_profits_are_tanking.html |
| 21:37 | <AryehGregor> | (Opera matches FF) |
| 21:37 | <TabAtkins> | Oh god. |
| 21:39 | <AryehGregor> | Seems like simple floats. |
| 21:39 | <TabAtkins> | Yeah, it's the #mainWell element that gets big, but I can't tell why. |
| 21:39 | <TabAtkins> | It doesn't have an explicit width on it, and its parent, #leftColumn, is a correct width. |
| 21:40 | <AryehGregor> | #blogArticle #mainWell { width: auto } |
| 21:40 | <AryehGregor> | Removing that fixes Chrome. |
| 21:40 | <AryehGregor> | Well, sort of. |
| 21:41 | <AryehGregor> | It's too narrow. |
| 21:41 | <TabAtkins> | Yeah, that allows the #mainWell { width: 351px; } rule to apply. |
| 21:41 | <AryehGregor> | Oh. |
| 21:42 | <AryehGregor> | So still odd. |
| 21:42 | <TabAtkins> | Yes. |
| 21:42 | <AryehGregor> | Removing float: left fixes it? |
| 21:42 | <TabAtkins> | Wow, yeah. That's... bizarre. |
| 21:43 | <AryehGregor> | Seems to change the padding or something in Firefox, but looks fine. |
| 21:43 | <AryehGregor> | Do you want to make a minimal test case, or shall I? |
| 21:43 | AryehGregor | wonders if this is a Chrome bug or a spec bug |
| 21:43 | <TabAtkins> | I'll do it, I suppose. I've got the relevant people to show it to just a few feet away. |
| 21:44 | <AryehGregor> | Show me the test case when you're done so I can poke at it. |
| 21:44 | <TabAtkins> | kk |
| 21:48 | <TabAtkins> | Ah, found it. Look in the last comment for an attempt at a bbcode url tag. |
| 21:48 | <TabAtkins> | It's long enough to stretch the element, and the BFC chain makes the article grow as well. |
| 21:49 | <TabAtkins> | So now to actually reduce and find the inconsistency. |
| 21:49 | <AryehGregor> | I hate it when content can stretch the whole page. |
| 21:56 | <TabAtkins> | Ah, and the issue is that Firefox is treating the /s in the url as break opportunities, while Chrome waits for the ? before finding one. |
| 21:56 | <AryehGregor> | Oh. |
| 21:56 | <AryehGregor> | I guess there's no good place to spec that. |
| 21:56 | <TabAtkins> | I... dunno. Hm. |
| 21:56 | <AryehGregor> | Kind of annoying, though. That should probably be standard. |
| 21:56 | <AryehGregor> | Since it can have major effects on layout like this. |
| 21:57 | <zcorpan_> | unicode has suggestions on breaking opportunities iirc |
| 21:57 | <zcorpan_> | http://unicode.org/reports/tr14/ |
| 21:58 | <Philip`> | "The third Internet Explorer Platform Preview is available for download. We're excited to announce the availability of several major features you've asked for, such as Canvas, HTML5 Video and Audio, SVG gradients, Web Fonts, and more." |
| 21:58 | <AryehGregor> | Woo-hoo! |
| 21:58 | <AryehGregor> | I guess still no WebM by default, though, huh? |
| 21:59 | <zcorpan_> | what do they mean by Web Fonts? |
| 21:59 | AryehGregor | assumes that's also because of lawyers, but is pretty sure he's right this time. |
| 21:59 | <Philip`> | zcorpan_: Maybe they mean WOFF |
| 21:59 | <zcorpan_> | WOFF? |
| 21:59 | <TabAtkins> | zcorpan_: Presumably proper support for @font-face. |
| 21:59 | <TabAtkins> | And/or WOFF, yeah. |
| 21:59 | TabAtkins | thinks IE8 had proper @font-face support. |
| 22:00 | <Philip`> | "This release includes support for the HTML5 <audio>, <video>, and <canvas> elements, the Web Open Font Format (WOFF), and many other new and improved capabilities." |
| 22:01 | <Philip`> | (Seemingly can't download it yet though - they're not very good at updating all their pages simultaneously) |
| 22:01 | <Philip`> | Ah, http://ie.microsoft.com/testdrive/info/ReleaseNotes/Default.html updated now |
| 22:02 | <Philip`> | "MP4 H.264 playback support, using hardware or software decoding. Support for WebM software is not included in this release" |
| 22:02 | <Philip`> | "Web font formats: EOT. WOFF. Raw installable fonts (TrueType, OpenType)" |
| 22:02 | <gsnedders> | msPerformance? |
| 22:02 | <AryehGregor> | What? |
| 22:02 | <AryehGregor> | TTF and OTF support? |
| 22:02 | <gsnedders> | window.msPerformance is what? |
| 22:03 | <gsnedders> | "HTML5-conformant whitespace handling" — childNodes? |
| 22:03 | <Philip`> | gsnedders: Maybe it's like a turbo button on old computers |
| 22:03 | <gsnedders> | Most of the new ES5 stuff except strict mode |
| 22:04 | <Philip`> | Before IE8 they wanted opt-in standards support, so maybe now they're doing opt-in performance |
| 22:08 | <Philip`> | http://ie.microsoft.com/testdrive/Graphics/DeepZoom/Default.html seems quite nice |
| 22:10 | <gsnedders> | With or without the turbo button pressed? |
| 22:12 | <Philip`> | I suppose turbo buttons couldn't work on modern computers because they have too many megahertz to display on the LED display, so users wouldn't know how fast their CPU was |
| 22:12 | jgraham | didn't realise that computers came with LCD displays until today |
| 22:13 | <Philip`> | It was bad enough when they exceeded 100MHz and had to add an extra two LEDs onto the left |
| 22:13 | <gsnedders> | jgraham: Then you tried to work out what you could do with it |
| 22:13 | <jgraham> | gsnedders: Well obviously |
| 22:13 | <jgraham> | Anyway I can't imagine his Steveness allowing such tasteless bling |
| 22:14 | <TabAtkins> | AryehGregor: Yeah, MS had been talking about TTF support. |
| 22:14 | <TabAtkins> | If it's what I've heard, you can only use TTF if none of the embedding bits are set. That excludes most existing desktop fonts. |
| 22:14 | <AryehGregor> | I thought the only reason WOFF existed is because MS refused to implement TTF support. |
| 22:14 | <Philip`> | So if everyone supports TTF now, why are we bothering with WOFF? |
| 22:14 | <TabAtkins> | Wonderful question! |
| 22:14 | <jgraham> | I thought font foundaries liked WOFF |
| 22:15 | <TabAtkins> | Yeah, for some reason they do. |
| 22:15 | <TabAtkins> | I'm pretty sure they don't understand it. |
| 22:15 | <AryehGregor> | Well, WOFF has built-in compression or something, right? |
| 22:15 | <AryehGregor> | So there's not absolutely no reason to use it? |
| 22:15 | AryehGregor | should test how IE9 handles his website . . . |
| 22:15 | <TabAtkins> | Yes, it uses a per-table compression algo. |
| 22:16 | <jgraham> | YEah I'm not sure how a tiny technical barrier can turn a whole industry from "impossible" to "fine" |
| 22:16 | <TabAtkins> | Which gets decently better numbers than just gzipping the whole thing. |
| 22:16 | <jgraham> | How much better? |
| 22:16 | <AryehGregor> | It's good anyway, you don't have to worry about configuring your web server to gzip it. |
| 22:16 | <TabAtkins> | I forget. There were comparisons with actual numbers on the font mailing list a year ago. |
| 22:16 | <TabAtkins> | Like 30% iirc. |
| 22:17 | <AryehGregor> | I'm all in favor of formats with built-in compression. |
| 22:17 | <AryehGregor> | Unless they're text formats to begin with, in which case it might be annoying. |
| 22:17 | <AryehGregor> | But fonts aren't text files, so there's basically no reason to not compress them. |
| 22:17 | <TabAtkins> | Yeah, but you're not losing anything with binary formats. |
| 22:17 | <AryehGregor> | (at the format level, I mean) |
| 22:17 | <jgraham> | I guess 30% might be non-negligible |
| 22:17 | <AryehGregor> | Even if the compression were just plain old gzip on the whole file. |
| 22:18 | <AryehGregor> | jgraham, you mean, when the font file blocks page rendering in some browsers? I'd say so. |
| 22:18 | <jgraham> | AryehGregor: Blocking rendering seems silly |
| 22:18 | <AryehGregor> | Well, tell the WebKit developers that. |
| 22:18 | <jgraham> | AryehGregor: Sure |
| 22:18 | <AryehGregor> | You have some FOUC-style effect either way. |
| 22:19 | <jgraham> | webkit developers: blocking rendering seems silly |
| 22:19 | <AryehGregor> | Unless you actually block rendering of the whole page from that point on, which no one does. |
| 22:19 | <jgraham> | AryehGregor: Presumably fonts are highly amenable to being cached |
| 22:19 | <AryehGregor> | Except that a large fraction of hits have empty cache in practice. |
| 22:19 | <AryehGregor> | Especially if most of your traffic is from occasional visitors, which is true for a lot of sites. |
| 22:20 | <jgraham> | In general, but for sites that you visit with any regularity it should be fine |
| 22:20 | <jgraham> | But I am not disagreeing with you |
| 22:20 | <AryehGregor> | Do I get to add parity-ie to the whiteboard of <https://bugzilla.mozilla.org/show_bug.cgi?id=276431>; now? |
| 22:21 | <jgraham> | (you can probably get similar savings just by using a better general-purpose compression algorithm on the whole file, since fonts tend to be rather static) |
| 22:22 | <jgraham> | (won't really work on the web though) |
| 22:22 | AryehGregor | needs to go use IE9 to check out his web page, and also the HTML5 beta on YouTube, just to see for himself that it's actually true |
| 22:22 | <AryehGregor> | jgraham, but that will be much slower to decompress. |
| 22:23 | <AryehGregor> | Oh, maybe YouTube does UA sniffing and blacklists IE9? |
| 22:23 | <jgraham> | AryehGregor: No idea how it compares to the format specific compression or other timescales |
| 22:29 | <JonathanNeal> | AryehGregor, probably not a blacklist, probably a whitelist "Supported Browsers" |
| 22:29 | <Philip`> | http://blogs.msdn.com/b/ie/archive/2010/06/23/html5-native-third-ie9-platform-preview-available-for-developers.aspx |
| 22:40 | <paul_irish> | thx Philip` for breaking the news. :D |
| 22:40 | <Peter-> | paul_irish: didn't you see it coming? :P |
| 22:41 | <paul_irish> | well everyone was hoping and expecting... but official confirmation is shit hot sweetness. |
| 22:41 | <Philip`> | paul_irish: I didn't do anything worthy of thanks - I just saw elsewhere on IRC that it had apparently been released, and then reloaded all the pages until MS got around to uploading them :-) |
| 22:41 | <Peter-> | I've spent quite some time last week writing a blog mock up about it, MS was just making it quite obvious |
| 22:42 | <Peter-> | replying on the canvas accessibility thing made it real obvious imo |
| 22:42 | <TabAtkins> | AryehGregor: https://bugs.webkit.org/show_bug.cgi?id=41103 |
| 22:43 | <TabAtkins> | Ironically, the bug itself demonstrates our linebreaking behavior. |
| 22:43 | <Philip`> | Peter-: I think they could reply on the canvas accessibility thing without having got into the details of actually implementing canvas |
| 22:43 | <Peter-> | Philip`: In theory, yes, but I consider it unlikely as he replied on behalf of Microsoft, instead of just on a personal note |
| 22:43 | <Philip`> | Their questions about specific requirements in the canvas spec seem more obvious, because nobody would look in that much detail unless they were implementing it or writing tests |
| 22:45 | <Peter-> | That too, indeed : |
| 22:48 | <Rik`> | 83/100 on Acid3. That's not something I expected so early on IE |
| 22:50 | AryehGregor | confirms that HTML5 YouTube works in the Platform Preview, although it's choppy right now |
| 22:52 | <AryehGregor> | So, my reaction to IE9 is now even more strongly 1) awesome!, and 2) be very afraid. |
| 22:53 | <AryehGregor> | TabAtkins, now, where should this be specced? |
| 22:53 | <TabAtkins> | Apparently, in Unicode. |
| 22:53 | AryehGregor | doesn't think "it shouldn't be specced" is a good answer, given the large rendering discrepancy on that page |
| 22:53 | AryehGregor | reads the Unicode spec |
| 23:00 | <Hixie> | http://www.youtube.com/watch?v=91bNp7HJolE |
| 23:05 | <AryehGregor> | TabAtkins, looks like U+002F SOLIDUS is in the class "SY: Symbols Allowing Break After (A)", so breaks should occur after it except if it immediately precedes a digit. |
| 23:05 | <AryehGregor> | "URLs are now so common in regular plain text that they need to be taken into account when assigning general-purpose line breaking properties. Slash (solidus) is allowed as an additional, limited break opportunity to improve layout of Web addresses. As a side effect, some common abbreviations such as “w/o” or “A/S”, which normally would not be broken, acquire a line break opportunity. The recommendation in this case is for the layout |
| 23:05 | <AryehGregor> | system not to utilize a line break opportunity allowed by SY unless the distance between it and the next line break opportunity exceeds an implementation-defined minimal distance. |
| 23:05 | <AryehGregor> | " |
| 23:05 | <AryehGregor> | Ack, too long. |
| 23:06 | <TabAtkins> | K, so we're not following unicode. That's cool. |
| 23:06 | <TabAtkins> | FWIW, IE doesn't follow that either. However, it puts a linebreak opportunity before [, so it still ends up wrapping that line sufficiently. |
| 23:06 | <AryehGregor> | The full algorithm looks quite complicated. I suspect browsers don't implement it for some reason. |
| 23:07 | <AryehGregor> | For instance, it says that breaks are permitted before %, but not if it's preceded by a number, even if there's intervening whitespace. |
| 23:07 | AryehGregor | tests that |
| 23:08 | <Philip`> | http://canvex.lazyilluminati.com/83b/play.xhtml - yay, Canvex sort of works in IE9, if I disable the SVG <object>s (otherwise it doesn't seem to load the wall textures) and do s/const/var/ in the JS |
| 23:08 | <AryehGregor> | Firefox 3.7, Chrome dev, and Opera 10.60 all ignore that. |
| 23:10 | <Philip`> | Still drops down to ~15fps in Ultra size when moving, though :-( |
| 23:11 | AryehGregor | can't figure out how [ is supposed to be handled |
| 23:11 | <AryehGregor> | It looks like "(AL | NU) × OP" means "do not break between an alphanumeric character and an opening punctuation character". |
| 23:17 | <AryehGregor> | Hmm, it seems like the prose contradicts the actual algorithm? |
| 23:17 | <TabAtkins> | That's not surprising. |
| 23:17 | <AryehGregor> | Oh, no, I see. |
| 23:17 | <AryehGregor> | It's covered by the last rule, "Break everywhere else." |
| 23:18 | <AryehGregor> | It actually looks to be very thorough and well-considered. |
| 23:18 | <AryehGregor> | The algorithm, I mean. |
| 23:18 | <TabAtkins> | That's cool. |
| 23:18 | <AryehGregor> | Although as with some other Unicode algorithms, it concedes that you may have to tailor it for best results. |
| 23:19 | <zcorpan_> | ok now i have ie9 preview 3 up and running |
| 23:19 | <zcorpan_> | doesn't seem to support <video controls> |
| 23:20 | <zcorpan_> | but does support <audio controls> |
| 23:21 | <zcorpan_> | hmm. only respects width/height on video if both are supported, and stretches the video instead of letterboxing |
| 23:22 | <zcorpan_> | ah, does support <video controls>, but they don't appear if the video is too small |
| 23:22 | <zcorpan_> | it seems they did fix the fallback bug i reported |
| 23:30 | <zcorpan_> | Philip`: i've run it through your canvas tests. do you want me to click 'submit results'? |
| 23:31 | <Philip`> | zcorpan_: No - that'll just give a 404, I think |
| 23:31 | <TabAtkins> | a;lskjdf;aslkdh;akl I cant' install preview 3. And i couldn't install preview 2 either. I uninstall preview 1.9, install preview 3, and it just gives me 1.9 back again. |
| 23:31 | <f1lt3r> | IE9 get's Canvas huh? Is this the end of SVG?! ...just kidding ;) http://bit.ly/aSIwRu |
| 23:32 | <Philip`> | zcorpan_: If you copy-and-paste the test output from the textarea thing then I could probably stick it into the results table fairly easily |
| 23:32 | <zcorpan_> | i wonder how i go back in ie9 preview |
| 23:33 | <TabAtkins> | zcorpan_: You use my computer, apparently. |
| 23:33 | <Philip`> | zcorpan_: I'm not sure that you can |
| 23:34 | <zcorpan_> | sigh |
| 23:34 | zcorpan_ | runs the tests again |
| 23:39 | <Philip`> | Can it cope with lots of tests on a single page? |
| 23:40 | <zcorpan_> | yeah |
| 23:40 | <zcorpan_> | is the 'generate report' button supposed to navigate to a different page? |
| 23:40 | <zcorpan_> | i don't get a chance to copy the textarea |
| 23:40 | <Philip`> | No, it should just fill in the textarea |
| 23:41 | <zcorpan_> | ie9 navigates... |
| 23:41 | <Philip`> | IE8 with excanvas doesn't, unless I'm horribly mistaken |
| 23:41 | <zcorpan_> | why the ******* is there no back functionality?? |
| 23:41 | <zcorpan_> | or stop? |
| 23:42 | <Philip`> | <button type="button" onclick="document.getElementById('report').value = genreport()">Generate test report</button> |
| 23:42 | <Philip`> | I assume I shouldn't need a return false in there, or anything like that? |
| 23:44 | <zcorpan_> | you shouldn't... but it seems ie9 wants to submit the form there |
| 23:47 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/518 (ie9 also screwed up the save function and gave "http://software.hixie.ch:80utilities/js/live-dom-viewer/saved/518";) |
| 23:47 | <AryehGregor> | zcorpan_, I think the idea is so no one uses it as their normal browser and then hates on them for its missing features. |
| 23:47 | <AryehGregor> | They seem to go a little overboard, though. |
| 23:48 | <Hixie> | does http://software.hixie.ch/utilities/js/live-dom-viewer/saved/519 show usemap="" working on <canvas> in any browser? I can't reproduce chaals' claim that all the browsers support it already. |
| 23:48 | <Hixie> | am I just doing it wrong? |
| 23:59 | <zcorpan_> | Philip`: ok i edited the DOM and could now copy the textarea |
