| 01:08 | <MikeSmith> | mcarter_: have you done a write-up anywhere yet on your implementation related to the connection API? |
| 01:10 | <takkaria> | PlotKit is interesting, but also lacking in a bunch of features |
| 01:10 | <takkaria> | for example, vertical gridlines |
| 02:28 | <Hixie> | annevk: please send feedback to the list, not the irc channel :-) |
| 02:43 | <gsnedders> | This internet access saga is truly bizarre (but it works again now, so hey) |
| 02:44 | <annevk> | Hixie, ok, e-mailed you + www-archive |
| 02:50 | <gsnedders> | It feels weird sending emails to Hixie without www-archive :P |
| 03:55 | <Hixie> | annevk: thanks |
| 04:34 | <annevk> | geez |
| 04:34 | <annevk> | twitter is slower than ever (besides when it's unresponsive) |
| 04:59 | <Lachy> | Woo Hoo! This book is finally available for pre-order. http://www.amazon.com/Ultimate-HTML-Reference-Ian-Lloyd/dp/0980285887/ |
| 04:59 | <Lachy> | I was one of the technical reviewers for it as it was being written |
| 05:04 | <Philip`> | Lachy: What makes it ultimater than the thousands of other HTML books? :-) |
| 05:05 | <Lachy> | cause I reviewed it and know it's good :-) |
| 05:05 | <Philip`> | That kind of appeal to authority is not very convincing :-p |
| 05:07 | <Lachy> | For one reason, unlike many other books that teach people to use XHTML, this one actually teaches both HTML and XHTML and gives good advice about the use of both. |
| 05:08 | <Lachy> | there's a public beta online here http://reference.sitepoint.com/html |
| 05:10 | <Lachy> | hmm. It seems to be missing entity references. |
| 05:10 | <Lachy> | oh well, that can be added to the next revision |
| 05:19 | <Lachy> | Hixie, yt? |
| 05:21 | <Lachy> | Hixie, the entity reference table in the spec is missing the <tbody> after the first row |
| 05:23 | <Hixie> | w3c or whatwg? |
| 05:25 | <Lachy> | whatwg |
| 05:25 | <Lachy> | I didn't check the w3c copy of the spec |
| 05:25 | <Lachy> | I only noticed in the whatwg copy cause I was copying the table for use in the html authoring guide |
| 05:25 | <annevk> | w3c too iirc |
| 05:25 | <Lachy> | I'm going to rewrite it to make it more author friendly |
| 05:26 | <Hixie> | oh, i see what you're saying |
| 05:26 | <Hixie> | odd |
| 05:26 | <Hixie> | if possible, can you send mail? |
| 05:26 | <Hixie> | i'm in the middle of a painful edit |
| 05:26 | <Lachy> | sure |
| 05:26 | <Hixie> | thanks |
| 05:30 | <Lachy> | Hixie, do you use a script to generate that table? |
| 05:30 | <Hixie> | yes |
| 05:30 | <Lachy> | Can I get a copy of it, so I can modify it to generate a more appropriate table for the author guide. |
| 05:31 | <Hixie> | it's one of my first ever python scripts, so i dunno :-) |
| 05:31 | <Lachy> | LOL |
| 05:32 | <Hixie> | http://junkyard.damowmow.com/322 |
| 05:32 | <Hixie> | that script is then called using this bash magic: |
| 05:32 | <Hixie> | wget -o /dev/null -N http://www.w3.org/2003/entities/2007xml/unicode.xml |
| 05:32 | <Hixie> | [ unicode.xml -nt entities-unicode.inc ] && nice -n 19 python .entity-processor.py > .new-entities-unicode.inc |
| 05:32 | <Hixie> | [ -s .new-entities-unicode.inc ] && mv -f .new-entities-unicode.inc entities-unicode.inc |
| 05:32 | <Hixie> | cat entities-* | sort | uniq > entities.inc |
| 05:32 | <Lachy> | thanks |
| 05:33 | <Hixie> | and entities-* matches the entities-unicode.inc file mentioned above and entities-legacy.inc |
| 05:33 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/entities-legacy.inc |
| 05:33 | <Hixie> | which is a hard-coded list of entities |
| 05:35 | <annevk> | Hixie, doing more work on sandboxing? |
| 05:35 | <Hixie> | yeah |
| 05:35 | <Hixie> | the http://www.whatwg.org/specs/web-apps/current-work/index-diff file shows what i have so far |
| 05:39 | <annevk> | Hixie, for seamless it should probably say something about initial containing block and such too |
| 05:39 | <Hixie> | othermaciej: the problem with making item() available, etc, is that you lose the ability to use the data-item="" attribute |
| 05:39 | <Hixie> | it does |
| 05:39 | <Hixie> | unless i messed up the commit |
| 05:40 | <Hixie> | search for "initial containing block" in html5 and there are two occurances, both doing what you just asked for :-) |
| 05:40 | <annevk> | it sets the height tozero... |
| 05:40 | <Hixie> | right |
| 05:41 | <annevk> | it doesn't entirely remove it |
| 05:41 | <annevk> | hmm |
| 05:41 | <Hixie> | you can't remove it |
| 05:41 | <Hixie> | that would break css in pretty fundamental ways |
| 05:41 | <Hixie> | it's like saying we should remove the root element |
| 05:41 | <Hixie> | what would it even mean? |
| 05:41 | <annevk> | it means that the initial containing block of the nested browsing context is that of the browsing context |
| 05:41 | <annevk> | well, that's what I thought it would specify |
| 05:42 | <othermaciej> | Hixie: yeah, I can see why it could cause conflicts |
| 05:42 | <Hixie> | annevk: wow, that would be weird |
| 05:43 | <annevk> | now absolutely positioning stuff still goes against the nested browsing context initial containing block, which is not what you want (not always anyway) |
| 05:43 | <Hixie> | why wouldn't it be what you want? |
| 05:44 | <Hixie> | it's still an iframe |
| 05:44 | <Hixie> | you can't render outside the iframe |
| 05:44 | <Hixie> | if you could you'd be open to all kinds of weird hacks |
| 05:44 | <annevk> | if you could you'd have the client-side includes people have been looking for |
| 05:45 | <Hixie> | i don't think client side include requests have really been looking for ways to render outside the box |
| 05:45 | <Hixie> | they mostly just want to include their navigation links or header or footer |
| 05:50 | <annevk> | btw, in the short definition for the sandbox attribute you should note that giving it values means you lift restrictions |
| 05:51 | <roc> | I prefer what Hixie currently has |
| 05:52 | <roc> | we don't want to make handling of the IFRAMEd content too weird |
| 05:52 | <annevk> | Hixie, maybe split "xxx_origin_please_suggest_a_better_name" into "dom-access" and "storage-access" |
| 06:02 | <Hixie> | annevk: sandbox="dom-access" doesn't convey what it does, since even with sandbox="", DOM access is still possible, just not from other documents, even if their URIs are in the same origin |
| 06:02 | <Hixie> | annevk: and storage access (and XHR, etc) is allowed if scripting is enabled, it just doesn't work (since the document isn't in the expected origin) |
| 06:04 | <annevk> | localStorage would actually still work and end up in void, or not? |
| 06:04 | <annevk> | maybe just "default-origin" or some such then? |
| 06:06 | <annevk> | Hixie, btw, these two comments make it much more clear for some reason what the attribute is supposed to do then the note in the spec |
| 06:06 | <Hixie> | yeah i dunno how to explain it |
| 06:08 | <annevk> | maybe localStorage should fail if the origin is an identifier and not a tuple |
| 06:12 | <annevk> | hmm, StorageEvent.uri should be StorageEvent.url ... |
| 06:14 | <roc> | one day I'll have to figure out what the difference between a URL and a URI is. Wouldn't want to embarrass myself in public |
| 06:14 | <Dashiva> | Don't forget IRI |
| 06:14 | <roc> | oh yeah, I discovered those recently. Mad |
| 06:14 | <hober> | and URN |
| 06:16 | <Philip`> | "URI" is the term you use when talking to standards people so you look clever, and "URL" is the term you use when talking to normal people so you're understood |
| 06:17 | <andersca> | lol |
| 06:19 | <annevk> | <input type=url> was at one point type=uri... |
| 06:20 | <Hixie> | i plan to change the spec to use the term "url" |
| 06:20 | <Hixie> | and just define "url" in the terminology section as being an iri |
| 06:21 | <Hixie> | i expect this will cause the nitpickers to have enough heart attacks to keep them off our back for a few months |
| 06:21 | <Hixie> | (actually, not just an iri. it will depend on the character encoding in weird ways.) |
| 06:21 | <Dashiva> | Hixie: Also define uri as url, then |
| 06:22 | <annevk> | hmm, URL5 :) |
| 06:22 | <Hixie> | Dashiva: what does that mean? |
| 06:28 | <Dashiva> | Hixie: Just in case there's a URI left in there somewhere, it should be defined :) |
| 06:30 | <annevk> | othermaciej, there's a difference between style.foo = x and storage.foo = x |
| 06:30 | <annevk> | othermaciej, for style.foo to work foo has to bedefined on the CSS2Properties interface |
| 06:31 | <annevk> | othermaciej, storage.foo will always work (though maybe not when foo matches some existing member) |
| 06:32 | <Hixie> | Dashiva: it's easy to ensure there isn't :-) |
| 06:32 | Hixie | is utterly tangled up in a mess of defining scripting enabled/disabled on a per-browsing-context basis instead of globally |
| 06:33 | <othermaciej> | annevk: sure, it is a predefined list instead of completely open-ended, but CSS styles do have the concept of adding and removing properties, and those properties are reflected directly as JS-level properties |
| 06:33 | <Hixie> | i agree with anne that it's not the same |
| 06:33 | <Hixie> | "'opacity' in style" is always true |
| 06:33 | <Hixie> | it doesn't become false when the property is removed |
| 06:34 | <roc> | "removeProperty" is a misnomer from the JS point of view |
| 06:34 | <Hixie> | i'm not wedded to the 'delete' syntax, but i think your argument that it's the wrong semantic is not valid |
| 06:34 | <othermaciej> | the style declaration example is not to illustrate that it is the wrong semantic |
| 06:35 | <othermaciej> | it is to illustrate that, in general, you can reasonably have custom getters and setters without custom deleters |
| 06:35 | <othermaciej> | and this will not confuse people |
| 06:35 | <Hixie> | i don't think it would confuse people |
| 06:35 | <othermaciej> | that was roc's argument |
| 06:35 | <othermaciej> | that if you don't have custom delete, you shouldn't even have custom get and set |
| 06:35 | <Hixie> | i just think that in this particular case, it makes sense to offer custom delete |
| 06:36 | <roc> | it's custom *add* that I really think deserves a matching custom delete |
| 06:36 | <Dashiva> | I assume setting it to undefined to delete was considered and rejected, what was the reasoning? |
| 06:36 | <Hixie> | setting it to "undefined" would set it to the string "undefined" |
| 06:36 | <othermaciej> | set and add have the same syntax in JS |
| 06:36 | <Hixie> | as currently defined |
| 06:37 | <Hixie> | othermaciej: style.foo = 'baz' is matched by delete style.foo, for non-valid values of 'foo' |
| 06:37 | <roc> | of course they have the same syntax, that's part of the problem ehre |
| 06:38 | <othermaciej> | Hixie: or indeed, for any object it is true that when the setter does nothing special, delete works normally |
| 06:39 | <Hixie> | right |
| 06:39 | <Hixie> | so why is this different? |
| 06:39 | <othermaciej> | well, it's not usually the case that when the setter *does* do something special, delete still works normally |
| 06:40 | <othermaciej> | (or beyond that, delete does something correspondingly special) |
| 06:40 | <Hixie> | i don't think we've ever really had an equivalent interface before |
| 06:41 | <Hixie> | except maybe NamedNodeMap, which imho is poorly designed |
| 06:41 | <Hixie> | but like i said, i don't really care much about this |
| 06:42 | <othermaciej> | I don't care that much about the semantic argument, except that I think having custom delete is a small improvement, and supporting it correctly is potentially a nontrivial burden |
| 06:42 | <Dashiva> | Are there any common cases where you'd be deleting stuff often? |
| 06:43 | <Dashiva> | I figure if you're setting a property for storage you're likely to keep it. Maybe it'll be unused (e.g. set to nothing) in periods, but the use for the property isn't going to disappear |
| 06:43 | <othermaciej> | I will admit to being a little biased, in that the crazy dynamicity of JS makes me want to cling to any shred of statically determined behavior |
| 06:43 | <othermaciej> | I think delete is not going to be nearly as common as set/add or get, but it seems plausible |
| 06:44 | <othermaciej> | (in the style case too I would guess you set a lot more often than you remove) |
| 06:44 | <Hixie> | well, the ie/ff argument is a strong one -- what we really should be asking is whether the ff team and the ie team plan to remove the custom getting when they switch from globalStorage to localStorage |
| 06:44 | <roc> | I don't really know why custom delete would be a big burden if you already support custom add |
| 06:44 | <Dashiva> | Because add is actually set? |
| 06:44 | <roc> | in syntax it is |
| 06:45 | <othermaciej> | custom code running at set time is something we already have to live with |
| 06:45 | <roc> | but implementation-wise, not really |
| 06:45 | <roc> | or not necessarily |
| 06:45 | <othermaciej> | both due to DOM APIs and due to supporting the Mozilla getter/setter extension to ECMAScript |
| 06:45 | <roc> | BTW I almost always see style.opacity = ''; rather than removeProperty |
| 06:46 | <Dashiva> | Because they're equivalent in practice |
| 06:46 | <jgraham> | Dashiva: It seems like there would be lots of cases where you wanted to persist some property for a certian amount of time (e.g. till the network becomes available) and then stop persisting it |
| 06:46 | <Dashiva> | jgraham: Sure, and later when the network becomes unavailable again, you'd want to persist that same property with a new value |
| 06:46 | <othermaciej> | custom code at delete time (in particular, JS executing as a result of the event dispatch) would be new |
| 06:46 | <othermaciej> | it's not impossible to handle |
| 06:47 | <othermaciej> | but every additional bit of operator overloading makes the language harder to optimize |
| 06:47 | <jgraham> | Dashiva: In that sort of case I would tend to delete stuff rather than set it to some magic value (e.g. the empty string) |
| 06:47 | <Dashiva> | jgraham: Because the case is very rare, right? |
| 06:48 | <roc> | I don't think 'delete' is going to make any material difference to the optimizability of JS |
| 06:48 | <jgraham> | No just because it feels like cleaning up your storage area is the right thing to do |
| 06:48 | <Dashiva> | Yes, and you want to clean up because you don't expect to use it in the near future |
| 06:49 | <jgraham> | I guess that depends what near future means |
| 06:49 | <Dashiva> | What I'm trying to claim is that if you use a property often enough that you'd benefit from delete shorthand, you're using it often enough that you're likely to be just nullifying the value instead |
| 06:51 | <othermaciej> | roc: every statement that can run arbitrary code invalidates many assumptions |
| 06:51 | <othermaciej> | currently when you see this code: |
| 06:51 | <othermaciej> | var x = 1; |
| 06:51 | <roc> | since 'set' and 'get' are already in that class |
| 06:51 | <othermaciej> | delete z.y; |
| 06:51 | <othermaciej> | you can assume x has the same value afterwards |
| 06:51 | <roc> | that game is already over |
| 06:51 | <Hixie> | othermaciej: no you can't |
| 06:51 | <Hixie> | othermaciej: z.y might run a getter |
| 06:52 | <Dashiva> | (Only on z, right?) |
| 06:52 | <roc> | I think you're going to have to stretch really hard to find a realistic testcase where optimizing around deletes is important and there are no gets/sets in the way |
| 06:53 | <jgraham> | Dashiva: I don't have a strong opinion on that. I guess my Python bias makes me think that delete is a reasonable syntax for this case but it's dangerous to apply reasoning from one language in another |
| 06:53 | <othermaciej> | Hixie: ok, if z is a local variable or parameter you can |
| 06:53 | <roc> | even if you come up with one, the problem is still completely dwarfed by gets/sets, so I still find it hard to care |
| 06:54 | <othermaciej> | roc: sure, I don't think it will be common, but the other crazy dynamic things in the language suck so much that on principle I am against additional overloading |
| 06:54 | <Hixie> | othermaciej: well, get IE and FF (or at least one of them) to not support delete when they switch to localStorage |
| 06:55 | <othermaciej> | I don't really want to engage in a majority vote power struggle, I just wanted to express the downsides of overloading the delete operator (particularly in a way that runs JS code) |
| 06:55 | <Hixie> | othermaciej: (right now you can't tell from the spec that 'delete' is supposed to do anything, it's just an [XXX] marker) |
| 06:55 | <roc> | I appreciate your principles but it really is too late to apply them to JS |
| 06:55 | <othermaciej> | it's not as bad as overloading * or && would be |
| 06:55 | <Lachy> | how do I see the output from the assert statements in python? Is there some debug mode I need to turn on or something? |
| 06:56 | <othermaciej> | roc: it is certainly possible to infer useful knowledge from some of the operators that are still not overloaded |
| 06:56 | <jgraham> | Lachy: You don't unless the expression evaluates to False |
| 06:56 | <Hixie> | othermaciej: my point is that even if i agreed with you, i wouldn't be able to do anything about it at this point really |
| 06:56 | <Hixie> | othermaciej: since the spec doesn't actually explicitly mention this at all right now |
| 06:56 | <Lachy> | oh, ok. The python docs aren't clear about that at all |
| 06:56 | <roc> | othermaciej: yeah, absolutely |
| 06:57 | <jgraham> | if they eval to False you'll get an AssertionError raised |
| 06:57 | <Hixie> | othermaciej: (also, note that overloading [[Delete]] is explicitly supported by the ES spec, unlike overloading the * or && operators) |
| 06:57 | <roc> | other areas of the language aren't as goofy as properties |
| 06:57 | <othermaciej> | (I would again point to * and && as examples, boy would it suck if those depended on the input types) |
| 06:57 | <roc> | well |
| 06:57 | <roc> | * already does, if you're optimizing hard |
| 06:59 | Hixie | starts seeing the light at the end of his scripting-disabled-per-browsing-context tunnel of doom |
| 07:00 | <Hixie> | hm |
| 07:00 | <Hixie> | i wonder if parsing changes if i set designMode |
| 07:00 | <othermaciej> | for * you know the result is a number and you know it always converts to number and multiplies as number - skipping conversions or optimizing for a subset of numbers based on additional knowledge can indeed help, but it is not as bad as + |
| 07:01 | <othermaciej> | Hixie: I have made my case, I am not really inclined to lobby implementors beyond that |
| 07:01 | <othermaciej> | (I would reserve that for more important issues) |
| 07:01 | <Dashiva> | othermaciej: Implement it yourself then ;) |
| 07:02 | <roc> | obviously we should have a new mozDelete JS operator |
| 07:02 | <Hixie> | othermaciej: at least one of the vendors hasn't even heard your case (microsoft aren't on the whatwg list) |
| 07:02 | <othermaciej> | Dashiva: WebKit already implements localStorage |
| 07:02 | annevk | gets a steady stream of html4all e-mails written by RB |
| 07:02 | <Hixie> | othermaciej: so i'm not sure what you're expecting to have happen |
| 07:02 | annevk | thinks it's time to go to bed |
| 07:03 | <Dashiva> | othermaciej: Hmm. It's hard to not implement delete any more than you already have, then. |
| 07:04 | <othermaciej> | Brady actually implemented delete but I'd like to encourage him to remove it |
| 07:05 | <Hixie> | sigh, ie8 throws an exception saying you can't get document.designMode if you try to set it (not get it) while parsing |
| 07:05 | <othermaciej> | Hixie: I am not expecting anything, I am just declining the action item of trying to persuade other implementors to do or not do anything specific when they implement localStorage (beyond stating the facts) |
| 07:05 | <takkaria> | RB has an interesting idea of use-cases |
| 07:05 | <Hixie> | othermaciej: ok |
| 07:06 | <othermaciej> | Hixie: but I can forward the thread to public-html if you think that would be helpful |
| 07:08 | <Hixie> | othermaciej: i don't really know what would be helpful. the spec will have to require [Delete] support of the browsers support it, though |
| 07:08 | <Hixie> | othermaciej: so at the end of the day, it _is_ a majority vote |
| 07:09 | Dashiva | wonders about the IE extensions to storage |
| 07:23 | <othermaciej> | Hixie: honestly I am more worried about whether Firefox and IE will transition to localStorage at all, or if we'll end up having to also implement globalStorage in WebKit |
| 07:24 | <othermaciej> | hopefully IE can since they are still just a beta but who knows? |
| 07:24 | <Hixie> | i hope ff does, since they were the reason we changed the api |
| 07:25 | <Hixie> | i have little hope of anything convenient to the health of the web coming from the IE team |
| 07:25 | <Hixie> | i mean, they couldn't even implement globalStorage without embrace-and-extending it |
| 07:25 | <Hixie> | even if they don't mean to, they seem to just act that way out of habbit |
| 07:27 | <othermaciej> | it does seem kind of habitual |
| 07:40 | <Dashiva> | othermaciej: Should it really say prefix twice? "This class is designed to carry a prefix but match exclusively on the prefix and namespaceURI" |
| 08:39 | <Philip`> | Hixie: Is it meant to be non-conforming if scripts cause an invalid state at any point during their execution, or only when they've finished? (e.g. if you do "img = document.createElement('img'); document.body.appendChild(img); img.src = '...'" is it non-conforming because there's (temporarily) an invalid state (with a srcless img)?) |
| 08:40 | <Hixie> | uh let me fix that hold on |
| 08:44 | MikeSmith | reads starts a read-through of r1643 <iframe sandbox> diff |
| 08:45 | <Philip`> | Good luck with that :-) |
| 08:45 | Philip` | just skimmed it to see if there were any obvious changes like an ASCII art elephant graphic |
| 08:48 | <Hixie> | Philip`: fixed |
| 08:51 | <Philip`> | Hixie: Thanks |
| 08:52 | MikeSmith | notes that http://dev.w3.org/cvsweb/html5/spec/Overview.html.diff?r1=1.830&r2=1.831&f=h provides side-by-side colored diff for those who like such things (I like the html5.org web-apps tracker view better myself...) |
| 08:53 | <Philip`> | Hixie: It seems unfair to only exempt automated conformance checkers from interpreting the author's intent - non-automated ones might be equally unable to interpret intent in some cases |
| 08:53 | <Dashiva> | I don't like how it selects the entire line with the background color |
| 08:55 | <Dashiva> | Lots of font tags there, ho |
| 08:55 | Dashiva | smiles at <font face="Helvetica,Arial" size="-1"> </font> |
| 08:55 | <Philip`> | e.g. I might submit a document written in Lojban to a non-automated conformance checking service, and they could point out lots of non-machine-checkable issues (like if I used <b> instead of <h1>) but couldn't possibly check all the issues (like if the alt text was a decent alternative to the image) |
| 08:57 | <Philip`> | I don't like the idea of conformance checkers anyway, I'd prefer conformance chess |
| 09:00 | <Dashiva> | If you lose, your page is deleted? |
| 09:02 | <Hixie> | Philip`: why couldn't a human determine if the page had good alt text? |
| 09:03 | <Hixie> | or rather, not good, but spec-compliant alt text |
| 09:03 | <Dashiva> | If he doesn't know the language |
| 09:04 | <Hixie> | one would need to know the language to correctly assess conformance of a document |
| 09:04 | <Hixie> | just like one would need more than 2 bytes of memory to correctly assess conformance of a document |
| 09:04 | Dashiva | sees a challenge! |
| 09:05 | <Dashiva> | How much cache do I get? |
| 09:05 | <Hixie> | none |
| 09:05 | <Dashiva> | Darn |
| 09:05 | <Hixie> | 2 bytes memory total |
| 09:05 | <Hixie> | including registers |
| 09:05 | <Hixie> | and I/O |
| 09:05 | <Dashiva> | Address space? |
| 09:05 | <Hixie> | one bit address space, 0 addresses the first byte, 1 addresses the second. |
| 09:07 | <Hixie> | you actually could do it in a conforming way -- just invoke the "User agents may impose implementation-specific limits on otherwise unconstrained inputs" rule to say that you only check documents up to 2 bytes |
| 09:07 | <Hixie> | and always say it'ss non-conforming |
| 09:07 | <Hixie> | but that's not the point! :-P |
| 09:07 | <Dashiva> | With enough disk space, and enough exams to procrastinate, I'm sure I could cook up something insane |
| 09:07 | <Hixie> | no disk space, you have 2 bytes total |
| 09:07 | <Hixie> | for everything |
| 09:08 | <Hixie> | program, data, cache, registers, everything |
| 09:08 | <Dashiva> | I have this vague feeling we've deviated from the initial problem statement somewhat |
| 09:08 | <Hixie> | including the video RAM |
| 09:08 | <Hixie> | :-) |
| 09:08 | <Hixie> | my point was just that there are minimum requirements for determining conformance |
| 09:08 | <Hixie> | one of those is (for non-automated checkers) knowign the language |
| 09:19 | <Philip`> | The service wouldn't be certifying conformance, it would just be helping me improve the quality of my document, so it's useful even if it isn't complete |
| 09:20 | <Hixie> | sure |
| 09:20 | <Hixie> | web browsers are useful even when they're not conforming too |
| 09:20 | <Hixie> | conformance isn't a minimum requirement for usefulness |
| 09:21 | <Hixie> | not by a long shot |
| 09:23 | Philip` | goes to bed :-) |
| 09:23 | <Hixie> | nn :-) |
| 11:28 | <Hixie> | hm, <iframe sandbox> for the first time introduces the concept of a document's origin changing while the document is up |
| 11:29 | <Hixie> | you could do var e = iframe.contentDocument.documentElement; iframe.setAttribute('sandbox', ''); |
| 11:29 | <Hixie> | at that point, you can navigate 'e' fine, but if you try to read anything from e.parentNode, you get an exception |
| 11:29 | <Hixie> | good times |
| 11:34 | <jruderman> | doesn't document.domain do that too? |
| 11:36 | <Hixie> | oh, i guess so |
| 11:36 | <Hixie> | yeah, fair enough |
| 11:37 | <jwalden> | thankfully that's the only other one |
| 11:37 | <Hixie> | though that one just changes the "effective origin" not the true origin |
| 11:37 | <jwalden> | effective origin is what matters, no? |
| 11:37 | <Hixie> | er, "effective script origin" |
| 11:37 | <jwalden> | for sec |
| 11:38 | <Hixie> | depends what for |
| 11:38 | <Hixie> | per spec document.domain doesn't affect where you can take images from for <canvas>, for instance |
| 11:39 | <Hixie> | and the rules for which browsing contexts you can navigate aren't affected by document.domain per spec |
| 11:39 | <jwalden> | oh, yeah |
| 11:41 | <Hixie> | and if you meta refresh to an http uri that redirects to a javascript: uri, the javascript: uri compares the original origin to the redirecting uri's origin to decide whether to run or not (and then runs in the same global context, but fails almost immediately since it can't get to anything on the Window or Document objects since it has a different effective script origin) |
| 11:41 | <Hixie> | hm, maybe that is a bug |
| 11:41 | <Hixie> | anyway |
| 11:41 | <Hixie> | the Web security model is going to be promising job security for us for years to come |
| 11:42 | <jruderman> | hah |
| 11:47 | <roc> | hmm |
| 11:47 | <roc> | changing the principal on a document actually sounds very scary |
| 11:47 | <roc> | that might be something to avoid if we can |
| 11:56 | <jwalden> | I think it's impossible to do that |
| 11:57 | <roc> | do it, or avoid it? |
| 11:57 | <jwalden> | avoid changing the principal |
| 11:58 | <roc> | we could just say that dynamic changes to 'sandbox' don't have any effect until a new document is loaded in the iframe |
| 11:58 | <jwalden> | that doesn't address document.domain |
| 11:58 | <jwalden> | but that seems like a good idea anyway |
| 12:17 | <Hixie> | roc: yeah, maybe |
| 12:17 | <Hixie> | roc: once i've sent out the e-mail where i say i added this, please do send any feedback you have :-) |
| 12:17 | <Hixie> | it'll likely be a few hours or days yet though |
| 12:18 | <roc> | our feedback on that should come from boris |
| 12:20 | <Hixie> | that's good too :-) |
| 12:20 | <Hixie> | this is all highly speculative stuff |
| 12:20 | <Hixie> | no rush or anything on any of this |
| 12:20 | <Hixie> | (sandbox="" or seamless="") |
| 12:21 | <roc> | these are features people have been asking for for years |
| 12:21 | <Hixie> | yeah |
| 12:21 | <roc> | I guess you saw the Mozilla bug |
| 12:21 | <Hixie> | indeed |
| 12:22 | <Hixie> | speccing this stuff was basically impossible until recent weeks, because it depends on so much of the previously unspecified stuff in really core ways |
| 12:22 | <Hixie> | i mean, it depends on the navigation model, on multiple windows, on how scripts run, on same-origin... it's got its tentacles all over the stuff that didn't ever get acknowledged before HTML5 |
| 12:23 | <Hixie> | these features may in fact be the first real author-visible tangible benefits of having this spec be this detailed |
| 12:24 | jwalden | fights the urge to make a bad pun on the mailing list |
| 12:25 | <roc> | why fight it |
| 12:25 | <jwalden> | because I'm not sure I have much more that's useful to say at the same time |
| 12:25 | <jwalden> | at least not if we wanted the test harness to be usable in current browsers |
| 14:51 | <hsivonen> | "Require that Henri do the impossible by checking that scripts never cause non-conforming states to occur." great |
| 16:02 | <annevk> | hsivonen, his various definitions of compatible are pretty strict |
| 16:02 | <annevk> | hsivonen, probably needs more ~ usage :) |
| 16:07 | <annevk> | " |
| 16:07 | <annevk> | The difficult, important, and often overlooked part of a version identification strategy is specifying the meaning and interpretation when a consumer encounters a version identifier it does not know about." |
| 16:07 | <annevk> | that's actually not just true for versioning :) |
| 16:11 | <hsivonen> | I think it is good that the doc acks that version identifiers aren't necessary, but it would be better to say that they are actually harmful |
| 16:12 | <annevk> | yes |
| 16:13 | <annevk> | maybe we should comment |
| 16:22 | <Hixie> | one day y'all will realise the true value of TAG findings... |
| 16:23 | <Hixie> | hsivonen: it wasn't really a major change to what we understood the spec to say anyway, i just hadn't realised that we hadn't made conformance checkers check for all conformance states |
| 16:23 | <Hixie> | hsivonen: it doesn't really affect you at all |
| 16:24 | <othermaciej> | is it greater than the value of TAG losings? |
| 16:26 | <hsivonen> | Hixie: as I said before, Dave Orchard's presentation about compatibility was good stuff before he got to applying it to XSD (it was XSD's fault that it wasn't as good from there on) |
| 16:27 | <hsivonen> | Hixie: I was just pointing out to annevk where the same reasoning is written down |
| 16:34 | <hsivonen> | aargh. I accidentally introduced a lot of bugs with Eclipse's refactoring tools |
| 16:36 | <roc> | Undo |
| 16:37 | <hsivonen> | roc: that would break a lot of good stuff too |
| 16:37 | <roc> | Redo :-) |
| 16:37 | <hsivonen> | fortunately, I have a way of identiying the problematic points |
| 16:37 | <Philip`> | Right click -> Remove Bugs (ctrl+alt+shift+r) |
| 17:38 | <Hixie> | what were the attributes we'd come up with for replacing data: URIs on <iframe>s? |
| 17:39 | <annevk> | html="" |
| 17:39 | <annevk> | markup="" |
| 17:39 | <annevk> | content="" |
| 17:39 | <hsivonen> | aren't data URIs more compatible? |
| 17:40 | <hsivonen> | or do we want incompatibility for security? |
| 17:40 | <Hixie> | data: URIs require too much thinking |
| 17:40 | <Hixie> | you have to escape too many characters (three four to be minimally safe, more to be compliant) |
| 17:41 | <Hixie> | and you don't get much backcompat anyway |
| 17:41 | <Hixie> | since IE doesn't support them |
| 17:42 | <hsivonen> | Hixie: by the time anyone ships a sandbox, IE8, Firefox, Safari and Opera together will be a big legacy |
| 17:42 | <Hixie> | a new attribute only really desperately needs one character escaped (the delimiter -- typically " => ") and for correctness the ampersand (& => &) though the latter isn't security-critical, and the former is very obvious if you get it wrong |
| 17:44 | <annevk> | ah crap, <meta> has stolen content="" already it seems |
| 17:44 | <Hixie> | IE8 doesn't support <iframe src="data:text/html,..."> either |
| 17:44 | <Hixie> | at least not in beta1 |
| 17:44 | <Hixie> | (acid3 tries to take care of that, but that's not likely to be seen until IE9) |
| 17:44 | <Hixie> | (and that's assuming a major IE8.5 between 8 and 9) |
| 17:47 | <annevk> | I like content="" the best |
| 17:48 | <Hixie> | "src", "source", "src2", "content", "value", and "data" are all vetoed |
| 17:48 | <Hixie> | doc="" is currently leading the pack |
| 17:48 | <Hixie> | with html="" a close second |
| 17:48 | <hsivonen> | will it accept only HTML fragments or XML too? |
| 17:48 | <Hixie> | HTML |
| 17:49 | <annevk> | that violates some principle you had initially |
| 17:49 | <Hixie> | which one? |
| 17:49 | <annevk> | that uas wouldn't be required to support both parsers if they didn't want to |
| 17:49 | <Hixie> | UAs wouldn't be |
| 17:49 | <annevk> | so XML UAs may ignore doc=""? |
| 17:49 | <hsivonen> | time to disassemble my code and count the bytes again... |
| 17:49 | <Hixie> | i dunno :-) |
| 17:50 | <Hixie> | doc="" doesn't exist |
| 17:50 | <Hixie> | it's just an idea |
| 17:50 | <Hixie> | i don't really want to skew this just to make the xml crowd happy |
| 17:50 | <Hixie> | since in practice nobody will use the xml version |
| 17:51 | <annevk> | htmldoc="" |
| 17:51 | <Hixie> | or type="" |
| 17:51 | <Hixie> | there are various options |
| 17:51 | <annevk> | lets not overload type even more :) |
| 17:52 | <Hixie> | does <iframe> have a type=""? |
| 17:52 | <Lachy> | Hixie, I think it does in HTML4 |
| 17:52 | <Hixie> | cool |
| 17:52 | <Hixie> | well then |
| 17:52 | <Hixie> | we just use that |
| 17:52 | Lachy | checks... |
| 17:52 | <annevk> | doesn't seem like it... |
| 17:52 | <annevk> | does have longdesc :) |
| 17:53 | <Lachy> | actually, it doesn't |
| 17:53 | <hsivonen> | w00t. only 7933 bytes |
| 17:54 | <Lachy> | what problem is this new attribute trying to solve? |
| 17:54 | <Hixie> | if it doesn't have it, then i say we're fine with using it for our piurposes |
| 17:54 | <Hixie> | which new attribute? |
| 17:54 | <Lachy> | the one you're discussing adding to iframe |
| 17:54 | <Hixie> | doc="" or type=""? |
| 17:55 | <Hixie> | doc="" solves the problem of there not being any good safe way to embed content inline in a sandbox |
| 17:55 | <annevk> | making type conforming will led to confusion when it is not used together with doc |
| 17:55 | <annevk> | lets call it doctype="" |
| 17:55 | <Hixie> | type="" solves the theoretical problem of not being able to decide whether doc="" is html or xml or text/plain or png... |
| 17:55 | <Hixie> | annevk: :-P |
| 17:56 | <Lachy> | ok, so it's a backwards incompatible replacement for data URIs that provides security in new browsers without compromising older ones. |
| 17:57 | <Hixie> | data: URIs don't really provide what we need here, so it's not a replacement for them |
| 17:57 | <Hixie> | data: URIs are too complicated to correctly escape to really be a good security solution |
| 17:57 | <Lachy> | I don't really like the idea of embedding markup within an attribute |
| 17:58 | <Hixie> | do you have a better idea? |
| 17:58 | <Lachy> | but I have no alternative solution |
| 17:58 | <Hixie> | i agree that it's suboptimal |
| 18:00 | <annevk> | alternatively we could put it inside <iframe> ... |
| 18:01 | <annevk> | though maybe that's more icky for authors than just escaping " |
| 18:01 | <Lachy> | is the proposal do be able to include fragments of HTML in them like this: <iframe doc="<p>hello <em>world!</em>">, and then that creates a document within the frame using that fragment? |
| 18:01 | <Hixie> | content inside <iframe> has REALLY obscure escaping semantics |
| 18:01 | <Hixie> | Lachy: yes |
| 18:01 | <Hixie> | Lachy: well, that's a variant of hte proposal |
| 18:01 | <Hixie> | i'm writing it up in more detail in the e-mail i'm sending |
| 18:02 | <Lachy> | I assume authors won't need to include <!DOCTYPE html> in the fragment? |
| 18:02 | <Hixie> | we could make that implicit, probably |
| 18:02 | <Lachy> | and it would only allow elements that are valid within <body> |
| 18:02 | <Hixie> | hy? |
| 18:03 | <Hixie> | why, even |
| 18:03 | <Lachy> | hm. I guess that's not necessary |
| 18:04 | <othermaciej> | putting unescaped markup in a quoted string seems like it makes it easy to accidentally terminate the attribute value early |
| 18:04 | <othermaciej> | (or maliciously) |
| 18:05 | <Hixie> | othermaciej: luckily, that is trivially detectable, and easy to solve |
| 18:05 | <Hixie> | othermaciej: even without security attacks, people will use " or ' in their comments and thus it'll be caught quickly |
| 18:06 | <Hixie> | othermaciej: and the delimiter is the only character you absolutely must escape |
| 18:06 | <othermaciej> | I thought your major argument against some approaches to inline sandboxing was that they still require (minimal) escaping |
| 18:07 | <Hixie> | my objections were that they required non-trivial or easy-to-get-wrong escaping. |
| 18:07 | <Hixie> | people would be motivated to get this right for reasons other than just security |
| 18:08 | <othermaciej> | escaping case-insensitive </sandbox> is not very hard, though certainly possible to get wrong |
| 18:08 | <Hixie> | since getting it wrong would break the entire page the moment someone used a quote or apostrophe (as appropriate) |
| 18:08 | <Hixie> | othermaciej: sure but people don't type </sandbox> in as a matter of course |
| 18:08 | <Hixie> | othermaciej: so there it becomes _only_ a security problem |
| 18:09 | <Hixie> | othermaciej: and since it's more than one character, you end up with problems with over-long utf-8 sequences, embedded nulls, all kinds of stuff like that |
| 18:09 | <Hixie> | othermaciej: none of which affects a single quote mark |
| 18:09 | <Hixie> | well the overlong utf-8 might i guess |
| 18:09 | <othermaciej> | you have to normalize in any case |
| 18:10 | <othermaciej> | (unicode normalize) |
| 18:10 | <othermaciej> | (or reject input that is not in normal form already) |
| 18:10 | <Hixie> | who does? |
| 18:11 | <Hixie> | as far as i can tell, with the doc="" idea everyone or anyone can forget to normalise and you're still ok |
| 18:11 | <othermaciej> | whoever is escaping quotes |
| 18:12 | <othermaciej> | (i.e. whoever processes the input after receiving it from an untrusted source but before putting it in the attribute value) |
| 18:12 | <Hixie> | why? |
| 18:12 | <annevk> | escaping </sandbox> would not cut it btw, consider </sandbox > |
| 18:13 | <othermaciej> | would escaping "</sandbox" cut it? |
| 18:13 | <othermaciej> | Hixie: to successfully escape denormal close quotes? |
| 18:13 | <othermaciej> | or am I missing the point of your "overlong utf-8" remark? |
| 18:13 | <Philip`> | You could easily forget to escape "</sandbox" case-insensitively |
| 18:14 | <annevk> | case-insensitive </sandbox might, but then so would </iframe i suppose |
| 18:15 | <annevk> | still, " seems a lot easier |
| 18:16 | <othermaciej> | it is easier, but the attribute approach has the big downside that you need an iframe per item to be sandboxed, and iframes are heavyweight |
| 18:17 | <othermaciej> | so if we can countenance some escaping of untrusted content being required, I'd rather see a version that is usable for hundreds or thousands of items |
| 18:17 | <Philip`> | Heavyweightedness is just an implementation bug :-) |
| 18:17 | <Hixie> | othermaciej: i'm confused. I'm talking about encoding U+0022 as, e.g., 0xC0 0xA2. |
| 18:17 | <Hixie> | othermaciej: which has nothing to do with unicode normalisation forms |
| 18:18 | <othermaciej> | Hixie: then I apologize for using the terminology incorrectly |
| 18:18 | <annevk> | othermaciej, ah yeah, creating hundreds of document objects is costly |
| 18:18 | <annevk> | not really sure how to do something smarter than that though |
| 18:18 | <othermaciej> | Philip`: some of the heavyweightedness of iframe is effectively required by specs |
| 18:18 | <Hixie> | othermaciej: all the workable sandboxing approaches i've seen so far invoke new browsing contexts (iframes) |
| 18:18 | <annevk> | afaict with <sandbox> you have the same issue, no? |
| 18:19 | <Hixie> | othermaciej: the only differences between the working proposals i've seen is how they encode the data |
| 18:19 | <Hixie> | othermaciej: i don't understand how to do origin isolation without a separate browsing context |
| 18:19 | <othermaciej> | Hixie: I agree you can't do a sandbox with any scripting enabled without a separate browsing context |
| 18:19 | <othermaciej> | (not feasibly anyway) |
| 18:19 | <othermaciej> | I think you can do a noscript sandbox without an extra browsing context or document |
| 18:20 | <Hixie> | it's not just scripting |
| 18:20 | <Hixie> | e.g. target="" and forms would need very complicated and subtle changes to be done safely without an iframe |
| 18:21 | <Hixie> | and i'm not confident that i could spec those precisely enough to avoid introducing security bugs into the spec |
| 18:22 | <Hixie> | and i'm certainly not willing to take on the responsibility for spec-mandated security holes in humanity's most widely deployed application platform :-) |
| 18:22 | <Hixie> | i can't afford the legal fees, for one |
| 18:23 | <annevk> | i hope you have some protection against that regardless :) |
| 18:23 | <othermaciej> | I think for the use case of the inline sandbox (blog comments or the like) it would be ok to totally ban targetted links and form elements (parser discards them) |
| 18:23 | <othermaciej> | and if the spec is found to require security holes it will be ignored on that count as I am sure you know |
| 18:23 | <annevk> | MessageEvent.uri comes to mind :) |
| 18:23 | <annevk> | though that's more a privacy issue |
| 18:23 | <Hixie> | othermaciej: not before multiple shipping implementations are out there, possibly with content depending on it (e.g. look how far we've gotten with blocking cross-origin <script> or form submissions) |
| 18:24 | <Philip`> | Hixie: Just add a statement "UAs must not contain any security holes" - if the spec also requires certain features which are security holes, then any UA trying to implement HTML5 will necessarily be non-conforming and not your problem any more |
| 18:24 | <Philip`> | For blog comments, could you put the entire comments section in a single sandbox? |
| 18:24 | <Philip`> | (to avoid the issues with having hundreds of separate sandboxes on a single page) |
| 18:25 | <Hixie> | othermaciej: (i'm not at all convinced i could catch all cases -- e.g so far your proposal has not covered banning <meta http-equiv=refresh>) |
| 18:25 | <othermaciej> | Philip`: often you want un-sandboxed content near each comment |
| 18:25 | <Hixie> | having one sandbox might work |
| 18:25 | <othermaciej> | Philip`: so not sure that works |
| 18:25 | <Hixie> | but there is that issue |
| 18:25 | <othermaciej> | Hixie: is <meta http-equiv=refresh> allowed in the body? |
| 18:26 | <Hixie> | nope, but the parser doesn't care about that |
| 18:26 | <othermaciej> | I don't really mean allowed |
| 18:26 | <othermaciej> | I mean, does it work when in the body |
| 18:26 | <Hixie> | sure |
| 18:26 | <Hixie> | i'm not sure how you'd disable script on a per-element basis, either |
| 18:26 | <annevk> | it could work if the parser just dropped certain elements during a certain mode |
| 18:27 | <annevk> | "in sandbox insertion mode" |
| 18:27 | <annevk> | or something |
| 18:27 | <Hixie> | e.g. you'd have to somehow handle <img src="foo.cgi"> redirecting to a javascript: URI |
| 18:27 | <othermaciej> | Hixie: redirecting to a javascript: URI is not allowed in any case |
| 18:27 | <Hixie> | it is per spec at the moment |
| 18:27 | <othermaciej> | (it would be a security hole) |
| 18:27 | <Hixie> | and it is nicely and safely defined |
| 18:28 | <Hixie> | (it runs in a void execution context and its return value is used as the image data) |
| 18:28 | <othermaciej> | disallowing redirect to javascript: is perfectly safe |
| 18:28 | <Hixie> | (unless the origins match in which case it runs in the context of the page, iirc) |
| 18:28 | hsivonen | wants to see an accessibility advocate type alt text for hundreds of vacation photos |
| 18:28 | <othermaciej> | I don't see the point of allowing it, context notwithstanding |
| 18:29 | <Philip`> | annevk: Then some people would want to handle <!--[if IE]><script>alert('haxxored')</script><![endif]--> too, and it'd seem a bit dangerous |
| 18:29 | <Hixie> | well it's just one example of what the spec does currently allow which we would have to handle somehow |
| 18:29 | <othermaciej> | I think the spec just shouldn't allow that |
| 18:29 | <othermaciej> | but good point |
| 18:29 | <Hixie> | with a browsing context, handling it is trivial |
| 18:29 | <Hixie> | you just disable scripting. |
| 18:30 | <othermaciej> | well, you have to make sure not to create a special-case void scripting context there either |
| 18:30 | <othermaciej> | I wouldn't assume that just automatically follows |
| 18:30 | <annevk> | Philip`, I'm assuming conforming parsers |
| 18:31 | <Lachy> | Hixie, how can U+0022 be encoded as 0xC0 0xA2? That doesn't seem to work |
| 18:32 | <Hixie> | Lachy: lax UTF-8 decoders that do no sanity checking would decode that to U+0022 |
| 18:32 | <Philip`> | annevk: That seems like an impractical assumption |
| 18:34 | <annevk> | Philip`, your practical assumption has security holes |
| 18:37 | <Philip`> | annevk: My assumption that some people won't implement the parser precisely, combined with your suggestion to enforce security rules in the parser, is what has security holes |
| 18:41 | <annevk> | Hixie, you went from attribute DOMString to boolean DOMString |
| 18:43 | <annevk> | you want attribute boolean |
| 18:43 | <Hixie> | lol |
| 18:43 | <Hixie> | i suck |
| 18:59 | annevk | wonders which browser Hixie used |
| 19:00 | <hsivonen> | chaals++ on wai-xtech |
| 19:00 | <Hixie> | safari trunk |
| 19:00 | <Hixie> | i may have js disabled, i didn't check |
| 19:00 | <Hixie> | i've been doing tests that involve disabling js recently |
| 19:00 | <annevk> | k |
| 19:00 | <Dashiva> | A gallery that doesn't work without JS is pretty sad |
| 19:01 | <annevk> | i wrote it myself for myself so i don't really care about that |
| 19:01 | <annevk> | though cross browser would be nice |
| 19:01 | <Dashiva> | :) |
| 19:01 | <annevk> | at some point i guess i will use pushState() and such |
| 19:01 | <Hixie> | if it's for yourself, interop isn't important and worrying about conformance seems mostly pointless |
| 19:02 | <Hixie> | let alone accessibility |
| 19:34 | <hsivonen> | Hixie: do you have a full list of known (including non-conforming HTML legacy) attributes for HTML, MathML and SVG? |
| 19:59 | <hsivonen> | Philip`: do you have a full attribute list by any chance? |
| 20:02 | hsivonen | is glad Hixie didn't add xml:id to the adjustable attributes |
| 20:04 | <annevk> | I'm pretty sure that was a conscious decision |
| 20:04 | <hsivonen> | me too |
| 20:05 | <annevk> | hsivonen, full attribute list is pretty hard to determine, no? |
| 20:05 | <hsivonen> | annevk: perhaps, but presumable Hixie already did part of the work in order to find the camelCased ones |
| 20:10 | <annevk> | hsivonen, oh, I think that list is complete, but doesn't include SVG 1.2 |
| 20:19 | <hsivonen> | annevk: I need a list that includes non-camelcase SVG and HTML (incl legacy) and MathML |
| 20:23 | <takkaria> | Doug Crockford's JS book is well-written |
| 21:17 | <Philip`> | hsivonen: I don't |
| 21:18 | <hsivonen> | Philip`: ok. thakn |
| 21:18 | <hsivonen> | s |
| 21:24 | <hsivonen> | dealing with xmlns cruft in the V.nu parser is painful |
| 21:26 | MikeSmith | contemplates making joke about how maybe some people would say namespaces should have been titled pain-spaces, but reconsiders... |
| 22:04 | <Dashiva> | I wonder if Dmitry would have better luck with his proposals if he didn't invent new words for every single term |
| 22:07 | <MikeSmith> | using "Man of good will," as a salutation is nice, though |
| 22:08 | <MikeSmith> | the spirit of optimism in it |
| 22:08 | <Lachy> | it's werid and I don't like it. |
| 22:08 | <MikeSmith> | Lachy: c'mon |
| 22:09 | <Philip`> | http://lists.xml.org/archives/xml-dev/200805/msg00087.html |
| 22:09 | <Philip`> | Not sure where else it's been posted |
| 22:09 | <MikeSmith> | I think "quixotic" is the word I'm looking for |
| 22:10 | <MikeSmith> | Lachy: please consider adding Cervantes "Don Quixote" to your reading list, if you haven't read it yet |
| 22:10 | <MikeSmith> | before or after "At Swim-Two-Birds" |
| 22:11 | <Lachy> | MikeSmith, it's far too formal for a place that is more comfortable when treated as a relatively informal discussion channel in most cases |
| 22:12 | <MikeSmith> | yeah, I suppose it is if you take it too seriously |
| 22:13 | <takkaria> | windows mobile is one of the worst OSes I've ever ever used |
| 22:13 | <MikeSmith> | but it's a quite appropriate way to address the world if you're battling windmills |
| 22:13 | <MikeSmith> | takkaria: amen to that |
| 22:14 | <Philip`> | MikeSmith: You think it's optimistic to imply there's one man in the HTML WG who is of good will? |
| 22:15 | <MikeSmith> | Philip`: ah geez.. I really doubt he means to imply that |
| 22:16 | <Philip`> | takkaria: Windows, Linux and OS X are three of the worst desktop OSes I've ever used |
| 22:16 | <MikeSmith> | Windows Mobile in a special class by itself |
| 22:16 | <Philip`> | (though they're also three of the best) |
| 22:16 | <hsivonen> | gotta love all the special attentition lang/xml:lang requires... |
| 22:17 | <MikeSmith> | if you want a good laugh, try some javascript timing tests on a windows mobile device some time |
| 22:17 | <MikeSmith> | or any kind of timing test |
| 22:18 | <Philip`> | or any other kind of test |
| 22:18 | <MikeSmith> | heh |
| 22:18 | <takkaria> | if you want two hours of frustration, try to send a file that's about 0.5MB smaller than the amount of space you have free on your storage card via bluetooth |
| 22:19 | <takkaria> | because it seems to accept the file, ask if you want to save it, and when you answer "yes", delete it since it's worried about free space |
| 22:20 | <takkaria> | and AFAICT, there's no way to tell it to save on the 1GB microSD card which has more than enough free space for fifty copies of the same file |
| 22:20 | <takkaria> | </rant> |
| 22:21 | hsivonen | tries to trade memory for execution speed with the attribute silliness |
| 22:23 | <takkaria> | hmm, Gez seems to think that the entirely emotive reply to Hixie about his lack of empathy was appropriate in a technical context |
| 22:26 | <Dashiva> | And this from the same crowd who insist that we absolutely must take into consideration AT five versions outdated because the users don't upgrade :) |
| 22:27 | <Philip`> | The best thing about the alt discussion is that the really long threads look pretty in Gmail when it shows the colour-coded names of authors |
| 22:28 | <takkaria> | I also emailed Gez privately just because emailing the list seemed like it was clogging up people's inboxes |
| 22:28 | <takkaria> | sigh |
| 22:30 | <hsivonen> | aaaargh. it's crazy how much code I have to write to support both HTML5 DOMs and XML 1.0 + Namespaces infosets |
| 22:31 | <hsivonen> | Namespaces-- |
| 22:31 | Philip` | suggests dropping XML support |
| 22:32 | <Philip`> | XML isn't even trendy any more, so there's no reason to bother with it |
| 22:32 | <hsivonen> | Philip`: that would mean violating the SAX API all the time and dropping generic DOM support and dropping XOM support |
| 22:33 | <Philip`> | Hmm, I suppose that could be cosidered a bit of a pain |
| 22:35 | <hsivonen> | the thing is that only the TreeBuilder knows if xlink:href needs to be dropped on the floor or kept when the parser is coercing the data into a proper infoset |
| 22:48 | Philip` | isn't sure "tangents of tangents" has a particularly useful geometric meaning :-( |
| 22:48 | <takkaria> | Philip`: sorry |
| 22:49 | <Philip`> | since a tangent is a straight line touching some other line, so a tangent of a tangent would just be the tangent itself :-p |
| 22:49 | <takkaria> | luckily I wasn't using it geometrically |
| 22:49 | <hsivonen> | Philip`: only in 2D |
| 22:49 | <Philip`> | Indeed - in that case it does make sense :-) |
| 22:49 | <takkaria> | hmm, this discussion would then be a tangent of a tangent of a tangent... |
| 22:50 | <Philip`> | hsivonen: s/straight line/(N-1)-dimensional plane in an N-dimensional space/ |
| 22:51 | Philip` | hopes he didn't get that entirely wrong |
| 22:51 | <hsivonen> | the attribute names are much worse than the element names |