| 00:00 | <jamesr> | in gl there's a set of built in blend modes that conceptually work the same way |
| 00:01 | <roc> | true |
| 00:02 | <roc> | still |
| 00:03 | <roc> | in your example, you can just draw a quad that fills the entire clip rect |
| 00:03 | <roc> | anyway, just come up with the right spec and we can change |
| 00:07 | <jamesr> | do we have any idea what modes people really want to use? |
| 00:07 | <TabAtkins> | I doubt it. ^_^ |
| 00:07 | <jamesr> | roc: to be honest i'm not sure the safari behavior is strictly speaking better |
| 00:08 | <Hixie> | you could pretty easily find out, just instrument the operator attribute in chrome and let it loose |
| 00:08 | <jamesr> | that might be biased behind if(WebKit) sniffing |
| 00:08 | <jamesr> | but that is a good idea |
| 00:08 | <TabAtkins> | Hixie: That could easily be biased towards "wtf why is this mode different in Chrome and Firefox?" issues. |
| 00:09 | <TabAtkins> | Though, still, maybe useful. |
| 00:09 | <roc> | we changed 'copy' from source-bounded to source-unbounded and got one bug filed against us, for some Chrome experiemnt |
| 00:09 | <jamesr> | if it turns out that nobody uses anything except for source-over then i'd suggest removing the other modes from the spec until someone wants to use them and then requiring that proposed modes have compatible implementations that browser vendors are happy with |
| 00:10 | <jamesr> | it sucks to have a big matrix of modes that do not interoperate at all without any evidence that people want them |
| 00:10 | <roc> | 'copy' is clearly used |
| 00:11 | <TabAtkins> | Hmm. 'copy' is equivalent to just clearing the canvas and then drawing onto it, right? |
| 00:22 | <othermaciej> | tabatkins: I think copy is equivalent to srcover on top of a 0-alpha background but not totally sure w/o doing the math |
| 00:22 | <TabAtkins> | The spec description of 'copy' is just "draw A. B is ignored". Which seems to be precisely the same as clearing the canvas and drawing A. |
| 00:22 | <TabAtkins> | "Display the source image instead of the destination image." |
| 00:30 | <othermaciej> | it just copies the pixels |
| 00:30 | <Hixie> | TabAtkins: what's normative in that list is the Porter-Duff definitions, not the prose |
| 00:31 | <othermaciej> | it doesn't really matter if the background is cleared |
| 00:31 | <jamesr> | othermaciej: it does for regions outside the bounds of the source |
| 00:32 | <jamesr> | (if you have a notion of bounds of the source) |
| 00:32 | <TabAtkins> | othermaciej: Right. I'm just saying that, if people are using 'copy', they can equivalently just clear the canvas (the usual trick is by doing a null-resize) then drawing as normal. |
| 00:32 | <jamesr> | TabAtkins: null-resize dumps all other state |
| 00:32 | <jamesr> | not quite the same |
| 00:32 | <TabAtkins> | jamesr: Ah, right. Forgot about that. |
| 00:33 | <othermaciej> | tabatkins: you might also not be copying over the whole canvas |
| 00:33 | <othermaciej> | (or is that what the globalCompositeOperation debate is about?) |
| 00:33 | <jamesr> | othermaciej: with copy you actually are |
| 00:33 | <TabAtkins> | Right, when clip regions are considered. |
| 00:33 | <TabAtkins> | othermaciej: That's what the debate is about. ^_^ |
| 00:33 | <othermaciej> | that makes copy pretty useless |
| 00:33 | <jamesr> | a 'copy' is over the entire canvas (respecting clip region) in ffx |
| 00:34 | <othermaciej> | one way you may want to use it is to clone chunks of a canvas to tile, or to draw an image that you know has no alpha into some region in the canvas, but that is pretty useless if it clears the whole canvas |
| 00:35 | <jamesr> | for that you can set a clip |
| 00:38 | <TabAtkins> | Unrelated: goddammit we need different terms for "absolute or fixed position" and "absolute or fixed position or floating". |
| 00:43 | <roc> | actually I think coming up with a reasonable definition for source-bounded operators is easy |
| 00:44 | <roc> | just do it |
| 00:45 | <Hixie> | i don't think "just do it" will pass by quality bar :-P |
| 00:45 | <Hixie> | s/by/my/ |
| 00:45 | <roc> | that was an instruction, not proposed specification text :-) |
| 00:46 | <Hixie> | TabAtkins: "positioned" and "out-of-flow"? |
| 00:46 | <TabAtkins> | Hixie: "positioned" includes relpos. |
| 00:46 | <Hixie> | oh right |
| 00:47 | <TabAtkins> | Floats are in-flow for any layout mode except static flow. But this isn't expressed anywhere. >_< |
| 00:48 | <TabAtkins> | (Whereas abspos/fixpos are out-of-flow for all layout modes.) |
| 00:49 | <Hixie> | yeah i have to admit i don't mind having to work on html5 instead of css :-P |
| 00:50 | <estellevw> | what is the shortest valid HTML5 document? |
| 00:50 | <estellevw> | <!DOCTYPE html><meta charset=utf-8><title>Ugliest</title><p>valid html5 file</p> |
| 00:50 | <estellevw> | is that valid? and if so, it the meta required? |
| 00:50 | <TabAtkins> | You don't *need* the meta. |
| 00:50 | <jamesr> | <!DOCTYPE html> |
| 00:50 | <TabAtkins> | Otherwise, yeah, valid. |
| 00:50 | <jamesr> | ? |
| 00:50 | <TabAtkins> | jamesr: No, you need a title. |
| 00:50 | <TabAtkins> | But you don't need anything in the body. |
| 00:51 | <TabAtkins> | So <!DOCTYPE html><title></title> is the shortest possible, iirc. |
| 00:51 | <estellevw> | thanks |
| 00:52 | <Hixie> | are we not counting iframe srdoc documents as HTML5 documents? |
| 00:52 | <TabAtkins> | Probably not? |
| 00:52 | <TabAtkins> | What requirements are dropped from @srcdoc? |
| 00:52 | <Hixie> | because teh shortest iframe srdoc document is the empty string, but it has to be in a srcdoc="" attribute. :-) |
| 00:52 | <TabAtkins> | Ah, kk. |
| 00:52 | <Hixie> | doctype and title are optional in those |
| 00:52 | <Hixie> | <!DOCTYPE html><title></title> is probably non-conforming though |
| 00:52 | <TabAtkins> | I didn't know you'd dropped the title requirement. |
| 00:53 | <Hixie> | since <title> represents the document's title, and the empty string isn't a good title |
| 00:53 | <Hixie> | and the spec says you have to use elements appropriately to be conforming |
| 00:53 | <Hixie> | :-P |
| 00:53 | <TabAtkins> | Valid by validator.nu. ^_^ |
| 00:53 | <TabAtkins> | I'd say the empty string is a good title for the empty document. |
| 00:54 | <Hixie> | yeah i was thinking that as i was writing it |
| 00:57 | <estellevw> | :) |
| 00:58 | <TabAtkins> | <!DOCTYPE html><title>This document intentionally left blank</title> |
| 02:28 | <AryehGregor> | If you have a File object, can you slice it up into multiple Blobs if you want to fiddle with it and don't want the whole thing to be in memory at once? |
| 05:27 | <micheil> | Hixie: you about? |
| 05:30 | <Hixie> | yo |
| 05:33 | <micheil> | Hixie: question.. on websockets |
| 05:33 | <Hixie> | sure |
| 05:33 | <micheil> | if I can remember exactly what it was >_> |
| 05:34 | <micheil> | oh, right, would it be an idea to change the client side interface to show if there was actually a problem contacting the websocket server |
| 05:34 | <micheil> | eg, if there's a proxy in the way that allows you to load the client, but you get a 403 when you try to access the ws server |
| 05:35 | <micheil> | so that this type of state can be handled in browser more correctly |
| 05:35 | <Hixie> | by interface, do you mean exposing to the JS, or exposing to the user? |
| 05:35 | <micheil> | exposing to the front-end developer |
| 05:36 | <micheil> | so, things that could be exposed: timeout, 403 etc. |
| 05:36 | <micheil> | but not actually expose what the error was on server |
| 05:37 | <micheil> | just if the client can't actually connect to server |
| 05:37 | <micheil> | and also if the client gets disconnected from server prematurely |
| 05:37 | <micheil> | eg, on a network connection such as WiFi on an iPhone |
| 05:38 | <micheil> | the user goes into say a tunnel, then there's no network coverage, it would be good to be able to check on the client side for this case |
| 05:38 | <Hixie> | do you mean to the developer, or to the script the developer writes? |
| 05:38 | <micheil> | so, really it's a case of problem between client and server connection, not a problem the server has with a connection |
| 05:38 | <micheil> | the script the developer writes. |
| 05:38 | <Hixie> | it would be a security flaw to expose the network-level error status |
| 05:39 | <Hixie> | it would let you probe intranets, for example |
| 05:39 | <Hixie> | however, you can detect when the user's system goes offline entirely, by checking for body.ononline and body.onoffline |
| 05:41 | <micheil> | eg, new WebSocket(..); ws.addListener(...) |
| 05:41 | <micheil> | actually, that's another thing, why not use DOM Events? |
| 05:43 | <franksalim> | micheil, I am confused. where do you see addListener? Is that in node? |
| 05:43 | <micheil> | franksalim: no, I'm use to DOM events, that's why I wrote it |
| 05:44 | <micheil> | my bad |
| 05:44 | <Hixie> | micheil: we do use DOM Events |
| 05:44 | <micheil> | do you? |
| 05:44 | <Hixie> | yes |
| 05:44 | <micheil> | I see ws.onopen etc. everywhere? |
| 05:44 | <Hixie> | you can use either .onopen or you can attach an 'open' event listener |
| 05:44 | <Hixie> | (onopen is far easier of course) |
| 05:44 | <micheil> | ah |
| 05:45 | <micheil> | I don't think that's clearly documented then |
| 05:45 | <micheil> | also. I may be writing a websocket client test suite, is there anything in particular I should make sure I include? |
| 05:45 | <Hixie> | the IDL clearly says "WebSocket implements EventTarget;" |
| 05:45 | <micheil> | hmm.. does the spec? |
| 05:46 | <Hixie> | the IDL is in the spec... so yes |
| 05:46 | micheil | checks |
| 05:47 | <Hixie> | also everything is defined in terms of "Event Handler", etc |
| 05:47 | <Hixie> | this might be easier to see in the WHATWG complete spec (the web apps 1.0 spec), since all the stuff is cross-referenced there |
| 05:48 | <micheil> | okay, I'm probably also going to write some client side developer documentation, I'll be sure to include this. |
| 05:48 | <micheil> | (just because I doubt developers will really read a spec.) |
| 05:49 | <Hixie> | yeah the spec is written mainly for the implementors |
| 05:49 | <micheil> | yeah, like our selves |
| 05:53 | <Hixie> | ok i've changed the websocket protocol so that Sec-WebSocket-Protocol is now a space-separated list of tokens |
| 05:53 | <Hixie> | and you have to return one to connect |
| 05:53 | <Hixie> | rather than it being a single token you have to return |
| 05:53 | <franksalim> | will the protocol selected by the server exposed in the API? |
| 05:54 | <franksalim> | *be exposed |
| 05:54 | <Hixie> | yeah i added WebSocket.protocol for that |
| 05:54 | <franksalim> | that's pretty nice |
| 05:54 | <micheil> | Hixie: hmm.. so eg: Sec-WebSocket-Protocol: Proto1 Proto2 Proto3 .... |
| 05:54 | <Hixie> | yup |
| 05:55 | <micheil> | awesome |
| 05:55 | <Hixie> | in the constructor it's still just a single argument (space-separated string) |
| 05:55 | <Hixie> | so you do var ws = new WebSocket('ws://...', 'Proto1 Proto2 Proto3'); |
| 05:56 | <micheil> | hmm.. |
| 05:56 | <micheil> | I disagree there |
| 05:56 | <franksalim> | not WebSocket(url, proto1, proto2, proto3)? |
| 05:56 | <micheil> | we have an array type in js for a reason. |
| 05:56 | <micheil> | new WebSocket(url, protocols[] ) |
| 05:58 | <micheil> | eg: var ws = new WebSocket("ws://localhost/";, ["msgpack", "bson", "json"]) |
| 05:58 | <micheil> | (where i'm actually using protocol to say what kind of message content encoding I have) |
| 05:58 | <Hixie> | i considered doing var ws = new WebSocket('ws://...', ['Proto1', 'Proto2', 'Proto3']); |
| 05:58 | <micheil> | why not? |
| 05:58 | <micheil> | it makes most sense to a front-end developer |
| 05:58 | <Hixie> | it would need changes to implementations |
| 05:59 | <micheil> | and the current doesn't? |
| 05:59 | <micheil> | if( Array.isArray(protocol)) { protocol = Array.prototype.join.call(protocol, " "); } |
| 05:59 | <Hixie> | only minor ones |
| 05:59 | <micheil> | not that hard to change. |
| 05:59 | <franksalim> | ...and using variable arity would prevent us from adding a meaningful third parameter |
| 06:00 | <franksalim> | but i would prefer not to have space separated strings in an API |
| 06:00 | <micheil> | I'd say that protocol can be either a string or array type |
| 06:00 | <micheil> | which is a perfectly decent way of declaring an API for a js interface, commonly used by developers |
| 06:02 | <micheil> | and then, if a browser doesn't support the array, then it throws an array of bad arguments |
| 06:02 | <micheil> | * throws an error |
| 06:02 | <micheil> | try {} catch(e) {} it, handle it appropriately / try again with string |
| 06:04 | <franksalim> | i hope developers will list meaningful protocols or start specifying new protocols on top of json instead of just sending a format like "json" |
| 06:05 | <Hixie> | i guess i could make it an array |
| 06:05 | <Hixie> | is anyone using that argument yet? |
| 06:05 | <micheil> | no, not here |
| 06:05 | <franksalim> | Hixie, at least not widely. It is really going to be useful when there are public cross-origin websocket services, and there aren't many of those |
| 06:05 | <micheil> | I currently don't even support it on the server-side |
| 06:06 | <micheil> | there's actually two franksalim |
| 06:06 | <franksalim> | two is not many :-) |
| 06:06 | <micheil> | Pusher App and some one else. |
| 06:06 | <micheil> | as for Pusher, I speak with the developers regularly, and they subscribe to hybi, so changes should be good. |
| 06:07 | <micheil> | I'll try and contact the other company and get them to watch the list if they don't. |
| 06:07 | <Hixie> | i'll prod the browser vendors, see what they say |
| 06:07 | <Hixie> | if everyone's ok with changing, then i'm ok with it |
| 06:07 | <Hixie> | but for such a minor thing, i'm also happy to go with a space-separated list |
| 06:07 | <Hixie> | after all, that's what the protocol uses |
| 06:08 | <micheil> | protocol should never influence the browser implementation. |
| 06:08 | <micheil> | we want it easy enough for anyone to be able to write a client. |
| 06:08 | <micheil> | servers should still be easy, but require technical knowledge |
| 06:08 | <micheil> | reason: then you can have websockets as a service (Software as a Service anyone?) |
| 06:09 | <Hixie> | you mean write a script that uses websockets, right? as opposed to an actual websockets client |
| 06:09 | <franksalim> | writing a client to support one specified protocol requires technical knowledge, much less 2+ protocols and negotiation |
| 06:09 | <micheil> | Hixie: client as in say a chat app or something. |
| 06:09 | <franksalim> | i mean a protocol client for a protocol over websocket |
| 06:09 | <micheil> | so, application? |
| 06:10 | <Hixie> | right |
| 06:10 | <Hixie> | yeah dunno what you'd call it |
| 06:10 | <Hixie> | "script" maybe :-) |
| 06:10 | <franksalim> | protocol client |
| 06:10 | <micheil> | Hixie: I'll try to standardise on that from now on. |
| 06:10 | <franksalim> | or client |
| 06:10 | <Hixie> | subprotocol client maybe |
| 06:10 | micheil | hates the word "script" it sounds so "script-kiddy-ish" |
| 06:10 | <Hixie> | "protocol client" sounds like the actual browser |
| 06:10 | <micheil> | application |
| 06:10 | <franksalim> | i'm not sure i like the term subprotocol. everything can layer on anything else |
| 06:10 | <micheil> | that works., no? |
| 06:11 | <franksalim> | xmpp/websocket is essentially the same protocol as xmpp/tcp |
| 06:11 | <Hixie> | micheil: yeah that works too |
| 06:11 | <franksalim> | Hixie, it is recursive. it is like the 'actual' browser :-) |
| 06:11 | <micheil> | actually, interesting thing, there's a webworkers implementation in Node.js that uses WebSockets as the underlying communication medium |
| 06:12 | <franksalim> | Hixie, it doesn't stop being a protocol just because it is in a soft layer |
| 06:12 | <Hixie> | franksalim: yeah |
| 06:12 | <Hixie> | franksalim: i just use "subprotocol" because it's easier to grep for in the spec :-) |
| 06:12 | <micheil> | also, from that other day Hixie, the time for websockets is seriously now. I've currently got two job opps where websockets are wanted. |
| 06:12 | <Hixie> | franksalim: (you'll notice i don't call it that in the protocol or the api) |
| 06:12 | <micheil> | one from a startup, one from a large well established company |
| 06:12 | <franksalim> | Hixie, that _should_ have also cleared up the intent of subprotocol vs. alternative upgrade framing, too |
| 06:13 | <franksalim> | (on HyBi) |
| 06:13 | <Hixie> | micheil: it would have been five years ago if we'd been at this stage then |
| 06:13 | <Hixie> | micheil: there's been pent-up demand for this for years |
| 06:13 | <micheil> | Hixie: five years ago, and I wouldn't have been here ;P |
| 06:13 | <Hixie> | franksalim: not sure what you mean |
| 06:13 | <micheil> | Hixie: infact.. five years, that's almost mid-webstandards movement, no? |
| 06:14 | <franksalim> | calling it subprotocol indicates layering not alternative framing syntax, i think. there was some misunderstanding about that |
| 06:14 | <micheil> | (not webstandards for browser, but for developers) |
| 06:14 | <Hixie> | "webstandards movement"? |
| 06:14 | <Hixie> | franksalim: ah, maybe |
| 06:14 | <franksalim> | someone should write a history book :-) |
| 06:14 | <Hixie> | franksalim: i didn't understand -- still don't understand -- many of the discussions on hybi |
| 06:15 | <Hixie> | i get the feeling there are two very distinct desires |
| 06:15 | <Hixie> | and yet we're working on the same protocol |
| 06:16 | <franksalim> | at least two |
| 06:16 | <Hixie> | yeah, maybe more |
| 06:16 | <franksalim> | although fewer now than when half the list was talking about reverse http |
| 06:17 | <Hixie> | i just wish that the people who aren't trying to design a trivially implementable TCP-for-browsers protocol would design their own protocol instead of trying to warp websockets to their needs |
| 06:21 | <micheil> | Hixie: actually, there's talk in the dev community that when websockets support high bit data, people want to use them for transporting everything like images & binary data |
| 06:21 | <micheil> | (by support, I mean, in both server and browser) |
| 06:22 | <Hixie> | yeah |
| 06:22 | <Hixie> | binary data over websockets should be available later this year, i expect |
| 06:22 | <micheil> | cool |
| 06:22 | micheil | has his parser ready to do it, but isn't yet |
| 06:23 | <micheil> | Hixie: do you use something like svn or git to manage the document versions for the specs? |
| 06:23 | <Hixie> | svn |
| 06:23 | <Hixie> | svn.whatwg.org |
| 06:23 | <micheil> | could you publish the diffs? |
| 06:23 | <Hixie> | svn.whatwg.org/webapps/source specifically |
| 06:23 | <Hixie> | the repo is public |
| 06:23 | <Hixie> | you can see the differs also at http://html5.org/tools/web-apps-tracker |
| 06:24 | <Hixie> | diffs, even |
| 06:24 | <micheil> | yeah, that's not so awesome though :P |
| 06:24 | <Hixie> | (the web-apps-tracker page is what i use, personally, rather than svn directly) |
| 06:25 | <micheil> | Hixie: I'd go for git style patch files. |
| 06:25 | <franksalim> | i leave for a minute, and i see you've been talking about one of my favorite things: binary data over websockets |
| 06:25 | <micheil> | Hixie: could I have permission to actually mirror the document on github? |
| 06:25 | <micheil> | (they have a useful git -> svn thing) |
| 06:25 | <micheil> | or svn -> git |
| 06:26 | <franksalim> | that's when the subprotocol aspect will be _killer_ |
| 06:26 | <micheil> | franksalim: agreed |
| 06:27 | <Hixie> | micheil: sure, feel free to do whatever. The doc is under the license shown at the top of the WHATWG spec, which is pretty liberal. |
| 06:28 | <micheil> | okay. |
| 06:32 | <micheil> | Hixie: do you have a Github account by any chance? |
| 06:32 | <Hixie> | no |
| 06:32 | <micheil> | okay |
| 06:33 | <micheil> | Hixie: let me know if you ever create one, that way I can correctly get the attribution right |
| 06:33 | <Hixie> | k |
| 06:35 | <micheil> | just waiting on github to import it. |
| 06:35 | <micheil> | http://github.com/miksago/whatwg-webapps-mirror |
| 07:10 | <myakura> | http://f1results.socialminds.com.br/ uses <progress> and <meter> but i don't think it uses them in a conforming way. |
| 08:03 | <baba> | omg, so html5 isn't going to be official till 2022 probably? |
| 08:04 | <Hixie> | "official"? |
| 08:04 | <baba> | W3 Recommendation |
| 08:04 | <Hixie> | according to the W3C, it'll be a W3C recommendation before the end of september. |
| 08:04 | <baba> | W3C |
| 08:05 | <micheil> | Hixie: hmm.. "html5" vs ? |
| 08:05 | <Hixie> | (then again, according to the W3C, it'll be in last call before the end of June 2008, and it's still not in last call there) |
| 08:05 | <baba> | http://en.wikipedia.org/wiki/HTML5 |
| 08:05 | <micheil> | would it be an idea to give a timeline guide as to when we can start using various things under the umbrella "html5" |
| 08:05 | <baba> | it says "Ian Hickson, editor of the HTML5 specification, expects the specification to reach the Candidate Recommendation stage during 2012, and become a W3C Recommendation in the year 2022 or later." |
| 08:05 | <Hixie> | baba: ah, yeah, my guess is it'll be a REC around then. |
| 08:06 | <micheil> | eg, WebSockets are available in some browsers from February 2010 onwards |
| 08:06 | <Hixie> | baba: not sure that that's a particularly interesting milestone though |
| 08:06 | <Hixie> | baba: REC for a Web spec at this point is basically when the technology dies |
| 08:06 | <baba> | lol |
| 08:06 | <Hixie> | that wasn't meant to be a joke :-) |
| 08:06 | <Hixie> | specs that are useful are in active maintenance |
| 08:07 | <micheil> | Hixie: agreed. |
| 08:07 | <micheil> | also, I like that there may be some drive behind some specs that they are being designed based off implementation |
| 08:08 | <baba> | Hixie, how are you/did you go about learning html5? |
| 08:09 | <Hixie> | well i basically wrote it |
| 08:09 | <Hixie> | so... |
| 08:09 | <baba> | http://www.w3schools.com/html5/default.asp ? |
| 08:09 | <baba> | what? |
| 08:09 | <baba> | really? |
| 08:09 | <micheil> | baba: yeah |
| 08:09 | <Hixie> | i guess i did it the hard way |
| 08:09 | <baba> | oh, speaking with the big boys, didn't know |
| 08:09 | <Hixie> | :-) |
| 08:09 | <micheil> | Hixie == Ian Hickson, the guy that writes a lot of the specs |
| 08:09 | <Hixie> | this is where the sausage is made |
| 08:09 | <Hixie> | well, this is where we talk about how the sausage is made |
| 08:09 | <Hixie> | it actually gets made in emacs |
| 08:10 | <baba> | gotcha |
| 08:10 | <micheil> | Hixie: and where we argue about how vim is better. |
| 08:10 | <Hixie> | pah |
| 08:10 | <baba> | lol |
| 08:10 | <micheil> | >_> |
| 08:10 | <micheil> | Hixie: how.. uh.. big is that svn repo? |
| 08:10 | <baba> | i'm waiting to graduate before i reinstall ubuntu |
| 08:10 | <micheil> | Hixie: github's been fetching it for the past 2-3 hours, I'm sure. |
| 08:10 | <baba> | forces me to play too much with customization |
| 08:11 | <Hixie> | micheil: there's only a few files in there, but one of them is 4MB and has >4000 revisions |
| 08:11 | <micheil> | or not. only 1.4hrs |
| 08:11 | <Hixie> | and the other main one is 5MB and has the same number of revisions |
| 08:11 | <micheil> | hmm.. |
| 08:11 | <micheil> | k, so, like, 4000x4000+4000x5000+3000 |
| 08:12 | <micheil> | so, uh, pretty damn massive. |
| 08:12 | <Hixie> | and i wasn't even using it for the first few years :-) |
| 08:12 | <micheil> | >_> |
| 08:13 | <micheil> | eh' hopefully the github guys won't lynch me for doing this. |
| 08:13 | <Hixie> | micheil: heh |
| 08:16 | <baba> | so who forks the bill for html5 development? |
| 08:17 | <Hixie> | depends what you mean |
| 08:17 | <Hixie> | if you mean who pays for whatwg.org's hosting, i do |
| 08:17 | <Hixie> | if you mean who pays for the browser vendors to implement the spec, they pay the cost themselves |
| 08:18 | <micheil> | and if you mean who pays hixie to write them, well, Hixie ? :P |
| 08:18 | <Hixie> | if you mean who pays us to take part in the process, well, many of us are employed by various companies, and many others are just volunteers |
| 08:18 | <baba> | yeah, but Ian, who's compensating you for all your time developing the html5 specs |
| 08:18 | <Hixie> | i'm a google employee |
| 08:18 | <baba> | oh, didn't realize you still were |
| 08:18 | <Hixie> | and they pay me to work on this pretty much fulltime |
| 08:18 | <micheil> | but google's not the only party. |
| 08:18 | <Hixie> | before that opera paid me about 50% time to work on this |
| 08:18 | <baba> | guess it's to everyone's advantage to implement this |
| 08:18 | <Hixie> | but all the browser vendors are involved, as are many other companies |
| 08:18 | <baba> | including MS? |
| 08:19 | <Hixie> | and other organisations |
| 08:19 | <Hixie> | yup |
| 08:19 | <baba> | they send someone there to slow u down? |
| 08:19 | <Hixie> | the w3c html wg has been chaired by a microsoft person since inception |
| 08:19 | <micheil> | while I don't do things financially, I'm an implementor of a few parts, so, I often ask questions & provide feedback |
| 08:19 | <Hixie> | (different person then than now, and they're not the only chair, but still, it's pretty high-profile involvement for microsoft) |
| 08:19 | <micheil> | and really, microsoft aren't slow, it's just adoption |
| 08:20 | <micheil> | I could say Firefox and Safari are slow, because they don't support WebSockets at draft76, but that'd be stupidity. |
| 08:20 | <Hixie> | microsoft have definitely not been responsible for any slowness in html5's development so far |
| 08:21 | <micheil> | and without implementation, a spec doesn't really mean much |
| 08:21 | <baba> | then why does IE always have issues |
| 08:21 | <baba> | with even the current standards |
| 08:21 | <micheil> | baba: even people who aren't microsoft don't do things to standards |
| 08:21 | <Hixie> | i gotta go to bed |
| 08:21 | <Hixie> | nn |
| 08:22 | <baba> | goodnight |
| 08:22 | <micheil> | Hixie: good point, it is 3am |
| 08:22 | <micheil> | Night' |
| 08:23 | <baba> | didn't mean to start a MS bashing session, just curious why I always have to adjust what I do so my css or whatever works on IE |
| 08:24 | <micheil> | baba: two words: corporate adoption |
| 08:24 | <micheil> | IE is such that if there's anything that's a massive change, the adoption is massively slow. |
| 08:25 | <micheil> | most government departments in australia, for instance, still use IE 6 or below |
| 08:25 | <micheil> | because there's ghosts from the browser wars. |
| 08:25 | <estellevw> | baba: lack of auto updating too |
| 08:26 | <estellevw> | if IE6 autoupdated to IE7, then to IE8, we wouldn't see 4% of people still using IE6 |
| 08:26 | <micheil> | but then again, IE aren't the only ones that don't implement things correctly, for instance, Safari 5 doesn't handle the response handshake in websockets correctly |
| 08:26 | <micheil> | iirc,. |
| 08:27 | <micheil> | estellevw: you'd still have apps written to target IE6 which would need compleete rewrites to work on IE > 6, so, consequentially, IT admins disable automatic updates |
| 08:29 | <baba> | hmm, good point |
| 08:29 | <baba> | it does ask you to update though in windows |
| 08:29 | <baba> | ...btw, is there a solution for Pasting into the browser with html5? |
| 08:29 | <baba> | from the clipboard |
| 08:30 | <baba> | an image |
| 08:32 | <micheil> | umm.. no, but you could use I think the HTML5 drag and drop (only in some browsers) |
| 08:33 | <micheil> | morning zcorpan_ |
| 08:33 | <baba> | hmm |
| 08:33 | <baba> | micheil, so flash is still the only solution for that? |
| 08:33 | <micheil> | flash isn't the only solution |
| 08:33 | <micheil> | and I'd say it's not a solution. |
| 08:34 | <baba> | mhtml |
| 08:34 | <micheil> | HTML has always had the <input type="file"> for a long long time |
| 08:34 | <micheil> | use it, it's there for a reason. |
| 08:34 | <baba> | but how about pasting from the clipboard |
| 08:34 | <baba> | an image from the clipboard |
| 08:34 | <zcorpan_> | morning micheil |
| 08:35 | <micheil> | baba: not possible. |
| 08:36 | <baba> | because there's still no where to store the image? |
| 08:36 | <micheil> | no |
| 08:36 | <micheil> | think about it, if you could programatically pull something from a visitors clip board, without their permission, then you'd have a big big security problem |
| 08:37 | <baba> | only if they choose to paste |
| 08:37 | <micheil> | but how do you know if they are pasting? |
| 08:37 | <micheil> | document.addEventListener("paste", fn) ? |
| 08:37 | <micheil> | I don't think so. What are they pasting into? a textarea, a canvas element, etc |
| 08:50 | <zcorpan_> | Hixie: why did you ban U+0020 in subprotocol? |
| 08:52 | <zcorpan_> | Hixie: oh, nm |
| 08:52 | <baba> | micheil, just how you know if they are pasting text |
| 08:53 | <micheil> | baba: well, in Mozilla code base, I can actually listen for it |
| 08:53 | <micheil> | baba: via an API that's private to the Chrome (not accesible from pages), which is provided using a technology called XPCom |
| 08:53 | <micheil> | it's basically a C / C++ api accessor |
| 09:15 | <phrearch> | hi |
| 09:18 | <estellevw> | when did <a> lose the ping attribute? |
| 09:18 | <estellevw> | or was i mistaken that it was ever there? |
| 09:20 | <estellevw> | i see it http://www.w3.org/TR/2010/WD-html5-diff-20100624/ but not http://dev.w3.org/html5/markup/a.html |
| 09:23 | <jgraham> | estellevw: It lost it when people complained about it. It is still in the WHATWG copy though |
| 09:25 | <estellevw> | see it http://dev.w3.org/html5/html-author/#the-a-element too. Wondering if i should file a bug. |
| 09:26 | <hsivonen> | the /html-author/ doc isn't active being worked on |
| 09:26 | <hsivonen> | I guess Lachy has been busy with other stuff |
| 09:29 | <zcorpan_> | yay hybi are +1ing |
| 09:34 | <Lachy> | hsivonen, I'm waiting to be assigned time to work on that stuff |
| 09:42 | <baba> | micheil, what I meant was, how come it's not dangerous for text to be able to be pasted in, but it is for images? |
| 09:49 | <micheil> | baba: because, text is what it's always been |
| 09:50 | <micheil> | also, it's really quite complicated to handle any clipboard data, eg, how do you know what mime-type to show it with? |
| 09:58 | <baba> | micheil, by trial-error? |
| 09:59 | <micheil> | too expensive to process. |
| 10:00 | <baba> | hmm |
| 10:00 | <baba> | how does flash do it? |
| 10:06 | <micheil> | no idea. |
| 10:08 | <kbrosnan> | http://www.adobe.com/livedocs/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00002187.html ? |
| 10:08 | <baba> | k |
| 10:08 | <baba> | oh wow |
| 10:08 | <baba> | thanks kbrosnan |
| 10:09 | <baba> | kbrosnan, question is, if there is an image in the clipboard, how does it know to paste an image |
| 10:09 | <baba> | how does it "check" |
| 10:09 | <kbrosnan> | no idea, just used $search_engine for flash clipboard api |
| 10:11 | <baba> | gotcha |
| 10:12 | <jgraham> | abarth: yt? The webkit parser tests Just Work now you have added them to the test directory. So that's fine. |
| 10:12 | <abarth> | jgraham: cool |
| 10:12 | <jgraham> | I don't know how to sync. What are your requirements |
| 10:12 | <jgraham> | ? |
| 10:12 | <abarth> | don't know |
| 10:13 | <abarth> | the question is whether we should continue to modify those files in the webkit tree |
| 10:13 | <abarth> | and upload them periodically |
| 10:13 | <abarth> | or whether you want the ability to edit them in the code.google.com repo |
| 10:13 | <abarth> | in which case we should probably make new dat files for new tests |
| 10:14 | <jgraham> | I am happy to not touch those files if you want to edit them locally and then periodically resync |
| 10:14 | <abarth> | ok, let's try that for a while |
| 10:15 | <jgraham> | I am also happy if you always edit in the html5lib repository and just resync to the webkit repository when needed |
| 10:15 | <jgraham> | But I guess that might be harder for you |
| 10:16 | <abarth> | jgraham: yeah, that doesn't integrate with our process that well |
| 10:16 | <jgraham> | OK |
| 10:19 | <hsivonen> | fwiw, I edit in html5lib first and then sync to mozilla-central |
| 10:19 | <jgraham> | (I guess the only problem is if you accidentially add buggy tests. In that case being able to make fixes fast is good.) |
| 10:20 | <abarth> | we're getting to the ned of implementing the parser, so we'll be done with these tests soon |
| 10:20 | <abarth> | the stuff i'm fixing now is fiddly webkit stuff that's not visible in the DOM |
| 10:21 | <abarth> | we also need to implement ian's latest round of changes to the spec |
| 10:21 | hsivonen | spent the vast majority of time fixing Mochitests and Gecko stuff (as opposed to writing the parser core) |
| 10:21 | <jgraham> | Oh yeah, spec changes are another problematic case |
| 10:22 | <jgraham> | hsivonen: You implemented off-the-main-thread parsing at the same time, which I guess didn;t make it easier |
| 10:22 | <jgraham> | :) |
| 10:22 | <hsivonen> | jgraham: yeah, that, too |
| 10:22 | <abarth> | we're down to 80 tests that have different expectations between the new and old parser |
| 10:22 | <abarth> | but we've been able to explain most of those differences |
| 10:22 | <hsivonen> | a big part of the mochitest failures arose from off-the-main-thread parsing |
| 10:23 | <hsivonen> | abarth: 80 tests makes me feel a bit better :-) |
| 10:23 | <abarth> | well, we used to fail some 15k tests |
| 10:23 | <abarth> | so it's a big improvement :) |
| 10:24 | <abarth> | hsivonen: i don't really understand off the main thread parsing |
| 10:24 | <hsivonen> | abarth: do you have HTML5-compliant about:blank timing? |
| 10:24 | <abarth> | dunno |
| 10:24 | <abarth> | probably not |
| 10:25 | <hsivonen> | I postponed that to after Firefox 4.0 |
| 10:25 | <abarth> | how does one test taht? |
| 10:25 | <hsivonen> | so Gecko's about:blank currently isn't compliant |
| 10:25 | <abarth> | the problem with working on the parser is you need to decide where to stop implementing the spec |
| 10:25 | <abarth> | because, in principle, you could do the whole thing from that foundation |
| 10:25 | <hsivonen> | abarth: you poke the document of an iframe or of a window.open()ed window at various points in time to see what's there |
| 10:26 | <abarth> | oh, i'm sure that's not right |
| 10:26 | <abarth> | that stuff is crazy |
| 10:26 | <abarth> | the parser runs really slowly in debug mode |
| 10:26 | <abarth> | because we've loaded it up with so many asserts |
| 10:27 | <abarth> | we'll probably have to take a bunch of those out |
| 10:27 | <abarth> | which is kind of too bad |
| 10:27 | <hsivonen> | I'm planning on putting more asserts in :-) |
| 10:27 | <hsivonen> | currently, the Java asserts are carried over to C++, which isn't nice |
| 10:29 | <abarth> | ok, bed time for me |
| 10:30 | <abarth> | more triage in the morning :) |
| 10:50 | <jgraham> | Hmm some of these webkit tests seem to rely on scripting |
| 11:39 | <karlcow> | I wonder how many sites are sending the optional "Comment=comment" with cookies |
| 11:41 | <Philip`> | karlcow: Very few |
| 11:42 | <Philip`> | and half of them are Comment=Sun+ONE+Application+Server+Session+Tracking+Cookie and the other half are Comment=1-800-Volunteer.org |
| 12:07 | <hsivonen> | what happened to being able to request more context in the Web Apps Tracker? |
| 12:09 | <jgraham> | hsivonen: I think anne removed it and waited to see if you complained |
| 12:10 | <hsivonen> | I'm complaining now |
| 12:11 | <hsivonen> | sooo... |
| 12:12 | <hsivonen> | suppose we have <svg><foreignObject><math><u> |
| 12:13 | <hsivonen> | the spec now says that upon <u>, you pop elements until either math or svg has been popped, switch to the secondary insertion mode and reprocess |
| 12:13 | <hsivonen> | is that really right? |
| 12:13 | <hsivonen> | hmm. maybe it is |
| 12:14 | <hsivonen> | but what about <math><annotation-xml><svg><u> |
| 12:14 | <hsivonen> | is it right in that case? |
| 12:14 | <hsivonen> | or in <svg><svg><u> |
| 12:14 | <hsivonen> | ? |
| 12:15 | <hsivonen> | I can't recall why I've implemented it in another way |
| 12:15 | <hsivonen> | but I've made it pop until the top of the stack is an HTML element |
| 12:17 | <zcorpan_> | hsivonen: seems it's not really right in all cases |
| 12:18 | <zcorpan_> | hsivonen: the intent was to not pop so far for e.g. <svg><foreignContent><math><u> |
| 12:20 | <zcorpan_> | hsivonen: i guess the spec should revert that change or come up with something else that works better |
| 12:20 | <hsivonen> | sigh. http://html5.org/tools/web-apps-tracker?from=5154&to=5155 is going to result in another unreviewable patch for sicking to review |
| 12:22 | <jgraham> | hsivonen: I guess if there are bugs filing them with testcases that the revised spec should pass is the way forward |
| 12:24 | <jgraham> | This bit of the spec seems to be enormously fragile |
| 12:25 | <jgraham> | I'm not sure if there is something to learn from that |
| 12:26 | <zcorpan_> | hsivonen: i reopened http://www.w3.org/Bugs/Public/show_bug.cgi?id=8966 |
| 12:27 | <Matjas> | I have an input field ‘slug’ which indicates part of an URL that will be generated. I’d like to preview that URL. Which markup to use? <samp>http://domain.ext/<var>slug</var></samp>;? |
| 12:28 | <hsivonen> | zcorpan_: thanks |
| 12:28 | <Matjas> | s/preview that URL/show a preview of that URL/ |
| 12:28 | <hsivonen> | I wonder if it still holds that reprocessing an end tag token can never cause reprocessing in the 'in foreign content' mode... |
| 12:29 | <Smylers1> | Matjas: <var>slug</var> makes sense when you literally have the word ‘slug’ in there as a placeholder. But not for an actual slug. |
| 12:29 | <zcorpan_> | hsivonen: maybe we could have breakout bookmarks in the stack of open elements or so? |
| 12:30 | <Matjas> | Smylers1: I see. So as soon as it’s an actual slug, use <span> instead? |
| 12:30 | <Matjas> | Smylers1: Or is there a better alternative? |
| 12:30 | <Smylers1> | Why does it need anything? |
| 12:31 | <Smylers1> | If you wish it to be styled differently from the fixed part of the URL, you could use <b>. |
| 12:31 | <Matjas> | Smylers1: I’d like to use JS to dynamically change the preview based on the input, so I figured perhaps it would be a good idea to visually indicate the difference from the fixed URL part |
| 12:31 | <Smylers1> | <b> sounds right then. |
| 12:32 | <hsivonen> | zcorpan_: or maybe we should have the same scope check in this case that we have in the case where an end tags has been processed according to the rules of the secodary insertion mode |
| 12:32 | <Smylers1> | Or possibly <mark>, to highlight the part of the URL you're drawing readers' attention to. |
| 12:33 | <Matjas> | Smylers1: Oh yes, can’t believe I forgot about <mark>! |
| 12:33 | <Matjas> | Smylers1: And <samp> would be okay to use as a wrapper for the entire URL? |
| 12:33 | <Smylers1> | Those both have the advantage over <span> of conveying something even to users without CSS. |
| 12:33 | <karlcow> | Philip`: interesting thanks |
| 12:34 | <Smylers1> | I've only ever considered <samp> for output of text-based programs, but it seems OK to use here too. |
| 12:34 | <Smylers1> | If you need anything at all there. |
| 12:39 | <hsivonen> | it's ridiculous how much http://html5.org/tools/web-apps-tracker?from=5154&to=5155 simplifies code |
| 13:03 | <jgraham> | zcorpan_: Maybe it would be good to add the expected DOM trees to that comment? |
| 13:28 | <jgraham> | """the amateur programmer requirement has been |
| 13:28 | <jgraham> | widely rejected""" |
| 13:28 | <jgraham> | that's news to me |
| 13:28 | <jgraham> | (re: websockets) |
| 13:29 | <jgraham> | Am I just not following along enough? |
| 13:30 | <othermaciej> | lots of people said they don't like it |
| 13:31 | <othermaciej> | I don't know if that counts as "widely rejected" |
| 13:34 | <hsivonen> | Web specs also need to be resient against professionals who aren't careful enough |
| 13:45 | <jgraham> | I wonder if it is worth my while saying that I believe in that requirement |
| 14:20 | <jgraham> | There is no reason I am missing that <!DOCTYPE potato SYSTEM 'taco"'> should parse to anything other than a DOCTYPE with name html and system id taco" is there? |
| 14:21 | <jgraham> | s/html/potato/ |
| 14:22 | <jgraham> | These webkit tests seem to assume no public id or system id, but I think they are wrong |
| 14:24 | <gsnedders> | jgraham: Yeah, the rest is as the DOCTYPE is created (i.e., the public identifier is missing) |
| 14:24 | <jgraham> | Yeah I think the html5lib format doesn't distinguish missing from empty string |
| 14:28 | <hsivonen> | what's the best way to search one's own tweets? |
| 14:29 | <jgraham> | hsivonen: I thought it was a write-only medium... |
| 14:29 | <hsivonen> | apparently inurl: on Google |
| 14:31 | <jgraham> | Does http://search.twitter.com/advanced do what you want? I don't know if it time-limits... |
| 14:32 | <jgraham> | (but possibly the answerr to "best" is "have a local backup that can be conveniently grepped") |
| 14:33 | <jgraham> | That search page seems to be useless... |
| 14:35 | <hsivonen> | jgraham: nope, it doesn't do what I want |
| 14:35 | <hsivonen> | I wanted to find the tweet I mentioned in my latest email to the whatwg list |
| 14:38 | <Lachy> | is there a way on twitter to extract your entire history of tweets in one long file? |
| 14:39 | <gsnedders> | No, you can only get a three-digit number at a time |
| 14:50 | <Smylers1> | Lachy: http://tweetbackup.com/ will do that. |
| 14:51 | <Smylers1> | Sign up, using Twitter's oauth, then you can get an export of all your tweets in a text file (including tweets from before you signed up). |
| 14:56 | <Lachy> | Smylers1, thanks. Trying it out now. |
| 14:56 | <Lachy> | hopefully I have fewer than 3200 posts, which seems likely given my relatively infrequent usage |
| 15:14 | <erlehmann> | „So I heard you like Ogg, so i implemented it to toll you that I haven't implemen- OH WAIT :D“ |
| 15:18 | <Lachy> | erlehmann, where is that quote from? |
| 15:19 | <erlehmann> | Lachy, I invented it after reading mike shavers suggestion on the list that implementors should implement basic ogg support to determine if it is ogg to then tell that they do not support it. |
| 15:22 | <jgraham> | A warning that you're about to open a 5MB "text" document might be |
| 15:22 | <jgraham> | humane anyway. |
| 15:22 | <jgraham> | (Mike Shaver) |
| 15:23 | <jgraham> | Yeah "Warning: you appear to be reading the HTML5 spec. Are you sure you want to continue? (y/n)" |
| 15:23 | <jgraham> | I guess it is strictly html rather than text, but that doesn't obviously make it better... |
| 15:25 | <erlehmann> | jgraham, i thought that too. after all, with text/html, its major type is "text" ;) |
| 15:27 | <erlehmann> | I hereby humbly suggest that "HTML5 spec" should now be abbreviated as "HTML5MB". |
| 15:27 | <jgraham> | We could just version it according to size |
| 15:27 | <erlehmann> | BRILLIANT |
| 15:27 | <jgraham> | Once it reaches 6Mb it is HTML6 |
| 15:28 | <jgraham> | (cutting stuff out could be a problem of course) |
| 15:28 | <erlehmann> | http://www.nioutaik.fr/images/galerie/brilliant.jpg |
| 15:29 | <jgraham> | hsivonen: Do you remember what was decided about coalescing adjacent character tokens in cases like <table>a<tr></tr>b ? |
| 15:30 | <jgraham> | Oh I found it |
| 15:30 | <jgraham> | The spec says not to coalese |
| 15:30 | <jgraham> | hsivonen: Do you agree with the spec? :) |
| 15:31 | <jgraham> | (it seems that Mimefield disagrres with the spec) |
| 15:31 | <jgraham> | *disagrees |
| 15:36 | <erlehmann> | Mimefield. Hehe. |
| 15:36 | <erlehmann> | The silent browser! |
| 15:36 | <gsnedders> | All I'm saying <http://gsnedders.html5.org/html5.txt>; is a number of megabytes of text |
| 15:37 | <jgraham> | Oh, that is a horrible typo |
| 15:39 | <hsivonen> | jgraham: it was easier to implement coalescing in all cases than to special-case something |
| 15:40 | <jgraham> | hsivonen: That is my feeling too. But webkit appear to be implementing coaleascing |
| 15:40 | <hsivonen> | jgraham: so I guess I disagree with the spec until someone demonstrates that this is an actual DoS-by-author-incompetence problem against Gecko |
| 15:40 | <hsivonen> | (there are other ways to mount deliberate DoS attacks on Gecko) |
| 15:40 | <hsivonen> | jgraham: do you mean non-coalescing? |
| 15:40 | <jgraham> | hsivonen: Yes |
| 15:40 | <Philip`> | What about deliberate DoS attacks on other users of the parser, e.g. the validator? |
| 15:41 | <hsivonen> | Philip`: the validator uses SAX, so the question isn't applicable |
| 15:41 | <Philip`> | Ah |
| 15:41 | <hsivonen> | Philip`: and, IIRC, the Java tree builders don't coalesce, but my memory may be failing |
| 15:42 | <hsivonen> | Coalescing in Gecko is needed, because there are discretionary flushes |
| 15:42 | <hsivonen> | and because there's document.write |
| 15:42 | <hsivonen> | hooray to document.write |
| 15:52 | <hsivonen> | huh? so mkv doesn't have a magic within a constant amount of bytes |
| 15:52 | <hsivonen> | that seems like a terrible design decision |
| 15:53 | <jgraham> | hsivonen: Is the hadling of whitespace characters in the table text mode a) different from the spec and b) if so, deliberate? |
| 15:54 | <jgraham> | It seems different to me, but I guess I could be confused |
| 15:54 | <jgraham> | e.g. in <TABLE><center><font>a</center> <img> <tr><td></td> </tr> </table> |
| 15:55 | <hsivonen> | jgraham: not deliberate if actually different |
| 15:56 | <jgraham> | hsivonen: It seems to me that the spec requires hat whitespace-only text is not foster parented but only inserted into the current node |
| 15:56 | <jgraham> | *that |
| 15:57 | <jgraham> | Gecko seems to foster parent |
| 15:57 | <jgraham> | But I might be missing something crucial |
| 15:58 | <erlehmann> | hsivonen, i would like to see the design rationale for the webm container :/ |
| 15:59 | <Lachy> | hsivonen, MKV always has the EBML magic number in the first 4 octets. It's just the doctype that can vary slightly in position, depending on the presence of some other EBML header elements |
| 16:00 | <foolip> | right, sniffing it is not difficult |
| 16:04 | <Lachy> | foolip, has google changed their mind about insisting on the right mime type for webm, despite insisting to us long ago that they would only support webm with the right type? |
| 16:05 | <foolip> | Lachy, I guess they never checked the MIME type at all, it's just used for canPlayType |
| 16:05 | <foolip> | I tested an Ogg video with the wrong MIME type, but it's hard to imagine it's different for WebM |
| 16:05 | <erlehmann> | weird |
| 16:06 | <foolip> | perhaps they've fixed it in their snapshots, but I doubt that too |
| 16:06 | <Lachy> | oh, wtf? I'm sure I mentioned that bug to them on sea otters, and I assumed they would fix it |
| 16:06 | <foolip> | are any of the Chrome engineers actually active on the lists? |
| 16:06 | <foolip> | It'd be easier to not have to guess |
| 16:07 | <foolip> | or, um, test it yourself, I mean :) |
| 16:11 | <AryehGregor> | Sea otters? |
| 16:12 | <AryehGregor> | (also, Chrome developers are active in #chromium and #webkit, in my experience) |
| 16:12 | <foolip> | AryehGregor, a private list prior to the public launch of WebM |
| 16:12 | <AryehGregor> | Oh. |
| 16:12 | <AryehGregor> | Fascinating. |
| 16:16 | <hsivonen> | do Carakan and Nitro support JITting to PPC? |
| 16:16 | <AryehGregor> | MikeSmith, is it supposed to be "crackles" or "cackles"? When I Googled it I found both, but "cackles" makes much more sense to me. |
| 16:18 | <MikeSmith> | AryehGregor: dunno.. could be I typed it in wrong, or could be that it's ambiguous in John Clare's manuscript, and different editors transcribe it differently |
| 16:18 | MikeSmith | checks now |
| 16:19 | <MikeSmith> | my Norton Anthology of Poetry has "crackles" |
| 16:20 | <hsivonen> | looks like Carakan has PPC support |
| 16:20 | <MikeSmith> | AryehGregor: which I like better than "cackles", even if it makes less sense |
| 16:20 | <MikeSmith> | AryehGregor: I think Clare was in an insane asylum when he wrote that poem |
| 16:21 | <AryehGregor> | In that case, the less sane one is probably correct, and the more sane one probably arose due to some helpful person like me assuming a copyist made a mistake. |
| 16:21 | <foolip> | hsivonen, I doubt it produces PPC machine code, on PPC it ought to be running the interpreter only |
| 16:21 | <AryehGregor> | (this is a general principle when reconciling variant texts, the one that makes less sense is probably correct) |
| 16:21 | <jgraham> | hsivonen: Carakan doesn't do JIT/PPC |
| 16:21 | <jgraham> | I wonder if V8 works at all on PPC |
| 16:22 | <jgraham> | Because it doesn't have an interpreter |
| 16:22 | <foolip> | it doesn't? |
| 16:22 | <foolip> | can it run on ARM? |
| 16:22 | <jgraham> | foolip: Yeah, they have ARM support |
| 16:22 | <foolip> | well, that seems less insane then :) |
| 16:23 | <jgraham> | (for people not keeping up, Carakan also has JIT-for-ARM: http://labs.opera.com/news/2010/07/21/ ) |
| 16:24 | <MikeSmith> | AryehGregor: yeah -- even with sane poets, overzealous editors have "corrected" a lot of stuff they would have been better left untampered with |
| 16:24 | <hsivonen> | jgraham, foolip: oh, ok. Lots of misleading reporting about PPC and Carakan then |
| 16:24 | <jgraham> | hsivonen: What are you reading? |
| 16:24 | <hsivonen> | Nitro assembler source code doesn't appear to have PPC support |
| 16:26 | <hsivonen> | jgraham: C|Net |
| 16:26 | <hsivonen> | jgraham: but looing closer, they didn't say JIT |
| 16:26 | <hsivonen> | just put Caracan and PPC in the title |
| 16:27 | <hsivonen> | so no one has a JS JIT for PPC? |
| 16:27 | <foolip> | developing that would be a waste of time |
| 16:27 | <foolip> | PPC is going away |
| 16:27 | <hsivonen> | curiously, Nitro assembler has a MIPS back end |
| 16:28 | <jgraham> | hsivonen: I hear MIPS is used on some devices, but I have no idea what (actually I know nothing about it) |
| 16:28 | <AryehGregor> | Why do you care about JITing to PPC? |
| 16:29 | <Philip`> | Maybe you want fast JavaScript in a web browser on a games console |
| 16:29 | <AryehGregor> | JIT to Cell!!! |
| 16:30 | <hsivonen> | AryehGregor: I don't really *care*. I'm just curious. |
| 16:30 | <Philip`> | AryehGregor: Cell is kind of just PPC plus some extra data processing units |
| 16:31 | <AryehGregor> | Maybe everyone should JIT to LLVM and thus support everything that does. (Note: LLVM seems to be some new trendy technology, so it's appropriate for me to advocate it without understanding whether it would be remotely appropriate for this purpose) |
| 16:35 | Philip` | supposes Opera could care, because the Wii is PPC and it'd be nice if you could play JS games in Opera on there |
| 16:47 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=579846 hooray for abstraction layer violations |
| 16:48 | <hsivonen> | Hixie: is it intentional that caching related pragmas aren't in HTML5? |
| 17:15 | <Hixie> | hsivonen: only insofar as i was trying to keep it to a mininmum. If it's compat-needed, file a bug, I'll add whatever you say is needed. |
| 18:22 | <gsnedders> | Yay for WebKit behavioural changes linked to Radar issues! |
| 18:35 | <JonathanNeal> | Unless I missed it @ http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#annotations-for-assistive-technology-products-(aria) the paragraph element <p> doesn't have an implicit aria role? |
| 19:19 | <AryehGregor> | Does anyone here know about the File API spec? It seems to have no way to look at pieces of a large file without loading the whole thing into memory. |
| 19:19 | <AryehGregor> | I'm trying to figure out if 1) this is true, and 2) it's been discussed before. |
| 19:23 | <AryehGregor> | I guess I'll just post to public-webapps. |
| 20:00 | <JonathanNeal> | <nav> still need headings, yes? |
| 20:00 | <jgraham> | Not "needs" |
| 20:00 | <jgraham> | But it is a section it can have a heading |
| 20:00 | <jgraham> | Otherwise a reasonable UA would make something up |
| 20:05 | <JonathanNeal> | So, it's safe to abandon a heading for a <nav> |
| 20:05 | <JonathanNeal> | Is that written anywhere, though? |
| 20:05 | <AryehGregor> | It's not written anywhere that you have to have a heading for a <nav>. |
| 20:05 | <boogyman> | abandon? wtf |
| 20:05 | <AryehGregor> | So, you can infer that you don't. |
| 20:06 | <boogyman> | <nav> spec states that it's for some sort of page navigation, there's no reference to required pre-req encapsulation |
| 20:07 | <JonathanNeal> | boogyman, well, the last time I asked about it, I seem to remember there being strong consensus to include it. So, I would be abandoning a previous paradigm I thought to follow. |
| 20:08 | <JonathanNeal> | I just have to get over the fact that gsnedders gonna call my navigation an Untitled Section. |
| 20:08 | <gsnedders> | JonathanNeal: Well, yeah |
| 20:08 | <gsnedders> | I'm lazy :P |
| 20:09 | <gsnedders> | (I was going to fix it, then I realized how much effort it would be.) |
| 20:09 | <boogyman> | The nature of the <nav> implies it would be encapsulated by <header>, however it's not 'technically' wrong |
| 20:09 | <JonathanNeal> | gsnedders, it is difficult to have it say something like "Navigation" if it comes from a nav? |
| 20:10 | JonathanNeal | activates gsnedders encouragement mode. |
| 20:12 | <gsnedders> | JonathanNeal: Yes |
| 20:25 | <AryehGregor> | I see references to being able to slice a File into Blobs. |
| 20:25 | <AryehGregor> | Am I just missing that somewhere? |
| 20:34 | <AryehGregor> | Bingo! http://dev.w3.org/2006/webapi/FileAPI/#dfn-slice |
| 20:53 | <gsnedders> | jgraham: I'm not sure it's possible to implement LysKOM as a Thunderbird extension |
| 20:55 | <gsnedders> | "Conferences hold articles. They are represented in the protocol as a data type called Conference. Each conference has a creator, the person who created the conference, and a supervisor, a conference whose members can modify the conference. If the supervisor is a person, the members of that person's mailbox are supervisors, which in most cases is only that person." |
| 20:55 | <gsnedders> | WTH? |
| 20:57 | <othermaciej> | I hope most nouns in that paragraph are terms of art |
| 20:57 | <gsnedders> | Are people conferences? |
| 20:57 | <gsnedders> | Or how else can a supervisor be a conference and a person? |
| 20:58 | <Philip`> | That sounds like a typo to me |
| 20:58 | <Philip`> | (Should be "a person whose members") |
| 20:58 | <jgraham> | Argh |
| 20:59 | <Philip`> | Oh, maybe not |
| 20:59 | <gsnedders> | (For the curiour, that's from the LysKOM spec) |
| 20:59 | <Philip`> | because then "If the supervisor is a person" wouldn't make sense |
| 20:59 | <jgraham> | I just lost an email |
| 20:59 | <gsnedders> | The spec also contains, "Long live FORTRAN!". |
| 20:59 | <jgraham> | Stupid web browser |
| 20:59 | Philip` | decides to happily not understand it |
| 21:00 | <jgraham> | gsnedders: This is #whatwg we don't talk about legacy internet technologies that should have died years ago but mysteriously linger on here |
| 21:00 | <jgraham> | Oh wait... |
| 21:01 | <aliok> | HI all, can anyone point me to some document where I can learn styling Html5 date picker? |
| 21:01 | <jgraham> | gsnedders: (FWIW I assume that the underlying model is that "everything's a conference") |
| 21:02 | <jgraham> | (but I could be wrong) |
| 21:02 | <gsnedders> | jgraham: This isn't mentioned in the spec |
| 21:02 | <jgraham> | gsnedders: What isn't? |
| 21:02 | <gsnedders> | And it's implied People are a separate type to Conference and Text-Stat |
| 21:03 | <zcorpan_> | micheil: array won't throw. it'll just be converted to a string |
| 21:04 | <jgraham> | gsnedders: From reading the above I would assume that People are a subtype of Conference |
| 21:04 | <AryehGregor> | aliok, you can't, basically. |
| 21:04 | <jgraham> | But what do I know |
| 21:04 | <AryehGregor> | Not yet, anyway. |
| 21:04 | <gsnedders> | jgraham: I'd assume that if it weren't for the next section in the spec |
| 21:05 | <aliok> | AryehGregor, thanks anyway. |
| 21:06 | <jgraham> | gsnedders: Oh |
| 21:06 | <aliok> | BTW, if anyone interested we're implementing Html5 enabled JSF components. A live demo is deployed at http://html5-comp-lib-showcase-snapshot.latest.aliok-com-tr-test.appspot.com/index.jsf |
| 21:06 | <jgraham> | gsnedders: (I don't see why what you said precludes the thunderbird extension, although I am not sure how one would implement "mark all messages with the same id as read") |
| 21:06 | <jgraham> | (maybe the feed support already does that?) |
| 21:07 | <gsnedders> | jgraham: I don't see how you can implement a new incoming and outcoming protocol in an extension |
| 21:07 | <gsnedders> | But maybe the docs are just bad |
| 21:12 | <jgraham> | gsnedders: jcranmer had some blog posts |
| 21:12 | <jgraham> | They didn't implement a new protocol I guess |
| 21:16 | <aliok> | AryehGregor, styling of those is written somehere in some spec but not implemented yet, right? |
| 21:23 | <jgraham> | abarth, hsivonen: Filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=10221 on the text node coalescing behaviour |
| 21:44 | <jamesr> | Philip`: is there any way to get the output from your canvas conformance suite in a more machine-parsable way? i want to compare the output of http://philip.html5.org/tests/canvas/suite/tests/index.2d.html between two different builds and i can't see any way to do that other than looking at all the squares |
| 21:47 | <Philip`> | jamesr: If you use http://philip.html5.org/tests/canvas/suite/reportgenentry.html then it'll generate YAML code in the textarea at the bottom |
| 21:47 | <Philip`> | The submit button won't work so don't click that |
| 21:47 | <Philip`> | but it should be possible to diff the outputs |
| 21:48 | <jamesr> | ok |
| 21:48 | <jamesr> | why YAML? |
| 21:48 | <Philip`> | Why not? |
| 21:49 | <Philip`> | It's easy to generate and easy to read and easy to parse (given suitable libraries) |
| 21:49 | <jamesr> | but <insert markup system here> is clearly superior! |
| 21:49 | <jamesr> | Philip`: thanks, i think that'll do the trick |
| 21:49 | <Philip`> | and I was already using it for writing the test cases since it's concise and human-writable |
| 21:50 | <Philip`> | and it's complex and crazy enough to be fun |
| 21:55 | <jcranmer> | gsnedders: with a bit of pain |
| 21:55 | <gsnedders> | jcranmer: So a bit of pain there, and a lot of pain at the badly documented protocol? Nice. |
| 21:56 | <jcranmer> | if you're doing a wire protocol, you're likely using C++ already, which is easier |
| 21:56 | <jcranmer> | it basically lacks documentation on the receiving end |
| 21:56 | <gsnedders> | s/$/ if you know C++/ |
| 21:56 | <jcranmer> | binary protocol stuff in JS is not fun |
| 21:56 | <gsnedders> | I wasn't really thinking about using JS |
| 21:57 | <gsnedders> | JS doesn't work that well for binary data |
| 21:57 | <jcranmer> | for TB, you pretty much have a choice of JS or C++ |
| 21:58 | <gsnedders> | I know. |
| 21:58 | <gsnedders> | I, uh, wasn't entirely convinced I wanted to implement it in TB anyway |
| 21:58 | <jcranmer> | fortunately, it should become easier in the future |
| 21:58 | <gsnedders> | jgraham is the once convinced of that. |
| 21:58 | <gsnedders> | :) |
| 21:58 | <gsnedders> | (I think a more radical UI would be better, but oh well) |
| 22:01 | <AryehGregor> | aliok, I don't know if a spec even exists at this point. |
| 23:01 | <gsnedders> | MikeSmith: I just finished The Third Policeman… That was very… surreal and weird. |
| 23:02 | <micheil> | hmm.. anyone know about firefox WS implementation? |
| 23:02 | <micheil> | http://github.com/miksago/node-websocket-server/issues#issue/12 |
| 23:02 | <MikeSmith> | gsnedders: ah, I envy you for having recently read it the first time |
| 23:02 | <MikeSmith> | there's only one first time |
| 23:02 | <micheil> | if browser gets closed with an open connection, I get back some oddities to what chrome and safari show |
| 23:03 | <gsnedders> | MikeSmith: Indeed, it very much seems like a book that will never be the same once you know how it ends. |
| 23:03 | <MikeSmith> | yeah |
| 23:03 | <MikeSmith> | gsnedders: you should read "At Swim-Two-Birds" next |
| 23:03 | <AryehGregor> | I hate things like that. Because I prefer to just read the same things over and over so I don't have to worry about if they'll be good, and that spoils my strategy. :( |
| 23:04 | <gsnedders> | There again, I can imagine a certain beauty to it another time. |
| 23:04 | <gsnedders> | I still want to properly re-read Ada or Ardor |
| 23:04 | <gsnedders> | Which I re-read in fragments when writing dissertation on it, but have only properly read through it once |
| 23:04 | <gsnedders> | And that has so many beautiful sub-plots running witihn it |
| 23:07 | <MikeSmith> | I re-read parts of "At Swim-Two-Birds" all the time |
| 23:07 | <MikeSmith> | it's like the Bible |
| 23:07 | <MikeSmith> | it should have chapter and verse numbers |
