| 00:00 | <Hixie> | media-specific stuff and presentational stuff generally doesn't belong in html itself |
| 00:00 | <annevk3> | Hixie, and since it's specific to <textarea>/<input> i'd sort of like it to be in HTML5; just like <img>.height/width |
| 00:00 | <Hixie> | why would it be specific to textarea or input? |
| 00:00 | <annevk3> | the only use case is for those elements |
| 00:01 | <ojan> | Hixie: textarea/input are the only elements that get user-inserted content whose dimensions are not visible to a web-developer |
| 00:01 | <ojan> | Hixie: the use case in question is making a textarea/input that sizes to it's content |
| 00:02 | <Hixie> | ojan: wouldn't height:intrinsic just do that automatically? |
| 00:02 | <Hixie> | and width:intrinsic for the single-line case |
| 00:04 | <ojan> | Hixie: where is height/width:intrinsic specced? |
| 00:05 | <annevk3> | http://dbaron.org/css/intrinsic/ |
| 00:05 | <annevk3> | though it's not called intrinsic |
| 00:05 | <annevk3> | and it doesn't work in Mozilla which has implemented those properties |
| 00:05 | <annevk3> | solving this through CSS does seem better though |
| 00:06 | <ojan> | yeah, definitely for this use-case |
| 00:06 | <ojan> | and i can't think of other use-cases for knowing the size of a textarea/input's content |
| 00:07 | <annevk3> | anyway, bedtime |
| 00:07 | <annevk3> | nn |
| 00:08 | <ojan> | annevk3: thanks for your feedback. |
| 00:11 | <ojan> | Hixie: technically, the intrinsic width algorithms don't work on textareas/inputs because they look at the child blocks of a node |
| 00:12 | <ojan> | Hixie: which textareas/inputs don't have |
| 00:12 | <john_fallows> | Hixie: the SSE spec still references eventsource element in the Notes section |
| 00:13 | <ojan> | Hixie: nm. it would get the widht of the textnode inside the textarea |
| 00:18 | <ojan> | Hixie: does anyone implement height/width:intrinsic? |
| 00:19 | <Hixie> | ojan: textareas don't have text nodes (per specs, anyway), they are replaced elements with intrinsic dimensions |
| 00:19 | <Hixie> | ojan: no idea, don't think so |
| 00:19 | <Hixie> | john_fallows: oops |
| 00:22 | <Hixie> | ojan: i gotta say, the idea of text fields that grow as i type seems bad from a ui perspective |
| 00:28 | <Philip`> | I wrote a thing to let people edit numbers in a matrix, and used a table of <span contenteditable>s so that each column would automatically grow to fit the text you enter |
| 00:29 | <Philip`> | If I could use <input> and have it automatically grow then that'd be nicer |
| 00:31 | <Hixie> | that's plausible i guess |
| 00:31 | <Hixie> | defintely a css problem though |
| 00:32 | <ojan> | Hixie: gmail chat has this. textareas with a min-height of 36px, and a max-height of 80px |
| 00:32 | <Hixie> | yeah, it's fucking annoying |
| 00:32 | <ojan> | Hixie: that then grow with their content to 80px and then get a scrollbar |
| 00:32 | <Hixie> | i always end up mistyping, moving my caret to the wrong place, deleting stuff i wasn't expecting, all kinds of crap like that |
| 00:33 | <ojan> | Hixie: i'm much more annoyed at sites that just leave you stuck with small textareas |
| 00:33 | <Hixie> | that's why webkit's resize text areas thing is fine :-) |
| 00:34 | <ojan> | Hixie: on a somewhat related note, what do you think of height/width:intrinsic on iframes? |
| 00:35 | <Hixie> | has to be same-origin, but i think it's a good idea. <iframe seamless> relies on it. |
| 00:36 | <ojan> | Hixie: why does it have to be same-origin? |
| 00:36 | <ojan> | does leaking the height/width of the iframe really affect security? |
| 00:40 | <Hixie> | ojan: there are (mostly theoretical) concerns that it could, yeah. |
| 00:41 | <Hixie> | ojan: e.g. you could determine if someone is logged in to google or not pretty easily |
| 00:41 | <ojan> | Hixie: like what? |
| 00:42 | <ojan> | Hixie: I ask because one of the primary use cases I can think of is cross-domain |
| 00:42 | <Hixie> | or you might be able to work out someone's bank balance to an order of magnitude |
| 00:42 | <Hixie> | roc was the main one to originally bring up this concern |
| 00:44 | <ojan> | seems like a stretch to me. |
| 00:45 | <ojan> | Hixie: there are things that you can't do with height/width: intrinsic that you could if you had the contentWidth/Height |
| 00:46 | <ojan> | Hixie: i'm not sure they're real use cases though |
| 00:46 | <ojan> | Hixie: e.g. you have an app that has a textarea that fills most of the page, but you want a different background color behind the text |
| 00:47 | <Hixie> | again, that's stylistic |
| 00:47 | <ojan> | Hixie: you can't simulate that correctly with a textarea inside a div |
| 00:47 | <Hixie> | i'm all for presentational things, but they belong in css, cssom, and xbl; not html |
| 00:47 | <ojan> | Hixie: so you're saying that there could be a pseudo-element or something that represents the block inside the textarea? |
| 00:47 | <Hixie> | yeah, or xbl could be used to "reconstruct" the textarea out of contentEditable bits or some such |
| 00:48 | <Hixie> | or we could have a textarea syntax highlighting api |
| 00:48 | <ojan> | yeah...i guess there's a future world in which you could get an element that behaved like a textarea, but was actually a contentEditable div |
| 00:48 | <ojan> | that would be better anyways. |
| 00:49 | <ojan> | we're not too far from that now. |
| 01:02 | <roc> | ojan: leaking information through the sizes of pages may be a bit far fetched ... or maybe not. You could almost certainly use it to check for the existence of pages cross-domain |
| 01:02 | <ojan> | roc: that's true. |
| 01:02 | <roc> | basically, people have come up with all kinds of crazy exploits for the cross-domain information channels we currently have to support |
| 01:02 | <roc> | we're reluctant to add more such channels |
| 01:02 | <ojan> | roc: i'm just thinking of the crazy hackery things like google gadgets do to get cross-domain iframes to size to their content |
| 01:03 | <ojan> | roc: that's reasonable. |
| 01:03 | <roc> | just on the basis of "hmm, *I* can't think of a way to exploit this, right now" |
| 01:03 | <ojan> | roc: i buy that argument. |
| 01:03 | <ojan> | roc: it's just disappointing. |
| 01:03 | <roc> | pages should be able to opt into exposing this information |
| 01:04 | <roc> | they sort of already can using postMessage, but it's a pain |
| 01:04 | <ojan> | roc: yeah, it would be good if there were a declarative way |
| 01:04 | <ojan> | roc: a meta tag or somesuch |
| 01:05 | <ojan> | roc: wrt the contentHeight/Width discussion. what do you think of Hixie's suggestion to just support height/width:intrinsic instead? |
| 01:05 | <roc> | doesn't really work |
| 01:05 | <roc> | the intrinsic size of textareas is already defined |
| 01:05 | <ojan> | why? |
| 01:05 | <roc> | it's set by 'rows' and 'cols' |
| 01:06 | <roc> | that matters for table cell sizing etc |
| 01:06 | <roc> | maybe that's not actually specced and we could redefine it |
| 01:07 | <roc> | or maybe there should be a "shrinkwrap" control that redefines the intrinsic size to be based on the content of the textarea |
| 01:07 | <ojan> | roc: as in, a property on textareas/inputs? |
| 01:07 | <roc> | or maybe a CSS property |
| 01:08 | <roc> | but since 'rows' and 'cols' are already there ... |
| 01:08 | <ojan> | roc: it could be someone wonky like rows=intrinsic |
| 01:08 | <Hixie> | cols="" in HTML5 is basically just the way to set the point at which lines wrap |
| 01:09 | <roc> | yeah that's not a bad idea |
| 01:09 | <Hixie> | i didn't come up with a justification for rows="", but it's in there too for completeness |
| 01:09 | <roc> | Hixie: that's OK but it doesn't change the fact that the CSS intrinsic height has to be based on them too |
| 01:09 | <Hixie> | it doesn't have to be. we could define things in other ways. |
| 01:10 | <Hixie> | e.g. define two intrinsic dimensions, one triggered by height:auto and one by height:intrinsic |
| 01:10 | <Hixie> | or whatever |
| 01:10 | <roc> | adds complexity |
| 01:11 | <roc> | I hate having multiple variables that almost but not quite mean the same thing |
| 01:13 | <ojan> | really what we want is a way to tell a textarea to size like a div and an input to size like a span (minus the wrapping part) |
| 01:13 | <Hixie> | yeah, maybe there needs to be a value that means "auto-like-what-blocks-do-instead-of-intrinsic" |
| 01:14 | <roc> | really what we want is plaintext contenteditable :-) |
| 01:14 | <ojan> | roc: that's true |
| 01:15 | <ojan> | roc: does gecko support that |
| 01:15 | <ojan> | ? |
| 01:15 | <ojan> | roc: webkit does it turns out |
| 01:15 | <roc> | not in a Web-exposed way |
| 01:15 | <roc> | but our textareas and text inputs have an anonymous block inside, much like Webkit's |
| 01:16 | <roc> | setting up the editor with plain text rules probably wouldn't be too hard |
| 01:16 | <roc> | you have to worry about edge cases where the page inserts non-plaintext itself |
| 01:16 | <ojan> | roc: the way webkit's works is that you can insert non-plaintext from JS, but not from user-actions (e.g. paste) |
| 01:16 | <ojan> | roc: which i think is the preferred implementation actually |
| 01:17 | <ojan> | roc: allows you to do richer content (e.g. syntax highlighting) |
| 01:17 | <roc> | I'm not sure how our plain-text editing rules would interact with content that wasn't actually plain text |
| 01:17 | <ojan> | yeah, that's the tricky bit |
| 01:17 | <roc> | that's never been tested and therefore doesn't work |
| 01:18 | <ojan> | it would be a shame not to support it though. it opens up a ton of doors to doing things in web pages that are immensely difficutl right now |
| 01:19 | <ojan> | roc: http://www.plexode.com/cgi-bin/eval3.py#ht=%3Cdiv%20style%3D%22border%3A1px%20solid%22%20contentEditable%3D'plaintext-only'%3Eadsf%3C%2Fdiv%3E&ohh=1&ohj=1&jt=&ojh=1&ojj=1&ms=100&oth=0&otj=0&cex=1 |
| 01:20 | <roc> | no vendor prefix? shame! |
| 01:20 | <ojan> | (that's teh webkit contenteditabe) |
| 01:20 | <ojan> | roc: i'm not sure it was intentionally exposed actually... |
| 01:20 | <roc> | but yeah, that's the way to go! |
| 01:20 | <ojan> | roc: i only noticed it cuz i was looking at source code |
| 01:22 | <ojan> | roc: also works with -webkit-user-modify:read-write-plaintext-only |
| 01:22 | <ojan> | roc: worth me filing a mozilla bug for then? |
| 01:24 | <roc> | Maybe not until you have a spec for how it should work interoperably |
| 01:24 | <roc> | for example |
| 01:24 | <ojan> | roc: as in, how to deal with non-plaintexts that's inserted by thye page? |
| 01:24 | <roc> | yeah, mainly |
| 01:25 | <roc> | like if I'm in a <ul> |
| 01:25 | <roc> | and I hit return |
| 01:25 | <roc> | but it's plaintext mode |
| 01:25 | <roc> | does a list bullet get inserted? |
| 01:26 | <ojan> | roc: yeah. all that needs specing. fwiw webkit always just inserts a BR on enter in plaintext mode |
| 01:26 | <ojan> | as best i can tell |
| 01:26 | <roc> | that seems slightly weird to me |
| 01:26 | <ojan> | which seems totally reasonable and simple |
| 01:26 | <ojan> | lols |
| 01:27 | <ojan> | yeah, there's a ton of open questions |
| 01:27 | <ojan> | e.g. what happens when you hit backspace |
| 01:27 | <roc> | that too |
| 01:28 | <ojan> | roc: there's a small crew of us here at google that are working on specing all these thigns for regular contenteditable. probably wouldn't be too much extra work to spec it for plaintext contenteditable as well |
| 01:28 | <ojan> | roc: i'll bring it up in our next meeting |
| 01:28 | <roc> | also what happens with soft and hard spaces ... normally plain-text editing assumes white-space:pre or similar, but what if we're editing white-space:normal text? |
| 01:28 | <roc> | it starts to sound to me like the simplest way to spec plain-text mode would be to make it just like HTML mode except that certain user commands are completely disabled --- ones that create formatting where there wasn't any before, like "bold". |
| 01:29 | <roc> | and others like "paste" strip formatting |
| 01:30 | <roc> | ojan: I hope that spec will be open to outside feedback |
| 01:30 | <ojan> | roc: speaking of which we've been thinking we might be getting to a point where we'd want to involve other vendors to get their perspective. who on the mozilla side might be interested? |
| 01:30 | <roc> | haha |
| 01:30 | <ojan> | roc: :) |
| 01:30 | <roc> | it's probably better to publish it rather than make it invitation-only |
| 01:30 | <roc> | Chris Pearce could look at it |
| 01:31 | <roc> | Daniel Glazman might also be interested |
| 01:31 | <ojan> | roc: yeah...we're still doing the legwork of speccing the basics first |
| 01:31 | <ojan> | roc: e.g. we did a look at what existing word processors do when you hit enter/tab/etc and are trying to come up with recommended behaviors from that |
| 01:32 | <ojan> | roc: where existing word processors includes word, web browsers, notepad, textedit, etc |
| 01:32 | <roc> | yeah, it seems better to me to have plain-text mode just be HTML mode with enough stuff disabled that if you start with plain text, there is no way for the user to end up with anything but plain text |
| 01:33 | <ojan> | roc: i think i agree with you. the only exception is hitting enter |
| 01:33 | <ojan> | roc: i think inserting a br on enter is not really what you want in the rich-edit case |
| 01:34 | <ojan> | where in plain-text, with just user-inserted content, i would expect the end result to just be text + BRs |
| 01:35 | <roc> | seems to me if the user hits enter in white-space:pre text, we should just insert a newline |
| 01:35 | <roc> | in either mode |
| 01:35 | <ojan> | roc: yup...but plaintext doesn't imply white-space:pre, right? |
| 01:35 | <ojan> | or maybe it should |
| 01:35 | <roc> | no |
| 01:35 | <roc> | but they'll often go together |
| 01:36 | <ojan> | roc: yeah, in practice you'd usually want white-space:pre-wrap i guess |
| 01:36 | <roc> | yeah |
| 01:36 | <roc> | either way |
| 01:37 | <ojan> | roc: does gecko not support user-modify? |
| 01:38 | <ojan> | i just tried -moz-user-modify:read-write |
| 01:39 | <roc> | not really |
| 01:39 | <roc> | as far as I know |
| 01:40 | <roc> | we just hide the caret but don't actually block editing if it's contenteditable |
| 01:40 | <ojan> | oh weird...netscape supported it but gecko doesn't? |
| 01:40 | <ojan> | (according to the interwebs) |
| 01:41 | <roc> | I'm not sure what it means to "support" it if you don't support contenteditable |
| 01:41 | <roc> | which Netscape didn't |
| 01:41 | <roc> | of course |
| 01:41 | <ojan> | yeah |
| 01:41 | <ojan> | i was looking at http://www.aptana.com/reference/html/api/CSS.field.-moz-user-modify.html |
| 01:41 | <ojan> | user-modify is way more useful that contentEditable though |
| 01:42 | <ojan> | not for the read-only or write-only properties, but that you can nest editable bits inside non-editable bits inside editable bits without messing with the actual DOM. |
| 01:42 | <ojan> | lets you do things with layout like image captions that are otherwise really really hard |
| 01:43 | <ojan> | roc: anyways, i have to go. thanks for your feedback today |
| 07:42 | <Hixie> | i hate browser release days |
| 07:43 | <hsivonen> | Hixie: you should move acid tests to a different server |
| 07:43 | <Hixie> | tempted |
| 08:10 | <aboodman> | Hixie: has anyone been in here recently asking about localstorage and concurrency? |
| 08:10 | <aboodman> | the topic has come up on a chromium mailing list, i guess it is complicated. |
| 08:10 | <Hixie> | sicking mentioned it a few weeks ago |
| 08:11 | <Hixie> | the spec right now just assumes a global lock that is released by the script ending |
| 08:11 | <Hixie> | which i guess isn't so hot |
| 08:11 | <Hixie> | what does IE8 do? |
| 08:11 | <aboodman> | not sure |
| 08:11 | <aboodman> | good question |
| 08:15 | <hsivonen> | aargh. The release version of IE8 shows the compatibility view button even with the HTML5 doctype |
| 08:15 | <hsivonen> | didn't the Windows 7 RC not do that? |
| 08:30 | Hixie | moves the web workers source document into the html5 source document |
| 08:41 | <Hixie> | ok my script now generates |
| 08:41 | <Hixie> | 2 whatwg specs |
| 08:42 | <Hixie> | 5 w3c specs |
| 08:42 | <Hixie> | 1 ietf spec |
| 08:42 | <Hixie> | a validation report |
| 08:42 | <Hixie> | diffs |
| 08:42 | <Hixie> | checks for broken links |
| 08:42 | <Hixie> | and checks for how many issues were added or removed |
| 08:42 | <hsivonen> | Hixie: you can then publish the full thing as a "compilation" of 6 specs :-) |
| 08:43 | <Hixie> | that's what i validate :-) |
| 08:48 | <Hixie> | and my commit script commits to two subversion repos, five cvs repos, and submits the I-D to the IETF system |
| 08:48 | <Hixie> | oh and generates the multipage version |
| 08:49 | <Hixie> | oh and my main script also gets the pubrules check on the main html5 spec |
| 08:49 | <Hixie> | and there's a cronjob that counts issues and makes pdfs |
| 08:49 | <Hixie> | ok bed time now |
| 08:49 | <Hixie> | nn |
| 08:49 | <hsivonen> | nn |
| 09:06 | <hsivonen> | can someone help me understand why http://hsivonen.iki.fi/html5-lecture/html5-tml.ogg works in Firefox, in XiphQT and in VLC on Mac but not in VLC on Windows or VLC on Linux? |
| 09:12 | zcorpan | confirms that it doesn't work with vlc on windows but works with mplayer on windows |
| 09:12 | <jgraham> | hsivonen: Define "works" |
| 09:12 | <jgraham> | It started playing with VLC/linux for me |
| 09:13 | <jgraham> | but I don't think sound was working |
| 09:13 | <jgraham> | But that could be my system |
| 09:13 | <zcorpan> | yes it plays but it looks like garbage |
| 09:15 | <zcorpan> | hsivonen: is there any sound? |
| 09:22 | <zcorpan> | hsivonen: mplayer says the video is 0:47:14 long but it plays beond that |
| 09:24 | <hsivonen> | jgraham, zcorpan: there should be 1024*768@15fps video and mono audio. I only get audio in VLC on Intrepid and Windows 7 |
| 09:24 | doublec | looks |
| 09:25 | <hsivonen> | the right duration is 1:36:11 |
| 09:25 | <hsivonen> | oops. bad "only" placement |
| 09:26 | <hsivonen> | in VLC on Intrepid and Windows 7, audio plays, video does not |
| 09:26 | <hsivonen> | in Firefox on Mac and Windows 7, both audio and video play |
| 09:26 | <hsivonen> | in VLC and QiphQT on Mac, both audio and video play |
| 09:26 | <doublec> | yeah, plays fine in ff on linux here |
| 09:27 | <hsivonen> | could it be that the video is CPU-intensive and VLC drops video altogether if it can't play it in real time? |
| 09:29 | <doublec> | where is it not playing? |
| 09:29 | <doublec> | it works in mplayer, vlc and ff for me |
| 09:30 | <hsivonen> | doublec: video doesn't play on Intrepid on older computer and doesn't play on Windows 7 (on virtual machine) |
| 09:31 | <jgraham> | hsivonen: It plays on VLC/Intrepid for me |
| 09:31 | <jgraham> | I can't test the audi though as VLC is complaining oss audio output error: cannot open audio device (/dev/dsp) |
| 09:32 | <hsivonen> | hmm. video plays on intrepid totem on a VM for me but not on older hardware |
| 09:32 | hsivonen | blames old hardware and moves on |
| 09:32 | <hsivonen> | thanks |
| 09:34 | <jgraham> | Yeah it plays on totem for me too |
| 09:34 | jgraham | wonders how to fix his audio problems |
| 09:38 | <doublec> | see what has the audio device locked open? |
| 09:38 | <doublec> | sudo lsof |grep snd |
| 09:50 | <virtuelv> | jgraham: kill pulseaudio? |
| 09:52 | <jgraham> | virtuelv: That seemed to help, although it really didn't want to die |
| 09:53 | <virtuelv> | jgraham: you'll be happy to note that I haven't had a single sound problem since updating to jaunty (except two days ago, where everything went bonkers for all of five minutes) |
| 09:54 | jgraham | is slightly nervous to update a miachine he has to work on to a prerelease OS |
| 09:54 | <jgraham> | *machine |
| 09:54 | <jgraham> | So I guess I will wait a bit and then have sound joy in april (hopefully) |
| 09:59 | <virtuelv> | jgraham: I wasn't suggesting you updated just yet :-) |
| 10:00 | <virtuelv> | I did so to circumvent other issues, particularily with multi-monitor support on my work machine |
| 10:01 | <virtuelv> | so far, I've not had any downtime at all |
| 10:01 | jgraham | would also like to get multi-monitor support working better |
| 10:01 | <jgraham> | Although that might be solvable without an upgrade |
| 10:03 | <virtuelv> | it's mostly solvable, except if you drag your machine around a lot |
| 10:04 | <hsivonen> | It seems that Ogg total duration display is rather broken in various apps |
| 10:04 | <hsivonen> | perhaps the ability to cat two ogg streams isn't such a great feature after all |
| 10:07 | <virtuelv> | ok, vlc has problems getting continuous playback of the audio |
| 10:07 | <virtuelv> | but video is fine |
| 10:09 | <virtuelv> | it's lost 1216 buffers a few minutes into the video |
| 10:10 | <virtuelv> | hsivonen: I see you're encoding the audio at 8Khz |
| 10:11 | <virtuelv> | unless saving those megabytes is an extreme priority, I'd just use 44.1 or 48, given that a sound card usually has to upsample anyhow |
| 10:11 | <hsivonen> | virtuelv: the orginal recording was 8 kHz |
| 10:11 | <hsivonen> | *original |
| 10:11 | <hsivonen> | virtuelv: recorded on Nokia N800 |
| 10:12 | <hsivonen> | I'd love to know how to do this properly next time |
| 10:12 | <hsivonen> | with a bluetooth microphone and screen capture software that doesn't suck and can spool a couple of hours of screen data |
| 10:13 | <hsivonen> | or a new version of Keynote if the new version doesn't suck |
| 10:15 | <jgraham> | When we did this kind of thing for a conference we ended up using some box that sat between the computer and the projector to capture the video. But that had the requirement that people be able to use their own laptops |
| 10:15 | <jgraham> | so we couldn't install any special software |
| 10:15 | <jgraham> | (and everyone wore a mic and we captured the audio from that somehow) |
| 10:16 | <virtuelv> | hsivonen: This was basically just a screencast, and meant as such, right? |
| 10:16 | <doublec> | most ogg players don't handled cat'd streams well |
| 10:16 | <virtuelv> | convert your presentation to SVG? :P |
| 10:49 | <hsivonen> | virtuelv: it was meant to be a live audio recording of a lecture with synchronized projector-equivalent video |
| 10:49 | <hsivonen> | virtuelv: I lack the authoring tools for doing this in SVG |
| 10:50 | <hsivonen> | jgraham: how much does such a box weigh and cost? I'd expect a box to be an overkill for someone who presents perhaps twice a year |
| 10:52 | <jgraham> | hsivonen: Don't know. It was pretty small. It wasn't the perfect solution since it was basically intercepting the video signal occasionally; I think we had to have quite infrequent sampling to make it work well enough, but that means video and things don't get captured so well |
| 10:52 | <jgraham> | hsivonen: See http://www.ast.cam.ac.uk/meetings/gravity08/video_archive.html for example output |
| 10:53 | <hsivonen> | jgraham: I want a solution that samples 15 times per second but is smart enough to encode just a repeat bit when the frame is the same as the previous one |
| 10:53 | <hsivonen> | I will have to experiment with Snapz Pro in the two-screen Keynote presentation mode |
| 10:58 | <hsivonen> | heh. Lessig on Keynote's video export: "Like selling a spreadsheet that can't multiply" |
| 11:03 | <hsivonen> | also, I should get some "umm" and "uhh" elimination coaching te make recording more worthwhile... |
| 11:06 | <jgraham> | hsivonen: I thought you started off slightly shaky but got a lot better once you got into it |
| 11:06 | <hsivonen> | jgraham: thanks |
| 11:52 | <hsivonen> | hmm. SMIL 3.0 allows declarative content selection based on OS name... |
| 12:24 | zcorpan | wonders whether the split-out sections are now only under w3c license and not under whatwg license |
| 12:25 | hsivonen | wonders what build howcome used for http://people.opera.com/howcome/2009/talks/03-css3.html |
| 12:26 | <hsivonen> | rounded corners and box-shadow don't work in Opera 10 |
| 12:26 | <zcorpan> | hsivonen: probably some internal build using presto 2.3 |
| 12:26 | <hsivonen> | zcorpan: ah. rounded corners are coming, then. Yay! |
| 12:27 | <annevk3> | post Opera 10 most likely |
| 12:34 | <Lachy> | the CSS3 Transitions demo in that presentation draws the Opera logo upside down. I wonder why he did that. |
| 12:39 | <jgraham> | zcorpan: That would be quite worrying. Although I think we could go back to the earlier versions if Hixie turns evil or something |
| 12:42 | <annevk3> | the source document is still under a liberal copyright aiui |
| 12:42 | <jgraham> | Still someone should email the list because it is unclear |
| 12:47 | <hsivonen> | are tests 007, 008 and 009 at http://hixie.ch/tests/adhoc/dom/level0/write/ demos or test cases? |
| 12:47 | <hsivonen> | if they are test cases, what's the pass condition? |
| 12:49 | <hsivonen> | a number of those tests leave the trobber in the loading state in Firefox |
| 12:49 | <annevk3> | "WARNING!! 004 to 013 are DEMOS not TESTS at this time." |
| 12:49 | <annevk3> | rtfm |
| 12:49 | <annevk3> | o_O |
| 12:49 | <hsivonen> | oops. I read "to" as "and". need to be more careful |
| 12:51 | <hsivonen> | sigh. I fail already at test 003 |
| 14:21 | <hsivonen> | I'm completely confused by the results I'm getting with http://hixie.ch/tests/adhoc/dom/level0/write/003.html |
| 14:21 | <hsivonen> | as far as I can tell, all the scripts run, but for some reason most of them leave no trace in the variable collecting the results |
| 14:35 | <hsivonen> | hmm. so I indeed have the right execution order |
| 14:35 | <hsivonen> | perhaps I lose the window object on the way... |
| 15:23 | <Philip`> | http://search.cpan.org/dist/IWL/lib/IWL/Canvas.pm |
| 15:23 | <Philip`> | Seems likes it generates JS code for each method you call, which seems a bit peculiar compared to simply writing the JS yourself |
| 15:24 | <hsivonen> | but code generation FTW! |
| 15:25 | <jgraham> | Also it is widely known that javascript is a horrible language that people used to perfectly sensible languages like perl avoid at all costs |
| 15:26 | <Philip`> | At least JS lets you use $ in your variable names, so it's not all that different |
| 16:30 | <Philip`> | http://stopdesign.com/archive/2009/03/20/goodbye-google.html - "a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better" |
| 16:30 | <Philip`> | Aha, that explains http://krijnhoetmer.nl/irc-logs/whatwg/20090303#l-561 |
| 16:30 | <Philip`> | Also, it's taking the colour-of-the-bikeshed idea to a whole new level |
| 16:52 | <hsivonen> | wow. the IE8 mode switching is so insane that it is hard to express as a flowchart |
| 17:04 | <hsivonen> | This flowchart is looking way too crazy |
| 17:04 | <hsivonen> | I think I'm going to continue it another day |
| 17:04 | <Philip`> | Would it be easier to write as code rather than as a flowchart? |
| 17:04 | <hsivonen> | perhaps |
| 17:05 | <hsivonen> | with goto |
| 17:05 | <hsivonen> | well, perhaps with function calls, too |
| 17:05 | <hsivonen> | but so far I am confident to say that anyone who presents three or so simple rules is not telling the whole story |
| 17:07 | <hsivonen> | also, it seems that too many people jumped the gun with stuff documented at the beta stage |
| 17:08 | <hsivonen> | the only way to hide the compat button (for an author) is to use new previously unadvertised X-UA-Compatible values |
| 17:10 | <karlcow> | http://beta.w3.org/ |
| 17:12 | <Philip`> | hsivonen: Which values are those? |
| 17:12 | <hsivonen> | and of course, MSDN documentation is wrong (Film at 11) |
| 17:12 | <hsivonen> | IE=8 |
| 17:13 | <hsivonen> | IE=7 |
| 17:13 | <hsivonen> | Philip`: ^ |
| 17:13 | <hsivonen> | Philip`: as opposed to IE=IE8 |
| 17:14 | <hsivonen> | MSDN is wrong about IE=a |
| 17:15 | <hsivonen> | current draft: http://hsivonen.iki.fi/ie8-mode.pdf |
| 17:30 | <mpilgrim> | hsivonen: that flowchart makes no sense |
| 17:30 | <mpilgrim> | to me |
| 17:31 | <mpilgrim> | what happens if the X-UA-Compatible meta element is not present? |
| 17:41 | <Philip`> | I see some code in IE saying /rss/channel/*[local-name() = 'X-UA-Compatible' and namespace-uri() = 'http://www.microsoft.com/schemas/rss/monitoring/2007';] |
| 17:42 | <Philip`> | I guess that means there's an <rssmonitoring:X-UA-Compatible> element you can use? |
| 17:51 | <mpilgrim> | http://www.google.com/search?q=rssmonitoring+site:microsoft.com says that namespace is about web slices |
| 17:53 | <mpilgrim> | but it may have been an earlier version |
| 17:53 | <mpilgrim> | the current web slices seems to be based around hAtom |
| 17:53 | <mpilgrim> | can't find documentation of that namespace |
| 17:54 | <mpilgrim> | but it makes sense that if IE/trident-based apps are displaying HTML fragments from feeds, MS would want a way to specify the rendering mode of such fragments |
| 17:55 | <mpilgrim> | (at least, it makes as much sense as anything else MS has done with their rendering modes) |
| 17:59 | <hsivonen> | mpilgrim: It's a draft, so it is missing arcs. Nodes, too! |
| 18:26 | <Philip`> | hsivonen: Maybe you could write the flowchart in Graphviz so it'll automatically do all the layout, rather than trying to squeeze more arcs into it manually |
| 19:08 | <ojan> | Hixie: ping |
| 19:08 | <Hixie> | hey |
| 19:08 | <ojan> | Hixie: after yesterday's discussion, i came to the conclusion that worrying about textareas and inputs working better is silly |
| 19:08 | <Hixie> | heh |
| 19:08 | <ojan> | Hixie: we should instead focus on making contentEditable meet the textarea/input use-cases |
| 19:09 | <ojan> | Hixie: because replaced elements are just dumb. |
| 19:09 | <ojan> | Hixie: webkit already supports contentEditable=plaintext-only |
| 19:09 | <ojan> | Hixie: so that's most of it |
| 19:09 | <ojan> | the only thing left is making it so elements can get treated as form controls |
| 19:10 | <ojan> | e.g. get browser auto-restore, auto-submission in forms, etc |
| 19:10 | <Hixie> | that's non-trivial |
| 19:10 | <ojan> | Hixie: then this totally replaces the need to try and come up with APIs on textareas to do syntax highlighting etc |
| 19:11 | <Hixie> | to put it bluntly |
| 19:11 | <ojan> | Hixie: i've not really thought about it much, what's difficutl about it? |
| 19:11 | <Hixie> | i think for syntax highlighting requiring authors to do DOM manipulation is going to be painful |
| 19:11 | <Hixie> | so painful, e.g., that the Bespin guys wrote their own editor using <canvas> rather than doing it |
| 19:11 | <ojan> | i'm not convinced that's true |
| 19:12 | <Hixie> | that's a bit like saying "what's difficult about building an aircraft carrier" :-) |
| 19:12 | <ojan> | if all user-insertion is plain-text |
| 19:12 | <ojan> | and the JS has total control over the DOM |
| 19:12 | <ojan> | the hard part currently is dealing with the fact that the user can insert any sort of crazy |
| 19:12 | <Hixie> | if the user inserts a " and you now have to go through an redo all the DOM just to change colours, that's going to be crazy |
| 19:12 | <ojan> | but if you control the DOM that gets created, then you can make a lot of simplifying assumptions |
| 19:12 | <Hixie> | and simply isn't going to scale to multimegabyte files |
| 19:13 | <ojan> | that's true |
| 19:13 | <Hixie> | you want to be able to just style what's on the screen, and you want to do it quickly, just walking through the source saying blue, blue, green, blue, etc |
| 19:13 | <inimino> | doing syntax highlighting with DOM in real time is very painful |
| 19:13 | <Philip`> | Real (non-web) text editors don't scan through the entire file when updating syntax highlighting - they just do it incrementally, and sometimes get it wrong but nobody minds |
| 19:14 | <Philip`> | (Or at least Vim doesn't, judging by how it sometimes gets confused when I jump around in a Perl script) |
| 19:14 | <ojan> | Hixie: forgetting syntax highlighting for a moment, there are plenty of other good use-cases for plaintext contentEditable |
| 19:15 | <Hixie> | Philip`: emacs' appears to be full-file, but it's async and doesn't handle all of perl's constructs |
| 19:15 | <Hixie> | ojan: no disagreement from me here, i just think that making it fit into the form submission model and session history is a giant amount of work |
| 19:16 | <ojan> | Hixie: why? |
| 19:16 | <ojan> | Hixie: what's different about it from a textarea? |
| 19:16 | <Hixie> | again, that's a bit like asking "why is building an aircraft carrier hard?". it's just a lot of complexity, there's no one big problem. |
| 19:16 | <Hixie> | it's doable |
| 19:16 | <Hixie> | it's just a lot of work |
| 19:17 | <Hixie> | probably a lot more work than just fixing <textarea> would be |
| 19:17 | <Hixie> | but what we should do is start from use cases |
| 19:17 | <Hixie> | look at requirements, and consider how best to address them for user and authors |
| 20:00 | <Hixie> | ahhhh |
| 20:00 | <Hixie> | having the web workers source in the same documents as html5 makes my life so much easier |
| 20:20 | <john_fallows> | Hixie: with the spec refactoring to extract EventSource and WebSocket APIs, where is the best place to track evolution of the wire protocol for WebSockets? |
| 20:21 | <Hixie> | the wire protocol is at http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol |
| 20:29 | <jgraham> | The google logo today is cool |
| 20:42 | <mpilgrim> | hsivonen: fair enough; i'm mostly interested in the shortest path (measured in bytes) to get IE8 to act like a real browser, i.e. best-possible-standards-mode or whatever it is they're calling it |
| 20:43 | <mpt> | ha |
| 20:43 | <mpt> | We received our first "Your Web site doesn't work properly in Compatibility View" bug report today |
| 20:45 | <jcranmer> | Hixie: oh, yuck @ the draft |
| 20:45 | <Hixie> | hm? |
| 20:45 | <hsivonen> | mpilgrim: X-UA-Compatible: IE=8 as a HTTP header plus the HTML5 doctype |
| 20:46 | <jcranmer> | why can't you be like a normal RFC? |
| 20:46 | <Hixie> | hsivonen: surely that will then fail in IE9? |
| 20:46 | <Hixie> | jcranmer: how is it not like a normal RFC? |
| 20:46 | <hsivonen> | Hixie: who knows |
| 20:46 | <jcranmer> | it's way too complicated |
| 20:46 | <Hixie> | i don't know much about writing RFCs |
| 20:46 | <Hixie> | any advice on making it easier would be welcome |
| 20:46 | <Philip`> | IE=edge should still work |
| 20:47 | <hsivonen> | Philip`: more bytes |
| 20:47 | <jcranmer> | explain that the protocol uses UTF-8 or ASCII or whatever |
| 20:47 | <jcranmer> | and just write the text out in ASCII |
| 20:47 | <mpilgrim> | i was hoping for something that didn't involve adding MS-specific cruft to the output stream |
| 20:47 | <Philip`> | assuming IE9 doesn't treat 'edge' as a synonym for '8' for compatibility |
| 20:47 | <mpilgrim> | but maybe that's too much to ask |
| 20:47 | <Hixie> | jcranmer: ? |
| 20:47 | <hsivonen> | Philip`: exactly |
| 20:47 | <john_fallows> | Hixie: thanks, what is the process for participating in community feedback for that? is it the same as before with the HTML5 mailing list and this IRC channel, or is there a new process for WebSocket wire protocol now that it is IETF instead of W3C ? |
| 20:47 | Hixie | looks at the i-d to see what jcranmer means |
| 20:47 | <Hixie> | john_fallows: the whatwg list is still an appropriate place for now |
| 20:48 | <jcranmer> | http://tools.ietf.org/html/rfc3977 is one that's easier for me to read... |
| 20:48 | <hsivonen> | mpilgrim: I was hoping that the HTML5 doctype would hide the compat view button, but sadly, it does not :-( |
| 20:48 | <john_fallows> | Hixie: ok, thanks. I suppose that will be changing later on, but will continue to provide feedback here until then. |
| 20:49 | <Hixie> | jcranmer: i don't understand what is hard to read |
| 20:49 | <Hixie> | jcranmer: can you be more specific? |
| 20:49 | <Hixie> | john_fallows: yeah, next week will be when we find out what the IETF wants to do, i imagine |
| 20:50 | <jcranmer> | Hixie: say something along the lines of "The character set for all commands is UTF-8" (or US-ASCII, if you prefer) and forgo rewriting every string in hexadecimal |
| 20:50 | <Hixie> | jcranmer: it's a binary wire protocol. i don't understand what you mean. There are no commands. |
| 20:51 | <Hixie> | jcranmer: could you point to a specific section with what you mean? |
| 20:51 | <jcranmer> | § 2.1 |
| 20:52 | <jcranmer> | instead of saying "Send ... 47 45 54 20..." just say "Send GET ..., encoded as ASCII" |
| 20:52 | <Hixie> | jcranmer: i do not have faith that if i give strings, they will be sent correctly. For example, it is not uncommon for people to get the CRLF thing in HTTP wrong. |
| 20:53 | <Hixie> | jcranmer: why does it matter what the strings are, anyway? |
| 20:53 | <Hixie> | jcranmer: it's just an opaque handshake |
| 20:53 | <jcranmer> | it's easier to read |
| 20:53 | <Hixie> | why would you need to read those byte sequences? |
| 20:53 | <Hixie> | it doesn't matter what they say |
| 20:53 | <Hixie> | they're opaque |
| 20:53 | <Hixie> | it does in fact say what they say, under the blocks of bytes |
| 20:53 | <Hixie> | where it says NOTE: |
| 20:54 | <jcranmer> | I'll also admit that I first interpreted it as saying |
| 20:54 | <jcranmer> | "Send the string "47 45 54 20"..." |
| 20:55 | <jcranmer> | i.e, 34 37 20 34 35 20 35 34 20 32 30... |
| 20:55 | <Hixie> | it says "send the following bytes" |
| 20:55 | <Hixie> | i don't know how to be clearer than that |
| 20:59 | jcranmer | also notes that there are /too/ many instances of //'s for his tastes |
| 21:00 | <Hixie> | jcranmer: yeah well i'd rather not be using ASCII |
| 21:01 | <Hixie> | jcranmer: but if we're stuck in the 70s, i need some way to distinguish variable names from prose |
| 21:01 | <Hixie> | jcranmer: and /var/ is the convention |
| 21:01 | <mpilgrim> | we must be discussing RFCs |
| 21:01 | <jcranmer> | well, you've successfully made it not feel like an RFC |
| 21:02 | <jcranmer> | I don't think I see a single SHOULD, MUST, or MAY in there |
| 21:02 | <Hixie> | there are 10 MUSTs |
| 21:02 | <Hixie> | 7 SHOULDs |
| 21:02 | <Hixie> | and 4 MAYs |
| 21:02 | <mpilgrim> | are they capitalized? |
| 21:03 | <jcranmer> | no |
| 21:03 | <mpilgrim> | ah |
| 21:03 | <Hixie> | no |
| 21:03 | <jcranmer> | the capitalization is key, IMHO |
| 21:03 | <Hixie> | capitalising them looks dumb |
| 21:03 | <mpilgrim> | you MUST capitalize |
| 21:03 | <jcranmer> | you also didn't cite RFC 2119 |
| 21:03 | <Hixie> | really? |
| 21:03 | <Hixie> | crap, i must have missed including the boilerplate |
| 21:03 | <Hixie> | woah |
| 21:03 | <Hixie> | no conformance section |
| 21:04 | <Hixie> | i forgot to copy that over when i extracted this from html5 |
| 21:04 | <Hixie> | my bad |
| 21:04 | <Hixie> | will fix |
| 21:04 | mpilgrim | is guessing hixie hasn't learned about RFC nits yet |
| 21:04 | <Hixie> | i hate the rfc format |
| 21:04 | <mpilgrim> | or you've forcibly erased it from your mind |
| 21:04 | <Hixie> | "stuck in the 70s" really is the only way to describe it |
| 21:05 | <mpilgrim> | http://www.ietf.org/ID-Checklist.html |
| 21:05 | <jcranmer> | hey, I like RFCs |
| 21:05 | <mpilgrim> | there are automated tools to check for nit-compliance |
| 21:05 | <Hixie> | mpilgrim: i run them |
| 21:05 | <mpilgrim> | and they missed the fact that you have no boilerplate section?! |
| 21:06 | <mpilgrim> | i think you're doing it wrong ;) |
| 21:06 | <Hixie> | i have the ietf boilerplate |
| 21:06 | <Hixie> | just not the whatwg boilerplate |
| 21:06 | <mpilgrim> | ah |
| 21:06 | <Hixie> | here i'll do it now |
| 21:07 | <mpilgrim> | bah, gotta go hang out with wife's work friends |
| 21:16 | <Hixie> | olliej: yt? |
| 21:16 | <olliej> | Hixie: yup |
| 21:16 | <Hixie> | olliej: did you get a feeling that the mozilla guys came to some kind of agreement on how to do importScripts()? |
| 21:17 | <olliej> | Hixie: err, i believe we did |
| 21:17 | <olliej> | but i can't recall what it was |
| 21:17 | <olliej> | i think we just decided that the current spec was right |
| 21:18 | <Hixie> | so mozilla's going to change? |
| 21:22 | <Hixie> | olliej: they concur, thanks |
| 21:22 | <olliej> | \o/ |
| 21:29 | <mpilgrim> | hooray for android! |
| 21:32 | <Hixie> | jcranmer: i tried to fix it, but the ietf won't accept ID submissions for some reason |
| 21:33 | <Hixie> | i'm starting to get really tired of the ietf |
| 21:33 | <Hixie> | and i've barely started working with them |
| 21:41 | <Hixie> | jcranmer: i put a copy at http://www.whatwg.org/specs/web-apps/current-work/.ietf-websocket-protocol/draft-hixie-thewebsocketprotocol-04 |
| 21:41 | <Hixie> | while i wait for the ietf to learn what "release early release often" means and why month-long outages are ridiculous |
| 21:46 | <Hixie> | olliej: are you ok with us just dropping prototypes in the structured cloning step? |
| 21:46 | <Hixie> | olliej: or do you want is to flatten? |
| 21:46 | <olliej> | Hixie: yes |
| 21:46 | <olliej> | Hixie: drop them |
| 21:46 | <Hixie> | ok |
| 21:46 | <olliej> | Hixie: i'm also unsure what is meant by "host object" |
| 21:47 | <olliej> | Hixie: eg. should a Regex object clone? or is it considered a host object? |
| 21:47 | <olliej> | Hixie: or should the properties on a Regex object be cloned, but produce a generic object, not a regex? |
| 21:47 | <Hixie> | i think "host object" has a strict meaning in ES3.1 |
| 21:47 | <Hixie> | but i forgot about RegExp objects |
| 21:47 | <Hixie> | so i'll add that too |
| 21:48 | <Hixie> | is it ok if i clone ImageData and don't support directly cloning CanvasPixelArray? |
| 21:48 | <Hixie> | or should i support both? |
| 21:49 | <olliej> | i think it only makes sense to support cloning imagedata |
| 21:49 | <Hixie> | k |
| 21:49 | <olliej> | Hixie: as if you clone CPA you can't reattach it to an imagedata object |
| 21:49 | <Hixie> | yeah |
| 21:49 | <olliej> | so it would in effect become unusable |
| 21:49 | <Hixie> | that was my thinking too |
| 21:49 | <Hixie> | just making sure you agreed :-) |
| 21:53 | <Hixie> | holy crap, Microsoft Update defaults to non-SSL and asks you to download an ActiveX control! |
| 21:53 | <Hixie> | thanks but no thanks |
| 21:53 | Hixie | switches to SSL |
| 21:53 | <Philip`> | But the ActiveX control is signed, so you can trust it |
| 21:54 | <Hixie> | it's not the control i'm scared of, it's the commands sent TO the control |
| 21:54 | <Philip`> | An attacker might cause you to unwittingly update your Microsoft software? |
| 21:55 | <Hixie> | who knows what that activex control supports |
| 21:55 | <Philip`> | The attackers probably know |
| 21:55 | <Hixie> | jesus, they even REDIRECT YOU to the http:// url in a subframe |
| 21:55 | <Hixie> | good lord |
| 21:56 | <Philip`> | You could always use the built-in autoupdate system rather than the web-based version |
| 21:56 | <Hixie> | there is one? |
| 21:56 | <Hixie> | how do i update IE8 using that? |
| 21:57 | <Philip`> | You switch on Automatic Updates, and then wait a while until a notification pops up, I guess |
| 21:57 | <Hixie> | i want it now |
| 21:57 | <Philip`> | I don't think you can get IE8 via the update system yet, you have to download it from http://www.microsoft.com/ie |
| 21:58 | <Philip`> | (and probably uninstall any pre-release version of IE8 first) |
| 21:58 | <Hixie> | oh good lord |
| 21:58 | Philip` | isn't sure if that's necessary, but it seems safest |
| 21:59 | Hixie | adds microsoft next to the IETF on his list of silly people for the day |
| 21:59 | <Philip`> | It only took me 40 minutes to upgrade IE8 |
| 21:59 | <Philip`> | and I only found two bugs in the installer |
| 22:03 | <Philip`> | http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx - "For IE8 Beta-1, we closed off the information-disclosure problem whereby JavaScript can read the .value attribute of a file upload control and determine the full local pathname ... We elected to prepend “C:\fakepath\”" - hooray, they're HTML5 compliant |
| 22:03 | <Hixie> | yup |
| 22:03 | <Hixie> | it's not a coincidence :-P |
| 22:04 | Philip` | suspected as much :-) |
| 22:04 | <Philip`> | Microsoft seems to be doing a lot to promote standards mode, by entirely removing their new features from quirks mode |
| 22:06 | <Philip`> | "The first change is that we now return null and not undefined for keys that don’t exist in DOM storage. The second change is that we removed the length and remainingSpace properties when iterating DOM storage using a for..in statement." - hmm, but they didn't remove or vendor-prefix their extensions |
| 22:42 | <Hixie> | i click "download now" for IE8 and it pops a dialog with two more "download now" buttons |
| 22:42 | <Hixie> | what part of "now" do they not understand? |
| 22:46 | Philip` | remembers reading that the person who first implemented Amazon's patented one-click ordering system had been unable to fully understand the "one-click" concept and had added a confirmation dialog box |
| 22:47 | <Philip`> | http://beta.w3.org/TR/html401/ looks different |
| 22:48 | <Hixie> | that beta site has so many lines, rectangles, and links going on it's crazy |
| 22:49 | Philip` | discovers the magic slidey news thing on the front page |
| 22:50 | <Philip`> | Seems it'd be more intuitive to just, like, show all the news on there, rather than hiding it behind obscure buttons that make it hard to notice and hard to scroll through |
| 22:50 | <Hixie> | front page? |
| 22:51 | <Philip`> | http://beta.w3.org/ |
| 22:51 | <Hixie> | oh that front page |
| 22:51 | <Hixie> | that page looks like a bunch of news clippings all thrown on a pile to me |
| 22:51 | <Hixie> | i have no idea where to look |
| 22:52 | <Hixie> | there are links at the top, the top right, the right, the bottom right, the bottom middle, the bottom left, the left, and the middle |
| 22:55 | <Hixie> | (in this respect, btw, it's not particularly worse than the old one) |
| 23:26 | Hixie | prefixes all the form-related attributes on <input> with "form" so that "action" is "formaction" instead |
| 23:26 | <Hixie> | such a pain in the behind |