| 00:05 | gsnedders | finds http://lists.w3.org/Archives/Public/spec-prod/2009AprJun/0010.html |
| 00:26 | gsnedders | thinks from his query that there are 2245 TRs |
| 00:41 | <heycam> | Hixie, i do plan to finish that testing |
| 00:41 | <heycam> | (and fix the tests up) |
| 00:42 | <heycam> | i'll have a small amount of time after the svg wg's f2f next week that i'll be working on webidl stuff |
| 01:08 | gsnedders | laughs at HTML 5 now calling itself a "Draft Standard" |
| 01:08 | <Hixie> | i was so happy to hear that html5 was a standard |
| 01:08 | <Hixie> | i always thought that we were supposed to not call w3c things standards |
| 01:08 | <gsnedders> | Me too. |
| 01:09 | gsnedders | still agrees with you, and just thinks it is more W3C fucked-up-ness |
| 01:09 | <gsnedders> | Uh, the spec is loading really slowly here. |
| 01:09 | <gsnedders> | Like 4KB/s |
| 01:10 | <gsnedders> | Do we have any idea about implementations for iframe@sandbox? |
| 01:10 | <Hixie> | wfm |
| 01:10 | <Hixie> | no |
| 01:27 | <gsnedders> | Oh, just my local net is busy |
| 02:23 | <heycam> | hi, what in the spec determines how external javascript encoding is determined? |
| 02:35 | <Hixie> | heycam: html5 has some stuff for how to do it for <script> |
| 02:35 | <Dashiva> | heycam: I believe "Running a script" in 4.3.1 the script element |
| 02:37 | <heycam> | ok thanks |
| 02:38 | <heycam> | so i'm wondering if/how the processing of scripts labelled as text/javascript differs from what rfc 4329 says to do with them |
| 02:40 | <heycam> | this is the question i'm trying to answer: "Why is HTML5 making the default be text/javascript rather than application/ecmascript?" |
| 02:40 | <Dashiva> | There's a bug for that |
| 02:41 | <heycam> | yeah, but i don't remember a clear reason being given |
| 02:41 | <heycam> | i'll look it up again |
| 02:42 | <Hixie> | the type doesn't matter to the implementations |
| 02:42 | <Hixie> | the implementations completely ignore the type part of the content-type |
| 02:42 | <Hixie> | you could have image/png and it'd work as well |
| 02:42 | <Hixie> | at least over the wire |
| 02:42 | <Hixie> | the type="" attribute is a different matter |
| 02:42 | <Hixie> | but all this is academic |
| 02:42 | <heycam> | ah, i'm asking about the type="" attribute |
| 02:42 | <Hixie> | the only reason that i use text/javascript instead of application/ecmascript is that application/ecmascript is stupid |
| 02:43 | <Hixie> | everyone calls it text/javascript |
| 02:45 | <heycam> | i guess what i want to know is: how would things break if you normatively referenced rfc 4329 for the processing of <script type=text/javascript> and <script type=application/ecmascript>, and for if you changed the default type of <script> with no type="" to be application/ecmascript |
| 02:45 | <Hixie> | what does rfc4329 say that can be referenced? |
| 02:45 | <Hixie> | i didn't realise it defined anything useful other than the type names |
| 02:46 | <heycam> | it gives some requirements on encoding detection / error reporting, i think |
| 02:46 | <Hixie> | s/useful/usable/, i guess, given my stance on the names :-) |
| 02:46 | <Hixie> | oh? |
| 02:46 | <heycam> | i thought so |
| 02:46 | Hixie | looks |
| 02:46 | <heycam> | but i could be wrong, i just skimmed |
| 02:46 | <heycam> | i remember implementing distinct codepaths for text/javascript and application/ecmascript in batik, a while ago, based on what rfc 4329 said |
| 02:47 | <Hixie> | rfc4329 is misleading then |
| 02:48 | <heycam> | i.e., doesn't describe reality? |
| 02:48 | <Hixie> | uh yeah, having now looked at this seems highly in variance with implemented practice |
| 02:48 | <heycam> | ok |
| 02:48 | <Dashiva> | "Use of the "text" top-level type for this kind of content is known to be problematic." |
| 02:49 | <Dashiva> | What is the reason here? I'm not in the know. |
| 02:49 | <heycam> | default us-ascii encoding? |
| 02:49 | <Hixie> | or iso-8859-1 depending on which spec you read |
| 02:49 | <Dashiva> | Is that it? |
| 02:49 | <Hixie> | (it's nonsense) |
| 02:49 | <Hixie> | i believe so |
| 02:49 | <Hixie> | there is no real problem |
| 02:50 | <heycam> | well i see that html5 maps us-ascii to windows-1252 |
| 02:50 | <Hixie> | the problem is a persistent myth promulgated by a variety of spec writers |
| 02:51 | <Dashiva> | Hmm, the RFC claims charset defaults to UTF-8 |
| 02:51 | <Dashiva> | That's not really true, is it? |
| 02:51 | <Hixie> | no |
| 02:51 | <Hixie> | i would basically ignore 4329 altogether |
| 02:52 | <heycam> | i'd like concrete things that rfc 4329 conflicts with to answer the question about why it uses text/javascript and doesn't reference that rfc, if you could |
| 02:52 | <heycam> | s/why it/why html5/ |
| 02:52 | <Hixie> | search for 4329 in html5 |
| 02:53 | <heycam> | yep i did that |
| 02:53 | <heycam> | there's just that one note |
| 02:53 | <Hixie> | right |
| 02:53 | <Hixie> | that's the reason for why it uses text/javascript |
| 02:53 | <Hixie> | the reason it doesn't refer to the charset algorithm is the charset algorithm is wrong |
| 02:53 | <Hixie> | e.g. it ignore charset="" on <script> |
| 02:54 | <Hixie> | doesn't take into account the refering document's charset |
| 02:54 | <Hixie> | does support UTF-32 |
| 02:54 | <Hixie> | and suggests that the type is relevant |
| 02:54 | <Dashiva> | Hmm, it defers to XML Media Types on the processing. That's why text/ and application/ are different |
| 02:55 | <Hixie> | 3023 |
| 02:55 | <Hixie> | that's where a lot of this nonsense started |
| 02:55 | <Hixie> | regarding text/ vs application/ |
| 02:55 | <heycam> | that text/javascript is more commonly used might be a reason to refer to the language as "text/javascript", but that doesn't have anything to do with requirements on how to process script, right? |
| 02:55 | <Hixie> | right |
| 02:55 | <heycam> | the encoding/charset stuff sounds like the kind of answer i want |
| 02:55 | <MikeSmith> | wakaba: you around? |
| 02:56 | <heycam> | "RFC 4329 requires <script type=text/javascript> to be processed like A, but in reality browsers need to be processed like B." |
| 02:56 | Hixie | should point out that he's not a big fan of tiny specs that over-solve non-problems, like 4329 |
| 02:56 | <heycam> | s/browsers need to be/browsers need to process it/ |
| 02:56 | <MikeSmith> | wakaba: if/when you have time, please try a traceroute to svn8.cvsdude.com and let me know what you get |
| 02:57 | <MikeSmith> | wakaba: I'm on my emobile connection and can't get any route to it |
| 02:57 | <Hixie> | heycam: did this come up in the svgwg? |
| 02:57 | <heycam> | the quoted question at the top did, yes |
| 02:58 | <Hixie> | the only reason i'm making the default text/ instead of application/ is that there's no reason to introduce application/ and everyone calls it text/ |
| 02:58 | <Hixie> | i'm not doing it because of charsets |
| 02:58 | <heycam> | hmm ok |
| 02:58 | <Hixie> | (and that is already mentioned in the spec) |
| 02:58 | <heycam> | i guess the more pertinent question then is why you don't normatively reference rfc 4329 |
| 02:59 | <heycam> | to which the answer is the charset/encoding stuff? |
| 02:59 | <Hixie> | yeah |
| 02:59 | <Hixie> | though nobody other than you has asked that :-) |
| 02:59 | <Hixie> | asked me that, anyway |
| 02:59 | <heycam> | didn't jreschke? |
| 02:59 | <Hixie> | did he? |
| 02:59 | <heycam> | i thought that's what that bugzilla bug was |
| 02:59 | <Hixie> | i thought he spoke of the type name only |
| 02:59 | <heycam> | but i couldn't find it |
| 02:59 | <heycam> | ah ok |
| 03:00 | <heycam> | processing for all the many different media types to identify javascript are handled the same in html5, yes? |
| 03:00 | <Hixie> | for type="", language="", or Content-Type: ? |
| 03:01 | <heycam> | type="" |
| 03:01 | <heycam> | (you've said Content-Type is ignored, right (except for its charset parameter)?) |
| 03:02 | <Hixie> | let's see... (for type...) |
| 03:04 | <Hixie> | heycam: the only difference appears to be the one listed here: http://www.whatwg.org/specs/web-apps/current-work/#support-the-scripting-language |
| 03:05 | <heycam> | the e4x bit? |
| 03:10 | <Hixie> | yeah |
| 03:10 | <heycam> | is this right?: <script src=""> without a type="" attribute that references a resource served as whatever media type, without a charset parameter, will be decoded using the referencing html document's encoding |
| 03:11 | <heycam> | (also if the resource doesn't have a BOM) |
| 03:11 | <Dashiva> | Yes |
| 03:11 | <Dashiva> | Although you probably meant without a charset attribute? |
| 03:12 | <heycam> | oh i meant charset parameter on the Content-Type |
| 03:12 | <heycam> | (but also without a charset="" on the <script>) |
| 03:12 | <heycam> | or does that charset parameter on the Content-Type not do anything either? |
| 03:12 | <Dashiva> | Yeah, because type doesn't really enter into it |
| 03:12 | <Dashiva> | It does |
| 03:13 | <heycam> | ah i see what you mean |
| 03:13 | <heycam> | the charset parameter in the type="" is ignored, it's the charset="" attribute that makes a difference |
| 03:14 | <heycam> | ok so that's a good concrete answer to the question of why rfc 4329 isn't normatively referenced |
| 03:14 | <heycam> | thanks |
| 03:15 | <heycam> | this is the kind of thing that it's hard to get a sense of quickly looking at the algorithms |
| 03:16 | <heycam> | informative, declarative text that summarises how encoding of an external script is determined would have been handy to answer my question, i think |
| 03:17 | <Dashiva> | It would be nice |
| 03:17 | <jruderman> | does "unknown parameters" in http://www.whatwg.org/specs/web-apps/current-work/#support-the-scripting-language refer to things like ;e4x=1 and ;version= ? |
| 03:17 | <Dashiva> | But when Hixie writes an algorithm it usually means he wasn't able to define things neatly declaratively |
| 03:18 | <heycam> | try harder, Hixie, gosh! |
| 03:18 | <heycam> | i don't mind even if the declarative informative parts aren't completely accurate |
| 03:18 | ezyang | finally got around to running kcachegrind on profiler output of html5lib php |
| 03:18 | <heycam> | and defer to the algorithm for details |
| 03:19 | <heycam> | but i guess that could be misleading for people, and might encourage them not to look into the details in the algorithm |
| 03:22 | <Hixie> | heycam: it's not clear such text is a good idea, since because it would be simpler than the real text, people would use it instead of the real text |
| 03:23 | <heycam> | yes i could understand that |
| 03:23 | <Hixie> | jruderman: it means parameters that the browser doesn't know |
| 03:23 | <Hixie> | heycam: oh, you just said that. nevermind :-) |
| 03:23 | <Hixie> | heycam: the other problem is that i don't know which parts of the spec people will want these summaries for |
| 03:24 | <heycam> | right |
| 03:24 | <Hixie> | heycam: and doing it for every little thing would double the size of the spec |
| 03:24 | <jruderman> | Hixie: i wasn't sure what "parameters" meant in that context |
| 03:24 | <Hixie> | jruderman: MIME parameters |
| 03:24 | <jruderman> | i was afraid that would be the answer ;) |
| 03:24 | <Hixie> | jruderman: see the MIME spec for details :-) |
| 03:38 | <ezyang> | Bottom line is, 4 seconds to parse a 2MB document is not bad. |
| 03:39 | <ezyang> | I don't think I'm going to waste too much time optimizing the hell out of it. |
| 03:39 | <ezyang> | A C implementation is generally useful, but lots of work. |
| 03:39 | <ezyang> | (this is to gsnedders) |
| 03:44 | <Hixie> | "I think, in fact, that if I may pose myself as not belonging to the hegemony, then I am one of the least conspirational persons of that lot - too little, perhaps." |
| 03:44 | <Hixie> | i am going to have to frame that and print it |
| 03:44 | <Hixie> | er, print it then frame it |
| 03:50 | <gavin_> | paranoid about not being paranoid enough? |
| 03:56 | <Hixie> | and using the word "hegemony" in the same sentence as claiming to not be conspirational |
| 04:08 | <MikeSmith> | I wonder if some people read their mailing-list postings aloud to themselves before sending them |
| 04:08 | <MikeSmith> | while looking in the mirror |
| 04:09 | <MikeSmith> | I mean people other than me |
| 04:09 | <MikeSmith> | or if they wink at themselves while doing so |
| 04:10 | ezyang | wink wink |
| 04:10 | ezyang | wink wink wink if you know what I mean |
| 04:10 | <ezyang> | wink wink |
| 05:03 | <Hixie> | haha, awesome |
| 05:03 | <Hixie> | unrelated people are referring to html5 as a "draft standard" now: http://www.cre8asiteforums.com/forums/index.php?showtopic=71518&mode=linearplus |
| 05:05 | <hobo> | well thats good news |
| 05:06 | <othermaciej> | Hixie: that's what I've always called it when I talk about it... |
| 05:06 | <othermaciej> | but it's nice that I can be pedantically correct now when I say that |
| 05:28 | <shepazu> | Hixie: did it escape your attention that Google was calling HTML5 a standard at Google I/O? |
| 05:28 | <Hixie> | no, but google are hardly "unrelated" :-) |
| 05:28 | <othermaciej> | shepazu: calling it a "draft standard" is definitely an improvement |
| 05:28 | <shepazu> | people have always used the term "standard" pretty loosely... |
| 05:28 | <othermaciej> | that is what I called it in my Google I/O talk |
| 05:29 | <Hixie> | it was in fact google's calling it a standard that cause plh to complain, which caused me to update the spec's title to use the word "standard" |
| 05:29 | <othermaciej> | Google also claimed many things are part of HTML5 which are actually now separate specs |
| 05:29 | <shepazu> | and that were never part of HTML5, like Geolocation API |
| 05:29 | <othermaciej> | I've advised potential Apple presenters to try to be more precise |
| 05:29 | <shepazu> | Hixie: you may have misunderstood... PLH wasn't complaining about the word, just noting that it's not yet done |
| 05:30 | <othermaciej> | calling it a standard without being clear about the draft status is incorrect |
| 05:30 | <othermaciej> | and potentially misleading |
| 05:30 | <shepazu> | the word really only matters for the pedantic, or when it actually matters to make a distinction |
| 05:30 | <Hixie> | shepazu: yes, i understand that (see the comments on the blog post for details) |
| 05:31 | <othermaciej> | PLH had a point, although if I were him, I would focus less on that and more on the extremely positive PR being generated for a W3C draft |
| 05:31 | <shepazu> | othermaciej: yes, I think that was what PLH was pointing out... that it's still a draft |
| 05:31 | <othermaciej> | like if you look at this: http://www.w3.org/QA/2009/05/_watching_the_google_io.html |
| 05:32 | <shepazu> | I think that PLH's post was optimistic on the whole... it told people how to get involved, said that it was still ongoing, and talked about the various related activities |
| 05:32 | <othermaciej> | there's about 1.5 sentences in the whole thing that seem happy about HTML5 getting a positive reception |
| 05:32 | <Hixie> | othermaciej: the reason google people refer to all this as "html5" is that there's no other catchphrase for it, btw, an issue that i brought up months ago in this channel |
| 05:32 | <Hixie> | othermaciej: not sure what to do about it |
| 05:32 | <Hixie> | othermaciej: until we have another marketable term, google'll probably continue calling it all "html5" |
| 05:32 | <Hixie> | othermaciej: because people respond to that term |
| 05:32 | <othermaciej> | Hixie: I think Apple will probably end up riding the catchphrase wave, though maybe be clear that it includes more than just the HTML 5.0 draft standard |
| 05:33 | <shepazu> | there's nothing wrong with marketing terminology, and there's nothing wrong with being more precise, depending on the audience |
| 05:33 | <othermaciej> | though maybe with the synchronicity of HTML 5 and ES5, we could call the whole current generation of Web standards "Web 5.0" |
| 05:33 | <othermaciej> | (see, this is why I'm not in marketing) |
| 05:33 | <shepazu> | othermaciej: you, sir, are correct :) |
| 05:33 | <Hixie> | shepazu: i think there _is_ something wrong with calling, e.g. the geolocation spec "HTML5" |
| 05:34 | <Hixie> | othermaciej: yes, i agree that "Web 5.0" is what we should use |
| 05:34 | <shepazu> | Hixie: and that's why you weren't up on stage :) |
| 05:34 | <shepazu> | I think that cat's out of the bag |
| 05:34 | <othermaciej> | Hixie: if I actually thought that was a good term I could probably put it in the buzz-vocabulary |
| 05:34 | <Hixie> | no, i wasn't on stage because i refused because i didn't want to appear vendor-biased :-) |
| 05:34 | <othermaciej> | all it would take is one WebKit blog post plus get some key apple folks to talk about it |
| 05:35 | <othermaciej> | but I'm not sure "Web 5.0" is actually good |
| 05:35 | <shepazu> | fwiw, I think "Web 5.0" is lame |
| 05:35 | <othermaciej> | it's not bad in itself, but it will remind people of "Web 2.0" and "web 3.0" |
| 05:35 | <shepazu> | it's too Web 2.0 |
| 05:35 | <shepazu> | yes |
| 05:35 | <Hixie> | well, i'm fine with whatever term people want, but until we have one, expect google's marketing to continue saying "html5" :-) |
| 05:35 | <shepazu> | Open Web is much better |
| 05:35 | <Hixie> | at least the chrome guys now say "OWP" |
| 05:36 | <Hixie> | but "OWP" is apparently not a term that people respond to |
| 05:36 | <shepazu> | OWP is also terrible |
| 05:36 | <othermaciej> | for Open Web Platform? |
| 05:36 | <Hixie> | othermaciej: yeah |
| 05:36 | <shepazu> | Open Web. |
| 05:36 | <othermaciej> | the problem with that is, it's not specific to the current generation of improvements |
| 05:36 | <othermaciej> | (or Open Web) |
| 05:36 | <Hixie> | (chrome use OWP for the concept in general, not this generation) |
| 05:36 | <othermaciej> | yeah |
| 05:37 | <othermaciej> | we say similar things - "open web", "web platform", "web technology", "standards-based web" |
| 05:37 | <othermaciej> | I like the 5 as a signifier of the current generation |
| 05:37 | <zcorpan> | W3C 5 |
| 05:37 | <othermaciej> | it's just too bad Web x.0 is somewhat poisoned by past meaningless buzzwords |
| 05:38 | <othermaciej> | zcorpan: that sounds like a model number for a european luxury car |
| 05:38 | <othermaciej> | "Web 5" could avoid the .0 taint, but it's not as euphonious |
| 05:39 | <arun__> | I wasn't too thrilled with 3D being associated with HTML5 in past catchphrasing at Google I/O, but whatever :) |
| 05:39 | <othermaciej> | I think of the things they referred to as HTML5, only AppCache, <canvas> and <video> are actually in HTML5 |
| 05:41 | <olliej> | and all of them have been shipping for more than a year |
| 05:41 | <arun__> | The 5 signifier is good, but unfortunately ECMAScript 5 is merely a renaming of the ersthwile ECMAScript Edition 3.1, so it's almost 5 because of standards-setting org rigidity :) |
| 05:42 | <arun__> | Open Web, 5th Generation |
| 05:43 | <heycam> | Open Web: The Next Generation |
| 05:43 | <othermaciej> | 5th Generation Web? |
| 05:43 | <heycam> | Hixie is Picard, rubys is Riker (because of the beard, obviously), ... |
| 05:43 | <arun__> | heh :) Or, just to futz with O'Reilly, maybe Web 5.0? |
| 05:44 | <othermaciej> | arun__: we just talked about Web 5.0, and how it may bring up bad associations with Web 2.0... |
| 05:44 | <othermaciej> | but then again, for the target audience, the associations may be positive |
| 05:44 | <arun__> | :) |
| 05:44 | <tantek> | a whole nother meaning to "5 > 2" |
| 05:45 | <othermaciej> | I've almost talked myself into Web 5.0 |
| 05:46 | <arun__> | I'm definitely warming up to Web 5.0. 5.0 is attractive numerology; Fx 3.5, etc. There's fives in sufficiently needle-moving things. |
| 05:46 | <zcorpan> | maybe Opera 10 should be renamed to Opera 5 |
| 05:47 | <shepazu> | AppWeb? |
| 05:48 | <shepazu> | zcorpan: no, it should be Opera X |
| 05:48 | <zcorpan> | shepazu: too apple-y |
| 05:48 | <shepazu> | then the next version should be Opera X: beagle |
| 05:49 | <shepazu> | followed by pug, chihuahua, and weinerdog |
| 05:50 | <zcorpan> | what would the UA string be? Opera/X.beagle ...? |
| 05:50 | <othermaciej> | I asked Apple marketing for advice on a buzzword |
| 05:53 | <shepazu> | I suspect it might be too late... HTML5 is probably going to stick |
| 05:56 | <heycam> | Hixie, minor nit: s/WebIDL/Web IDL/ throughout the spec (except when it's a [WebIDL] reference) |
| 05:56 | <Hixie> | heycam: can you file a bug or drop me a mail? |
| 05:57 | <heycam> | yep |
| 05:57 | <Hixie> | thanks |
| 06:46 | zcorpan | splits off the Ogg controversy to a separate page on wikipedia |
| 06:57 | <zcorpan> | i think that's enough wiki editing for today |
| 07:22 | <arun__> | I'd like to replace FileList as defined here: http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.html#FileList-if with something that uses sequence<File> which is much more accurate to real world usage. heycam, that's merely typedef FileList sequence<File> right? |
| 07:23 | <heycam> | yep, apart from the fact that sequences aren't defined properly at the moment |
| 07:23 | <heycam> | how do you want the sequences to behave? |
| 07:23 | <arun__> | OK, but what if FileList were to *also* have a unsigned int for length? |
| 07:23 | <arun__> | Frankly, I want sequences to behave like ECMAScript 3.0 Arrays :) |
| 07:24 | <heycam> | arun__, ok |
| 07:24 | <heycam> | i think there a different use cases for different sequence-ish/array-ish behaviour |
| 07:24 | <heycam> | so you just want to expose an array as an idl attribute |
| 07:24 | <heycam> | is the array mutable? |
| 07:24 | <arun__> | heycam, hmm... I may have simplified. |
| 07:25 | <arun__> | The array represents the number of File objects selected by the user. |
| 07:25 | <arun__> | And I was thinking that FileList would expose an unsigned int for length. |
| 07:25 | <heycam> | guess i should look at the spec |
| 07:26 | <arun__> | http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.html#FileList-if is what I want to replace . |
| 07:26 | <heycam> | ok |
| 07:27 | <heycam> | so it's a read only sequence |
| 07:27 | <arun__> | So you'd say myFile = inputElement.files[0]; yourFile = inputElement.files[1]; (where inputElement.length = 2) |
| 07:27 | <heycam> | can't change the length, or what File objects are stored in there |
| 07:27 | <heycam> | you can certainly do that sort of thing at the moment with an interface and use of [IndexGetter] |
| 07:27 | <arun__> | Yep. |
| 07:27 | heycam | has a telcon now, so you'll have to excuse me for a bit |
| 07:27 | <arun__> | Yeah, I wonder if [IndexGetter] is better than sequence here. |
| 07:28 | <Hixie> | why would sequence not work? |
| 07:28 | Hixie | hopes sequence<> will work soon because HTML5 uses it :-) |
| 07:29 | <heycam> | coz i've commented most of it out |
| 07:29 | <arun__> | I'm ok with using sequence<> and like it, actually. But in heycam's draft, it seems commented out. |
| 07:29 | <heycam> | i'll take a look at all the specs currently using sequence and hash something out in a couple of weeks |
| 07:29 | <arun__> | I'm warming up to [IndexGetter] now actually. |
| 07:30 | arun__ | goes back to reading Web IDL... |
| 07:33 | <Hixie> | it being commented out is no reason not to use it if you ask me :-) |
| 07:33 | <Hixie> | it just means we don't know exactly what it'll be yet :-) |
| 07:34 | <arun__> | Hixie, unless [IndexGetter] is invalid for this use case (is there a mutable/immutable thing that I should know?), it seems to do the trick admirably. |
| 07:34 | <arun__> | I like sequence<> but this seems quick and dirty for my use case. |
| 07:36 | <Mrmil> | Hi, I'll take the advantage that there's so many of you in the morning (well, my morning that is) and would like you to have a look at http://server.ebrana.cz/olda/_apps/html5/ and tell me what I can fix again. Thanks. :) |
| 07:36 | <Hixie> | arun__: [IndexGetter] works fine here too |
| 07:37 | Hixie | uses [IndexGetter] a lot in his specs |
| 07:37 | <Hixie> | it's a lot more work :-P |
| 07:37 | <arun__> | FWIW I want sequence<> used in the emerging 3DWeb spec. |
| 07:37 | arun__ | now has to go back to setting an agenda for the upcoming meeting *sigh |
| 07:38 | <Hixie> | oh is there a mailing list for that yet? |
| 07:38 | <arun__> | Mrmil, at first blush, the site seems ok. |
| 07:39 | <arun__> | Hixie, there *is* a closed mailing list presently. |
| 07:40 | <zcorpan> | Mrmil: you could remove class="hidden" and replace the selector with nav h2 |
| 07:41 | <Hixie> | arun__: closed? |
| 07:41 | <Hixie> | arun__: how do we join it? (and when will it be open?) |
| 07:41 | <arun__> | Hixie, I continue to exert gentle pressure for more openness (I'm the Chair of the WG), but by "closed" I mean that it is for members only. |
| 07:41 | <Mrmil> | zcorpan: that's true but I have an experience that the more complex the site is, the more hidden elements it has. So it's more space-wise to have short hidden classes do the trick than long selector lines in the css sheet. |
| 07:42 | <Hixie> | arun__: how do i become a member? |
| 07:42 | <arun__> | Hixie, your company is on it, and if you want to be on it, that's pretty straightforward. |
| 07:42 | <Mrmil> | zcorpan: And I don't want to hide every nav h2. |
| 07:42 | <zcorpan> | Mrmil: fair enough |
| 07:43 | <Mrmil> | zcorpan: Hookey. |
| 07:43 | <zcorpan> | Mrmil: <q>appealing</q> - i think this is not quite proper use of <q> per spec |
| 07:43 | <Mrmil> | arun__: Thanks :) |
| 07:43 | <arun__> | Hixie, ask Fette et al, but basically you sign up with your company credentials on khronos. |
| 07:43 | <Mrmil> | zcorpan: Hehe, I know, I'll rewrite the text today. |
| 07:44 | <Hixie> | arun__: hm, ok, will ask, thanks |
| 07:44 | <Hixie> | arun__: how does a random person become a member? |
| 07:44 | <Hixie> | arun__: we should post a blog post like the whatwg one telling people how to join |
| 07:44 | <zcorpan> | Mrmil: the <address> only "applies" to the <aside> section per spec. although one could argue that that the spec is being silly |
| 07:45 | <zcorpan> | Mrmil: <div class="clear"></div> - you could use :after instead |
| 07:45 | <Mrmil> | zcorpan: could do, no problem |
| 07:45 | <arun__> | Hixie, right now, the random person can only become a member by invitation based on merit as judged by other members (unlike how public-html⊙wo works -- but note I'm not implying anything about merit on that list ;-) ) OR if they pay. |
| 07:46 | <Hixie> | hm, that sucks |
| 07:46 | <Hixie> | we should fix that |
| 07:46 | <arun__> | Hixie, essentially this is a closed group; and I'm trying :-) |
| 07:46 | <Hixie> | well, i guess i'll join and help you :-) |
| 07:46 | <Hixie> | who's against it? |
| 07:46 | <annevk2> | are documents public? |
| 07:46 | <Mrmil> | zcorpan: done. Address in aside only sounds a little limitating (hope this word exitsts) |
| 07:47 | <arun__> | annevk2, I'd like to make 'em so by being efficient in releasing specs. |
| 07:47 | <arun__> | annevk2, but we've barely started still. |
| 07:47 | <zcorpan> | Mrmil: you could send feedback to the list regarding <address> in <aside> |
| 07:48 | <arun__> | Hixie, what do you mean by [IndexGetter] is more work to use than sequence<>? You mean, instead of a typedef statement, you have to deal with the whole interface stuff? |
| 07:48 | <Mrmil> | zcorpan: Ok, will do |
| 07:50 | <Hixie> | arun__: you have to define what all the indices are and so on |
| 07:50 | <arun__> | Hixie, blah. I see your point. |
| 07:50 | <arun__> | sequence<> would have been easier. |
| 07:50 | <annevk2> | just use sequence |
| 07:50 | <annevk2> | it will be defined in the end |
| 07:51 | <annevk2> | IndexGetter and all is only needed when you need special members on the interface |
| 07:52 | <arun__> | annevk2, hmm... I'm defining an interface which exposes an array and an unsigned long. Seems like a single typdef won't do the trick; I need an interface statement. |
| 07:52 | <annevk2> | what's the unsigned long? |
| 07:53 | <annevk2> | got to run, be back in a bit |
| 07:55 | Mrmil | wonders what to do next. Another page or polish the one? |
| 07:58 | <zcorpan> | Mrmil: you could rewrite the page in xhtml2 |
| 07:59 | <Mrmil> | zcorpan: Or I can as well jump out of window. |
| 08:04 | <MikeSmith> | anybody know of a way to tell svn to ignore ssl certificate errors? |
| 08:06 | <Hixie> | arun__: if sequence<> defines an Array, then that's got your unsigned long |
| 08:07 | <arun__> | Hixie, eh? I'm talking about readonly unsigned long length; |
| 08:07 | <Hixie> | right, depending on how heycam defines sequence<>, that might come for free |
| 08:08 | <arun__> | heheh, that's a little imprecise. I'll roll with a classic interface with [IndexGetter] I think :) |
| 08:08 | <arun__> | I like sequence<> tho'. |
| 08:09 | <arun__> | I think we should get it spec'd to allow length attributes to come for free (modulo mutability) |
| 08:11 | arun__ | heads out for a brief pause |
| 08:12 | <Hixie> | yeah might be good to have a |sequence<T>| and a |readonly sequence<T>| or |[Readonly] sequence<T>| |
| 08:13 | <Hixie> | man i never have any idea what kristof is talking about |
| 08:16 | <Mrmil> | Hixie: Is it just me or does sound a little arrogant? |
| 08:17 | <Hixie> | who, kristof? |
| 08:17 | <Mrmil> | yes |
| 08:18 | <Hixie> | not compared to a lot of the traffic on the public-html list! |
| 08:18 | <Hixie> | (including my own!) |
| 08:18 | <Hixie> | i just wish he'd include context so i had any idea what he was talking about |
| 08:18 | <Hixie> | he's dramatically improved his tone since the early days |
| 08:19 | <Hixie> | which is good |
| 08:19 | <othermaciej> | bonus points to Sam for jumping on the bandwagon of "disagree == ignore" |
| 08:19 | <othermaciej> | which is kind of an arrogant way to think about things |
| 08:19 | <zcorpan> | i always typo <frameset> as <fieldset> |
| 08:19 | <Mrmil> | Hixie: Interesting :) |
| 08:20 | <othermaciej> | Kristof has sensible things to say at times but other times I get lost reading his messages |
| 08:24 | <hsivonen> | Hixie: might not hurt to put "authoring tools should default to using UTF-8 for newly-created documents" or something of that nature in the spec |
| 08:25 | <Hixie> | file a bug, suggesting where to put it |
| 08:25 | <hsivonen> | Hixie: OK. |
| 08:35 | <ojan> | Hixie: is http://dev.w3.org/html5/websockets/ the most up to date websockets draft? |
| 08:36 | <ojan> | i couldn't find a version on whatwg.org |
| 08:36 | <annevk42> | yes |
| 08:36 | <Hixie> | yes |
| 08:36 | <ojan> | thx |
| 08:36 | <annevk42> | but there's also an I-D that goes along with it |
| 08:36 | <ojan> | a wot? |
| 08:36 | <Hixie> | http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol |
| 08:37 | <annevk42> | thot /\ |
| 08:37 | <ojan> | :) |
| 08:38 | <Hixie> | you implementing? |
| 08:38 | <ojan> | Hixie: no. i have a meeting tomorrow with people who'd like to implement though. |
| 08:38 | <Hixie> | ah, cool |
| 08:39 | <ojan> | figured i should read the spec first :) |
| 08:39 | <Hixie> | :-) |
| 08:39 | <Hixie> | the text thing describes the wire protocol |
| 08:39 | <Hixie> | the w3c one defines the dom api |
| 08:39 | <ojan> | i see, i was just about to ask that |
| 08:39 | <Hixie> | (the ietf got upset that we were defining wire protocols in the w3c) |
| 08:40 | ojan | is already sick of standards politics |
| 08:43 | <hsivonen> | ojan: you probably haven't seen the hybi list yet... |
| 08:43 | <Hixie> | it's very odd having my boss post to the whatwg list |
| 08:43 | <Hixie> | not to mention dannyb, who's also on my team |
| 08:44 | <ojan> | hsivonen: no, i haven't. what is that? |
| 08:44 | <hsivonen> | ojan: I mean, reading the hybi list is an interesting dose of politics |
| 08:44 | <ojan> | ah |
| 08:44 | <hsivonen> | ojan: it's the IETF list for web socket |
| 08:44 | <hsivonen> | ojan: and for things that got lumped into the same list |
| 08:44 | <Hixie> | technically it's the IETF list for bidirectional HTTP |
| 08:44 | <Hixie> | and websocket somehow got dragged into it |
| 08:45 | <Hixie> | though most of the people there don't want it |
| 08:45 | <Hixie> | in practice if websocket is implemented, it'll become a moot issue |
| 08:45 | <MikeSmith> | Hixie: who's your boss? |
| 08:46 | <othermaciej> | I'm not sure what "bidirectional HTTP" even means |
| 08:46 | <Hixie> | chris dibona |
| 08:46 | <ojan> | Hixie: we have a number of teams asking for it |
| 08:46 | <Hixie> | othermaciej: that's part of the problem |
| 08:46 | <Hixie> | ojan: you should have seen the wave team salivating when i told them about it :-P |
| 08:46 | <othermaciej> | people seem to have all sorts of different and weird ideas about it |
| 08:46 | <othermaciej> | WebSocket is on deck for us Apple folks as one of the next WebKit features to tackle, once Safari 4 final ships |
| 08:47 | <ojan> | othermaciej: there are chromium people who plan to start working on it soon as well. i have a meeting with them tomorrow. |
| 08:48 | <othermaciej> | ojan: maybe there should be some coordination so we don't end up with duplicated efforts |
| 08:48 | <ojan> | othermaciej: totally. |
| 08:49 | <othermaciej> | (and I am remiss in not really sharing our engine feature plans, but we'll probably let webkit-dev know soonish about some of the big things we are interested in working on) |
| 08:49 | <ojan> | othermaciej: that would definitely help in our roadmap planning. |
| 08:50 | <Hixie> | should usemap="#x" require a matching id="x" or a matching name="x"? hsivonen, zcorpan, any opinions? spec says name="", but i think that's a typo |
| 08:50 | <othermaciej> | would help to hear the same from Google |
| 08:50 | <ojan> | othermaciej: are there specific webkit folk they should contact outside of webkit-dev? |
| 08:50 | <hsivonen> | Hixie: isn't name what actually works everywhere except Gecko's XML mode? |
| 08:50 | <othermaciej> | webkit-dev is probably better than contacting specific folks in any case |
| 08:51 | <hsivonen> | Hixie: I *think* I sent feedback when I last tested this, but now I can't remember what I said |
| 08:51 | <Hixie> | oh, wait, i was looking at <img name> |
| 08:51 | <Hixie> | but it should be <map name>, right? |
| 08:51 | <Hixie> | and that exists |
| 08:51 | <Hixie> | so nevermind |
| 08:51 | <Hixie> | i'm an idiot |
| 09:21 | <ojan> | Hixie: what happens with websockets if the server sends the client some data and the client closes the socket before receiving that data? |
| 09:22 | <ojan> | or, more importantly, the other way around...client sends the server data, but the server closes the socket before receiving the data |
| 09:22 | <ojan> | is there a way for the client to detect that the server never got the transmission? |
| 09:26 | <ojan> | hm...i guess TCP/IP deals with this for you so that situation isn't actually possible? namely, the packet transmission would fail |
| 09:27 | <ojan> | nevermind...it is possible. client calls postMessage, then gets disconnected from the internet. is there anyway for them to see that the server never got the postMessage data? |
| 09:28 | <Philip`> | What if the server got the message but then got disconnected from the internet itself, so it couldn't send any acknowledgement back |
| 09:28 | <Philip`> | s/$/?/ |
| 09:28 | <Hixie> | ojan: if they care, they have to have the server ack everything |
| 09:29 | <ojan> | Hixie: i see |
| 09:55 | <hsivonen> | http://www.w3.org/mid/E34714E1E6587741AD32C8E445B6F4AB01637C9D⊙dwsc is interesting |
| 10:04 | <MikeSmith> | hsivonen: I very much hope that vcs for validator.nu moves to something other than subversion eventually |
| 10:06 | jgraham | starts doing a little mercurial dance in the background |
| 10:08 | Philip` | averts his gaze in embarrassment |
| 10:09 | <jgraham> | Philip`: Just be glad I asn't doing the Git dance |
| 10:10 | <Philip`> | YAML really is a rubbish output format |
| 10:10 | <Philip`> | (probably because it's incredibly complicated, and therefore nobody implements it properly) |
| 10:11 | <Philip`> | JSON seems to work a lot better, i.e. it actually works |
| 10:11 | <hsivonen> | MikeSmith: ok. if now is the time when svn is actually a problem, I guess exploring a move to hg is now justified. |
| 10:12 | <othermaciej> | Hixie, ojan: depending on the particular case, there might be simpler ways to check than having the server ack everything |
| 10:12 | <othermaciej> | for example, the client could include a sequence number in every message, and when making a new connection to the server, the server could report the last sequence number it got |
| 10:12 | <Hixie> | indeed |
| 10:12 | <othermaciej> | TCP guarantees you won't lose just middle messages |
| 10:13 | <hsivonen> | MikeSmith: CVSDude doesn't have hg yet, so switching to hg means either bitbucket or Google. |
| 10:13 | <othermaciej> | and as long as you remain connected there's no need to ack |
| 10:13 | <othermaciej> | it's only after losing connectivity that it's possible some tail of the stream never arrived |
| 10:13 | <ojan> | yup |
| 10:13 | <hsivonen> | MikeSmith: I'll think about this and will ask fantasai after I've thought about this |
| 10:13 | <MikeSmith> | hsivonen: OK |
| 10:15 | <MikeSmith> | hsivonen: it's not an acute problem for many at the moment, since I finally managed to solve the particular problem I was having (but only after spending a good part of the afternoon trying to troubleshoot it) |
| 10:15 | <MikeSmith> | but I've found subversion to be a chronic time-waster |
| 10:16 | <hsivonen> | yeah, svn sucks once you've seen hg |
| 10:16 | <hsivonen> | svn seemed great when you had only seen cvs |
| 10:16 | <zcorpan> | contenteditable is such a mess |
| 10:16 | <hsivonen> | also, gotta check on the hg Eclipse plug-in situation |
| 10:17 | <jgraham> | zcorpan: and in other news... |
| 10:17 | <MikeSmith> | hsivonen: I find the worst thing about the svn client and library is that when I do run into problems with it, it is very time-consuming to try to troubleshoot them -- mostly because of the almost total lack of any useful error messages about what's causing the problem |
| 10:18 | <MikeSmith> | in the case of the problem I ran into today, it was because of libneon |
| 10:18 | hsivonen | has no idea what libneon is |
| 10:18 | <MikeSmith> | but there was no way I could have ever figured that out from the error output that svn was giving |
| 10:18 | <MikeSmith> | hsivonen: I didn't know what libneon was until today either |
| 10:19 | <MikeSmith> | apparently it is what subversion relies on for https |
| 10:40 | <MikeSmith> | is there some parameter I can pass to http://html5.org/tools/web-apps-tracker to make it show more than the default number of changes that it shows? |
| 10:40 | <MikeSmith> | annevk42: ↑ |
| 10:40 | <MikeSmith> | (assuming it was annevk42 who wrote the interface) |
| 10:41 | <jgraham> | MikeSmith: There is but I don't know what |
| 10:42 | <MikeSmith> | k |
| 10:42 | <Philip`> | MikeSmith: ?limit=123 |
| 10:43 | <MikeSmith> | Philip`: thanks |
| 10:43 | <Philip`> | according to http://code.google.com/p/html5/source/browse/trunk/web-apps-tracker/trackerlib.py |
| 10:43 | <annevk42> | limit |
| 10:43 | <annevk42> | you can even get infinite by using -1 |
| 10:46 | <MikeSmith> | sweet |
| 10:52 | <MikeSmith> | hsivonen: anyway, I'm very happy to help in any way I can with migration to mercurial hosting, if/when you want to migrate |
| 10:54 | <Hixie> | ok bed time |
| 10:54 | <Hixie> | nn |
| 11:18 | <hsivonen> | no <video> in Opera 10 beta, right? |
| 11:21 | <annevk42> | I don't think we'll do <video> for 10 |
| 11:21 | <hsivonen> | ok |
| 11:25 | <hsivonen> | hmm. Opera just autoupdated itself to Opera/10.00 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.1 build 6343 calling itself alpha with the old appearance |
| 11:40 | <hendry> | hmm, was hoping Opera 10 would support border-radius |
| 11:41 | <hsivonen> | I guess Alpha really means Alpha at Opera, since the engine features didn't get a trunk update between Alpha and Beta |
| 11:42 | hsivonen | wonders how many concurrent engine branches Opera has |
| 11:43 | <zcorpan> | Opera 10 alpha and Opera 10 beta both use core 2.2 which is pretty old now |
| 11:48 | <hsivonen> | I was hoping to get to a point where I could write that three out of five support Theora natively, one supports it with XiphQT and the last one has issues but has Cortado :-/ |
| 11:48 | <hsivonen> | I guess I'll have to wait until Opera 10.next |
| 11:49 | hsivonen | wonders how <video> is doing in Epiphany-WebKit |
| 12:49 | <hsivonen> | ezyang: the test case for <!DOCTYPE html><body xlink:href=foo><math xlink:href=foo></math> is now wrong |
| 12:49 | <hsivonen> | xlink:href doesn't go into the XLink namespace on HTML elements |
| 12:50 | <hsivonen> | (I'll fix) |
| 12:50 | jgraham | thought he had fixed that |
| 12:51 | hsivonen | does hg pull |
| 12:51 | <hsivonen> | ok. I had a stale local repo |
| 12:54 | <hsivonen> | hmm. the frameset tests have changed to be less WebKit-compatible |
| 12:54 | hsivonen | tests IE |
| 12:56 | <hsivonen> | I'm unable to figure out what the actual rendered effect of IE's crazy DOM would be |
| 12:56 | <hsivonen> | but the tests are now less aligned with Opera, too |
| 13:08 | <hsivonen> | why are </body> and </html> differnt in 'in head' and 'in head noscript'? |
| 13:32 | Mrmil | wonders if anyone is alive here. He added one little thing to his test page and might need a little feedback again. |
| 13:33 | <jgraham> | Everyone's dead, Dave |
| 13:33 | <Mrmil> | Auuuuu I'll eat you my little fishie... |
| 13:40 | <Mrmil> | never mind then |
| 13:40 | <annevk42> | it's easier to just post your question and later check the minutes if someone picked up on it |
| 13:40 | <annevk42> | this IRC channel works very well asynchronously from time to time |
| 13:41 | <Mrmil> | I know, I just posted it here 5 million times that I'd feel like spamming |
| 13:42 | <Mrmil> | It's here http://server.ebrana.cz/olda/_apps/html5/ and I added the little searchform in the head |
| 13:44 | <Philip`> | I don't particularly like how the search box expands when I click on it - that seems like unusual and unexpected behaviour |
| 13:44 | <Mrmil> | better now? |
| 13:45 | <Mrmil> | right, if it should do that, it should probably expand on the other side, hm hm |
| 13:46 | <Philip`> | I like it now that it doesn't surprisingly expand for no reason :-) |
| 13:46 | <Mrmil> | Ok :) |
| 13:47 | <Mrmil> | the html of it is pretty simple, there is no problem I think |
| 13:47 | <Philip`> | Hmm, does HTML 5 not have <input type=search>? |
| 13:48 | <Philip`> | Oh, it does |
| 13:48 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#text-state-and-search-state |
| 13:48 | <Philip`> | Maybe that would be appropriate for the search box? |
| 13:49 | <Mrmil> | damn, there you go, I am so used to this html that I forgot there could be even better solution. Thanks Philip, I'll fix that |
| 13:49 | <Mrmil> | I haven't really looked into the html5 forms, but it's on my list |
| 13:50 | <Philip`> | Hmm, I think <time datetime="2009-06-03T13:20:34"> is invalid |
| 13:51 | <Philip`> | If it's a date-and-time then it needs to be a global date-and-time, i.e. include timezone information |
| 13:51 | <Mrmil> | I checked that, it's valid |
| 13:52 | <Philip`> | According to the spec, or according to a possibly-buggy validator? |
| 13:52 | <Mrmil> | according to Hixie |
| 13:52 | <Mrmil> | he said it was optional |
| 13:53 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element goes to http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-date-or-time-string which goes to http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-global-date-and-time-string |
| 13:53 | <Philip`> | which says you need either Z or [+-]\d\d:\d\d |
| 13:53 | <Philip`> | Am I missing something here? |
| 14:04 | <Mrmil> | 2009-06-03T13:20:34+02:00 so this would be CET time right |
| 14:05 | <Philip`> | CET with daylight saving would be +02:00, I believe |
| 14:06 | <Mrmil> | right |
| 14:18 | <wakaba_> | MikeSmith: http://pastebin.com/f3a189e59 |
| 14:18 | <wakaba_> | my emobile connection don't have route, either... |
| 14:22 | <Mrmil> | Philip`: Whew, we have old php here, had to do it manually. Good now? <time datetime="2009-06-03T15:02:40+02:00"> |
| 14:23 | <Philip`> | Mrmil: Looks good to me, though I'm not sure why validator.nu accepts it without the timezone |
| 14:25 | <Mrmil> | Philip`: well, me neither, though it does sound weird to have the stamp without a timezone |
| 14:30 | <ezyang> | hsivonen: (stark) So... is this fine distinction between having an actual namespace and being a literal foo:bar actually what happens in browsers? |
| 14:32 | <hsivonen> | ezyang: yes |
| 14:32 | <ezyang> | Good grief |
| 14:33 | <ezyang> | It's almost as if they ignored all of the good bits of XML. |
| 14:34 | <Philip`> | The implementations existed before XML did, and then it became too late to change because of legacy content |
| 14:34 | <hsivonen> | ezyang: what would be the good bits in this case? |
| 14:34 | <ezyang> | The good bits would be consistency and namespacing. |
| 14:35 | <Philip`> | Controversial :-o |
| 14:35 | <hsivonen> | I agree about consistency. I disagree on namespacing. |
| 14:35 | <ezyang> | As a tool author, namespaces are uniformly a good thing. It's unclear about that on the browser side |
| 14:35 | <Philip`> | HTML is consistent - you parse a sequence of non-whitespace characters and use that as the attribute name, and that's it (and you don't put the attribute into any particular namespace) |
| 14:37 | <annevk42> | Where is the Google Wave desktop drag & drop API defined? |
| 14:38 | <annevk42> | I couldn't find it in the Gears documentation |
| 14:39 | <jgraham> | annevk42: Is there work going on anywhere to make that stuff work without gears? |
| 14:41 | <Philip`> | Does Hg make it possible to import an external library into my repository, apply some local patches, and then easily keep the external library up-to-date with external revisions? (I presume it's just some kind of simple merging, but I don't know enough about Hg to know if there's a specific way to make it work properly) |
| 14:42 | <jgraham> | annevk42: (e.g. in webapps since I don't really follow that) |
| 14:45 | <jgraham> | Philip`: It seems like the answer is "Maybe". There are a couple of adddsons that claim to do things like svn:externals but it's not clear if they work well or not |
| 14:47 | <annevk42> | jgraham, about as much work as work on video streaming and audio manipulation APIs |
| 14:47 | <jgraham> | annevk42: Is that a long way of saying "no but people would like it to"? |
| 14:48 | <annevk42> | jgraham, though in the Wave video Google claims they want to work on this soon |
| 14:48 | <annevk42> | jgraham, a long way of saying no work at all |
| 14:48 | <annevk42> | jgraham, but also that I think there should :) |
| 14:48 | <jgraham> | annevk42: Agreed :) |
| 14:48 | <Philip`> | jgraham: Ah, I don't want it to be automatic - I just want it to be a straightforward manual process (e.g. copy the external library's latest files, then commit it to Hg somehow, then hope that a normal Hg checkout will incorporate those latest files plus any custom patches) |
| 14:49 | <Philip`> | (presumably with some merging happening somewhere but I don't really know where) |
| 14:49 | <jgraham> | Philip`: Presumably you can just clone the original then make your changes and then pull the original changes every so often and remerge |
| 14:50 | <Philip`> | Hmm |
| 14:50 | <Philip`> | Where would the original changes be pulled from? |
| 14:51 | <jgraham> | Philip`: The VCS of the external library |
| 14:51 | <jgraham> | I guess |
| 14:52 | jgraham | feels he is missing something |
| 14:52 | <Philip`> | Can you pull from it if it's using SVN? |
| 14:53 | <jgraham> | Philip`: Yeah if you use {some random tool that lets you do that} |
| 14:53 | Philip` | doesn't really know much about this at all |
| 14:53 | <jgraham> | hgsvn maybe? |
| 14:53 | <Philip`> | Ah, okay |
| 14:53 | <jgraham> | http://www.selenic.com/mercurial/wiki/WorkingWithSubversion |
| 14:57 | <Philip`> | Sounds like it's all kind of straightforward, which is nice |
| 15:04 | <MikeSmith> | wakaba_: thanks. cause of my problem turned out to not be a routing issue but instead a debian packaging flub combined with fundamental borkedness in svn |
| 15:46 | <Hish> | hi. is there an official way how to implement svg in html5? I only know that xhtml/svg is working... |
| 15:47 | <annevk42> | you mean as an author? |
| 15:48 | <annevk42> | at some point <div> <svg> <circle /> </svg> </div> (with appropriate attributes) will work |
| 15:49 | <Hish> | without namespaces? |
| 15:51 | <Philip`> | Hish: Yes |
| 15:52 | <Hish> | ok. thx a lot. |
| 15:52 | <Philip`> | Hish: (though you'll have to wait years until you can use it reliably) |
| 15:52 | <Hish> | sure. i stick with xhtml/svg for the time being |
| 15:55 | <gsnedders> | I guess in recent browsers you can do something like changeNSElements = document.getElementsByTagName("svg").getElementsByTagName("*") and change the namespace of each element |
| 15:55 | <gsnedders> | I guess you'll have to do it for the svg element itself |
| 15:59 | <jgraham> | gsnedders: If you were a bit more clever than that you could probably implement something not too dissimmilar to the foreign content mode of the parser using js working on the post-parse tree |
| 15:59 | <jgraham> | With some restrictions like no self-closing elements |
| 16:00 | <gsnedders> | jgraham: Probably. But that's more work. :) |
| 16:00 | beowulf | subscribes to gsnedders newsletter |
| 16:01 | <gsnedders> | beowulf: Pff. Writing one is too much effort. |
| 16:02 | <jgraham> | gsnedders: It would be nice to support MathML and HTML in SVG in HTML. So you would at least want to special-case <foreignContent> |
| 16:04 | <gsnedders> | hmm… I'm not getting Opera 10 Beta as an auto-update :\ |
| 17:25 | <ezyang> | gsnedder: ping |
| 17:28 | jgraham | wishes we could just drop all the week numbering stuff from HTML5 |
| 17:50 | <gsnedders> | ezyang: Including my full nick in pings helps :P |
| 17:52 | <ezyang> | heh |
| 18:10 | <gsnedders> | I could do with some way of raising warnings in Anolis |
| 18:13 | <gsnedders> | And then do things like warn about referencing obsolete docs |
| 19:00 | <takkaria> | wow |
| 19:00 | <takkaria> | http://lists.w3.org/Archives/Public/www-tag/2009Jun/0000.html |
| 19:00 | <takkaria> | and more specifically, http://larry.masinter.net/versioning-html.html |
| 19:04 | tantek | notes that the versioning-html.html document itself lacks traditional W3C document versioning, i.e. as described/shown here: http://www.w3.org/2001/06/manual/#Errata |
| 19:04 | zcorpan | fails to resist the temptation to discuss bytes-to-DOM of XML and error handling in XML with the XML Core WG |
| 19:05 | <zcorpan> | http://lists.w3.org/Archives/Public/public-xml-core-wg/2009Jun/0009.html |
| 19:05 | <gsnedders> | zcorpan: There is fairly decent error handling dictated in the XML spec at least :P |
| 19:15 | <zcorpan> | gsnedders: but not error recovery |
| 19:30 | <gsnedders> | zcorpan: No, but it is handling :P |
| 20:09 | <zcorpan> | yay my edits on wikipedia haven't been reverted yet |
| 20:12 | gsnedders | wonders what edits |
| 20:12 | <zcorpan> | to the html5 page |
| 20:13 | <atwilson> | I'm somewhat confused about the language surrounding task sources in section 6.5.4 - in particular, if an object is no longer used as a task source for an event loop (for example, a MessagePort that has been closed, does that imply that all queued (but not yet dispatched) events for that task source are removed from the queue? |
| 20:13 | <atwilson> | Anyone know what behavior is intended? |
| 20:16 | <Hixie> | atwilson: why would that cause it to no longer be used? |
| 20:17 | <atwilson> | Ah. |
| 20:17 | <atwilson> | I read this: When a port's port message queue is open, the event loop must use it as one of its task sources. and assumed that causing close() would also close the message queue, but apparently that is not the case. |
| 20:18 | <Hixie> | nope |
| 20:18 | <Hixie> | i should probably make that clearer |
| 20:18 | <atwilson> | Close just prevents the ports from communicating with one another, but doesn't affect the open status of the queues. |
| 20:18 | <Hixie> | maybe use different words than open/close |
| 20:20 | <atwilson> | Yeah, maybe. The spec pretty clearly doesn't say that the message queue is closed - that was entirely my misreading, although I guess explicitly stating that the port message queue should be left open wouldn't be bad. |
| 20:20 | <zcorpan> | "W3C: Web Storage draft standard" - http://en.wikipedia.org/wiki/DOM_storage |
| 20:22 | <Hixie> | atwilson: i've reowrded it to say "enabled" vs" disabled" and to mention that it never goes back to disabled |
| 20:22 | <atwilson> | Hixie: OK. Note that it *does* go back to disabled if the port is cloned. |
| 20:22 | <Hixie> | actually no, it just gets emptied |
| 20:23 | <Hixie> | this has much the same effect, of course |
| 20:23 | <atwilson> | Ah, you are right again. |
| 20:23 | <Hixie> | i have an unfair advantage in that i wrote this nonsense :-) |
| 20:23 | <Hixie> | sadly i still sometimes find i wrote something that i didn't think i wrote :-( |
| 20:24 | <atwilson> | Anyhow, I like having the port never go back to disabled. Thanks for clarifying. |
| 20:25 | <Hixie> | only 850 e-mails to go to hit my OKR |
| 20:26 | <Hixie> | that's about 30 e-mails a day until the end of the month |
| 20:26 | <Hixie> | should be feasible... |
| 21:21 | <jgraham> | gsnedders: You could use the warnings module with anolis to generate warnings, maybe |
| 21:46 | <gsnedders> | jgraham: Are they not just exceptions, which would make them hard to use? |
| 21:50 | <gsnedders> | jgraham: What could PMS do with them anyway? |
| 21:50 | <gsnedders> | jgraham: I guess it could put them in a comment before the root element |
| 21:57 | <jgraham> | gsnedders: They are basically exceptions yes |
| 21:57 | <jgraham> | But higher level code can choose which ones to react to and how to deal with them |
| 21:57 | <jgraham> | Dunno if it's a good idea or not |
| 21:59 | <jgraham> | gsnedders: In particular it might be more sutiable for language/api level stuff than application level stuff |
| 22:00 | <jgraham> | For your use case it is probably a bad idea |
| 22:02 | gsnedders | orders Lightroom |
| 22:02 | gsnedders | hopes it is all right to use his father's name in the billing address (as that must be as on credit card) while doing it at the educational store in my name… |
| 22:10 | <gsnedders> | Now, phase two of spending my father's money: plane tickets to get to/from Sweden. |
| 22:12 | <gsnedders> | noooo… |
| 22:12 | <gsnedders> | flight sold out since yesterday! |
| 22:12 | <gsnedders> | Sux. |
| 22:12 | <gsnedders> | Oh, no. |
| 22:12 | <gsnedders> | Just Ryanair website maybe broken… |
| 22:13 | <gsnedders> | I should probably be using a released web browser… |
| 22:22 | <gsnedders> | Yay. Ryanair is awesome. Buying single plane tickets you have to buy them one at a time. |
| 22:34 | <jgraham> | gsnedders: Their website is intentionally crap to make you think that they are cheap |
| 22:34 | <gsnedders> | jgraham: They're cheaper than Flyglobespan at least :D |
| 22:35 | <gsnedders> | (Which is a similar low-cost airline) |
| 22:35 | <jgraham> | hsivonen: Does the change to the test with <body><frame></frame></frame><frameset> reflect some anticipated change in the spec or can I not read? |
| 22:35 | <gsnedders> | Oh, fun fact: last October I flew from Edinburgh to Paris by Air France because it was cheaper than flying by EasyJet |
| 22:36 | <jgraham> | AFAICT the only way to set the frameset-OK flag to true is by not having an explicit <body> |
| 22:36 | <jgraham> | Although it is too late and I am too tired for me to try reading the spec properly, so I could be wrong |
| 22:37 | <jgraham> | gsnedders: I bet Ryanair are much much worse. They are much worse than EasyJet |
| 22:37 | <gsnedders> | jgraham: Indeed. |
| 22:38 | <gsnedders> | jgraham: My flight from Nice to Edinburgh on Flyglobespan, a apparently low-cost airline cost something like £120 |
| 22:42 | <gsnedders> | Sadly, however, Ryanair is the only airline that flies the routes I need this summer. |
| 22:42 | <gsnedders> | STN–NYO: 73.26 GBP |
| 22:42 | <gsnedders> | NYO–SXF: 220 SEK |
| 22:42 | <gsnedders> | SXF–STN: 25 EUR |
| 23:00 | <hober> | Mr. Last Week must be disappointed that http://www.google.com/squared/search?q=WHATWG+teamsters doesn't result in anything. |
| 23:02 | <Philip`> | http://www.google.com/squared/search?q=html5+elements - hmm |