| 00:03 | <_bga> | michaelw null in webkit |
| 00:03 | <_bga> | you set propety |
| 00:03 | <_bga> | not attibute |
| 00:06 | <michaelw> | _bga: with that reasoning, the value of the attribute should not change from what it was previously |
| 00:07 | <michaelw> | _bga: also getAttribute returns a DOMString |
| 00:07 | <michaelw> | IMO, it should return |
| 00:07 | <michaelw> | "" |
| 00:08 | <michaelw> | (the empty string), sorry for the extra newline |
| 00:08 | <_bga> | of course |
| 01:02 | <Hixie> | zewt: i think if you think that a self-signed cert provides any security you have not attempted to mitm anyone |
| 01:04 | <TabAtkins> | Hixie: Still better than nothing. |
| 01:04 | <Hixie> | i think it might actually be worse than nothing |
| 01:04 | TabAtkins | is annoyed at browsers being paranoid about self-signed certs when they don't say a thing about login forms over http. |
| 01:04 | <Hixie> | because it gives a significantly distorted sense of security |
| 01:05 | <TabAtkins> | The correct sense is "better than nothing, worse than CA-signed". |
| 01:05 | <Hixie> | it's really not particularly better than nothing |
| 01:05 | <Hixie> | it's trivial to mitm somebody and offer them an identical-looking cert |
| 01:10 | <zewt> | it doesn't create any sense of security when implemented correctly; and it's very hard (impossible) to MITM on a large scale without anyone being able to find out |
| 01:11 | <Hixie> | it's very hard to passively sniff on a large scale too |
| 01:11 | <zewt> | orders of magnitude easier |
| 01:11 | <Hixie> | actually not really |
| 01:11 | <zewt> | untrusted crypto shouldn't be presented to users as a "secure connection"; it should just be there, invisible to the user as part of the protocol |
| 01:12 | <Hixie> | mitm'ing self-signed certs on a network where you control all the inbound and outbound traffic can be done completely transparently to anyone except those actually checking the fingerprints |
| 01:12 | <zewt> | eg. if all of my HTTP traffic was encrypted but not signed, and I suspected my ISP of MITM'ing to work around it, I could find out |
| 01:12 | <zewt> | but none of it is encrypted, so I have no way whatsoever of finding out |
| 01:13 | <Hixie> | you just have the routers do the TLS handshake and switch the server's cert for a dynamically-generated one |
| 01:13 | <Hixie> | why would you suspect your ISP? |
| 01:13 | <zewt> | why would I not? |
| 01:13 | <zewt> | or any other party with access |
| 01:13 | <Hixie> | have you _ever_ checked the fingerprint of _any_ self-signed cert? |
| 01:14 | <Hixie> | btw, in the context of this discussion (websocket) the user isn't presented with anything, secure or not |
| 01:14 | <zewt> | like i said, i didn't mean this as an objection against this particular case |
| 01:14 | <Hixie> | that's why it's critical to only accept secure connections if the requested protocol is wss: |
| 01:15 | <zewt> | my objection is to convincing innocent bystanders that untrusted crypto is the same as cleartext, which it just isn't |
| 01:15 | <Hixie> | my objection is to convincing innocent bystanders that untrusted crypto is any better than cleartext, which it just isn't |
| 01:16 | <zewt> | then your objection is factually wrong |
| 01:16 | <Hixie> | as is yours :-P |
| 01:16 | <Hixie> | but worse, yours instills a false sense of security |
| 01:17 | <zewt> | if there was large-scale MITM'ing of unsigned SSL connections taking place by ISPs or backbone routers, I'd expect to see people notice; it'd be an easy thing to honeypot |
| 01:17 | <Hixie> | luckily, as there's no large-scale use of self-signed certs, it's not an issue |
| 01:17 | <zewt> | (wrong term, but right meaning) |
| 01:18 | <zewt> | i don't subscribe to the "hixie says trust-me" model of security, sorry :) |
| 01:18 | <Hixie> | my model is "don't trust me or anyone" |
| 01:19 | <Hixie> | https://blog.startcom.org/?p=125#more-125 |
| 01:19 | <zewt> | and in order to (not) do so, i prefer protocols that cause sniffing to require stream tampering to those that don't |
| 01:20 | <Hixie> | when was the last time you or anyone you know actually checked the fingerprint of a self-signed cert? |
| 01:20 | <Hixie> | that is the _only_ way you could tell if it was happening |
| 01:20 | <zewt> | ff's cert stuff is completely bogus--not that it shows bad certs, it's that it intentionally has a bad UI for it to make it annoying, which is never okay |
| 01:21 | <zewt> | we're not in an environment where that makes sense, because most of the traffic that could be in that category (encrypted but not signed) is currently cleartext |
| 01:21 | <Hixie> | i really think you underestimate the difficulty of mounting a mitm attack |
| 01:22 | <zewt> | even if so, i don't understate the detectability |
| 01:22 | <Hixie> | from personal experience, i can tell you that it is not even remotely difficult to do it in a way that nobody can notice |
| 01:22 | <Hixie> | s/can notice/does notice/ |
| 01:22 | <Hixie> | nobody knows the fingerprint of any of the servers they use |
| 01:22 | <zewt> | right now there's no reason to set up "honeypot traffic" like that; everything's just plaintext, so nobody has any incentive to do those sorts of large-scale MITMs, all they have to do is sniff |
| 01:24 | <Hixie> | all the interesting stuff is encrypted with signed certs |
| 01:24 | <zewt> | 1: cleartext traffic becomes encrypted 2: passive attacks no longer work; everyone using them either has to stop sniffing traffic or start tampering with data; 3: now you have a good reason to implement detection for that (eg. machines that just talk to random servers with known certificates to see if anyone's being evil) |
| 01:25 | <Hixie> | in a world where everyone used encryption with no signing, sure |
| 01:25 | <Hixie> | we're not, and never will be, in that world |
| 01:25 | <Hixie> | so it's irrelevant |
| 01:25 | <zewt> | hixie knows the future! |
| 01:26 | <zewt> | SPDY encrypts everything, signed or not, for example |
| 01:26 | <zewt> | (not to say i expect SPDY to take over) |
| 01:29 | <zewt> | i don't rule out a meaningful amount of cleartext data turning into encrypted data, but the chances of that definitely decrease when people claim that unsigned == cleartext |
| 01:29 | <zewt> | which is why it bothers me when I see it |
| 01:30 | <Hixie> | it bothers me because what you advocate increases the odds of people using unsigned encryption instead of signed encryption, which is extremely insecure |
| 01:31 | <Hixie> | users don't understand any of this stuff. They think "encrypted" means "safe" and that simply isn't the case. |
| 01:31 | <zewt> | we're not talking to users, we're talking to developers |
| 01:31 | <zewt> | users should certainly never see unsigned traffic as "secure" |
| 01:31 | <Hixie> | it's better to have plaintext that we can assume is sniffed than encrypted that we falsely assume is not |
| 01:31 | <Hixie> | users, developers, they don't understand it any better |
| 01:31 | <zewt> | if a developer doesn't understand it then he should have nothing to do with implementing it |
| 01:32 | <zewt> | i have little pity for developers who implement a "secure protocol" without knowing what they're doing, heh |
| 01:32 | <Hixie> | web developers do this all the time |
| 01:32 | <Hixie> | so in the real world, we have to take that into account |
| 01:32 | <zewt> | web developers use browser facilities, they don't implement encryption themselves |
| 01:34 | <zewt> | until someone has an epiphany and figures out a signing scheme where everyone can sign all of their traffic for free, I'll take partial security with known, quantifiable weaknesses than no security in a second |
| 01:34 | <zewt> | s/than/over/ |
| 01:35 | <Hixie> | web developers decide whether to use self-signed certs or not |
| 06:23 | <hsivonen> | hmm. "Bug reports submitted from a group of experts however can give more weight to bug reports, and assure browser/tool vendors that suggested fixes are appropriate." |
| 06:24 | <hsivonen> | from http://www.html4all.org/staging/a11y-bugs/ |
| 06:29 | <hsivonen> | The intro text on http://a11ybugs.org/ reminds me of CSS11 |
| 06:29 | <hsivonen> | a11y15? |
| 06:34 | <hsivonen> | what's the deal with the bad escaping in the <title> at https://tools.ietf.org/html/rfc2854 ? |
| 06:34 | <hsivonen> | I guess HTML is hard. no wonder they prefer plain text. |
| 06:35 | <hsivonen> | Which RFC has the syntax for the charset parameter? |
| 06:37 | hsivonen | tries https://tools.ietf.org/html/rfc2046 |
| 06:38 | <hsivonen> | RFCs need more hypertext |
| 06:49 | <hsivonen> | aargh. where does https://tools.ietf.org/html/rfc2045 say what a quoted-string is? |
| 07:53 | <hsivonen> | haha. since when has the HTML LS spec had a photo of a sink in it? |
| 07:54 | <hsivonen> | kitchen sink even, though it's not immediately obvious that the photo is indeed from a kitchen |
| 07:58 | <hsivonen> | is http://www.whatwg.org/specs/web-apps/current-work/#interactive the closest the spec has for defining how to tell the XHTML syntax and the HTML syntax apart? |
| 08:12 | <hsivonen> | filed as http://www.w3.org/Bugs/Public/show_bug.cgi?id=14565 |
| 08:51 | <foolip> | zcorpan, context? |
| 08:56 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=14552 |
| 08:58 | <zcorpan> | foolip: in particular supporting // in cue data seems annoying |
| 08:59 | <foolip> | zcorpan, I think it's not a big deal as it will mostly mess with URLs, but not having it also doesn't seem like a problem |
| 09:08 | <zcorpan> | breaking URLs seems annoying :) |
| 09:14 | <foolip> | Hixie still seems to like his COMMENT --> blocks |
| 09:18 | <nessy> | hi foolip |
| 09:18 | <foolip> | hi nessy |
| 09:18 | <nessy> | do you have a different suggestion for how to get comment blocks and similar header style information into WebVTT? |
| 09:18 | <foolip> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=14552 is what we've implemented |
| 09:23 | <nessy> | // is a really bad idea because we won't get urls easily then |
| 09:23 | <nessy> | also, are you suggesting to use comment syntax to make header blocks in WebVTT, such as style, metadata etc? |
| 09:28 | <foolip> | No, we're suggest that it just be comments, things that can be pre-processed away and has no effect on anything whatsoever |
| 09:28 | <foolip> | not visible by scripts, unlike DOM comments |
| 09:29 | <foolip> | zcorpan, http://www.w3.org/Bugs/Public/show_bug.cgi?id=14260#c17 seems reasonable, right? |
| 09:32 | <zcorpan> | seems reasonable |
| 09:33 | <nessy> | foolip, we need some kind of sectioning of header stuff (not for browsers, but for desktop players), and the cue syntax provides for that |
| 09:33 | <nessy> | so, unless we find a better parsing landmark that helps with sectioning, I am with Ian |
| 09:33 | <foolip> | nessy, sure, I think that's an orthogonal issue to comment syntax, though |
| 09:34 | <nessy> | I think we could tolerate /* */ |
| 09:34 | <nessy> | but using // is a really bad idea IMHO |
| 09:35 | <foolip> | sure, please comment as such |
| 09:58 | <nessy> | ok, done :-) |
| 10:54 | <zcorpan> | nessy: what you wrote in http://www.w3.org/Bugs/Public/show_bug.cgi?id=14552 doesn't work |
| 10:54 | <zcorpan> | 00:01.000 --> <00:02.000 |
| 10:54 | <zcorpan> | that will just cause that cue to be dropped |
| 10:55 | <nessy> | oh, because of the empty line? |
| 10:55 | <nessy> | hmm, I guess you're right |
| 10:55 | <zcorpan> | no |
| 10:55 | <zcorpan> | because the timings line is invalid |
| 10:55 | <zcorpan> | so the cue gets dropped |
| 10:56 | <nessy> | ah, that, too |
| 12:13 | <nessy> | gah, issue-179 raises its head! I was hoping it would be forgotten... |
| 16:14 | <AryehGregor> | Hmm, I just realized the Selection stuff in the editing spec wasn't all written by me. |
| 16:14 | <AryehGregor> | I think that means other people who contributed parts of it have to agree to the contributor agreement, or somesuch. |
| 16:32 | <dglazkov> | good morning, Whatwg! |
| 16:56 | <J_Voracek> | Good morning dglazkov! |
| 16:57 | <dglazkov> | I think he totally joined only to greet me. |
| 16:57 | <dglazkov> | that proves it that I am famous |
| 16:57 | <myakura> | night whatwg. |
| 16:57 | myakura | yawns. |
| 17:17 | <AryehGregor> | For out-of-range indices, should getters return null or undefined? |
| 17:20 | <AryehGregor> | localStorage returns null, but I thought everyone agreed that was a bad idea. |
| 17:21 | <AryehGregor> | UndoManager also seems to return null, and I'm not sure whether to suggest it change to undefined. |
| 17:30 | <AryehGregor> | Ugh, no ICS upgrade for Nexus One: http://www.telegraph.co.uk/technology/google/8848669/Android-upgrade-for-Google-Nexus-S-in-weeks.html |
| 17:31 | <AryehGregor> | That stinks. I thought the whole point of Google's official phones was that they'd actually upgrade the OS. |
| 17:38 | <zewt> | google does not have much of a track record for updating "flagship" android devices |
| 17:38 | <zewt> | (rather the opposite) |
| 17:40 | <hsivonen> | zewt: better track record than the track record vendors have with non-Nexus phones |
| 17:41 | <zewt> | that's like saying "mcdonalds has better food than that box of broken glass and rusty staples" |
| 17:41 | <zewt> | likely true, but... |
| 17:42 | <hsivonen> | Everyone's except Apple's phone OS update story is really sad |
| 19:29 | <bencc> | what browsers plan to support webrtc? |
| 20:20 | <AryehGregor> | Hmm. |
| 20:20 | <AryehGregor> | Looks like my gentest.html produces a sad tab in Chrome dev now. |
| 20:20 | <AryehGregor> | That's bad. |
| 20:45 | AryehGregor | isolates the issue |
| 20:51 | <AryehGregor> | http://code.google.com/p/chromium/issues/detail?id=101791 |
| 22:18 | <leaverou> | hi there, can somebody please tell me what output they get in IE10 from this? http://jsfiddle.net/leaverou/bFetP/show Thanks! |
| 22:22 | <TabAtkins> | The IE DOM is so bizarre sometimes... |
| 22:23 | <leaverou> | yeah, it keeps unknown properties |
| 22:23 | <leaverou> | and drops unknown values in known properties! |
| 22:23 | <leaverou> | and alas, I was hoping those flags might solve it for IE, but no |
| 22:23 | <leaverou> | maybe outerHTML |
| 22:30 | <leaverou> | geez, it's even removed from outerHTML /cc TabAtkins |
| 22:31 | <TabAtkins> | leaverou: Yeah, it must happen during parsing. |
| 22:31 | <leaverou> | so there's absolutely no workaround you think? |
| 22:31 | <bga_> | oh leaverou here |
| 22:31 | <leaverou> | bga_: hey |
| 22:31 | <bga_> | :) |
| 22:32 | <TabAtkins> | leaverou: Unless there's something really tricky, at this point I think not. |
| 22:32 | <TabAtkins> | But IE has surprised us in the past with nonsensical workarounds. |
| 22:32 | <leaverou> | TabAtkins: I'll ping Rey, it's our last hope I guess |
| 22:33 | <leaverou> | TabAtkins: so that's why CSS3PIE requires different properties even for values!! |
| 22:34 | <TabAtkins> | Ah, that makes sense. |
| 22:34 | <smaug____> | TabAtkins: haven't all the browsers surprised us with nonsensical workarounds. :) |
| 22:34 | <TabAtkins> | smaug____: I don't know if anything will ever top the IE shiv for the new elements. ^_^ |
| 22:34 | <leaverou> | smaug____: I think IE is the champion of that though |
| 22:52 | <zewt> | constructors that return a different type? that sounds ... evil |
| 22:52 | <TabAtkins> | zewt: Agreed. |
| 22:52 | <TabAtkins> | Either have real constructors or an honest factory. |
| 22:53 | <zewt> | also wouldn't translate well to most other languages (even if that's not a top concern for web APIs) |
| 22:55 | <smaug____> | zewt: huh, where was such ctors suggested |
| 22:56 | <smaug____> | oh, webapps |
| 22:56 | smaug____ | kicks heycam |
| 22:58 | <bencc> | is there a spec about webcam other than webrtc? |
| 22:58 | <bencc> | I mean, will ie10 be able to stream webcam without supporting webrtc? |
| 22:58 | <smaug____> | you mean using camera input ? |
| 22:58 | <smaug____> | there is some draft from DAP |
| 22:59 | <bencc> | DAP? |
| 22:59 | <bencc> | IE10 won't support plugins |
| 22:59 | <TabAtkins> | zewt: We really don't care at all other non-JS languages. But it's still bad. |
| 22:59 | <bencc> | but html5 doesn't have support for p2p connections and media streaming yet |
| 23:00 | <bencc> | so there is a gap |
| 23:00 | <smaug____> | bencc: DAP WG in W3C |
| 23:00 | <Hixie> | bencc: yes it does |
| 23:00 | <bencc> | Hixie: ? |
| 23:00 | <Hixie> | bencc: http://www.whatwg.org/specs/web-apps/current-work/#video-conferencing-and-peer-to-peer-communication |
| 23:01 | <bencc> | Hixie: thanks. how does it relates to webrtc? |
| 23:01 | <bencc> | and do you know if any browser support it? |
| 23:01 | <Hixie> | you mean the w3c webrtc thing? |
| 23:02 | <bencc> | yes |
| 23:02 | <Hixie> | the w3c webrtc thing is a fork of the text above |
| 23:03 | <bencc> | so which one is the "standard"? |
| 23:03 | <smaug____> | there isn't anything even close to stable spec yet |
| 23:03 | <smaug____> | afaik |
| 23:03 | <Hixie> | whatdo you mean by "standard"? |
| 23:03 | <bencc> | it seems that chrome, firefox and opera are going to support webrtc |
| 23:03 | <smaug____> | for video or audio streaming, not audio handling in general |
| 23:03 | <bencc> | but ie10 and safari? |
| 23:05 | <smaug____> | ask MS and Apple;) |
| 23:05 | <Hixie> | beats me |
| 23:05 | <Hixie> | i can't even work out which one chrome, firefox and opera are implementing :-) |
| 23:06 | <Hixie> | (not that i've investigated, been too busy with other things) |
| 23:06 | <bencc> | I see this in IE: http://html5labs.interoperabilitybridges.com/prototypes/media-capture-api/media-capture-api/info |
| 23:06 | <zewt> | ("forkable specs are bad, see watch we'll show you why!") |
| 23:06 | <bencc> | not sure if it supports streaming |
| 23:07 | <Hixie> | zewt: yeah pretty much |
| 23:08 | <smaug____> | bencc: that page is talking about DAP spec |
| 23:08 | <Hixie> | w3c really lost all credibility with their no-forking argument after that |
| 23:08 | <bencc> | smaug____: what does DAP means? |
| 23:09 | <zewt> | Hixie: are the specs conflicting? (same interface or renamed interfaces) |
| 23:09 | <Hixie> | zewt: yes |
| 23:09 | <smaug____> | bencc: the page is also talking about HTML Speech, which will probably rely on webrtc to get microphone input |
| 23:09 | <smaug____> | bencc: Device APIs and Policy Working Group |
| 23:09 | <smaug____> | DAP WG |
| 23:09 | <Hixie> | zewt: (in that they forked the whatwg one, and i haven't changed the whatwg since and they have changed their incompatibly) |
| 23:10 | <bencc> | this stuff is more complicated than programming :) |
| 23:11 | <zewt> | it's just complicated on a somewhat different axis :) |
| 23:17 | <heycam> | smaug____, is it really controversial to write things like `function Element(tagname) { return document.createElement(tagname); } var e = new Element("div");`? |
| 23:17 | <heycam> | `new Element("div")` looks like a lovely pattern to me |
| 23:17 | <heycam> | I mean, it reads pretty nicely |
| 23:18 | <smaug____> | but you get different interface back |
| 23:18 | <smaug____> | that is very strange |
| 23:18 | <smaug____> | and so far not used anywhere else in web platform |
| 23:20 | <TabAtkins> | heycam: new Element.Div() reads just as well without being a factory in disguise. |
| 23:21 | <smaug____> | heycam: also, what should new Element("a") return? an HTML Element or SVG Element? |
| 23:21 | <Hixie> | except you then have to create a mapping for all the elements which is really quite ugly |
| 23:21 | <TabAtkins> | Or hell, new Element.div(), so you can do new Element["div"]() easier. |
| 23:21 | <TabAtkins> | Hixie: You're talking about something hidden in the implementation which is completely irrelevant to real people. |
| 23:21 | <smaug____> | TabAtkins: how does that work with SVG vs HTML ? |
| 23:22 | <heycam> | smaug____, at least the returned thing is instanceof Element... |
| 23:22 | <TabAtkins> | smaug____: HTML wins! Woo! |
| 23:22 | <Hixie> | TabAtkins: it's not hidden, it's right there on Element |
| 23:22 | <heycam> | smaug____, the new Element("a") question is good |
| 23:22 | <heycam> | but you get the same thing with Elemetnt.a() |
| 23:22 | <TabAtkins> | (SVG is trying to put some effort into unifying style/script/a with HTML.) |
| 23:23 | <zewt> | heycam: everyone expects "new XXX()" to return an XXX, whether or not it's technically required; a factory doesn't make that implication |
| 23:23 | <smaug____> | heycam: I'm not saying new Element["a"]() is any better |
| 23:23 | <zewt> | best to honor the basic assumptions of what a constructor does |
| 23:24 | <TabAtkins> | zewt: Agreed. That's my "or be an honest factory" objection. |
| 23:24 | <heycam> | new new new new new new function Constructors4Life() { return Constructors4Life } |
| 23:24 | <TabAtkins> | heycam: Can you stack news like that? |
| 23:25 | <heycam> | oh what, maybe not :) |
| 23:25 | <heycam> | you need parens it seems |
| 23:25 | <TabAtkins> | That's what I thought. ^_^ |
| 23:25 | <heycam> | new (new (new ... |
| 23:26 | <zewt> | Could not join server since it couldn't be found. |
| 23:26 | <zewt> | hay wrong window |
| 23:26 | <TabAtkins> | Slightly unfortunate. Having to do (new Foo()).bar() is slightly annoying. |
| 23:26 | <TabAtkins> | But shrug, minor inconvenience. |
| 23:27 | <zewt> | similar annoyance to having to parenthesize functions |
| 23:27 | <Hixie> | i think the quasi strings are a more interesting approach than all the above, personally |
| 23:28 | <TabAtkins> | Hixie: Disagree. Quasi strings are a great complement, but they don't let you easily, say, make an element with a bag of properties. |
| 23:29 | <Hixie> | bag of properties? |
| 23:31 | <Hixie> | you can trivially do that in a helper function: function createElementWithBag(name, bag) { var r = document.createElement(name); for (var i in bag) r[i] = bag[i]; return r; } |
| 23:31 | <TabAtkins> | Hixie: new Video({autoplay: false, loop:true}) or something. |
| 23:31 | <Hixie> | we don't need to provide an API for that |
| 23:31 | <TabAtkins> | Hixie: I know you hate convenience APIs. |
| 23:31 | <Hixie> | i don't hate convenience APIs, I hate wasting our time adding stuff to the platform that is trivially already possible when we have way bigger fish to fry |
| 23:31 | <Hixie> | it's a huge opportunity cost |
| 23:32 | <TabAtkins> | You go fry those bigger fish. I'll cheerlead for making the fish easier to catch. |
| 23:33 | <Hixie> | you really think adding an API that does the equivalent of literally one line of code that can be banged out in 10 seconds in going to be a good use of our time? |
| 23:37 | <TabAtkins> | Hixie: Yes, when it improves consistency, readability, and writeability and is used so often. |
| 23:37 | <Hixie> | wow |
| 23:37 | <Hixie> | what other trivial things do you think we should add? |
| 23:37 | <TabAtkins> | Ponies, if you please? |
| 23:37 | <Hixie> | i'm not being sarcastic. i'm honestly curious. |
| 23:38 | <Hixie> | if it's a short list, it might make sense to just create a JS file that browsers are required to run by default or something. |
| 23:38 | <TabAtkins> | The two painfully annoying parts of the DOM that I regularly experience are (1) element creation and (2) meaurement/positioning. Both of these can be fixed by libraries, but are worthwhile fixing in the core. |
| 23:38 | <Hixie> | i'm all for making element creation easier, but what's hard about it is creating trees, not creating an element and setting some properties |
| 23:38 | <TabAtkins> | (Not all of the measurement features are actually doable in current JS, but a lot are.) |
| 23:39 | <Hixie> | the measurement/positioning thing is hopefully something that can be solved in CSSOM using some of the things i proposed a decade or so ago, or something derived from it |
| 23:39 | <Hixie> | anne's on that, i think |
| 23:39 | <TabAtkins> | Hixie: Trees are easy. "new Element.div({props}, "some text" , new Element.p({}, "more text in a <p>")) |
| 23:39 | <TabAtkins> | Hixie: Anne or me or roc, yeah. |
| 23:41 | <Hixie> | that's harder than `<div props>{text}<p>{moretext}`, or whatever syntax we come up with based on quasis |
| 23:41 | <Hixie> | e4x-like syntax |
| 23:41 | <TabAtkins> | Agreed, if your elements and attributes are known at write-time. |
| 23:41 | <TabAtkins> | The function appraoch is easier if you only know them at runtime. |
| 23:41 | <Hixie> | and uglier, imho, than Element.create("div", {props}, ["some text", Element.create("p", ["more text"])]) |
| 23:41 | <TabAtkins> | Both are good. ^_^ |
| 23:42 | <Hixie> | but in either case i agree that that's worth adding |
| 23:42 | <Hixie> | it was the implication of "Quasi strings are a great complement, but they don't let you easily, say, make an element with a bag of properties" that i object to |
| 23:42 | <smaug____> | In many cases innerHTML works quite well |
| 23:42 | <TabAtkins> | Hixie: Personal taste on that I guess. I like constructors better than factories, and omitting arrays when possible (since ES6 should have a way to expand arrays into varargs). |
| 23:42 | <Hixie> | namely that "easily, say, make an element with a bag of properties" is a use case that on its own should be fixed |
| 23:43 | <Hixie> | smaug____: innerHTML fails hard because it doesn't give you compile-time syntax checking |
| 23:43 | <Hixie> | smaug____: it also fails even harder due to XSS |
| 23:43 | <TabAtkins> | smaug____: Plus, injection woo! |
| 23:43 | <Hixie> | smaug____: (it makes injection easier than doing it right) |
| 23:44 | <smaug____> | I don't understand how Element.create gives syntax checking... |
| 23:45 | <Hixie> | smaug____: you can't do the equivalent of <b>x<i>y</b>z</i> with it |
| 23:45 | <smaug____> | creating Element.create("<") shouldn't work |
| 23:45 | <smaug____> | ah, you mean that |
| 23:45 | <TabAtkins> | Plus, it's theoretically possible to do content-model checking among the children passed to the function. |
| 23:46 | <Hixie> | well, it would be in some languages |
| 23:46 | <TabAtkins> | Dunno if that's a good idea or not. |
| 23:46 | <Hixie> | i don't think we'll see that in JS any time soon |
| 23:46 | <Hixie> | and the HTML rules are probably far too complex to be sanely represented in a type system |
| 23:47 | <TabAtkins> | Yeah, likely. |
| 23:47 | <bga_> | heh |
| 23:48 | <bga_> | sec |
| 23:48 | <TabAtkins> | Well, you don't need to use a formal type system to verify parameters passed to a function. That can be done manually. |
| 23:49 | <othermaciej> | I suspect not even Haskell's type system could do all HTML5 content model checks correctly |
| 23:49 | <Hixie> | TabAtkins: oh i meant at compile time |
| 23:49 | <Hixie> | TabAtkins: you could do runtime checking even of innerHTML, that's not so interesting |
| 23:52 | <TabAtkins> | Hixie: You're right. |
| 23:58 | <bga_> | http://pastie.org/2764698 |
| 23:58 | <bga_> | i hope it will in future web |
| 23:59 | <bga_> | and smart compiler can validate html |