| 00:23 | <zcorpan_> | annevk: did you get your t-shirt? |
| 02:50 | <kfish> | moin |
| 02:50 | <kfish> | is there any way to specify the authorship / authority of subparts of a web page? |
| 02:51 | <kfish> | s/is there/are there any proposals for/ |
| 02:51 | <zcorpan_> | <address>? |
| 02:51 | <kfish> | eg. if i wanted to say that the comments section of a web page was not authored by the site, could contain public comments ie. spam |
| 02:52 | <kfish> | basically, to set a nofollow attribute to an element |
| 02:52 | <zcorpan_> | use rel=nofollow on the links |
| 02:53 | <kfish> | cheers :-) |
| 02:54 | <zcorpan_> | using an outer <article> for the main post and nested <article>s for the comments would indicate that the inner articles were actually comments |
| 03:18 | <MikeSmith> | kfish - you on mixi? |
| 03:18 | <MikeSmith> | http://mixi.jp/show_friend.pl?id=299825 is me |
| 03:20 | <kfish> | MikeSmith, nice taste in music :-) |
| 03:20 | <kfish> | yeah cool, just sent you an invite |
| 03:23 | <MikeSmith> | you can join my 全日本酔払い連合 community |
| 03:23 | <MikeSmith> | All Japan Drunkard Association |
| 03:27 | <kfish> | hahaha :-) |
| 08:25 | <annevk> | zcorpan_, yeah |
| 08:26 | <zcorpan_> | annevk: did you wear it at reboot? |
| 08:26 | <annevk> | no :( |
| 08:27 | <zcorpan_> | ok |
| 08:45 | <annevk> | lol |
| 08:45 | <annevk> | the last e-mail about headers= is so confused |
| 08:45 | <annevk> | trying to read all kinds of silly meaning out of the HTML4 specification... |
| 09:02 | <hsivonen> | annevk: FWIW, in angels-on-heads-of-SGML-pins discussions one might claim that #IMPLIED attributes are magically there. In Web reality, of course, an attribute can be present or not present in the DOM. |
| 09:06 | <annevk> | hmm, I was afraid of that |
| 09:07 | <othermaciej> | I think it makes more sense to distinguish absent attribute from attribute set to default value |
| 09:07 | <othermaciej> | (not that my opinion has much relevance) |
| 09:07 | <annevk> | yeah, you're an implementor |
| 09:07 | <annevk> | go away! |
| 09:07 | <annevk> | oh wait |
| 09:08 | <hsivonen> | part of the problem is that SGML and Web have a different notion of what a default value is |
| 09:09 | <hsivonen> | in SGML the parser reports it. on the Web, the default isn't in the DOM but the implementation reading the DOM uses the defaults if stuff isn't in the DOM |
| 09:09 | <annevk> | if people could just accept that "the Web" and not "SGML-based HTML4" is the where we are starting from... |
| 09:09 | <othermaciej> | my opinion on what works or doesn't may be well-informed, my opinion on what makes sense is as arbitrary as anybody's |
| 09:09 | <annevk> | <div contenteditable> and <div> are quite different for instance |
| 09:10 | <othermaciej> | empty vs. null |
| 09:11 | <annevk> | yeah, in the new-world getAttribute() terms :) |
| 09:11 | <hsivonen> | annevk: is there a new-world getAttribute() now? the old-world getAttribute() is definitely influenced by SGML thinking |
| 09:12 | hsivonen | hasn't done enough JS DOM work lately: world view influenced by Java DOM |
| 09:12 | <othermaciej> | someone needs to make a DOM Core spec that's useful for browsers |
| 09:12 | <annevk> | getAttribute() returns null if no attribute is specified |
| 09:12 | <annevk> | as opposed to the empty string which is required by the DOM spec |
| 09:13 | <hsivonen> | annevk: cool. |
| 09:13 | hsivonen | has written a bug in Java assuming the intuitive behavior when the library implemented the spec |
| 09:15 | hsivonen | wonders why the Java API designers assume that for character decoding I want to either recover from errors silently or treat them in a Draconian way but they don't offer reported recovery |
| 09:31 | <Lfe> | i just found out about navigator.onLine.. it will work out quite nicely with google gears :) |
| 09:32 | <annevk> | Lfe, yeah, in due course the ideas of Google Gears should be integrated with the rest of the APIs I think |
| 09:33 | <Lfe> | annevk: i agree. that's the kind of thing that needs to be "standardized" in order to work nicely |
| 09:33 | <othermaciej> | there's already a SQL API in the spec, but the offline caching API needs to be worked out |
| 09:33 | <othermaciej> | and reconciled with what Mozilla did |
| 09:33 | <annevk> | and there are these worker thread APIs |
| 09:33 | othermaciej | is a bit disappointed in Moz for not going to standards with their stuff sooner |
| 09:33 | <othermaciej> | the worker thread APIs are the simplest part |
| 09:33 | <othermaciej> | but also kinda the least useful |
| 09:34 | <annevk> | and you had some ideas about integrating persistent storage with the SQL stuff right? |
| 09:34 | <othermaciej> | well, just a throwaway suggestion |
| 09:34 | <othermaciej> | maybe there is a better way to integrate |
| 09:35 | <othermaciej> | but it bugs me that in the spec they are completely separate |
| 09:35 | <annevk> | otoh, the globalStorage stuff can go from key / value to key / object |
| 09:35 | <annevk> | so you can store arbitrary DOM objects and such |
| 09:37 | <annevk> | I suppose SVGDocument.title can just be dropped... |
| 09:37 | <othermaciej> | I don't see how storing an arbitrary DOM node could possibly give sensible results |
| 09:37 | <othermaciej> | or even storing a function |
| 09:37 | <othermaciej> | (you could stringify, then they it's just a dumb key / value pair) |
| 09:38 | <annevk> | you could store E4X objects or a Document which you can use as XML database |
| 09:39 | <othermaciej> | storing a Node can't preserve identity, which in the case of DOM objects makes a difference |
| 09:39 | <othermaciej> | unlike strings |
| 09:39 | <othermaciej> | if you store an element that's in the document and has children, when you come back to that doc later and retrieve it, it won't still be in the document |
| 09:40 | <othermaciej> | so if you save nodes, you get the equivalent of serializing / deserializing markup anyway |
| 09:41 | <annevk> | oh, you mean they become detached? |
| 09:41 | <othermaciej> | well, it can't preserve identity across document reloads |
| 09:41 | <annevk> | that seems fine |
| 09:41 | <othermaciej> | that just can't work |
| 09:41 | <annevk> | it's just that the browser does the serializing for you |
| 09:41 | <othermaciej> | yeah but it's also not any more useful than storing strings |
| 09:42 | <hsivonen> | annevk: considering how the DOM is implemented, storing DOM nodes seems like a huge pain |
| 09:42 | <othermaciej> | basically you're asking it to store .innerHTML instead of .toString() |
| 09:42 | <Lfe> | regarding the ManagedResourceStore.checkForUpdate() (how one should attain updated data) - gears seems to do a HTTP GET and compare mydata.currentVersion to the localized version string. Why not use HTTP HEAD / etag for this? |
| 09:42 | <Lfe> | (or similar techniques) |
| 09:42 | <othermaciej> | HTTP HEAD is broken enough to be useless in practice |
| 09:42 | <hsivonen> | annevk: if I stick some random function objects onto a C++-backed DOM node, what would you store? |
| 09:43 | <annevk> | hmm |
| 09:43 | <annevk> | at some point Hixie defined it |
| 09:44 | <annevk> | but removed it based on feedback from Mozilla (too much work iirc) |
| 09:44 | <hsivonen> | annevk: doing an XHR-like save operation to a local store would be a lot simpler that JS/C++ object serialization |
| 09:44 | <othermaciej> | serliazing JavaScript functions in a way that round trips properly is nearly impossible |
| 09:44 | <Lfe> | othermaciej: isn't that up to the host to "solve"? a head/etag would save lots of potential kb's |
| 09:45 | <hsivonen> | othermaciej: mmap :-) |
| 09:46 | <othermaciej> | hsivonen: the hard part is handling captured scope - there's no clearly right way to restore it across exit and subsequent reload |
| 09:47 | <Lfe> | ah, manifestUrl != resourceUrl |
| 09:55 | <Lfe> | othermaciej: powernap? |
| 09:56 | <othermaciej> | Lfe: no, saw something on another channel that caught my eye |
| 10:43 | <annevk> | Shouldn't dir= default to something at some point? |
| 10:43 | <annevk> | Say, ltr for the root element... |
| 15:09 | <gsnedders> | apparently unit tests can avoid the need for an XML serialiser. |
| 15:09 | <gsnedders> | (when it comes to creating well-formed XML) |
| 16:00 | <Jero> | question: when the input stream is just "<html>", how are, according to the tree construction algorithm, the <head> and <body> elements created? |
| 16:01 | <annevk> | the current tree construction algorithm is not entirely correct as far as that goes |
| 16:02 | <Jero> | ah i see |
| 16:02 | <annevk> | html5lib is :) |
| 16:02 | <Jero> | so html5lib does stuff that isn't in the spec ATM to create those two elements?? |
| 16:02 | <Jero> | ok :p |
| 16:03 | <Jero> | and do you think those steps will eventually be added to the spec? |
| 16:03 | <annevk> | we also removed the insertion mode switch |
| 16:03 | <Jero> | or is it just temporarily? |
| 16:03 | <annevk> | and made it all phases |
| 16:03 | <annevk> | the spec will be fixed, yes |
| 16:04 | <gsnedders> | some sites depend on it, so it does need to be fixed |
| 16:05 | <Jero> | annevk: yeah, I noticed html5lib does it differently than the spec |
| 16:05 | <Jero> | will that also be changed in the spec? |
| 16:05 | <annevk> | the spec has a note to that effect at the moment |
| 16:05 | <gsnedders> | Jero: html5lib's deviations are for compatibility with the web, so yes |
| 16:06 | <annevk> | but if Hixie decides to write the same thing down in some other way... so be it |
| 16:09 | <Jero> | okay, but the output of html5lib is still compatible with the spec i assume, even though it changed the steps to process the token? |
| 16:09 | <annevk> | it's mostly equivalent |
| 16:09 | <Jero> | oh ok, than it doesn't really matter |
| 16:09 | <Jero> | bedankt :) |
| 23:05 | <hsivonen> | annevk: is the diff between the spec and html5lib documented? |