| 01:23 | <nattokirai> | bz: ping |
| 01:33 | <sgentle> | hi there |
| 01:33 | <sgentle> | is there a reasonable way to keep a reference to a set of elements in the DOM? Eg, if I had <ul><div /><li /><li /><div /></ul> and I wanted to keep a reference to the <li>s such that I could add another one at the end (or the start, or the middle), and the reference would stay valid even if extra nodes were added or removed around it? I think I basically want something like a documentFragment that is actually in the document |
| 01:55 | <roc> | what's wrong with just holding references to the nodes? |
| 02:04 | <sgentle> | gets a bit messy if you remove the last node and add it again |
| 02:04 | <sgentle> | (i.e., what do I anchor to if I have an empty list?) |
| 02:04 | <sgentle> | I'm poking around with Range, which looks promising |
| 02:05 | <sgentle> | (although, as always, browser support is a desolate wasteland of broken dreams) |
| 02:10 | <zewt> | a "reference" to an empty list is usually just null |
| 07:08 | <hsivonen> | AryehGregor: Dunno what the story with serialization is exactly. Maybe I should implement it for Firefox to make innerHTML work faster. |
| 08:11 | <zcorpan> | ok so what should happen if http://example.org embeds http://foo.example.org and they both set document.domain to example.org, then the outer page does <body onload="window[0].document.write('foo')"> ? what's the origin of the inner document? |
| 08:14 | <zcorpan> | afaict from the spec the origin doesn't change as a result of hte document being blown away |
| 08:15 | <zcorpan> | or, wait |
| 08:18 | <zcorpan> | argh |
| 10:25 | <smaug____> | hsivonen: curious, how stable is outerHTML, or how well do browsers implement it |
| 10:25 | <smaug____> | in other words, should I read the spec and file spec bugs :) |
| 10:26 | <smaug____> | Where is Ms2ger |
| 10:31 | <annevk> | hober: good news, the beer survived! |
| 10:49 | <hsivonen> | smaug____: I implemented the spec. Chrome and Opera 12 alpha seemed to implement the spec |
| 10:49 | <hsivonen> | smaug____: IE has implemented it for ages, but in IE, edge cases are weird |
| 10:50 | <hsivonen> | smaug____: edge cases being cases where the context node is something particularly special |
| 10:50 | <smaug____> | hsivonen: you mentioned something about body context yesterday |
| 10:51 | <hsivonen> | smaug____: no, I mentioned setting outerHTML on body, which makes html the context node for the fragment parsing algorithm |
| 10:51 | <hsivonen> | smaug____: that case works the same in Chrome, Opera 12 and (with the patch) Firefox |
| 10:51 | <hsivonen> | smaug____: the result is even logical in its own way even if counter-intuitive |
| 10:52 | <smaug____> | yeah, I meant using outerHTML on body |
| 10:52 | <hsivonen> | smaug____: it fails enough in IE that I don't expect anyone to assign to outerHTML on body anyway |
| 10:53 | <hsivonen> | smaug____: I think we shouldn't worry about the counter-intuitiveness and we should just do what the spec already says and what Opera 12 and Chrome already do |
| 10:53 | <jgraham> | hsivonen: We had a bug where people were assigning outerHTML on <html> |
| 10:53 | <smaug____> | hsivonen: what about DocumentFragment |
| 10:53 | <jgraham> | (it was dark-matterish though) |
| 10:53 | <smaug____> | it is *very* surprising to see <body> created automatically |
| 10:53 | <hsivonen> | smaug____: I made it work per spec |
| 10:54 | <jgraham> | smaug____: You mean <head>? |
| 10:54 | <smaug____> | I mean <body> |
| 10:54 | <hsivonen> | smaug____: in the document fragment case, the body node is only a fictional context node. it doesn't show up in the output |
| 10:54 | <hsivonen> | smaug____: you need to read the spec sentence very carefully |
| 10:55 | <hsivonen> | smaug____: italic parent and upright parent are different nodes |
| 10:55 | <hsivonen> | jgraham: does setting outerHTML on html do something reasonable in IE? |
| 10:56 | <hsivonen> | which reminds me that I should participate in the public-webapps thread and explain why tweaking fragment parsing is harder than it seems |
| 10:57 | <jgraham> | hsivonen: I don't think so |
| 10:57 | <jgraham> | It used to in Opera |
| 10:57 | <jgraham> | hsivonen: What is hard? |
| 10:58 | <hsivonen> | jgraham: DWIM without a context node so that *everything* works intuitively |
| 10:58 | <smaug____> | hsivonen: yes, please, comment something in the webapps |
| 10:58 | <hsivonen> | smaug____: oh, in the patch, I didn't try to make the optimization for parsing directly into the context node |
| 10:59 | <hsivonen> | smaug____: I figured that there are enough ways for the circumstances to prevent the optimization from working |
| 10:59 | <hsivonen> | smaug____: so it would be a premature optimization |
| 10:59 | <jgraham> | hsivonen: Any particular subset of everything you have in mind as being hard? |
| 11:00 | <smaug____> | hsivonen: yeah, we can optimize later |
| 11:00 | <hsivonen> | smaug____: I think we shouldn't optimize unless we later see a lot of perf-critical outerHTML use that would benefit from parsing directly to the context node |
| 11:00 | <hsivonen> | smaug____: ok |
| 11:00 | <smaug____> | hsivonen: I'll do some profiling later |
| 11:02 | <hsivonen> | jgraham: suppose you want a DWIM mode where <html>, <head>, <body>, <tbody>, <tr>, <td>, <g>, <mi>, etc. all do whatever the person invoking the parser intended |
| 11:03 | <hsivonen> | jgraham: in that case, you'd have to support <html> creating an node and enforcing the usual rules for its children *except* after </html>, it would have to allow siblings |
| 11:03 | <hsivonen> | jgraham: for no use cases--just for logic and completeness |
| 11:03 | hsivonen | goes read the public-webapps thread |
| 11:03 | <jgraham> | Why woulod it have to? |
| 11:04 | <hsivonen> | jgraham: for completeness |
| 11:04 | <hsivonen> | jgraham: otherwise, we'd end up cherry-picking magic modes for some hard tags but not others |
| 11:04 | <hsivonen> | jgraham: maybe we'll end up making a partially magic mode |
| 11:04 | <jgraham> | I mean if you do <html>{stuff}</html>{more stuff} in the contextless mode I would expect it to be like passing that to the HTML parser |
| 11:05 | <hsivonen> | jgraham: that's because you've done QA on an HTML parser! |
| 11:06 | <jgraham> | Well maybe :) But it doesn't seem particularly illogical |
| 11:06 | <hsivonen> | jgraham: btw, any word on the "Mobi" string? |
| 11:06 | <jgraham> | Much less than outerHTML |
| 11:07 | <jgraham> | hsivonen: Nothing definitive, there were suggestions that many combinations of the words "Opera" and "Mobile" including them individualy had been problematic on at least some sites |
| 11:08 | <hsivonen> | jgraham: thanks |
| 11:08 | <Ms3ger> | smaug____: at your service |
| 11:08 | <jgraham> | Argh it's the evil twin |
| 11:12 | <annevk> | 1.5 times as evil |
| 11:13 | <smaug____> | Ms3ger: hsivonen already answered |
| 11:25 | <zcorpan> | annevk: why doesn't https://bitbucket.org/annevk/webvtt/issues/query have issue tracking enabled? |
| 11:26 | <annevk> | prolly default |
| 11:30 | <zcorpan> | can you flip a switch? |
| 11:32 | annevk | flips and succeeds |
| 11:32 | <zcorpan> | thanks |
| 11:32 | <smaug____> | annevk: which all callbacks use handleEvent? EventListener, some GeoLocation stuff, but what else? |
| 11:33 | <smaug____> | Apparently FunctionStringCallback, but that can and should be changed |
| 11:33 | <smaug____> | and so should NavigatorUserMediaSuccessCallback |
| 11:33 | <smaug____> | aha |
| 11:33 | smaug____ | files spec bugs |
| 11:33 | <annevk> | BlobCallback |
| 11:33 | <annevk> | there's quite a few |
| 11:34 | <smaug____> | all the ones in HTML spec can be changed |
| 11:34 | <annevk> | there were some more according to people working on Chromium |
| 11:34 | <annevk> | still seems like a pretty silly idea to me |
| 11:34 | <smaug____> | what? |
| 11:35 | <smaug____> | to not use handleEvent everywhere? |
| 11:35 | <smaug____> | it is silly to have badly named methods in interfaces |
| 11:35 | <annevk> | just having function seems fine to me actually |
| 11:36 | <annevk> | these are a lot of extra methods you would have to learn in theory and they will likely almost never end up getting used |
| 11:36 | <smaug____> | "you would have to learn" ? |
| 11:36 | <smaug____> | who would have to learn |
| 11:37 | <annevk> | authors |
| 11:37 | <smaug____> | if web dev doesn't use {} syntax, he doesn't need to care about the method names |
| 11:37 | <annevk> | if they care about the non-function model at all |
| 11:37 | <annevk> | which seems unlikely |
| 11:37 | <smaug____> | {} is used pretty often for event listeners |
| 11:38 | <annevk> | I never encountered it |
| 11:38 | <annevk> | but I haven't done any research |
| 11:46 | <hsivonen> | smaug____: ok. I responded to the public-webapps thread |
| 11:51 | <jgraham> | hsivonen: Agreed that svg and mathml fragments might be problematic |
| 11:54 | <annevk> | fwiw |
| 11:54 | <annevk> | yehuda submitted a patch to the bug ms2ger filed for the HTML parsing algorithm |
| 11:54 | <annevk> | I guess that outlines his expectations |
| 11:54 | <hsivonen> | annevk: URL? |
| 11:56 | annevk | tries to find it |
| 11:58 | <annevk> | hsivonen: http://www.w3.org/Bugs/Public/show_bug.cgi?id=14694 |
| 11:59 | <hsivonen> | annevk: thanks |
| 12:04 | <jgraham> | That patch doesn't actually work does it? |
| 12:04 | <jgraham> | e.g. <tr><caption> |
| 12:04 | <jgraham> | Uh, bad example |
| 12:05 | <smaug____> | hsivonen: would it make sense to have some kind of innerHTML like method which had context node as a parameter |
| 12:06 | <zcorpan> | like createContextualFragment? |
| 12:06 | <smaug____> | that way svg/mathml could be handled somewhat sane way, |
| 12:06 | <smaug____> | zcorpan: something like that, but createContextualFragment is insane |
| 12:06 | <smaug____> | :) |
| 12:07 | <smaug____> | it is really silly that one needs to create and initialize a range object to get right context node |
| 12:07 | <jgraham> | (well actually not that bad an example, since that would crash I think) |
| 12:12 | <jgraham> | Umm, ignore me, I am being silly |
| 12:20 | <smaug____> | DocumentFragment parseHTML(DOMString aData, [optional] Element aContext) |
| 12:20 | <smaug____> | in Document |
| 12:20 | <smaug____> | or, in each element, but without optional parameter |
| 12:22 | <zcorpan> | innerHTML already has context |
| 12:23 | <hsivonen> | smaug____: the API that takes a DOM node as a context is innerHTML |
| 12:24 | <hsivonen> | smaug____: except the result holder is the same node, not a separate DocementFragment |
| 12:24 | <smaug____> | right |
| 12:24 | <hsivonen> | I think we should add innerHTML, outerHTML and insertAdjacentHTML to SVG and MathML nodes, too. |
| 12:25 | <smaug____> | hsivonen: I'm thinking about sane replacement to createContextualFragment. |
| 12:25 | <hsivonen> | smaug____: would it mark scripts as "already started" or not? |
| 12:26 | <smaug____> | bah. Why do you need to ask difficult questions |
| 12:26 | <hsivonen> | smaug____: I suppose we could have document.createContextualFragment(markup, contextLocal, contextNS) |
| 12:27 | <hsivonen> | smaug____: where omitting contextNS would default to the XHTML namespace |
| 12:27 | <hsivonen> | smaug____: and omitting both contextLocal and contextNS would do Yehuda's DWIM |
| 12:28 | <hsivonen> | or document.parseFragment to have a shorter name |
| 12:28 | <hsivonen> | and to avoid using the same name as a crazy feature |
| 12:35 | <jgraham> | document.parse would be a better name |
| 12:36 | <jgraham> | Nameing in the DOM was one of the things that all the js people were complaining about |
| 12:37 | <smaug____> | js or jQuery or who ;) |
| 12:41 | <hsivonen> | smaug____: Alex Russell in particular. |
| 13:09 | <annevk> | zcorpan: thanks for filing the WebVTT issues |
| 13:09 | <annevk> | zcorpan: I think I'm not going to work much until Monday so if you want to write patches... otherwise I'll get to it |
| 13:10 | <zcorpan> | k |
| 13:18 | <zcorpan> | annevk: i tried pushing a change. it said auth failed |
| 13:19 | <annevk> | try again |
| 13:20 | <zcorpan> | bb/acl: zcorpan is allowed. accepted payload. |
| 13:21 | <zcorpan> | i get an ugly username. oh well |
| 13:22 | <annevk> | way ahead of you |
| 13:23 | <zcorpan> | aah! thanks |
| 13:41 | <zcorpan> | hmm. settings parser looks scary. i'll leave that one for now :) |
| 13:44 | <zcorpan> | annevk: dom api doesn't expose linePosition auto value. (returns 0 instead.) should we get the spec changed to expose it? |
| 13:47 | <annevk> | zcorpan: if the API only exposes the computed value that does not seem necessary |
| 13:49 | <Philip`> | AryehGregor: If you still want a free Word, you could buy a new computer with Office Start 2010 on it (http://www.microsoft.com/oem/en/products/office/pages/office_2010_starter.aspx) |
| 13:49 | <davidb_> | t |
| 13:55 | <zcorpan> | annevk: it'd be nice if the dom api and your parser's api were consistent so it's easy to compare the output |
| 13:57 | <zcorpan> | annevk: also, i think it would be good to be able to set linePosition to "auto" in the dom api |
| 13:58 | <annevk> | maybe it should be made nullable |
| 14:05 | <Philip`> | (s/Start/Starter/) |
| 14:06 | jgraham | wonders how Philip` manages to collect quite so much correct-but-useless information |
| 14:07 | <annevk> | are you still working on your thesis Philip`? |
| 14:10 | <Philip`> | jgraham: Actually I didn't know about it until half an hour ago when looking at new laptops |
| 14:11 | <Philip`> | annevk: No, it's all written and submitted now |
| 14:37 | <annevk> | so how can webperf specs go to CR exactly? |
| 14:37 | <annevk> | http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PerformanceTimeline/Overview.html says entryType returns unsigned short but specs define DOMString values for it |
| 14:37 | <annevk> | const DOMString is going to be removed |
| 14:49 | <jgraham> | annevk: I get the impression WebPerf is the new D3E |
| 14:52 | <smaug____> | :) |
| 14:58 | <smaug____> | jgraham: NavigationTiming was in CR when it was still very much unimplementable |
| 15:15 | <hsivonen> | annevk: as part of your XHR testing and speccing, did you test if engines other than Gecko support multipart responses in XHR? |
| 15:15 | <hsivonen> | (the only test case I have at hand is entangled in mochitest) |
| 15:19 | <annevk> | afaik only Gecko does it |
| 15:34 | <smaug____> | hsivonen: http://mozilla.pettay.fi/post_multipart_test.html is an old test |
| 16:17 | <gsnedders> | Philip`: So what are you doing now? |
| 16:18 | <jgraham> | gsnedders: Shopping for a laptop by the sound of it |
| 16:50 | <annevk> | http://blog.whatwg.org/weekly-tpac-2011 |
| 16:50 | <annevk> | featuring tantek's <time> proposal |
| 16:58 | <AryehGregor> | Philip`, I have trouble understanding advice of the form "If you want a free X, you could buy Y." It doesn't seem internally consistent. |
| 17:01 | <zewt> | if you want a free phone, just sign this $2000 contract! |
| 17:04 | <jgraham> | AryehGregor: It seems to depend on whether the value to you of Y is greater than the cost of Y. If it is you could indeed regard X as free. |
| 17:04 | <jgraham> | (or equal to) |
| 17:04 | <AryehGregor> | jgraham, no, you're just getting a discount on both X and Y. |
| 17:06 | <jgraham> | I'm not sure why. If you have no interest in X but get it anyway, why would you regard that as a discount on X? |
| 17:06 | <AryehGregor> | Well, in any event, you're not getting X for free. You're getting X and Y in exchange for money. |
| 17:06 | <AryehGregor> | You might not care that you're getting X, and might be willing to pay the same amount for Y alone. |
| 17:07 | <AryehGregor> | But you're still only getting X in exchange for money, whatever else you get along with it. |
| 17:07 | <AryehGregor> | So it's not free. |
| 17:09 | tantek | is on the HTML-WG call |
| 17:09 | <tantek> | hgroup is not closed - due to being reopened/extended |
| 17:09 | <tantek> | what are various whatwg opinions on hgroup? |
| 17:10 | AryehGregor | doesn't care |
| 17:10 | <annevk> | "no change" |
| 17:12 | <tantek> | annevk, would you be opposed to altering (as in dropping) hgroup's presentational effects (e.g. on an automatically generated TOC - leave it up to the UA rather than specifying it) ? |
| 17:12 | <annevk> | not really, that's always up to the UA anyway |
| 17:12 | <tantek> | that's been the biggest problem with it in my opinion |
| 17:13 | tantek | is unable to get on w3c irc from his current location for some reason. :/ |
| 17:13 | <annevk> | are there any meaningful implementations for that yet? |
| 17:13 | <tantek> | not AFAIK |
| 17:13 | <tantek> | which is another good reason to drop that bit from the spec |
| 17:13 | <annevk> | tantek: you can use either http://irc.w3.org/ or irc://irc.w3.org:6665/ |
| 17:13 | <annevk> | (the former is a web interface) |
| 17:14 | <tantek> | aha - thanks for the web interface |
| 17:19 | jgraham | has the opinion that you should encourage people to have conf. calls |
| 17:20 | <jgraham> | *shouldn't |
| 17:20 | <annevk> | heh |
| 17:20 | <annevk> | the HTML WG is going to do a revert via MikeSmith |
| 17:20 | <annevk> | poor MikeSmith |
| 17:20 | <MikeSmith> | woe is me |
| 17:20 | <annevk> | are they going to install MikeSmith as editor next? |
| 17:20 | <annevk> | dial in |
| 17:20 | <annevk> | and find out next week, in the HTML WG teleconference |
| 17:23 | <tantek> | wow that was fast - just 25 min for the telcon |
| 17:23 | <jgraham> | tantek: I think that something with the semantic of <hgroup> is needed. I care less whether it is spelled <hgroup> or <hsub> or whatever |
| 17:23 | <tantek> | jgraham, opinion appreciated. |
| 17:23 | <jgraham> | Assuming they cover the same use cases |
| 17:23 | <tantek> | I tend to prefer avoiding namesmithing/bikeshedding, especially for things which have been in a spec for a while |
| 17:24 | tantek | would rather tweak/fix hgroup than introduce new element(s). |
| 17:24 | <jgraham> | Which they don't, quite, but it is unclear that the differences are important |
| 17:24 | <tantek> | agreed. |
| 17:24 | <karlcow> | I would prefer an attribute. hsub looks like an annotation. But really I do not care that much as in I didn't find any practical use for it |
| 17:24 | <tantek> | karlcow, why prefer an attribute? |
| 17:24 | <karlcow> | s/hsub looks/hsub content looks/ |
| 17:25 | <tantek> | and what attribute on what element(s)? |
| 17:26 | <annevk> | since when do we use attributes for semantics? |
| 17:26 | <tantek> | annevk, re: http://blog.whatwg.org/weekly-tpac-2011 |
| 17:26 | <karlcow> | tantek: an attribute because I don't see it only attached to headers. In case it makes sense (which I have doubt) to copy newspaper, magazine, there is always this kind of excerpt of bold text separating sections which looks like a bit the subtitle thing |
| 17:26 | <jgraham> | annevk: Since <input>? |
| 17:26 | <tantek> | s/support for years, months, birthdays lacking a year, and durations/support for years, months, birthdays lacking a year, timezones, and durations |
| 17:26 | <tantek> | jgraham - the input type morphing semantics have largely been admitted to be a design error |
| 17:27 | <tantek> | karlcow - it sounds like you're talking about a different use-case than hgroup |
| 17:27 | <tantek> | hgroup is quite narrowly defined for specific use-cases and I think it's good to keep it that way |
| 17:27 | <jgraham> | Well yes, but the question wasn't "was it a good idea?" |
| 17:27 | <karlcow> | tantek: possible. I didn't find usage of hgroup I guess. |
| 17:28 | <tantek> | jgraham, I think annevk meant that statement in a forward-looking manner ;) |
| 17:28 | <jgraham> | In the case of input, it is unlikely that we would have been able to easily introduce new input types as new elements, so that case isn't clearcut |
| 17:28 | karlcow | is dire need of things to markup people (authors, etc.) more than hgroup. :) |
| 17:28 | <jgraham> | But I agree in general the idea of an attribute doesn't sound great |
| 17:28 | tantek | has a spec that karlcow might be able to use to markup people. ;) |
| 17:30 | <karlcow> | <person class="auteur">tantek</person> has a <cite>spec</cite> |
| 17:31 | <karlcow> | <livingthing class="person"> if we want to be meta :p |
| 17:31 | jgraham | runs away |
| 17:31 | <Ms2ger> | <thing livingstate=living class=person>? |
| 17:31 | <dglazkov> | good morning, Whatwg! |
| 17:31 | <karlcow> | hehe |
| 17:32 | <tantek> | karlcow - nice HTML 3.0 you got there |
| 17:32 | <karlcow> | <person> <time> <location> and we can do a lot of things |
| 17:32 | tantek | notes that HTML 3.0 had <person> |
| 17:33 | <wilhelm> | <location> would be very nice. |
| 17:33 | <tantek> | karlcow - in practice, location markup has been problematic |
| 17:33 | <tantek> | in terms of data quality etc. |
| 17:33 | <tantek> | e.g. meta icbm stuff has been a disaster of inaccuracy |
| 17:33 | <karlcow> | I like the stance of flickr on that |
| 17:33 | <tantek> | so it's not clear we know how to design a good location element yet |
| 17:33 | <tantek> | based on data from past 10+ years of attempts to markup location |
| 17:33 | <karlcow> | aaron straup cope/flickr about areas and geoid |
| 17:34 | <tantek> | adr/geo microformats have had some success, but lat/long confusion (swapping, signs) continues to be an issue |
| 17:35 | karlcow | likes loose models |
| 17:35 | <tantek> | karlcow - do you have a <location> brainstorm written up on a wiki page? would love to know your next level down thoughts on that. |
| 17:35 | <tantek> | karlcow - that's perhaps TMI |
| 17:35 | <karlcow> | nope :) I don't think I have written things or maybe a long time ago on my blog in French. |
| 17:35 | <karlcow> | Could try to dig it |
| 17:36 | <zewt> | seems like you could never really get lat/long wrong (without noticing it) if it was actually being used |
| 17:36 | <karlcow> | TMI in american context maybe ;) |
| 17:36 | <Philip`> | AryehGregor: You might be wanting to buy a Y in any case, and you'd be getting a X with it even if you didn't want it, so if you do want it then it's a bonus for no extra cost |
| 17:36 | <zewt> | if you're in the US and you post something and a map opens on the side showing australia, something's amiss :) |
| 17:37 | <tantek> | zewt +1 |
| 17:37 | <Philip`> | gsnedders: Various bits and pieces, and vaguely trying to think about getting a proper job |
| 17:37 | <AryehGregor> | Philip`, something that you can get only in exchange for money is not free no matter how you slice it, except in marketing-speak. Just because it's a good deal doesn't mean it's free. |
| 17:38 | <tantek> | I think you can get entropy for free. |
| 17:39 | <AryehGregor> | It's possible in principle to produce arbitrarily large quantities of entropy while doing arbitrarily small quantities of work, yes. |
| 17:39 | <Ms2ger> | And bad APIs |
| 17:39 | <zewt> | you get entropy by default :) |
| 17:39 | <AryehGregor> | Sadly, someone normally has to be paid to come up with even bad APIs. |
| 17:40 | <karlcow> | http://code.flickr.com/blog/2009/10/19/small-bridges-to-proximate-spaces/ |
| 17:42 | <zewt> | your ipv6 is leaking |
| 17:43 | <MikeSmith> | <time> revert is done |
| 17:43 | <MikeSmith> | Laissez les bons temps rouler |
| 17:43 | <MikeSmith> | I'll send a message to the list |
| 17:43 | <karlcow> | http://www.archimuse.com/mw2009/papers/cope/cope.html |
| 17:43 | <annevk> | I wonder whether it'll go the way of the dodo |
| 17:43 | <annevk> | aka the <canvas> 2D spec |
| 17:44 | <karlcow> | you need <time> for the soup flavor |
| 17:47 | karlcow | likes that dodo in French means sleep |
| 17:56 | <Philip`> | AryehGregor: I suppose an alternative way to view is that if you have recently bought a Windows computer or know someone who has, that computer may well have a version of Office that you can legitimately use for no further cost |
| 17:56 | <AryehGregor> | Yes, that's valid. |
| 17:58 | Ms2ger | pokes Philip` towards W3C bugzilla |
| 18:00 | <Ms2ger> | I wonder who Shelly is going to replace Hixie with |
| 18:14 | <AryehGregor> | Ms2ger, don't be silly. Specs are made by the community, not individuals. HTML5 is no different from HTML 4.01, and we didn't need Hixie for that. The important thing is that everyone gets to decide together what will happen, not that there's anyone to actually do it. That part will naturally take care of itself. |
| 18:14 | Ms2ger | would enjoy sitting back and watching |
| 18:15 | <AryehGregor> | We already did, it was called XHTML2. |
| 18:15 | annevk | needs to get some party snacks |
| 18:15 | Ms2ger | passes annevk some popcorn |
| 19:00 | <AryehGregor> | Nice, now MikeSmith has to do merge conflict resolution, in CVS no less. Will he be asked to hand-revert the change every time Hixie updates the spec from now on? |
| 19:01 | AryehGregor | watches with interest |
| 19:01 | AryehGregor | really doubts there are no merge conflicts with subsequent changes, since it must have touched a ton of things to remove an element |
| 19:02 | <AryehGregor> | The date will conflict, at the very least. |
| 19:02 | <annevk> | hopefully for MikeSmith he is either in a bar or in bed given the time in Tokyo |
| 19:02 | <Ms2ger> | A bar is probably a better path |
| 19:02 | <Ms2ger> | Path? Guess |
| 19:02 | <annevk> | I know the path |
| 19:03 | annevk | has seen the bar |
| 19:04 | <wilhelm> | Where is the bar? Shinjuku Ni-chōme? |
| 19:05 | <annevk> | somewhere in nishishinjuku |
| 19:06 | <AryehGregor> | WebKit has no window.Selection . . . |
| 19:16 | <Hixie> | lol, the htmlwg chairs are funny |
| 19:16 | <Hixie> | i feel bad for mike |
| 19:18 | <annevk> | Ms2ger: I thought we knew it broke jQuery already and were waiting for sicking or some such? |
| 19:19 | <Ms2ger> | Were we? |
| 19:19 | <sicking> | you were? |
| 19:19 | <Ms2ger> | I'm waiting for sicking, but that's for reviews ;) |
| 19:19 | <annevk> | Ms2ger: sicking: guess not :) |
| 19:19 | <annevk> | I like how you fixed it |
| 19:20 | <Ms2ger> | Oh? |
| 19:20 | <annevk> | hehe, MikeSmith tweeting in Dutch |
| 19:20 | <annevk> | Ms2ger: keeping node document sane for document |
| 19:20 | <Ms2ger> | Yeah |
| 19:21 | <Ms2ger> | I think we use node document for documents in the spec |
| 19:23 | <AryehGregor> | What's correct behavior for http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1253 ? I assume it's iframe1, iframe2, body, which is what IE9 and Firefox 9.0a2 do. Chrome 16 dev and Opera 12.00 do iframe1, body, iframe2 (second iframe doesn't block the load event). |
| 19:27 | <AryehGregor> | If I just add an iframe dynamically, not from another iframe's onload handler, it does correctly block the load event in WebKit too. |
| 19:27 | <AryehGregor> | But if I add a second iframe from the first iframe's onload handler, the second one only blocks the load event in some browsers. |
| 19:31 | AryehGregor | works around it by using setup({explicit_done: true}) |
| 19:54 | <AryehGregor> | Do implementations ever actually throw TypeErrors? |
| 19:54 | <AryehGregor> | I assume so, but in what cases? |
| 20:00 | <AryehGregor> | Ah, IE9 does. Nice. |
| 20:02 | <Ms2ger> | We do for pure JS, but not yet for DOM stuff |
| 20:03 | <AryehGregor> | Good to know. |
| 20:03 | <AryehGregor> | Everyone but Gecko seems to return 0 across the board for the length property of DOM methods. |
| 20:04 | <AryehGregor> | At least the ones I've looked at. |
| 20:04 | <AryehGregor> | Gecko matches WebIDL and returns the minimum number of allowed arguments. |
| 20:04 | <AryehGregor> | (or whatever it's supposed to be; I'm mostly dealing with methods that have a fixed number of arguments) |
| 20:05 | <TabAtkins> | annevk: Yeah, using some script is trivial, but it's silly to do that when there's an element for the job. |
| 20:06 | <TabAtkins> | annevk: Plus the use-case for closing it is really minor in the first place. |
| 20:07 | <annevk> | "path of least resistance" was key, you could've been done already ;) |
| 20:07 | <annevk> | of course, if you want to make this work with <details>, why not, I don't really care |
| 20:14 | <annevk> | nn |
| 20:14 | <Ms2ger> | nn |
| 20:15 | annevk | hopes to wake up around six-sevenish |
| 20:15 | <Ms2ger> | That's not something I usually hope |
| 20:15 | <annevk> | me neither, but jetlag + going to bed real early makes it reasonable |
| 20:18 | <AryehGregor> | Hmm. What should getSelection() return when called on a Document with null defaultView? |
| 20:18 | <AryehGregor> | IE and Gecko seem to return the Selection for its window anyway, while WebKit returns null. |
| 20:19 | <AryehGregor> | How do I refer to the window corresponding to an object? Like, the window that has its interface and so on? |
| 20:21 | <AryehGregor> | No, better yet, IE returns a different Selection object entirely. |
| 20:21 | <AryehGregor> | Fun. |
| 20:21 | <Ms2ger> | new Image() probably has some wording for that |
| 20:25 | <AryehGregor> | jgraham, are assert_inherits and assert_idl_attribute exactly the same thing? |
| 20:25 | <AryehGregor> | Also, did you ever review my testharness.js patch? |
| 20:31 | <AryehGregor> | "If the [NoInterfaceObject] extended attribute was not specified on the interface, then the interface prototype object must also have a property named “constructor” with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } whose value is a reference to the interface object for the interface." |
| 20:31 | <AryehGregor> | That implies that Foo.prototype.constructor === Foo for any WebIDL interface, right? |
| 20:33 | <Ms2ger> | Sounds right |
| 20:33 | <AryehGregor> | Works in IE, not in Gecko. |
| 20:33 | <AryehGregor> | Also works in WebKit. |
| 20:33 | <Ms2ger> | Then it must be wrong ;) |
| 20:33 | AryehGregor | looks for other things to test |
| 20:34 | <AryehGregor> | Object.getPrototypeOf(), fun. |
| 20:34 | AryehGregor | tests that |
| 20:37 | <roc> | that might be fixed for NodeList in Gecko |
| 20:37 | <AryehGregor> | What in WebIDL defines that interface objects are own properties of the global object, and not inherited? |
| 20:40 | <Ms2ger> | For every interface that is not declared with the [NoInterfaceObject] extended attribute, a corresponding property MUST exist on the interfaces relevant namespace object. |
| 20:40 | <Ms2ger> | http://dev.w3.org/2006/webapi/WebIDL/#es-interfaces |
| 20:40 | <AryehGregor> | And it's just an own property by default? |
| 20:43 | <Ms2ger> | Could be clarified, I guess |
| 20:43 | <Ms2ger> | heycam|away, ^ |
| 20:46 | <AryehGregor> | Hmm, we need an assert_interface. |
| 20:46 | <AryehGregor> | I should write that. |
| 20:48 | <AryehGregor> | jgraham, if you aren't going to review my patches when I submit them on Bugzilla, and nor is anyone else, I'm just going to have to keep committing them directly to hg. |
| 20:48 | <AryehGregor> | I mean, when I do that, at least we make some progress. |
| 20:50 | <jgraham> | AryehGregor: I haven't seen the email |
| 20:51 | <jgraham> | This may be my fault |
| 20:51 | <AryehGregor> | jgraham, I filed it on October 28 and pinged you about it here at least a couple of times. http://www.w3.org/Bugs/Public/show_bug.cgi?id=14589 |
| 20:51 | <AryehGregor> | I'm happy to do review-then-commit, but there has to actually be timely review. |
| 20:54 | <jgraham> | AryehGregor: It looks OK, I think |
| 20:54 | <AryehGregor> | jgraham, thanks. |
| 20:54 | <AryehGregor> | I'll commit it. |
| 20:54 | AryehGregor | is currently working on an assert_interface method, though, so will get to that later |
| 20:57 | <jgraham> | I hate reviewing without a proper tool |
| 20:57 | <jgraham> | What will assert_interface do? |
| 21:11 | <AryehGregor> | jgraham, assert that something follows everything WebIDL says about interfaces. |
| 21:11 | <AryehGregor> | E.g., assert_interface("Selection", {options:...}, "desc . . ."); |
| 21:11 | <AryehGregor> | So far IE and Opera match spec, everyone else gets something wrong. |
| 21:12 | <AryehGregor> | Gecko has no .prototype.constructor, WebKit stringifies the interface object incorrectly. |
| 21:13 | <AryehGregor> | Tests are far more fun to write than specs! |
| 22:02 | <heycam> | Ms2ger, I think it's clear, but it'll become even clearer once modules are removed (and then the "interface's relevant namespace object" bit will be replaced by something like "ECMAScript global object") |
| 23:06 | <wilhelm> | Hm. How would you mark up the block of text “Sherlock Holmes–his limits” in this document? http://en.wikisource.org/wiki/Page%3AA_study_in_scarlet.djvu/26 |
| 23:09 | <TabAtkins> | With <hgroup>? |
| 23:09 | <TabAtkins> | Or, hm, no, never mind. |
| 23:09 | <TabAtkins> | Now that I'm reading the passage, it's just a normal heading. |
| 23:10 | <TabAtkins> | <section><h1><span class='name'>Sherlock Holmes</span> - his limits.</h1> <ol>...</ol></section> |
| 23:11 | <wilhelm> | It's a normal heading in a subdocument that shouldn't appear in the table of contents or document outline. |
| 23:11 | <wilhelm> | Hence my mild confusion. (c: |
| 23:11 | <TabAtkins> | subdocuments can't be marked up very well in HTML. |
| 23:12 | <wilhelm> | Indeed. |
| 23:12 | <TabAtkins> | <iframe srcdoc> ^_^ |
| 23:13 | wilhelm | cries. |
| 23:22 | <dglazkov> | why is there a distinction between TextTrack and HTMLTrackElement? |
| 23:22 | <rillian_> | HTMLTrackElement is a <track> you put in the document |
| 23:22 | <rillian_> | under a media element |
| 23:22 | <rillian_> | like <audio> or <video> |
| 23:23 | <rillian_> | to reference a text track file |
| 23:23 | <rillian_> | a TextTrack is a pure js object representing the result of parsing that file |
| 23:24 | <rillian_> | or, if you prefer, an HTMLTrackElement handles the plumbing between a TextTrack object and a MediaElement which is supposed to play it back |
| 23:24 | <Hixie> | dglazkov: you cna also get TextTracks straight from the media file |
| 23:24 | <Hixie> | dglazkov: or indeed create one out of whole cloth in the DOM |
| 23:25 | <dglazkov> | ohhhh. That makes sense. The media itself can have a TextTrack embedded in it |
| 23:26 | <dglazkov> | I was confused why the API for adding TextTracks isn't just adding an HTMLTrackElement child. |
| 23:27 | <dglazkov> | ok cool. Thanks, rillian_ and Hixie |
| 23:27 | <Hixie> | HTMLTextTrack is just for external text tracks |
| 23:27 | <Hixie> | if you're creating on dynamically, you don't need the element |
| 23:28 | <rillian_> | right, you can get a TextTrack from the parent's media file, from a separate HTMLTextTrack's file, or you can create it yourself |
| 23:28 | <rillian_> | e.g. from data you slurped out of your cms |
| 23:30 | <Hixie> | smaug____: what are all these bugs about? |
| 23:31 | <TabAtkins> | Hixie: Ignore them for now - there's still ongoing discussion about them on webapps. |
| 23:31 | <Hixie> | should they be closed, reassigned to smaug____, something else...? |
| 23:32 | <TabAtkins> | I suppose reassigned to smaug____ for resolution when we figure out what we want to do. |
| 23:33 | <smaug____> | Hixie: sorry |
| 23:33 | <smaug____> | Hixie: the main bug is just about remove handleEvent |
| 23:33 | <smaug____> | and =FunctionOnly |
| 23:34 | <smaug____> | I started to file them one by one, but then noticed that there are too many |
| 23:35 | <Hixie> | what's wrong with handleEvent? |
| 23:35 | <Hixie> | i'm confused |
| 23:35 | <smaug____> | silly name |
| 23:35 | <smaug____> | those interfaces have nothing to do with events |
| 23:35 | <Hixie> | i'm confused |
| 23:36 | <smaug____> | ? |
| 23:36 | <Hixie> | how about you pretend i haven't seen any of the bugs, nor any of the mailing list discussion, and you start over from the top :-) |
| 23:36 | <smaug____> | Hixie: in the interface you have handleEvent |
| 23:36 | <Hixie> | what interface |
| 23:37 | <smaug3G> | Hixie: in some callback interfaces you have method handleEvent |
| 23:37 | <Hixie> | yes |
| 23:37 | <smaug3G> | although the interface has nothing to do with events |
| 23:37 | <Hixie> | sure it's just a callback |
| 23:37 | <smaug3G> | there is no reason to have wrong name for the method |
| 23:38 | <Hixie> | doesn't matter what the name is |
| 23:38 | <jamesr_> | there's no reason to have _any_ name for the method 95% of the time |
| 23:38 | <smaug3G> | especially, if and when =FunctionOnly will be removed |
| 23:38 | <Hixie> | could be fooBarBaz |
| 23:38 | <Hixie> | FunctionOnly is being removed? |
| 23:38 | <smaug3G> | that is the other part |
| 23:38 | <jamesr_> | without FunctionOnly the name does matter, i suppose |
| 23:38 | <Hixie> | some languages need a name, even for interfaces marked FunctionOnly, because they don't have method pointers |
| 23:38 | <smaug3G> | there is no reason for =FunctionOnly |
| 23:39 | <smaug3G> | except perhaps for backwards compatibility in onfoo handlers |
| 23:39 | <Hixie> | surely if we default to only accepting function pointers this will cause all kinds of back-compat issues |
| 23:40 | <smaug3G> | I don't understand |
| 23:40 | <Hixie> | there are web pages that assume, e.g., that you can pass { handleEvent: function (event) { } } to addEventListener |
| 23:40 | <TabAtkins> | Yes, there is code in the wild that expects to be able to pass an object with a 'handleEvent' property to a callback. |
| 23:40 | <smaug3G> | so far most (all?) implementations just pretend that there is no =FunctionOnly |
| 23:40 | <smaug3G> | except for onfoo handlers |
| 23:41 | <smaug3G> | Hixie: yes, there are pages and good use cases for { handleEvent: function() {}} and there is no reason to not allow the same with other callbacks |
| 23:42 | <Hixie> | oh, i see, you're not proposing defaulting to FunctionOnly, you're proposing forcing all APIs to support both function pointers _and_ objects with a single method for the callback |
| 23:42 | <Hixie> | well if we do the latter then we definitely still need a name for the method! |
| 23:43 | <smaug3G> | How else would I want to remove FunctionOnly o_O |
| 23:43 | <Hixie> | i assumed you wanted to remove the ability to use objects. that's why i use functiononly, to simplify the api by only accepting one type. |
| 23:44 | <Hixie> | if you're saying i should use FunctionOnly less, that's a fine suggetion. File a bug on that with the use cases. |
| 23:44 | <smaug3G> | I don't understand what that simplifies |
| 23:44 | <smaug3G> | I did file a bug to remove =FunctionOnly |
| 23:44 | <smaug3G> | is there a usecase for =FunctionOnly ? |
| 23:45 | <Hixie> | you need a use case for additional abilities, not for lack of abilities |
| 23:45 | <Hixie> | the ability to use an object for a callback is an ability |
| 23:45 | <Hixie> | i mean we could also support strings as callbacks, the way setTimeout does |
| 23:45 | <Hixie> | we could also support URLs as callbacks |
| 23:45 | <Hixie> | or MessagePort objects |
| 23:45 | <Hixie> | or any number of other mechanisms |
| 23:45 | <smaug3G> | I'd say you need a reason to explicitly remove functionality |
| 23:46 | <Hixie> | the reason to remove functionality is always the same: make the platform simpelr |
| 23:46 | <smaug3G> | =FunctionOnly doesn't make platform simpler |
| 23:46 | <Hixie> | well i'm not really interested in arguing the point |
| 23:47 | <Hixie> | it seems self-evident that having two features is less simple than having one |
| 23:47 | <Hixie> | whether you agree or not, however, that is the reasoning for trying to limit the number of features |
| 23:47 | <smaug3G> | from implementation point of view making explicit limitations to the default handling is less simple |
| 23:48 | <smaug3G> | also from authoring point of view, since { handleEvent} is anyway supported in event listeners |
| 23:48 | <smaug3G> | and in fact with other non-legacy callbacks in most of current implementations |
| 23:50 | <Hixie> | that's the kind of information you should include in the bug, yes |
| 23:50 | smaug3G | so much wishes we could get some consistency to the platform |
| 23:51 | <Hixie> | says the person arguing for different names for different callbacks :-P |
| 23:52 | <Hixie> | anyway, i could only find one =FunctionOnly that needed to be changed, the drag-and-drop one |
| 23:52 | <Hixie> | did i miss anything? |
| 23:52 | <Hixie> | (the WebRTC stuff is likely to be removed so i'm ignoring that here) |
| 23:54 | <smaug3G> | most of them were in webrtc yes |
| 23:54 | <smaug3G> | I want consistency to callback method names: the method name should indicate what is the reason it is called. |
| 23:54 | <smaug3G> | also, same object can implement several callback interfaces |
| 23:55 | <Hixie> | i'm marking the webrtc bugs rejected since you filed them in the htmlwg component but the htmlwg doesn't have those interfaces |
| 23:55 | <Hixie> | i've changed them in the whatwg copy |
| 23:55 | <smaug3G> | { handleEvent: function(e) {}, handleMutations: function() {param} } .... |
| 23:55 | <Hixie> | i expect that text will be killed soon though |
| 23:56 | <Hixie> | since it looks like mozilla and google are looking at the webrtc wg at the w3c rather than the whatwg text |
| 23:56 | <TabAtkins> | smaug3G: That's being debated right now in webapps. It's somewhat premature to file bugs advocating one particular method yet. |
| 23:56 | Hixie | really doesn't understand why anyone would use an object for a callback when a closure does everything you would want, better |
| 23:56 | <smaug3G> | TabAtkins: I know it is being debated there. It has been debated several times before |
| 23:57 | <smaug3G> | it is handy to keep some state in the object, and you get right 'this' handling in the callback |
| 23:58 | <smaug3G> | (without need to do any additional JS stuff ) |
| 23:58 | <TabAtkins> | smaug3G: Sure, and that can all be done with a closure or .bind(). |
| 23:58 | <smaug3G> | that .bind() is something additional |
| 23:59 | <TabAtkins> | Your preference for {handleFoo:...} over .bind seems arbitrary. |
| 23:59 | <Hixie> | you don't get the right "this" |
| 23:59 | <TabAtkins> | Both are parts of the language. |
| 23:59 | <Hixie> | you get the "this" of the object passed to the method |
| 23:59 | <Hixie> | not the "this" of whatever object is setting all the callbacks |
| 23:59 | <Hixie> | which is typically the one you want |