| 06:58 | <annevk> | yay for simplified HTML |
| 06:58 | <annevk> | euh, XBL |
| 06:58 | <annevk> | guess I should read that |
| 07:42 | <annevk> | Hixie, do you care about oversights? |
| 07:42 | <annevk> | Hixie, e.g. XBLContentElement should be HTMLContentElement |
| 07:47 | <Hixie> | annevk: yeah... mail me what you see |
| 07:47 | <Hixie> | annevk: i have like 200 e-mails of feedback I haven't yet looked at |
| 07:47 | <Hixie> | annevk: before i actually go and fix the problems i want to see how much people like the simplified stuff |
| 07:49 | <annevk> | yeah, I wonder if we can simplify it even more |
| 07:50 | <Hixie> | we definitely can, the question is can we simplify it more without losing use cases |
| 07:51 | <annevk> | fwiw, I like it, but I also liked the original |
| 08:00 | <Hixie> | yeah |
| 08:01 | <Hixie> | the new one has some annoying problems |
| 08:01 | <Hixie> | problems which are why we didn't do it in html in the first place |
| 08:01 | <Hixie> | like you can't make a binding for <select>, say |
| 08:01 | <Hixie> | becaue <template> would always be "in body" |
| 08:02 | <annevk> | what if we made <template> act like a foreign land container except elements would still be in the HTML namespace? |
| 08:02 | <annevk> | or maybe do that for binding |
| 08:20 | <annevk> | ooh |
| 08:20 | <annevk> | Ian Fette has not added versioning |
| 08:20 | <annevk> | it was just proposed by Greg Wilkins |
| 08:20 | <annevk> | pfew |
| 08:20 | <zcorpan_> | Hixie: you can keep the background color, it's the shadow that disturbs me |
| 08:20 | <zcorpan_> | where's this xbl simplified you guys are talking about? |
| 08:21 | <annevk> | on the interwebs |
| 08:21 | <annevk> | http://dev.w3.org/2006/xbl2/Overview.html |
| 08:22 | <zcorpan_> | Xenogamous? heh |
| 08:24 | <hsivonen> | ooh. ooh. XBL being edited again! |
| 08:25 | <hsivonen> | hooray |
| 08:26 | <hsivonen> | I like the yellow halo on :target |
| 08:26 | <annevk> | hmm, he is supporting the Sec-WebSocket-Draft: 01 proposal |
| 08:27 | <annevk> | something like that just leaves everything wide open to be debated forever |
| 08:36 | <zcorpan_> | wait does xbl now use the html parser? |
| 08:36 | <nessy> | has anyone implemented xbl yet? |
| 08:40 | <nessy> | xbl2 that is |
| 08:40 | <annevk> | no |
| 08:40 | <annevk> | zcorpan_, that is the idea |
| 08:40 | <annevk> | zcorpan_, it would be integrated with HTML |
| 08:40 | <zcorpan_> | cool |
| 08:41 | <annevk> | http://dev.w3.org/2006/xbl2/Overview.html#editors-note |
| 08:41 | <zcorpan_> | yeah just read that |
| 08:43 | <hsivonen> | nice |
| 08:44 | <hsivonen> | Hixie: are you also going to make XBL2 not require any synchronous IO? |
| 08:44 | <Hixie> | annevk: then you couldn't just copy and paste HTML into a template, because (e.g.) implied tags wouldn't work |
| 08:44 | <Hixie> | hsivonen: loadBindingDocument() is no longer sync |
| 08:45 | <Hixie> | that was one of the changes... see the spec, there's a list of changes |
| 08:45 | <hsivonen> | Hixie: is all loading defined in terms of it? |
| 08:45 | <Hixie> | none of the other loading was ever synchronous, it just blocked parsing |
| 08:45 | <hsivonen> | Hixie: blocked parsing on arbitrary elements? |
| 08:45 | <Hixie> | not as far as i'm aware |
| 08:45 | <Hixie> | see the spec |
| 08:46 | <hsivonen> | Hixie: which elements can block parsing? |
| 08:46 | <Hixie> | none as far as i'm aware |
| 08:46 | <Hixie> | seriously, read the spec |
| 08:46 | <Hixie> | it's been years since i've been up to date with xbl |
| 08:47 | <Hixie> | and my changes were just me going once down the spec deleting text |
| 08:47 | <hsivonen> | last time I read it there was scary stuff |
| 08:47 | <Hixie> | it still is :-) |
| 08:47 | <Hixie> | though less so, since there's less stuff |
| 08:48 | <hsivonen> | Hixie: btw, "style sheet blocking scripts" is annoying |
| 08:48 | <hsivonen> | since "style sheet-blocking scripts" would mean totally the opposite |
| 08:49 | <hsivonen> | "style sheet that is blocking scripts" would be clearer |
| 08:49 | <hsivonen> | can't tell what AddStyleSheetBlockingScripts() adds |
| 08:51 | <Hixie> | file a bug |
| 08:52 | <Hixie> | i treat these terms as opaque personally |
| 08:52 | <Hixie> | i'd be equally happy calling them 0x000 0x001 0x002 0x003 etc |
| 08:52 | <Hixie> | sometimes coming up with terms is just a pain in the neck |
| 08:52 | <Hixie> | one of the worst cases being "value" |
| 08:52 | <Hixie> | which has about 4 different meanings just for the <input> element |
| 08:56 | <nessy> | lol |
| 08:57 | <nessy> | getting terminology right is hard - and then you end up with a <summary> element ... |
| 08:57 | <Ms2ger> | Hixie, the next time people complain that HTML is hard to read, I'll point them at that comment :) |
| 08:57 | <Hixie> | heh |
| 08:58 | <zcorpan_> | where's the websocket -00 draft? or does someone know when it was generated? |
| 08:58 | <Hixie> | "you think this is hard to read? just think how bad I *could* have made it!" |
| 08:58 | <annevk> | Hixie, ah I see |
| 08:59 | <Ms2ger> | "Append 0x007 to 0x003 and return 0x000." |
| 08:59 | <annevk> | zcorpan_, http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-00 |
| 08:59 | <annevk> | zcorpan_, http://tools.ietf.org/html/websocket lists various documents (substring search) |
| 09:00 | <zcorpan_> | thanks |
| 09:02 | <Hixie> | ok nn |
| 09:02 | <Ms2ger> | Also, Hixie, you should call it WebBL instead |
| 09:03 | <annevk> | hyatt vetoed WBL -- pronounced wibble |
| 09:04 | <annevk> | but if we make it a true part of HTML we should just get rid of XBL altogether, except in prose and funny examples |
| 09:12 | <hsivonen> | Why did hyatt veto it? W is the new X. |
| 09:12 | <annevk> | dunno, was a long time ago |
| 09:12 | <hsivonen> | or rather, "Web" is the new X |
| 09:12 | <annevk> | prolly because he minted the name |
| 09:13 | <hsivonen> | WebBL |
| 09:13 | <annevk> | but it doesn't really matter if it's integrated with HTML |
| 09:13 | <espadrine> | And "Xenogamous" feels like a big joke! |
| 09:14 | <annevk> | what's wrong with jokes? |
| 09:15 | <hsivonen> | "HTML5 Bindings" |
| 09:15 | <espadrine> | Spices up the reading of the spec with laughter, no harm done... |
| 09:15 | <MikeSmith> | espadrine: X is the secret ingredident in the web-scale sauce |
| 09:16 | <annevk> | X is from generation X ;p |
| 09:16 | <MikeSmith> | I think XBL2 needs shards |
| 09:16 | <MikeSmith> | because shards make everything better |
| 09:17 | <annevk> | heh |
| 09:17 | <espadrine> | Shards are cutting-edge technology! |
| 09:18 | <MikeSmith> | I've now replaced all my transaction support with shards |
| 09:18 | <MikeSmith> | because shards trump everything |
| 09:19 | <MikeSmith> | just as I am now systematically rewriting all my old crappy PHP apps with new crappy node.js ones |
| 09:33 | <annevk> | Ms2ger, test runner does not work in Opera? |
| 09:34 | <Ms2ger> | It should |
| 09:34 | <Ms2ger> | It might take a while, though |
| 09:34 | <annevk> | http://bitbucket.org/ms2ger/dom-range ?! |
| 09:34 | <annevk> | you should really make some kind of overview page :) |
| 09:35 | <Ms2ger> | annevk, http://bitbucket.org/ms2ger/ :) |
| 09:43 | <jgraham> | Ms2ger: It would be pretty nice if we could port your tests to use the same harness as all the other tests |
| 09:43 | <Ms2ger> | Is there a standard one now? |
| 09:44 | <jgraham> | "standard" |
| 09:44 | <jgraham> | it seems to be what we are using for the HTML testsuite at least |
| 09:46 | <jgraham> | Ms2ger: http://dvcs.w3.org/hg/html/file/9ae7a792e141/tests/resources/testharness.js |
| 09:46 | <jgraham> | I am responsible for the bugs and missing features in that harness |
| 09:48 | <Ms2ger> | I'll look at it |
| 10:05 | <annevk> | Ms2ger, fwiw, I'm planning to rewrite the DOM Core tests to use that harness as well |
| 10:06 | <annevk> | Ms2ger, it would remove a bunch of duplication and improve the error reporting significantly |
| 10:32 | <hsivonen> | I wonder if parser-inserted scripts that have been moved to a new document should run with the window object of the new doc or with the window object of the old doc (for security) |
| 10:33 | <hsivonen> | whether the script is permitted to run makes sense to check in the context of the old doc |
| 10:34 | <hsivonen> | it seems iffy to execute anything in the context of something else |
| 10:34 | <hsivonen> | but IE9 PP executes in the context of the new document (if at all) |
| 10:35 | <hsivonen> | Chrome executes in the context of the old doc |
| 10:39 | <zcorpan_> | "This also means that the script's global object is the outer browsing context's Window object, not the Window object inside the iframe." -- http://www.whatwg.org/specs/web-apps/current-work/complete/the-end.html#scripts-that-modify-the-page-as-it-is-being-parsed |
| 10:40 | <hsivonen> | zcorpan_: yeah, but I'm doubting if that's a good idea in terms of security |
| 10:41 | <zcorpan_> | "Note: This isn't a security problem since the script that moves the div into the outer Document can only do so because the two Document object have the same origin." |
| 10:41 | <hsivonen> | can it be proven that if a script were permitted to run in the context of the parser-associated document, it's always OK to let it run in the context of another document if whatever moved it there was permitted the move it there? |
| 10:42 | <hsivonen> | zcorpan_: what if the two documents have different Content Security Policies or some other thingies that restrict things further than Same Origin? |
| 10:43 | <annevk> | what other things? |
| 10:43 | <annevk> | there doesn't seem much agreement on CSP yet either |
| 10:43 | <zcorpan_> | i don't know anything about CSP, so dunno |
| 10:43 | <annevk> | e.g. abarth thinks most of it is not needed |
| 10:43 | <zcorpan_> | i don't mind changing the spec though |
| 10:44 | <hsivonen> | I know next to nothing about CSP, so I have no opinion on whether it is needed. However, if we ship it, I don't want to be the person who made it not do what it was advertised to do. |
| 11:22 | <hsivonen> | hmm. If I send email about the script evaluation context, where should I send it? |
| 11:22 | <hsivonen> | sending it to whatwg would exclude Microsoft |
| 11:23 | <annevk> | cc adrian? |
| 11:23 | <hsivonen> | but sending it to public-html would risk it getting lost among other emails |
| 11:23 | <annevk> | and Microsoft is on the WHATWG list |
| 11:23 | <hsivonen> | well, WHATWG list it is |
| 11:28 | <jgraham> | s/about script evaluation context/with any technical feedback/ :( |
| 11:46 | <hsivonen> | Hixie: did you examine Gecko or WebKit as a white box when speccing script execution? |
| 12:35 | <zcorpan_> | smoke signal-based browser, would be cool |
| 12:35 | zcorpan_ | is a bit behind on email |
| 12:36 | <jgraham> | zcorpan_: ?? |
| 12:38 | <zcorpan_> | an email from hixie from 29 july mentioned that browsers could be based on smoke signals |
| 12:39 | <zcorpan_> | Hixie: didn't whatwg emails have an archived-at header at some point? |
| 12:40 | <hsivonen> | the whatwg archives are sad. the charset sniffing limit had to grow mainly because it's too hard to get Dreamhost to fix their Apache |
| 12:41 | <zcorpan_> | from 512 to 1024? |
| 12:44 | <hsivonen> | zcorpan_: yeah |
| 12:51 | <annevk> | zcorpan_, no Archived-At header no |
| 12:51 | <annevk> | zcorpan_, I had this idea to make a script at some point, but that never happened |
| 12:52 | <annevk> | maybe we should apply for http://w3.markmail.org/ |
| 12:52 | <zcorpan_> | i'd like whatwg emails to have archived-at (and a pony) |
| 12:52 | <annevk> | i'd like them to have stable URLs for starters |
| 12:54 | <annevk> | smaug____, yt? |
| 12:55 | <smaug____> | yes |
| 12:55 | <annevk> | smaug____, Firefox does not associate form controls not in the DOM with a form attribute with forms in the Document |
| 12:55 | <annevk> | smaug____, the spec does require that afaict |
| 12:55 | <smaug____> | volkmar: ^^ |
| 12:56 | <annevk> | e.g. you do input = document.createElement("input"); input.form = "x"; and in the Document you have <form id=x>; input.form should give you that form |
| 12:56 | <smaug____> | annevk: do you know why the draft requires that? |
| 12:56 | <annevk> | there's just no check for in Documentness |
| 12:57 | <smaug____> | annevk: also, does form.element contain the created element? |
| 12:57 | <smaug____> | apparently no |
| 12:57 | <smaug____> | so the API is rather strange |
| 12:58 | <annevk> | maybe email the list? |
| 12:58 | <annevk> | i gotta go |
| 13:15 | <espadrine> | Am I wrong, or doesn't the latest Minefield have insertAdjacentHTML built-in? |
| 13:16 | <jgraham> | Too many negatives error |
| 13:16 | <jgraham> | iirc gecko has previously not supported insertAdjacentHTML |
| 13:16 | <jgraham> | I don't know if you are saying that now it does or that it still doesn't |
| 13:17 | <espadrine> | jgraham: sorry, I meant 'I am surprised that it still doesn't'! |
| 13:20 | <smaug____> | espadrine: you should file a bug report |
| 13:21 | <espadrine> | Maybe there is one already? I'm looking it up. |
| 13:21 | <smaug____> | there isn't |
| 13:21 | <smaug____> | I just looked at |
| 13:21 | <smaug____> | or, there isn't valid one |
| 13:21 | <smaug____> | because insertAdjacentHTML used to be IE only thing |
| 13:21 | <smaug____> | based on lack of bug reports it seems like insertAdjacentHTML is very rarely used |
| 13:22 | <smaug____> | or that js libraries have some helper methods for gecko |
| 13:25 | <zcorpan_> | regarding websrt, we could use innerHTML but say that conforming content is only allowed to use <b> <i> and <ruby> (for non-web reusability) |
| 13:25 | <jgraham> | zcorpan_: Would you realisticly expect that to have any effect? |
| 13:29 | <zcorpan_> | maybe not |
| 13:30 | <zcorpan_> | but with the current setup people will just use the metadata kind if they want to use other elements, which isn't much better |
| 13:30 | <zcorpan_> | we can always extend the list of allowed elements when we see what people use |
| 13:36 | <hsivonen> | when Web content says the encoding is EUC-JP or ISO-2022-JP, are browsers supposed to use the ISO mapping tables or the tables that have been modified for Windows-31J as when Web content says Shift_JIS? |
| 13:40 | <cyberix> | I wrote a simple application which is able to send some binary data as the body of an http POST request |
| 13:40 | <hsivonen> | smaug____: recently, I've seen Prototype, Firebug and Outlook Web App work around the lack of insertAdjacentHTML by using createContextualFragment |
| 13:40 | <cyberix> | http://www.cs.helsinki.fi/u/twruottu/testi/bpost.html |
| 13:40 | <cyberix> | It requires the user to download a file and upload it back by dragging it back to the browser |
| 13:40 | <cyberix> | but this is afaik the best way to do this at the moment |
| 13:40 | <hsivonen> | which is sad, because we could optimize insertAdjacentHTML the same way innerHTML is now optimized |
| 13:41 | <hsivonen> | and createContextualFragment confuses people |
| 13:41 | <hsivonen> | since the context is passed in a goofy way |
| 13:41 | <hsivonen> | because the method is on Range and not on Element |
| 13:44 | <jgraham> | Latest message to HyBi is interesting. Hasn't made it to the archives yet but might be http://www.ietf.org/mail-archive/web/hybi/current/msg04029.html eventually |
| 13:44 | <jgraham> | Mozilla plan to either not ship in Fx4 or ship in "a clearly for-experiment-only namespace" |
| 13:45 | <jgraham> | Dunno quite what that means |
| 13:45 | <jgraham> | Maybe add "moz" to the front of lots of the API bits |
| 13:45 | <jgraham> | Although ironically the API is the one thing that is likely to be stable |
| 13:54 | <jgraham> | (message is in the archives now) |
| 14:02 | <hsivonen> | speaking of createContextualFragment, Opera might want to clone https://bugzilla.mozilla.org/show_bug.cgi?id=585819 |
| 14:14 | <espadrine> | We will have neither insertAdjacentHTML nor outerHTML in Fx4. |
| 14:14 | <espadrine> | Johnny Stenback says, 'This won't happen for Firefox 4 unless someone steps up to own this. Not blocking.' |
| 14:14 | <hsivonen> | bug# ? |
| 14:14 | <espadrine> | https://bugzilla.mozilla.org/show_bug.cgi?id=92264 |
| 14:14 | <hsivonen> | thanks |
| 17:31 | <Philip`> | http://www.itworldcanada.com/news/opinion-disband-the-itu-t-ipv6-group/141380-pg1 - hooray for XML |
| 17:31 | <Philip`> | (In Opera I get a parse error) |
| 17:31 | <Philip`> | (Hmm, looks like it's text/html in Firefox) |
| 17:52 | <cyberix> | It seems that xhr2.send(Blob) has been replaced with xhr2.send(ByteArray) |
| 17:52 | <cyberix> | has ByteArray been defined somewhere? |
| 18:21 | <espadrine> | Do we have a constructor for the video element? |
| 18:22 | <espadrine> | I don't see it in the spec, and it seems unimplemented... |
| 18:22 | <Philip`> | espadrine: document.createElement('video') |
| 18:22 | <Philip`> | I don't believe there's an equivalent of "new Audio()" |
| 18:22 | <tabatkins> | There isn't. |
| 18:22 | <espadrine> | Ah, ok. |
| 18:23 | <espadrine> | Do you know why? |
| 18:23 | <Philip`> | I assume because it's useful to play audio without doing any DOM interaction |
| 18:23 | <Philip`> | whereas there's no point using video unless you put it in the DOM |
| 18:24 | <Philip`> | (Useful for things like sound effects in games) |
| 18:24 | <espadrine> | I admit that video is less often scripted... |
| 19:12 | <AryehGregor> | Isn't http://ie.microsoft.com/testdrive/HTML5/DOMCapabilities/Default.html the kind of test that IE developers have publicly said is not a reasonable kind of test because it doesn't test whether all the details of the implementation are correct? |
| 19:14 | <annevk> | you should probably add a link for "have publicly said" |
| 19:14 | <AryehGregor> | I would, but I'm lazy. |
| 19:15 | <AryehGregor> | It was in some post where they were saying how amazing it was that they passed 100% of the tests they wrote for the W3C, and were trying to downplay the important of sites like html5test.com. |
| 19:15 | <annevk> | cyberix, there's send(Blob) |
| 19:15 | <AryehGregor> | Pretty sure it was in an actual blog post, might have been in a [MSFT] comment. |
| 19:15 | <annevk> | oh yeah |
| 19:16 | <annevk> | I recall something like that |
| 19:17 | <AryehGregor> | It's a totally legitimate point, of course. Tests like Acid3 are pretty broken. |
| 19:17 | <AryehGregor> | They encourage vendors to implement some bare minimum of functionality that makes the test pass but isn't actually useful. |
| 19:17 | <AryehGregor> | Which breaks feature-testing and is evil. |
| 19:18 | <annevk> | Acid3 has taught us a bunch of things |
| 19:18 | <annevk> | I hope |
| 19:18 | <Hixie> | yes |
| 19:19 | <Hixie> | acid tests in general are helpful (would microsoft have even tried to do DOM Events without Acid3?), I think, but they are certainly only one part of a balanced diet |
| 19:22 | <annevk> | agreed, with lessons I meant testing for things that actually ought to have been removed from the platform (or changed drastically) |
| 19:23 | <annevk> | still a bit too much "unimplemented specs are nevertheless correct" |
| 19:23 | <annevk> | but I think we have a decent set of people now that will ensure that will not happen again that fast |
| 19:25 | <Hixie> | yeah i made a bunch of mistakes like that in acid3 |
| 19:25 | <Hixie> | i have a file somewhere listing my mistakes so i can remember them for acid4 :-) |
| 19:25 | <annevk> | heh, I should do that too |
| 19:29 | <volkmar> | annevk: hey, about your discussion with smaug later |
| 19:30 | <volkmar> | you were talking about form elements association |
| 19:30 | <volkmar> | don't understand whit was the problem |
| 19:31 | <smaug____> | volkmar: and I commented that it is rather |
| 19:31 | <smaug____> | er |
| 19:31 | <volkmar> | ? |
| 19:32 | <smaug____> | volkmar: based on the draft, if form attribute is set, the owner form should point to the form element even if the input element isn't in document |
| 19:33 | <volkmar> | that sounds insane |
| 19:33 | <smaug____> | volkmar: and I commented that it is rather strange API, that not-in-document element points to form, but .elements in form don't point to that |
| 19:34 | <volkmar> | and that's inconsistant |
| 19:34 | <volkmar> | label @for attribute required the element to be in the same document |
| 19:34 | <annevk> | that's how it works in Opera anyway |
| 19:35 | <annevk> | same document is that ownerdocument wise? |
| 19:36 | <annevk> | anyways, i don't mind the spec changing |
| 19:39 | <volkmar> | smaug____: did you find the part in the spec saying that .form should return the form element even if not in document ? |
| 19:39 | <smaug____> | volkmar: it is somewhere there |
| 19:39 | <smaug____> | not said explicitly |
| 19:41 | <smaug____> | volkmar: if you follow the steps to set form owner, you notice that the element doesn't need to be in document |
| 19:49 | <volkmar> | smaug____: can't found it, i'm obviously too stupid :( |
| 19:50 | <smaug____> | volkmar: somewhere here http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form |
| 19:51 | <volkmar> | yeah, i was looking to that |
| 21:32 | GPHemsley | wonders what browser vendor is not on the WHATWG list |
| 21:32 | <Hixie> | Microsoft |
| 21:33 | <Hixie> | is probably the one being talked about |
| 21:33 | <Hixie> | (there's of course also lots of smaller players who aren't on the list) |
| 21:34 | <GPHemsley> | right... but isn't Microsoft on the list? |
| 21:34 | <GPHemsley> | I recall reading stuff from them once |
| 21:34 | <Hixie> | microsoft policy is not to participate on the whatwg list |
| 21:34 | <Hixie> | they do have some people who are subscribed and some have participated in the past |
| 21:34 | <Hixie> | but they fear the lack of a patent policy |
| 21:34 | <Hixie> | (not an entirely unreasonable position) |
| 21:35 | <GPHemsley> | for the entirety of the WHATWG work? |
| 21:36 | <Hixie> | not sure what you're asking |
| 21:37 | <GPHemsley> | I was trying to clarify your point about the lack of a patent policy |
| 21:38 | <Hixie> | The concern that they have conveyed to me is regarding the lack of a patent policy of any kind with respect to the WHATWG effort. |
| 21:38 | <Hixie> | it's a concern that is mostly academic at this point since most of the content is also published by the W3C under their patent policy. |
| 21:54 | <AryehGregor> | I assume lawyers won't like the "most". |
| 21:58 | <Hixie> | that's not really a whatwg-specific problem. e.g. none of the WebSocket protocol stuff at the IETF is under a patent policy worth anything. |
| 21:58 | <Hixie> | but yes |
| 22:01 | <GPHemsley> | and what exactly the fear of? |
| 22:01 | <GPHemsley> | +is |
| 22:02 | <Hixie> | someone participating in the project (e.g. google) patenting something that then becomes part of the spec, getting microsoft to implement it, and then suing for patent infringement |
| 22:02 | <GPHemsley> | ah |
| 22:02 | <GPHemsley> | yeah, that's scary |
| 22:02 | <GPHemsley> | </3 software patents |
| 22:02 | <Hixie> | not really |
| 22:02 | <Hixie> | but it's something the w3c patent policy solves |
| 22:02 | <GPHemsley> | what's it say? |
| 22:03 | <GPHemsley> | and, more importantly, why doesn't WHATWG have one? |
| 22:03 | <Hixie> | that you can't sue other participants, basically |
| 22:03 | <Hixie> | making a patent policy is years of lawyer work |
| 22:03 | <Hixie> | and nobody has cared enough to do the work |
| 22:03 | <GPHemsley> | why not just "nothing here is patentable" |
| 22:03 | <GPHemsley> | boom, done |
| 22:03 | <Hixie> | what would that do |
| 22:03 | <GPHemsley> | no idea |
| 22:03 | <GPHemsley> | ;) |
| 22:04 | <Hixie> | the real scary imho is patents ending up in the hands of patent trolls |
| 22:04 | <Hixie> | and there ain't nothing a patent policy can do about that |
| 22:04 | <AryehGregor> | Who would agree to a WHATWG patent policy? Why would they? |
| 22:04 | <AryehGregor> | All HTMLWG members have to agree to the W3C one as a condition of participation. |
| 22:04 | <Hixie> | presumably the same people who agree to the w3c one (anyone who participates) |
| 22:05 | <GPHemsley> | Just saw this: @ConanOBrien Facebook is trying to trademark the word "Face". I am going to trademark the word "aceboo", and then wait for the dollars to roll in. |
| 22:05 | <Hixie> | (the reason the scenario listed above isn't scary is that all the people who would get sued have just as many patents of their own and would just counter-sue) |
| 22:05 | <AryehGregor> | So the whatwg list would no longer be open to immediate subscription, you'd need approval first? |
| 22:05 | <Hixie> | AryehGregor: if what occured? |
| 22:05 | <AryehGregor> | If you required a patent policy agreement from all contributors? |
| 22:06 | <AryehGregor> | Otherwise organizations could just have their employees participate and sign away all of their (the employee's) patents, which would be none. |
| 22:06 | <AryehGregor> | So you'd need to ask them who their employer is, at a minimum. |
| 22:06 | <Hixie> | if we request that people agree to something before they could post, then it seems tautological that they could indeed not post until they had agreed |
| 22:06 | <GPHemsley> | which is silly |
| 22:06 | <Hixie> | but i don't think anyone has proposed that so far |
| 22:06 | <Hixie> | since nobody has done any of the lawyery work |
| 22:07 | <AryehGregor> | But just asking them to agree isn't enough, you have to get their employer to agree. |
| 22:07 | <AryehGregor> | Or else it's kind of meaningless. |
| 22:07 | <AryehGregor> | Their agreement isn't binding on their employer. |
| 22:07 | <GPHemsley> | couldn't the patent policy be a stipulation of the standard, rather than the working group? |
| 22:08 | <Hixie> | GPHemsley: i don't know what that would mean |
| 22:08 | <GPHemsley> | yeah, I don't either... just thinking out loud |
| 22:08 | <Hixie> | but in general i recommend getting a law degree in patent law before trying to think about this stuff :-) |
| 22:08 | <GPHemsley> | :P |
| 22:09 | <GPHemsley> | yeah... everything I can think of just goes back to </3 software patents |
| 22:10 | <GPHemsley> | because it's really rather stupid for us all to be working together for a common goal, and then have somebody come out of nowhere and say "hahaha! you implemented the agreed-upon standard, which I secretly have a patent to! diediedie" |
| 22:11 | <GPHemsley> | that's worse than just trying to reverse engineer things 100 times |
| 22:13 | <AryehGregor> | I had an idea that a company like Google could use to kill software patents. I recently summarized it here: http://weblogs.mozillazine.org/roc/archives/2010/08/google_vs_oracl.html#c2727630 |
| 22:13 | <Hixie> | abarth: i don't understand your e-mail (re xbl2) |
| 22:13 | <AryehGregor> | I have some vague idea that maybe I could try pestering important people to listen to it, but I'm too lazy. |
| 22:14 | <abarth> | Hixie: xbl looks like a templating system |
| 22:14 | <abarth> | Hixie: where you supply a bunch of markup and script |
| 22:14 | <abarth> | and then instantiate the template with user-provided values |
| 22:14 | <Hixie> | AryehGregor: wouldn't that run afoul of the laws against, you know, the mafia |
| 22:14 | <Hixie> | abarth: i guess it vaguely is similar to such a concept |
| 22:15 | <AryehGregor> | Hixie, I dunno, why? The mafia breaks people's kneecaps, you're just enforcing your patents. And it's hardly anticompetitive, you're allowing anyone to join who wants to. |
| 22:15 | <abarth> | Hixie: at a quick glance, i didn't see how you instantate the template |
| 22:15 | <Hixie> | AryehGregor: well i'm no lawyer, so i have no idea |
| 22:15 | <AryehGregor> | Me either! |
| 22:16 | <hsivonen> | Hixie: AFAICT, RICO isn't being enforced against all operations in the U.S. that to a lay person look like protection rackets :-( |
| 22:16 | <abarth> | Hixie: there are two features that would be desirable from a security point of view |
| 22:16 | <abarth> | Hixie: 1) the ability to limit what can put put into one of the holes in the template |
| 22:16 | <abarth> | (e.g., text only, or passive content only, etc) |
| 22:17 | <abarth> | 2) the ability to supply content for the template in a way that's hard to XSS yourself |
| 22:18 | <Hixie> | abarth: you don't instantiate xbl bindings... they are just added to existing dom nodes |
| 22:18 | <Hixie> | abarth: there are no nodes created that aren't already in the dom |
| 22:18 | <Hixie> | abarth: all it does is slightly transform the dom for the purposes of css |
| 22:19 | <abarth> | i see |
| 22:19 | <hsivonen> | abarth: http://hsivonen.iki.fi/test/moz/move-during-parse-parent.html suggests WebKit runs parser-inserted scripts in the context of the parser's document |
| 22:19 | <hsivonen> | (crashes Chrome and Chromium content process on reload)) |
| 22:19 | <abarth> | Hixie: in the first example in the intro: |
| 22:19 | <abarth> | <div id="wrapper"> |
| 22:19 | <abarth> | <div id="col2"><content includes=".nav"></div> |
| 22:19 | <abarth> | <div id="col1"><content includes=".main"></div> |
| 22:19 | <abarth> | </div> |
| 22:19 | <abarth> | it looks like <content> is a placeholder |
| 22:19 | <abarth> | that gets filled with something |
| 22:20 | <abarth> | you're saying it's a dom node that already exists in your document |
| 22:20 | <abarth> | hsivonen: crashes are bad :) |
| 22:20 | <Hixie> | abarth: it doesn't get filled in, it's just that that is where the dom nodes get grafted in when creating the final flattened tree |
| 22:20 | <Hixie> | abarth: the dom nodes are already there though, yeah |
| 22:21 | <Hixie> | abarth: this is a pure-dom technology, nothing happens at the markup level |
| 22:21 | <hsivonen> | abarth: my point being that I don't believe WebKit does what I called #3 in my whatwg email |
| 22:21 | <hsivonen> | re: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-September/028357.html |
| 22:22 | <Hixie> | ooh, jgraham just updated his script |
| 22:22 | <Hixie> | oh i guess it could have happened any time in the last 4 days |
| 22:22 | <Hixie> | hm, or not |
| 22:22 | <Hixie> | i'm confused |
| 22:22 | <Hixie> | nevermind |
| 22:23 | <abarth> | Hixie: ok, that's slightly unfortunate, but I guess we'll have to solve XSS another way then :) |
| 22:28 | <abarth> | hsivonen: nice test case |
| 22:29 | <abarth> | hsivonen: webkit is very confused by that test case |
| 22:30 | <Hixie> | abarth: seems very fortunate to me, it means i don't introduce any new bugs :-) |
| 22:31 | <hsivonen> | abarth: I find it odd that you and jgraham characterize the test case as "nice" :-) |
| 22:31 | <abarth> | Hixie: it should be the case that a good client-side templating system would make XSS very uncommon |
| 22:32 | <abarth> | Hixie: the unfortunate part is to build all this machinery and then not solve XSS, since it's very nearby |
| 22:33 | <Hixie> | this is not a client-side templating system |
| 22:33 | <Hixie> | so that's ok :-) |
| 22:34 | <hsivonen> | I expect we won't be able to introduce One True templating system |
| 22:34 | <hsivonen> | enough people will want a different one and not use the safe one |
| 22:35 | <hsivonen> | most people aren't using XSS-resilient server-side templating systems |
| 22:36 | <AryehGregor> | I've heard Facebook has a nice hack to PHP that does that. |
| 22:36 | <AryehGregor> | You can do XML literals, and interpolation into them automatically escapes the variables. |
| 22:36 | <AryehGregor> | So like: echo <p>$msg</p>; |
| 22:37 | <ap> | Hixie: I have a Web page here that expects window.elementID to not find an element in strict mode (so it works in shipping Firefox). WebKit matches HTML5 in HTML documents, so it misbehaves on this page. Is a single example enough to change this part in HTML5 to match Firefox 3? |
| 22:37 | <ap> | Hixie: as a related issue, WebKit doesn't allow window.elementID for XHTML |
| 22:39 | <Ms2ger> | As a relates issue, WebKit seems to have way too many differences between HTML and XHTML |
| 22:40 | <Hixie> | ap: what does IE do? |
| 22:41 | <ap> | Hixie: I didn't test its strict mode, I can do that now |
| 22:41 | <Hixie> | ap: that would be interesting. Also, whether the original page works in IE, and why. |
| 22:42 | <ap> | Hixie: oh, I don't need to test. accessing the element works even in strict mode, which is how they test that it's IE |
| 22:42 | <Hixie> | oh heh |
| 22:42 | <ap> | Hixie: and then they use IE behaviors |
| 22:43 | <Hixie> | my expectation would be that there are pages that depend on both behaviours, and that we're screwed either way. |
| 22:44 | <Hixie> | so i'd rather keep the number of html/xhtml and quirk/noquirk differences as low as possible |
| 22:45 | <ap> | Hixie: this is also a pretty ugly behavior - and we know that we can live without it for the most part, given that Firefox works |
| 22:45 | <ap> | Hixie: with some properties coming from name and some from id, there is a lot of potential for mistakes, as well as other browser differences affecting results |
| 22:46 | <ap> | Hixie: having said that, we've been asked to support window.elementID in XHTML before |
| 22:47 | <Hixie> | i'm no fan of this behaviour, don't get me wrong :-) |
| 22:53 | <Ms2ger> | Hixie, now I was seriously thinking you loved it! |