| 04:31 | MikeSmith | peruses http://wiki.commonjs.org/wiki/Binary/D |
| 05:12 | <MikeSmith> | othermaciej: very cool to see Wildfox message about SVG filters support |
| 05:13 | <othermaciej> | MikeSmith: oh? |
| 05:13 | <MikeSmith> | on webkit-dev |
| 05:46 | <erlehmann> | SVG filters are PURE GOLD |
| 05:46 | <erlehmann> | i liek the whole displacement mapping thing best |
| 05:50 | <shepazu> | erlehmann: is that because of mariocart? http://www.tapper-ware.net/stable/PerspectiveWith6LinesOfXML-CanvasEnhanced/index.xhtml |
| 05:52 | <erlehmann> | shepazu, that would be one example. but animated displacement maps (gif files) are fine too. |
| 09:22 | <gsnedders> | http://www.w3.org/2001/tag/doc/content-to-apps.html |
| 09:24 | <Philip`> | 2001? That's an old document |
| 09:25 | <gsnedders> | Since when did dates in W3C URIs mean anything? |
| 09:26 | <Philip`> | Since humans started extracting obvious patterns and meaning from text that they read |
| 09:28 | <Hixie> | annevk: yt? what spec should define how the 'abort' event fires when the "unload a document" algorithm for the xhr's browsing context's document is run, if any? |
| 09:47 | <annevk> | hmm, prolly XHR :/ |
| 09:48 | <annevk> | well, which abort event? |
| 09:48 | <Hixie> | apparently (I haven't tested) 'abort' fires on XHR objects that are pending when the document is unloaded |
| 09:50 | <Hixie> | i really need a better term for "first script" |
| 10:01 | <annevk> | responsible script? |
| 10:01 | <annevk> | or something like that |
| 10:01 | <othermaciej> | what's special about the first script? |
| 10:03 | <othermaciej> | I see |
| 10:03 | <othermaciej> | the similar concept in WebKit is "dynamic global object" |
| 10:04 | <othermaciej> | the dynamic global object is the one where a particular nested chunk of script execution began |
| 10:06 | <othermaciej> | "first script" is not a great term, since an event listener is a function, not a script |
| 10:07 | <othermaciej> | "code entry-point" seems like a needlessly obscure term for a "function" |
| 10:08 | <othermaciej> | functions are also not necessarily associated at all with a script, in the sense of a <script> element anyway |
| 10:08 | <othermaciej> | it would be better to skip right to the global object from the function and bypass the concept of "script" |
| 10:19 | <Hixie> | code entry-point doesn't mean function |
| 10:19 | <Hixie> | e.g. <script>/*this is a code entry-point*/</script> |
| 10:19 | <Hixie> | it's not really to do with the global object either |
| 10:20 | <Hixie> | e.g. the script's base URL can be different for two scripts with the same global object |
| 10:22 | <othermaciej> | how? |
| 10:23 | <Hixie> | <script xml:base="a">...</script><script xml:base="b">...</script> |
| 10:24 | <othermaciej> | do browsers actually use the "script's base URL" as defined there, rather than the base URL of the script's global object's browsing context's active document? |
| 10:24 | <Hixie> | oh actually that's not true, my bad |
| 10:25 | <othermaciej> | what doing relative URL resolution for window.open for instance? |
| 10:25 | <Hixie> | no you're right |
| 10:25 | <Hixie> | the spec just has script's base URL as being a shorthand way of saying that |
| 10:25 | <Hixie> | i suppose i could remember the global object instead of the script and call it the dynamic global object |
| 10:26 | <othermaciej> | I'm not sure "dynamic global object" will be more clear to people necessarily, that was just a cite of our usage |
| 10:26 | <othermaciej> | we contrast it with the "lexical global object" which is the one where the currently running function was initially defined |
| 10:27 | <Hixie> | yeah i don't know if it's better enough to be worth it |
| 10:27 | <Hixie> | "first script" is confusing people though |
| 10:27 | <jgraham> | fwiw "dynamic global object" as a set of words doesn't really convey anything to me |
| 10:27 | <othermaciej> | I'm just saying that the "script" notion does not really add a useful abstraction, in terms of what actually needs to happen |
| 10:27 | <Hixie> | jgraham: that's a good thing, compared to "first script", which conveys something wrong. :-) |
| 10:28 | <othermaciej> | "outermost global object" would perhaps be better in context, though it might connote outermost frame instead of outermost in the sense of execution nesting |
| 10:28 | <Hixie> | othermaciej: it's a useful abstraction because there are three kinds of global objects (Window, WorkerGlobalScope, and the empty object) |
| 10:28 | <Hixie> | is there some term referring to the first stack frame? |
| 10:28 | <Hixie> | which we could adopt here? |
| 10:29 | <Hixie> | othermaciej: (though it could certainly be phrased in a different way than it is now) |
| 10:31 | <othermaciej> | too verbose but likely unambiguous: outermost script execution entry point |
| 10:31 | <Hixie> | entry script? |
| 10:31 | <Hixie> | might be better than first script, at any rate |
| 10:32 | <othermaciej> | "first script |
| 10:32 | <othermaciej> | " sounds too much like the first one that appears in the page |
| 10:32 | <Hixie> | right |
| 10:33 | <othermaciej> | is there any way in which an impotent script's base URL can be used? |
| 10:33 | <othermaciej> | I think the answer is no so the empty object case doesn't matter |
| 10:34 | <othermaciej> | anyway, "entry" might have less chance of producing confusion |
| 10:36 | <Hixie> | there isn't, and indeed its script's base URL is explicitly not set currently |
| 10:37 | <Hixie> | anyway, i'll leave this stuff for now |
| 10:37 | <Hixie> | websockets next, and then i'm ready for webapps LCs |
| 10:37 | <Hixie> | only 61 websocket e-mails |
| 10:54 | Hixie | looks at http://dev.w3.org/2009/dap/camera/Overview.html and wonders why <input type=image> as specced in html5 isn't enough |
| 10:54 | <Hixie> | (for what that api can do) |
| 11:16 | <Lachy> | Hixie, presumably, you mean, <input type=file>? |
| 11:16 | <Hixie> | uh yes |
| 11:26 | <virtuelv> | Hixie: because not everything is about grabbing a static image, deferring any control over the photo/film process to a native implementation |
| 11:27 | <virtuelv> | (I don't neccesarily completely agree with the approach in the spec, but <input type="file"> would be horribly insufficient, if you were to reimplent something like Layar, or the google turn-by-turn app from Android 2.0 |
| 11:27 | <Hixie> | certainly <input type=file> isn't the ultimate solution for everything |
| 11:28 | <Hixie> | i just meant for doing what was in the api spec |
| 11:30 | <virtuelv> | two problems (which can probably be overcome |
| 11:30 | <virtuelv> | 1) Media data from a device is not "files" |
| 11:30 | <virtuelv> | the main purpose of an API is to grab the data, not neccesarily for upload, but for later processing |
| 11:31 | <Hixie> | <input type=file> exposes a URL the same way the API does, these days |
| 11:31 | <virtuelv> | 2) <input type="file"> offers little control over the user interface, and would force the user to make an informed choice |
| 11:32 | <Hixie> | the api doesn't give much control either |
| 11:32 | <Hixie> | as written today |
| 13:53 | <glen1> | anyone know what the <figure/> tag mean |
| 13:56 | <annevk> | see the spec |
| 14:00 | <glen1> | the w3c page crashes my browser lol |
| 14:00 | <glen1> | is it for pictures and stuff |
| 14:01 | <foolip> | try the multipage version, it may crash your browser less |
| 14:01 | <glen1> | lol html5 sucks |
| 14:03 | <Philip`> | That was insightful |
| 14:03 | <annevk> | IRC always is |
| 14:04 | <foolip> | does anyone know how to set up irssi to show part messages for people who have spoken in the last x minutes, but ignore the rest? |
| 14:05 | <foolip> | I assume we have many irssi users here |
| 14:05 | Philip` | uses irssi but has no idea |
| 14:07 | <murr5y> | dare you do a version ctcp? :) |
| 14:40 | <foolip> | TabAtkins: well written, hope it helps |
| 14:40 | <TabAtkins> | Thanks, yeah. |
| 14:53 | <zcorpan_> | Hixie: not sure i follow the new text on interface objects in workers... should ImageData be visible to a worker? |
| 14:55 | <annevk> | it seems so |
| 14:56 | <annevk> | in particular because of "and the interfaces of any objects made accessible through APIs" |
| 15:00 | <zcorpan_> | and it's made accessible because you can postMessage an instance of an ImageData? |
| 15:08 | <annevk> | thinking about it more I guess it's not quite clear |
| 15:08 | <annevk> | well, it depends on how you interpret things |
| 15:08 | <annevk> | ImageData is made accessible through an API... |
| 16:00 | <virtuelv> | Hixie: yt? |
| 17:10 | <jgraham> | Argh |
| 17:12 | <Philip`> | ? |
| 17:13 | jgraham | has has had even more enough of the bug 8404 discussion than before |
| 17:15 | <jgraham> | It is like an initially minor itch that once scratched became pussy and started to bleed |
| 17:15 | <virtuelv> | oh well, I'm advocating <input type="file" for camera capture now |
| 17:16 | <virtuelv> | there's however a bit there about selecting a camera on clicking, |
| 17:16 | <virtuelv> | good approach for microdata? |
| 17:34 | <Philip`> | jgraham: I suggest amputation |
| 17:38 | <TabAtkins> | jgraham: I suggest writing the word as "puss-y" to avoid ambiguous connotations. |
| 17:47 | <adactio> | Hmmm... I just had a random thought... shouldn't the datalist element allow the optgroup element? |
| 17:55 | <TabAtkins> | <datalist> doesn't exist anymore, does it? |
| 17:56 | <myakura> | TabAtkins: I think that's <datagrid> which doesn't exist. I believe <datalist> does. |
| 18:01 | <adactio> | Datalist is alive and well (and implemented in Opera). |
| 18:02 | <jgraham> | TabAtkins: Yeah I noticed tht afterwards |
| 18:23 | <BenMillard> | evening all, long time since I've dropped by here :) |
| 18:24 | <BenMillard> | heh, it was "285 days ago" according to this: http://gavinsharp.com/irc/whatwg.html |
| 18:24 | <webben> | evening BenMillard :) |
| 18:25 | <BenMillard> | webben, I recognise your name (and several others) |
| 18:25 | <BenMillard> | I'm on a one-week holiday from my full-time website developer job |
| 18:26 | <BenMillard> | I'm going to apply to work at Opera, so I can help refine HTML5 and resume studying how authors use HTML, but I'm not sure if they have a job opening which fits that |
| 18:26 | <BenMillard> | "Core Technology Testers (Web technology experts)" is the closest I've found: http://www.opera.com/company/jobs/opening/67/ |
| 18:30 | <BenMillard> | jgraham, I've been using your Document Map add-on for Firefox during the past few months and really like it! |
| 18:30 | <BenMillard> | jgraham, I'm using 0.6.1 - is that the most recent version? |
| 18:30 | <webben> | BenMillard: Good luck! :) |
| 19:17 | <miketaylr> | and the troll of the day award goes to: http://twitter.com/slicknet/status/6276901024 |
| 19:17 | <miketaylr> | http://twitter.com/slicknet/status/6278180943 |
| 19:56 | foolip | reads http://edward.oconnor.cx/2009/12/RDFa-and-the-DOM |
| 20:04 | <Philip`> | On the subject of text vs (DOM|Infoset|any sane model), see also http://github.com/msporny/rdfa-test-suite/commit/a27e4f4500a854024b0e3914af13f6227d54d805 |
| 20:04 | <foolip> | wow, that was actually very well worth reading |
| 20:05 | <Philip`> | which seems to suggest SAX parsers may get confused by thinking markup like <string> is identical to <string> |
| 20:05 | <foolip> | (Edward O'Connor, not the git commit...) |
| 20:06 | <foolip> | hmm, a well written commit message though, I never bother writing that much |
| 20:07 | <Philip`> | It's a good explanation of the rationale behind the change, I just think the rationale is completely wrong and misguided :-) |
| 20:08 | <foolip> | I'm not sure I understand though |
| 20:08 | <Philip`> | (and caused by thinking the raw byte stream is important) |
| 20:08 | <foolip> | why would seeing <strong> in a text node cause you to think that's an XML literal? |
| 20:09 | <Philip`> | http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Nov/0099.html - "The first was an issue that would occur on SAX-based processors that did not have access to the raw byte stream and thus wouldn't be able to tell if the encoded "<strong>" value should be interpreted as an XML Literal or not." |
| 20:09 | <Philip`> | foolip: It wouldn't |
| 20:11 | <foolip> | I just don't know enough about how XML Literals are encoded or how SAX parsers work to understand |
| 20:11 | <foolip> | but that's OK, because I have packing to do and am flying to Vietnam on Friday |
| 20:11 | <foolip> | yay me |
| 20:14 | <Philip`> | They shouldn't be encoded at all - the idea is that when you're converting an element to a value, if it has child elements then you serialise the element's content into an XMLLiteral string, else you use the content as a typeless string |
| 20:14 | <Philip`> | which is nice and easy when you consider XML documents to be a tree/stream of elements and text nodes |
| 20:14 | <foolip> | right |
| 20:15 | <foolip> | so how do "SAX-based processors that did not have access to the raw byte stream" see XML? |
| 20:15 | <foolip> | last time I used SAX for anything I was feeding it XML as a string and got parse events |
| 20:16 | <Philip`> | but if you don't have that model then even the concept of "serialise the element's content" makes no sense, so it's sort of defined as copying the characters contained within the element, except munging it a bit to add namespace declarations, and also it needs canonicalisation, and the specification is really fuzzy |
| 20:16 | <foolip> | (or something along those lines) |
| 20:16 | <Philip`> | SAX processors see a stream of startElement and endElement and characters events |
| 20:16 | <Philip`> | (or something very similar to that) |
| 20:16 | <foolip> | oh, on that end |
| 20:16 | <foolip> | I was thinking backwards |
| 20:17 | <foolip> | of course |
| 20:18 | <foolip> | sounds like a problem very much not specific to RDFa though |
| 20:18 | <Philip`> | I don't think there's a problem at all |
| 20:19 | <Philip`> | Or, I don't think there's a problem at all with SAX |
| 20:19 | <Philip`> | or with writing RDFa processors on top of a SAX processor |
| 20:19 | <Philip`> | The only problem is the RDFa spec |
| 20:20 | <foolip> | what does it actually say to do produce an XML Literal? |
| 20:20 | <Philip`> | (which is mostly specific to RDFa, not other specs) |
| 20:20 | <foolip> | pretend it has the raw byte stream, I presume |
| 20:20 | <foolip> | oh well |
| 20:21 | <Philip`> | "The value of the [XML literal] is a string created by serializing to text, all nodes that are descendants of the [current element], i.e., not including the element itself, and giving it a datatype of rdf:XMLLiteral." |
| 20:22 | <Philip`> | plus errata: "For the avoidance of doubt, this means in part that the current default namespace of each descendant element MUST also be included in the emitted XML literal." |
| 20:22 | <Philip`> | plus errata: "Unfortunately, the requirements for such a serialized string are not completely clear when it comes to XML Namespaces. For the avoidance of doubt, in future versions of the RDFa Syntax Recommendation, we expect to indicate that the value of the XML literal SHOULD be serialized Exclusive Canonical XML as defined in [XMLEXC14N]. We advise current implementations to start supporting this use model now, since other participants in their XML tool ch |
| 20:22 | <hober> | foolip: thanks |
| 20:23 | <foolip> | sounds like it assumes a DOM |
| 20:23 | <Philip`> | Oh, so it does actually talk about serializing nodes |
| 20:23 | <foolip> | hober: oh there you are :) |
| 20:25 | <Philip`> | Discussions about the namespace/c14n requirements and RDFa-in-text/html seem to indicate that many people don't believe in the DOM-like model, though |
| 20:26 | <Philip`> | Anyway, I should probably stop complaining about this :-p |
| 20:26 | <foolip> | We probably all should |
| 20:27 | <foolip> | but while we're on the topic, I found this amusing: http://www.merttol.com/articles/web/understanding-rdfa.html |
| 20:27 | <foolip> | (see my comment at end) |
| 20:29 | <foolip> | I just hope that this whole RDFa issue doesn't have people hating *RDF* |
| 20:30 | <Philip`> | Not at all |
| 20:31 | <Philip`> | RDF is hated for its own unique reasons |
| 20:32 | <Dashiva> | RDF is too vague to be a proper target for hating |
| 20:34 | <foolip> | down with graphs! |
| 20:34 | <Philip`> | Down with data structures! |
| 20:34 | <Philip`> | Down with data! |
| 20:36 | <foolip> | PNG instead of HTML5? |
| 20:37 | <BenMillard> | foolip, that would put me and aobut 1,000,000 other people out of a job :( |
| 20:37 | <BenMillard> | s/aobut/about/ |
| 20:37 | <Dashiva> | Poor Bobby McFerrin, doomed to never be a unique individual |
| 20:41 | <Dashiva> | Maybe RDFa will usher in a new age of less graphy RDF, one where almost all statements use string literals |
| 20:43 | <Philip`> | Bonus points if you have RDFa embedded in markup inside string literals |
| 20:44 | <Sirisian_> | workmad3, why are you here? |
| 20:44 | <workmad3> | Sirisian_: just hovering :) |
| 21:13 | <TabAtkins> | othermaciej: Well, turns out I already had an account, but it doesn't *look* like I have editting privileges. I guess I'll wait for MikeSmith to show up in irc. |
| 21:17 | <othermaciej> | TabAtkins: I think Laura Carlson also has the power to enable editing - not sure who else |
| 21:17 | <othermaciej> | TabAtkins: I'm not really sure why the wiki is restricted in the first place - I'm not aware of any vandalism problems |
| 21:21 | <Philip`> | Maybe there aren't any vandalism problems because it's restricted |
| 21:23 | <Dashiva> | Or maybe maciej doesn't consider offers on cheap airline tickets vandalism |
| 21:25 | <othermaciej> | TabAtkins: looks like you should already have editing rights according to the list |
| 21:25 | <othermaciej> | TabAtkins: in fact supposedly both of us have the right to grant editing rights - perhaps that is just done by editing the <http://esw.w3.org/topic/ESWEditorsGroup>; page |
| 21:48 | <TabAtkins> | othermaciej: Hrm. It's telling me I don't have permission to edit this page, where "this page" is the new one I'm trying to create. |
| 21:50 | <othermaciej> | TabAtkins: unfortunately I don't really understand how the Wiki is managed |
| 21:50 | <TabAtkins> | Yeah, me neither. Shrug. |
| 21:50 | <othermaciej> | TabAtkins: I could paste in a copy of the document for you but I'm hesitant to put it in a place you can't edit |
| 21:51 | <TabAtkins> | You could paste it in, with a link to the location on my server for "latest version"? |
| 21:57 | <othermaciej> | your account is named TabAtkins? |
| 21:57 | <TabAtkins> | Yup |
| 22:08 | <TabAtkins> | othermaciej: Now that I think about it, I editted the Taxi page before TPAC. So I do have editting rights. Perhaps I just don't have page creation rights. |
| 22:08 | <TabAtkins> | If you can create the page for me I think it likely that I can edit it. |
| 22:10 | <TabAtkins> | (Which would explain why I don't see a "Create Page" button around anywhere, and had to manually put a new page in the url.) |
| 23:02 | <othermaciej> | TabAtkins: ok - what would you like the page to be called? |
| 23:02 | <TabAtkins> | I was attempting to call it Issue76CounterProposal, but use whatever you think is best. |
| 23:11 | <Philip`> | That naming convention doesn't scale well if there's more than two proposals |
| 23:11 | <hober> | Issue76StatusQuoChangeProposal? |
| 23:13 | <Lachy> | someone needs to put an end to this annoying figure vs. table discussion. The arguments are just getting repeated over and over again. |