| 00:01 | <kingryan> | I have an email mailbox that contains most of them. that works alright for me |
| 00:01 | <kingryan> | but I wish there were something better |
| 00:08 | <Philip`> | You can use svnsync to replicate the repository onto your own machine, then run a local web server with ViewSVN or Trac or something |
| 00:15 | <kingryan> | hmm, that sounds useful |
| 00:17 | <takkaria> | IIRC google have said they'll do something about it in an unspecified amount of time |
| 00:18 | Philip` | already has some other copy of Trac so he might see if it's trivial to do an html5lib one, since it's a reasonably nice source browser... |
| 01:24 | <Philip`> | Oh, good, it is easy to set up |
| 01:24 | <Philip`> | http://canvex.lazyilluminati.com/html5lib/ |
| 01:29 | <kingryan> | nice, Philip` |
| 01:53 | <welly> | is the faq response to "when will html 5 be finished" a joke? |
| 02:01 | <Philip`> | welly: No - it just has a more complete meaning of "finished", like requiring there to be multiple correct implementations of the whole specification before it's considered finished |
| 02:02 | <Philip`> | The writing of the specification will be finished much sooner, and implementations of some features are already available and usable |
| 02:02 | <welly> | Philip`: so in 15 years time, html 5 will be a complete specification? I can't help but think the internet moves on a little bit quicker than that |
| 02:03 | <welly> | i can't even imagine what kind of technology or standards we're going to be using in 15 years time |
| 02:04 | <Philip`> | HTML4 is almost ten years old already, and not that much has changed since then |
| 02:05 | <welly> | it seems like an interesting project but wow.. lol... 15 years. no, you're right but all the same. |
| 02:05 | <Philip`> | (HTML4 and CSS2 (I think) wouldn't be considered finished yet, if they used the same criteria as HTML5) |
| 02:05 | <welly> | ok |
| 02:06 | <welly> | what's the likelyhood of html being taken up and implemented by the browser developers? |
| 02:07 | <welly> | er html 5 |
| 02:07 | <Philip`> | Some parts have already been implemented - http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers |
| 02:08 | <welly> | ahh ok.. well that's promising |
| 08:56 | <Lachy_> | My presentation went well this morning :-) |
| 10:12 | <ROBOd> | hey guys |
| 10:14 | <ROBOd> | is it a problem if i sent two emails about the HTML 5 spec to www-html and not to public-html? i sent two emails yesterday by mistake to www-html. i forgot of public-html, eh |
| 10:27 | <annevk> | you could provide a pointer to your e-mails on www-html in your e-mail to public-html |
| 10:29 | <ROBOd> | annevk: eh, two mailing lists with almost the same name. i think should unsubscribe from www-html, just for avoiding these situations |
| 10:30 | <annevk> | that's what I did, though for different reasons |
| 10:31 | <ROBOd> | should i resend the two emails to public-html? or just a pointer? |
| 10:33 | <annevk> | whatever suits you |
| 10:34 | <hsivonen> | ROBOd: I unsubscribed from www-html after I ended up sending email to public-html when public-html was in recess. |
| 10:35 | <hsivonen> | ROBOd: also, www-html is more or less in /dev/null mode as far as actually getting yourself heard goes |
| 10:35 | <ROBOd> | hsivonen: yeah, too much confusion |
| 10:35 | <ROBOd> | hsivonen: precisely. i only got one reply :P |
| 10:35 | <annevk> | I believe Hixie still reads it |
| 10:39 | <ROBOd> | that's very nice, if Hixie still reads www-html |
| 18:57 | <G0k> | hey all |
| 18:57 | <zcorpan_> | hey G0k |
| 18:58 | <G0k> | i'm a little confused about the RemoteEventTarget interface in html 5 |
| 18:58 | <G0k> | "Any object that implements the EventTarget interface must also implement the RemoteEventTarget interface." |
| 18:58 | <zcorpan_> | which part is confusing? |
| 18:59 | <G0k> | i mean is that really the same as saying that the EventTarget interface is being amended to include some new methods? |
| 19:00 | <zcorpan_> | not quite but i guess the end result would be pretty much the same |
| 19:04 | <zcorpan_> | the difference being that it would be one interface instead of two... you can check whether an object implements a certain interface and which members it has |
| 19:04 | <G0k> | right but if any object that implements EventTarget "MUST" also implement RemoteEventTarget.... |
| 19:05 | <G0k> | i guess this allows you to detect legacy behavior better |
| 19:06 | <G0k> | ok the other thing |
| 19:06 | <G0k> | "For connections to domains other than the document's domain, the semantics of the Access-Control HTTP header must be followed. [ACCESSCONTROL]" |
| 19:06 | <G0k> | [ACCESSCONTROL] seems to be a dead link? |
| 19:06 | <zcorpan_> | yes, refs haven't been written yet |
| 19:06 | <G0k> | heh. oki |
| 19:08 | <zcorpan_> | http://dev.w3.org/cvsweb/~checkout~/2006/waf/access-control/Overview.html?content-type=text/html;%20charset=utf-8 |
| 19:12 | <G0k> | ok there's one other part that has me slightly confused |
| 19:12 | <G0k> | "If the Namespace is null and the Event field is message (including if it was not specified explicitly), then the MessageEvent interface must be used. |
| 19:12 | <G0k> | Otherwise, the Event interface must be used." |
| 19:12 | <G0k> | so that would seem to suggest for instance, that if you got an event like |
| 19:12 | <G0k> | Event: foo |
| 19:12 | <G0k> | data: bar |
| 19:13 | <G0k> | it would create an Event event with type "foo", then ignore the data field, since data isn't a defined attribute for the Event interface |
| 19:15 | <G0k> | which isn't bad, it's just precisely the opposite of how Opera has implemented it |
| 19:15 | <zcorpan_> | it is? |
| 19:15 | <G0k> | well like...see their sample code http://labs.opera.com/news/2006/09/01/ |
| 19:16 | <G0k> | they have it sendings stuff like |
| 19:16 | <G0k> | Event: the-answer |
| 19:16 | <G0k> | data: 42 |
| 19:16 | <G0k> | in their implementation, it sets the data attribute on the event |
| 19:16 | <G0k> | but that's not technically what the spec says, as the Event interface has no data attribute |
| 19:18 | <G0k> | for that matter, the pending patch for mozilla also implements it the other way |
| 19:18 | <zcorpan_> | hmm, might be a bug in the spec then |
| 19:20 | <G0k> | k. is there an issue tracker somewhere? |
| 19:20 | <zcorpan_> | no |
| 19:20 | <G0k> | should I use the forum? |
| 19:21 | <zcorpan_> | it would be great if you could send it to the list directly |
| 19:21 | <G0k> | which? html-dev or whatwg? |
| 19:21 | <zcorpan_> | whatwg |
| 19:22 | <G0k> | k |
| 19:22 | <zcorpan_> | what is html-dev? |
| 19:22 | <G0k> | er i dunno the one w3c runs |
| 19:22 | <zcorpan_> | aha. public-html |
| 19:22 | <G0k> | that one |
| 19:23 | <zcorpan_> | if you're subscribed then you can send it to that list if you want. if you do, include "detailed review of" in the subject line |
| 19:24 | <G0k> | k |
| 19:47 | <G0k> | sent |
| 19:47 | <zcorpan_> | thanks |
| 19:47 | <G0k> | np |
| 20:34 | <annevk> | it defaults to the MessageEvent actually, not Event |
| 20:34 | <G0k> | except if the Event: field is specified |
| 20:35 | <G0k> | (to something other than "message") |
| 20:35 | <G0k> | or at least that's what the spec seems to say right now |
| 20:36 | <annevk> | no |
| 20:36 | <annevk> | oh, maybe |
| 20:36 | <G0k> | "If the Namespace is null and the Event field is message (including if it was not specified explicitly), then the MessageEvent interface must be used. |
| 20:36 | <G0k> | Otherwise, the Event interface must be used." |
| 20:36 | annevk | looks at the spec |
| 20:36 | <annevk> | that seems wrong |
| 20:37 | <G0k> | yeah :) |
| 20:37 | <G0k> | it should just say |
| 20:37 | <G0k> | "Otherwise, the MessageEvent interface must be used" |
| 20:38 | <G0k> | (imho) |
| 20:38 | <annevk> | yeah, that's what we do anyway and it's proven useful |
| 20:38 | <G0k> | yep |
| 20:38 | <G0k> | it's what i did in my webkit implementation too, then i just re-read that |
| 20:41 | <annevk> | ah, you're implementing this in WebKit? awesome |
| 20:42 | <G0k> | yeah well...it's a little sketchy right now but with some work yeah it'll be cool. :) |
| 20:42 | <annevk> | :) |
| 20:42 | <G0k> | i'll be able to stream events to my iphone. :) |
| 21:02 | <annevk> | html5lib is linked from dailypythonurl, whatever that is |
| 21:02 | <annevk> | http://www.pythonware.com/daily/ |
| 21:40 | <Hixie> | (yes i still read www-html) |
| 21:40 | <Hixie> | if anyone sees G0k again, let him know I agree with his proposal |
| 21:41 | <Hixie> | i'd mail him straight back but his mail is lost somewhere in my event-source feedback pile |
| 21:41 | <zcorpan_> | "Henry Mason" <hmason⊙mc> |
| 22:05 | <Hixie> | thanks |
| 22:22 | <Jero> | hey whats up |
| 22:23 | <Jero> | I was wondering when the WHATWG will start on the HTML5 spec again |
| 22:26 | <zcorpan_> | Jero: you mean when Hixie will start edit the spec again? |
| 22:27 | <Jero> | or that, yes |
| 22:27 | <zcorpan_> | well, he's back from his vacation now so i guess he just needs to get up to speed with all email |
| 22:28 | <Jero> | i see, thanks |
| 22:30 | <zcorpan_> | http://annevankesteren.nl/2007/07/web#comment-6176 |
| 23:39 | <Hixie> | zcorpan_: i can't get to that site, is it down? |
| 23:40 | <hsivonen> | oh dear. this "low quality" thing is going to be a rathole |
| 23:43 | <Hixie> | it's the same style="" rathole we've always had |
| 23:44 | <hsivonen> | Hixie: no. now it is becoming a b and i rathole as well |
| 23:47 | <Hixie> | othermaciej_: <font> and style="" are "low quality" because they are media-specific, and potentially hide information from non-presentational UAs. |
| 23:48 | <Hixie> | othermaciej_: <div>s-containing-inlines are "low quality" because they imply some sort of paragraphing structure without giving any information about why |
| 23:49 | <Hixie> | othermaciej_: (typically, the latter is used as a workaround for the lack of a widget abstraction language like xbl) |
| 23:49 | <othermaciej> | Hixie: I don't see how style="" is media-specific |
| 23:50 | <othermaciej> | Hixie: it lacks the ability to give different styles per media, but can still be used in media-independent ways |
| 23:50 | <othermaciej> | since in practice most styles are not media-scoped anyway, nor do they need to be |
| 23:51 | <Hixie> | ok, strike the media-specific part |
| 23:51 | <othermaciej> | in that case, style="" hides no more information than <style>, <link rel="stylesheet"> or <style scoped> |
| 23:51 | <Hixie> | (though i actually do believe they usually result in media-specific content, even if it's technically possible to use them otherwise) |
| 23:51 | <othermaciej> | none of which you have labelled "low quality" |
| 23:52 | <othermaciej> | I have to go grab a beer, brb |
| 23:52 | <Hixie> | i considered including <style>, but in practice if you use a style sheet with selectors you tend to be pushed towards content that can stand even without the stylesheet. |
| 23:53 | <Hixie> | obviously though that's not automatically the case, which is why the other mode wouldn't be called "high quality" |
| 23:57 | <othermaciej> | back |
| 23:58 | <othermaciej> | if you include <style> and <link rel="stylesheet"> it would make it pretty hard to have a useful non-low-quality document |
| 23:58 | <Hixie> | indeed |
| 23:59 | <othermaciej> | but I don't think there's any evidence of a difference in hiding information from non-presentational UAs between those and style="" |
| 23:59 | <Hixie> | oh come now |
| 23:59 | <othermaciej> | I mean, that might be the case, but I am not sure how you would quantify it |