| 00:02 | <jamesr__> | does ECMA-262 provide a web-compatible definition of JSON? |
| 00:02 | <jamesr__> | it defers *mostly* to http://www.ietf.org/rfc/rfc4627.txt |
| 00:09 | <zewt> | seems like a spec that's published in PDF is inherently incompatible with the web |
| 00:10 | <jamesr__> | there's an html version of ECMA262 |
| 00:11 | <zewt> | oh, they have PDF in a big bold table, then html quietly in prose underneath it; strange |
| 00:15 | <zewt> | http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.3 it's nice that they're defining it algorithmically, but ouch |
| 00:22 | <zewt> | rfc4627 says to \u1234-escape UTF-16; looks like ecma-262 says to just return the surrogate, which appears to be what Chrome does |
| 00:23 | <zewt> | ... which is strange, actually, since it means to get "conforming" utf-16 you need to do postprocessing to escape non-bmp characters, you can't just dump the result into a utf-8 encoder |
| 00:24 | <zewt> | (i wonder how much of the web actually depends on JSON escaping non-BMP characters, which is pretty nasty) |
| 00:24 | <zewt> | i guess I should say how much software, given that JSON.stringify *doesn't* escape them |
| 01:13 | <aleray> | hi, I'm having an error with this code: http://dpaste.com/1410324/ |
| 01:14 | <aleray> | All strings must be XML compatible: Unicode or ASCII, no NULL bytes or control characters |
| 01:15 | <aleray> | problem is I have no control over the input, so this character pops up from time to time, I don't know why |
| 01:16 | <MikeSmith> | aleray: sounds like you need to preprocess the input |
| 01:17 | <aleray> | MikeSmith, I found the error. Stupid me |
| 01:18 | <aleray> | not sure actually, but good thinking |
| 01:41 | <aleray> | MikeSmith, yes it was this: "SPACE_REGEX.sub(u'\u2026 \1', text) to "SPACE_REGEX.sub(ur'\u2026 \1', text)" |
| 01:41 | <MikeSmith> | ok |
| 01:41 | <aleray> | it was introducing the \x01 control character |
| 01:44 | <MikeSmith> | I see |
| 04:21 | <Hixie_> | is there no way to position a background image's right edge 1em from the right edge of the background-origin ? |
| 07:35 | <zcorpan> | "ECMAScript 3 has literals (or at least initializers) for every type but timestamps. Having timestamp literals would probably help dissuade developers from the current practice of passing some (often) random string to Date.parse and ask it to figure out what it means. Since the input syntax to that function is not defined in the spec, this practice is is evil." http://wiki.ecmascript.org/doku.php?id=proposals:date_literal_ |
| 07:35 | <zcorpan> | syntax |
| 07:35 | <zcorpan> | ...why not define the input syntax for Date()? |
| 07:36 | <Ms2ger> | That's Work |
| 08:52 | <annevk> | matjas: should prolly list that as an open issue in http://javascript.spec.whatwg.org/#date |
| 08:53 | <zcorpan> | jgraham: https://critic.hoppipolla.co.uk/r/348 y no tracking? |
| 09:46 | <SimonSapin> | Hixie_: 'right 1em top 14px' |
| 09:47 | <SimonSapin> | full grammar: http://www.w3.org/TR/css3-background/#ltpositiongt |
| 09:51 | <Ms2ger> | odinho, good to hear that you like wptserve :) |
| 10:06 | <smaug____> | drawCustomFocusRing is oddly named. It may not draw anything |
| 10:07 | <zcorpan> | maybeDrawCustomFocusRing? |
| 10:08 | <smaug____> | I guess it should be split to two methods |
| 10:09 | <smaug____> | canDraw... |
| 10:09 | <smaug____> | hmm |
| 10:09 | <smaug____> | perhaps there should be just canDraw... |
| 10:09 | <smaug____> | and drawSystemFocus.. |
| 10:12 | <jgraham> | smaug____: Re: ServiceWorker and .ts, I read that as "we won't write a spec or use WebIDL because fuck you" |
| 10:13 | <smaug____> | ha |
| 10:14 | <jgraham> | zcorpan: Not tracking because the author did a rebase |
| 10:14 | <smaug____> | I thought more like: we use this hard to read way so than no one can comment on the API design |
| 10:14 | <jgraham> | smaug____: I think that amounts to the same thing |
| 10:15 | <jgraham> | zcorpan: (or, more precisely, I think they did an in-place history rewrite) |
| 10:17 | <Ms2ger> | What's this ServiceWorker thing? |
| 10:18 | <annevk> | Ms2ger: new NavigationController |
| 10:18 | <Ms2ger> | Oh, new new new appcache? |
| 10:19 | <smaug____> | yeah. and it is being implemented even though the proposal doesn't even have webidl for the interfaces :/ |
| 10:19 | <smaug____> | (makes it hard to help the on who is implementing it) |
| 10:19 | <smaug____> | s/on/one/ |
| 10:20 | <jgraham> | Ms2ger: Think of it as Google Gears for the 2010s |
| 10:20 | <annevk-cloud> | could contribute some IDL to the repo |
| 10:20 | <annevk-cloud> | I can do that next week somewhere |
| 10:20 | <annevk-cloud> | would that help, smaug____ ? |
| 10:20 | <smaug____> | webidl would help, yes |
| 10:20 | <jgraham> | Only if it was the canonical version |
| 10:20 | <jgraham> | Otherwise it will drift out of date |
| 10:21 | <smaug____> | now I have basically no idea what kind of odd event interface the thing has |
| 10:21 | <smaug____> | I know they are something very unusual |
| 10:21 | <Ms2ger> | Futures |
| 10:21 | <smaug____> | it has some odd mix of events and promises |
| 10:23 | smaug____ | is too negative |
| 10:24 | <Ms2ger> | You'd never |
| 10:24 | <odinho> | Ms2ger #) |
| 10:25 | <Ms2ger> | (I don't see you around a lot anymore) |
| 10:26 | <smaug____> | all I want is little consistency, also in API design :) |
| 10:36 | <annevk-cloud> | smaug____: I think that goes for the people involved in designing that too |
| 10:37 | <MikeSmith> | krijnh: http://krijnhoetmer.nl/irc-logs/whatwg don't seem to be responding |
| 10:38 | <smaug____> | annevk-cloud: sorry, I shouldn't be so negative, but it was just surprising to see an "API proposal" which didn't define the API in any common way |
| 10:39 | <annevk-cloud> | it coming from the people that don't like IDL, that kinda makes sense |
| 10:40 | <smaug____> | but even then it is missing lots of the API |
| 10:40 | <Ms2ger> | So if that's the kind of spec they want to see... |
| 10:40 | <smaug____> | and the definition of various things is just still wrong, but I guess that is expected when the spec is so early draft |
| 10:40 | <jgraham> | annevk-cloud: "I don't like WebIDL so I am going to be purposefully obstructive and use my own invented format" is kind of childish |
| 10:40 | <smaug____> | indeed |
| 10:41 | <annevk-cloud> | jgraham: I'm not sure why you'd interpret the motivation like that |
| 10:41 | <jgraham> | annevk-cloud: You just *said* that was the motivation |
| 10:42 | <annevk-cloud> | jgraham: from comments given thus far it seems pretty clear they want to figure out the API in terms of JavaScript first, and IDL second |
| 10:42 | <annevk-cloud> | jgraham: no, I was just describing a group of people |
| 10:44 | <jgraham> | I don't understand what distinction you are trying to make. But this approach increases the barrier to entry for giving feedback and makes implementation very challenging and likely to suffer from interop problems |
| 10:44 | <smaug____> | yeah, the current spec isn't anything for implementors |
| 10:44 | <smaug____> | you'll get random interfaces added to implementations |
| 10:45 | <jgraham> | Which perhaps wouldn't matter if this was really an early stage and no one was trying to implement |
| 10:45 | <jgraham> | But it isn't and they are |
| 10:45 | <annevk> | *shrug* |
| 10:50 | <MikeSmith> | if anybody has some time to help me with idlharness.js tests for the Notifications spec, https://critic.hoppipolla.co.uk/r/349 |
| 11:19 | <MikeSmith> | got to admire the honesty in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23260#c12 |
| 11:44 | <zcorpan> | where does the svg spec say which elements implement SVGElement? |
| 11:47 | <MikeSmith> | zcorpan: "All of the SVG DOM interfaces that correspond directly to elements in the SVG language (such as the SVGPathElement interface for the ‘path’ element) derive from the SVGElement interface." |
| 11:47 | <MikeSmith> | so does that mean.. All of the elements? |
| 11:47 | <MikeSmith> | all of the elements which have SVG DOM interfaces |
| 11:47 | <zcorpan> | MikeSmith: no, that just says that SVGFooElement inherits from SVGElement |
| 11:48 | <zcorpan> | MikeSmith: it doesn't say anything about which elements implement SVGElement |
| 11:48 | <zcorpan> | other than <path>, i guess |
| 11:48 | <zcorpan> | and the elements that have an interface that inherits from SVGElement |
| 11:49 | <MikeSmith> | yeah. You want the ones that actually just use SVGElement? instead of some other interface that inherits from it? |
| 11:50 | <zcorpan> | i want to know what interface this element is supposed to use: <foobarbaz xmlns='http://www.w3.org/2000/svg'/>; |
| 11:51 | <zcorpan> | all elements that are defined in svg say what interface they use, but i don't find any statement covering unknown elements in the svg namespace |
| 11:51 | <MikeSmith> | ah |
| 11:53 | <zcorpan> | html says "The HTMLUnknownElement interface must be used for HTML elements that are not defined by this specification (or other applicable specifications)." |
| 11:54 | <zcorpan> | blink and gecko appear to use SVGElement for unknown elements in the svg namespace |
| 11:54 | <zcorpan> | i'll file a bug on svg |
| 11:56 | <MikeSmith> | zcorpan: well I tried reading |
| 11:56 | <MikeSmith> | enough to know that http://www.w3.org/TR/SVG/single-page.html#svgdom-ElementsInTheSVGDOM doesn't help answer |
| 11:59 | <zcorpan> | well if it doesn't say anything, then i guess it means that it must use the Element interface. but that doesn't match reality |
| 12:56 | <Ms2ger> | krijn, down again? |
| 12:58 | <MikeSmith> | Ms2ger: seems so |
| 12:59 | <MikeSmith> | speaking of which I was trying to read the logs for when zcorpan pinged me yesterday about the parser |
| 12:59 | <MikeSmith> | zcorpan: I wasn't sure what you wanted me to try changing |
| 13:00 | MikeSmith | re-read local logs |
| 13:00 | <zcorpan> | http://logbot.glob.com.au/?c=freenode%23whatwg has logs |
| 13:00 | <krijnh> | Ms2ger: hm, no, but my hdd is full :D |
| 13:01 | <zcorpan> | MikeSmith: so i found bugs, you hadn't properly implemented my proposal because the v.nu parser's structure isn't a 1:1 mapping to the spec |
| 13:02 | <krijnh> | Ms2ger, MikeSmith: should be up again |
| 13:02 | <MikeSmith> | zcorpan: right that's what makes it harder to just quickly hack in changes |
| 13:03 | <Ms2ger> | Ta |
| 13:03 | <MikeSmith> | krijnh: thanks |
| 13:03 | <zcorpan> | (1) https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2534 should be commented out |
| 13:03 | MikeSmith | commenting out now |
| 13:04 | <zcorpan> | (2) https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2478 should be commented out |
| 13:05 | <zcorpan> | (3) https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2886 should be commented out |
| 13:05 | <zcorpan> | (4) https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L4021 should be commented out |
| 13:06 | <zcorpan> | (5) https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2981 add pop() before this line |
| 13:06 | <zcorpan> | that's all i found by looking at the code |
| 13:08 | <zcorpan> | well, and the changes to after after foo could be reverted since the it wasn't broken |
| 13:10 | <MikeSmith> | zcorpan: all the after after changes? |
| 13:12 | <zcorpan> | MikeSmith: the stuff up to line 930 in https://github.com/validator/htmlparser/commit/888fba3fe33c9b0fb0df76189b9d549eae176833 i think |
| 13:12 | <MikeSmith> | ok |
| 13:21 | <MikeSmith> | zcorpan: pushed to https://github.com/validator/htmlparser/commit/4924b651bc023ae080e99501eda473e5de510d3b but still fails at runtime due the same problem I mentioned |
| 13:21 | <MikeSmith> | I hope Henri will take an interest at some point |
| 13:22 | <MikeSmith> | in the mean time I'll make time later to try to figure out if I can make it work |
| 13:22 | <zcorpan> | MikeSmith: ok. what markup are you running to test? |
| 13:22 | <MikeSmith> | the HTML spec |
| 13:22 | <zcorpan> | single-page? |
| 13:23 | <MikeSmith> | yeah |
| 13:23 | <MikeSmith> | the validator tries to parse that at startup to extract the attribute information |
| 13:24 | <zcorpan> | ok so that sees <body> IN_HEAD |
| 13:26 | <MikeSmith> | right |
| 13:27 | <zcorpan> | so goes through https://github.com/validator/htmlparser/blob/4924b651bc023ae080e99501eda473e5de510d3b/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2531 |
| 13:27 | <zcorpan> | and then https://github.com/validator/htmlparser/blob/4924b651bc023ae080e99501eda473e5de510d3b/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2888 |
| 13:28 | <zcorpan> | at least now it doesn't pop() twice |
| 13:28 | <MikeSmith> | yeah |
| 13:28 | <zcorpan> | but i don't know why it fails |
| 13:30 | <MikeSmith> | zcorpan: relevant part of the stack trace is https://gist.github.com/sideshowbarker/6901293 |
| 13:31 | <zcorpan> | hmm, might have missed flush/pop here https://github.com/validator/htmlparser/blob/4924b651bc023ae080e99501eda473e5de510d3b/src/nu/validator/htmlparser/impl/TreeBuilder.java#L4004 |
| 13:31 | <MikeSmith> | ok will add that |
| 13:36 | <zcorpan> | but that's for end tags so won't change the case at hand |
| 13:41 | <zcorpan> | MikeSmith: hmm, the trace is weird, it goes through https://github.com/validator/htmlparser/blob/4924b651bc023ae080e99501eda473e5de510d3b/src/nu/validator/htmlparser/impl/TreeBuilder.java#L5067 but the html spec has attributes on the <body> |
| 13:43 | <MikeSmith> | hmm yeah hang on |
| 13:44 | <MikeSmith> | I've actually been running it with the W3C version of the spec |
| 13:44 | <MikeSmith> | (build switch) |
| 13:44 | <zcorpan> | url? |
| 13:46 | <niloy> | hey guys, is this the right place to talk about "for" attribute? |
| 13:46 | <jgraham> | Potentially |
| 13:47 | <niloy> | well I am facing this problem, I am creating a label and checkbox from javascript, I want to tie them up with "for", but "for" requires string only |
| 13:47 | <zcorpan> | MikeSmith: (url to the w3c version of the spec, that is) |
| 13:48 | <MikeSmith> | zcorpan: trace with non-W3C version says |
| 13:48 | <MikeSmith> | Caused by: java.lang.ArrayIndexOutOfBoundsException: -1 at nu.validator.htmlparser.impl.TreeBuilder.appendToCurrentNodeAndPushElement(TreeBuilder.java:5129) at nu.validator.htmlparser.impl.TreeBuilder.appendToCurrentNodeAndPushBodyElement(TreeBuilder.java:5064) at nu.validator.htmlparser.impl.TreeBuilder.appendToCurrentNodeAndPushBodyElement(TreeBuilder.java:5069) |
| 13:48 | <niloy> | if "for" accepted direct reference to HTMLNode, that would be cool |
| 13:48 | <MikeSmith> | zcorpan: hang one I'll get the URL |
| 13:49 | <MikeSmith> | zcorpan: https://raw.github.com/validator/validator/master/spec/w3c-html5.html |
| 13:49 | <MikeSmith> | and https://raw.github.com/validator/validator/master/spec/html5.html |
| 13:50 | <zcorpan> | niloy: so for is optimized for the declarative case, and the association doesn't work outside the document anyway, currently (per spec) |
| 13:51 | <zcorpan> | MikeSmith: thx. so w3c-html5.html sees <body> AFTER_HEAD |
| 13:51 | <niloy> | zcorpan, so it is worth it to make "for" work with HTMLNode directly, so that I dont have to think about generating unique strings? |
| 13:51 | <MikeSmith> | zcorpan: yeah seems so |
| 13:51 | <zcorpan> | niloy: can't you put the control inside the label? |
| 13:52 | <niloy> | zcorpan, yeh I can do that, thx |
| 13:54 | <zcorpan> | MikeSmith: ok then the trace makes sense |
| 13:55 | <zcorpan> | MikeSmith: what's on the stack at that point? |
| 13:55 | <zcorpan> | the stack of open elements |
| 14:02 | <MikeSmith> | zcorpan: dunno but I suppose I can hack in something to dump it out |
| 14:29 | <Domenic_> | Am I right that requestAutocomplete is screaming for a promise return type? |
| 14:30 | <zcorpan> | does this look right? |
| 14:30 | <zcorpan> | <p>The <dfn title=dom-Window-devicePixelRatio><code>devicePixelRatio</code></dfn> attribute must return the result of dividing the size of a CSS pixel at 100% |
| 14:30 | <zcorpan> | zoom by the size of a device pixel of the output device, in one dimension. If the device pixel is not square, then the smaller size must be used. |
| 14:32 | <zcorpan> | i guess "smaller size" is ambiguous if the device pixel isn't rectangular, either |
| 14:35 | <Domenic_> | ah I see that's already in the wiki spec |
| 14:35 | <zcorpan> | If the device pixel is not square, then the smaller of the vertical or horizontal size of the smallest bounding box of the device pixel must be used. |
| 14:36 | <MikeSmith> | zcorpan: in that case of both the WHATWG and W3C copies of the spec at the point where the parser fails, the stack of open elements shows html head script |
| 14:36 | <MikeSmith> | hmm but why does it still have the script element open |
| 14:37 | <MikeSmith> | zcorpan: anyway I'll be afk for a bit |
| 14:37 | <zcorpan> | ah interesting |
| 14:37 | <MikeSmith> | yeah |
| 14:37 | <MikeSmith> | something wrong there |
| 14:49 | <zcorpan> | i wonder what cssom-view should do when there are several screens |
| 14:49 | <zcorpan> | or when switching screens |
| 16:10 | <webchick> | Hi there, folks! |
| 16:11 | <webchick> | I'm Angie from the Drupal project. We have incorporated a Dialog API that attempts to conform as closely as possible to WhatWG's dialog spec at http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#the-dialog-element |
| 16:11 | <webchick> | I'm not fluent in RFC-ese so I had a question. |
| 16:12 | <webchick> | When a dialog has its close() method called, is it intended that the element stays in, or is removed from, the DOM? |
| 16:12 | <webchick> | Since it doesn't specify one way or the other explicitly, one of our developers is making the assumption it should stay there. But I think the *logical* assumption is that if it's no longer in your face, it's removed. |
| 16:13 | <nod_> | Hi there, I'm one of our developers :) |
| 16:13 | <webchick> | And I'm trying to figure out if the fact that both "When a http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#the-dialog-element element subject is to be closed, optionally with a return value result, the user agent must run the following steps:" and "If subject is in its http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document's http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.htm |
| 16:13 | <webchick> | nod_: Oh hai. :) |
| 16:14 | <webchick> | And/or if there is a better forum through which to get this question answered, please let me know. :) |
| 16:22 | <jgraham> | webchick: Since it doesn't way to remove it from the DOM, you don't remove it from the DOM |
| 16:22 | <jgraham> | Whatever is not explicitly allowed is forbidden |
| 16:22 | <webchick> | Dang. |
| 16:26 | <jgraham> | Basically the dialog exists in the DOM always, but the display is controlled by CSS |
| 16:26 | <jgraham> | (well, that skips quite a few details) |
| 16:27 | <webchick> | jgraham: Can I ask why that is? |
| 16:27 | <webchick> | I mean, I would expect that if it were hide()/show() |
| 16:27 | <webchick> | but it's open()/close() |
| 16:27 | <jgraham> | So Hixie_ was trying to work out what the right verbs should be the other day |
| 16:28 | <jgraham> | This seems like an interesting data point :) |
| 16:28 | <webchick> | Ha. :) |
| 16:28 | <webchick> | I'm always happy to walk into things totally clueless of the backstory and give opinions about what makes sense to me. ;) |
| 16:29 | <jgraham> | (I'm not sure how it would work if it was removed from the DOM, really. Where would it go? IF you wanted to re-open it later would you have to keep a js ref to the dialog around?) |
| 16:29 | <webchick> | Ok, well thanks for clearing that up, jgraham! Do you mind if I copy/paste this conversation into our issue tracker? else, I can just paraprhase it. |
| 16:29 | <jgraham> | Sure, feel free to do whatever you like :) |
| 16:29 | <webchick> | jgraham: Well, presumably it would remove it from the stack and if you wanted to re-open it, you'd start again from the "this doesn't exist in the stack yet, so make it new" |
| 16:32 | <Hixie_> | SimonSapin: ooh, interesting |
| 16:34 | <SimonSapin> | yeah, that seems to be one of the lesser known of the "new" (few years old) features |
| 16:34 | <jgraham> | Anyone know anything about pywebsockets? |
| 16:35 | <barnabywalters> | jgraham: I had a brief look at it before deciding to use a node.js package instead |
| 16:36 | <jgraham> | This is more of an internal-API question :) |
| 16:36 | <barnabywalters> | jgraham: can’t help then, sorry :) |
| 16:39 | <jgraham> | barnabywalters: Thanks anyway :) |
| 16:39 | jgraham | has enough of a hack to fix his problem now |
| 16:45 | <Hixie_> | bholley: should be online soon |
| 16:51 | <zcorpan> | jgraham: what about pywebsocket? |
| 16:51 | <jgraham> | zcorpan: I was going to ask about the API differences between standalone mode and mod_python mode |
| 16:52 | <jgraham> | Seems that your tests depended on request.args which is only there when running under apache |
| 16:52 | <jgraham> | In the end I just used urlparse on request.uri to get the query string out |
| 16:53 | <jgraham> | Seems kind of annoying to have two different APIs depending on the context you are running in |
| 16:53 | <zcorpan> | yeah i recall problems with the query string. we used standalone on t |
| 16:54 | <zcorpan> | but it was hacky either way |
| 16:55 | <zcorpan> | https://code.google.com/p/pywebsocket/issues/detail?id=68 |
| 16:57 | <SimonSapin> | jgraham: mod_python has been abandoned for years |
| 16:57 | <SimonSapin> | and pre-dates WSGI |
| 16:58 | <jgraham> | SimonSapin: I know |
| 16:58 | <jgraham> | That isn't very relevant though :) |
| 16:59 | <SimonSapin> | sorry then, carry on |
| 16:59 | <jgraham> | For whatever reason pywebsocket uses mod_python to run under apache and BaseHTTPRequestHandler to run standalone |
| 16:59 | <jgraham> | and then exposes the native "request" object, lightly modified, in each case |
| 16:59 | <jgraham> | And they don't have the same API |
| 16:59 | <jgraham> | Which is a problem because that's the API you code against |
| 17:00 | <webchick> | Thanks for the help, jgraham! I'll leave you folks to it. :) |
| 17:25 | <TabAtkins> | Hixie_: background-position: right 1em; |
| 17:28 | <TabAtkins> | Ah, never mind, SimonSapin already answered. |
| 17:48 | <gsnedders> | Random off-topic question: is there any central discussion anywhere about the long-term goal to replace SpiderMonkey in Servo? |
| 17:55 | <jgraham> | There is no long term goal to replace SpiderMonkey in Servo |
| 18:23 | <Hixie_> | MikeSmith: since i'm a pedant, i'll just point out (re your comment in bug 23145) that in XML the string <html/> is not necessarily a start tag... it can be the text of a comment or CDATA block, too. :-) |
| 18:27 | <jgraham> | Or an attribute? |
| 18:28 | jgraham | hasn't seen the context |
| 18:28 | <Hixie_> | no, "<" isn't valid in XML attributes |
| 18:31 | <jgraham> | Oh, XML |
| 18:31 | <jgraham> | I missed that critical point :) |
| 18:31 | <Hixie_> | hehe |
| 18:31 | <Hixie_> | yeah in HTML there's a ton of things it could be |
| 18:31 | <Hixie_> | e.g. contents of <script> or <textarea> |
| 18:31 | <Hixie_> | attribute value |
| 18:31 | <Hixie_> | something in the doctype... |
| 18:31 | <Hixie_> | etc |
| 18:35 | <Ms2ger> | Ah, Hixie_ |
| 18:35 | <Ms2ger> | A question about the xml serialization algorithm |
| 18:35 | <Hixie_> | yes sir |
| 18:36 | <Ms2ger> | It throws for input that can't be serialized as xml |
| 18:36 | <Ms2ger> | People want to stop doing that |
| 18:36 | <Ms2ger> | Any objection? :) |
| 18:37 | <Hixie_> | what do they want to do instead? silent data loss? |
| 18:38 | <Ms2ger> | Serializing as something that's not actually xml |
| 18:38 | <Ms2ger> | Like browsers do |
| 18:38 | <TabAtkins> | That seems bad in general, if the next thing in your pipeline is expecting XML. |
| 18:38 | <TabAtkins> | Silent data loss seems better than malforming XML. |
| 18:39 | <Ms2ger> | Want to try changing that in blink? |
| 18:39 | <TabAtkins> | Me? No. |
| 18:39 | <Hixie_> | wait, what? you want the xml serialiser to output non-xml-conforming content? |
| 18:39 | <Hixie_> | wouldn't that be... utterly pointless? |
| 18:39 | <Ms2ger> | I want the spec to match browsers |
| 18:39 | <TabAtkins> | But reporting a bug on Blink and pinging abarth with it would probably help. |
| 18:39 | <Hixie_> | ok but if the browsers are violating the xml spec, that means changing both HTML and XML |
| 18:40 | <Ms2ger> | They're not violating the xml spec |
| 18:40 | <Ms2ger> | They're just returning a string that isn't xml |
| 18:40 | <Hixie_> | ... |
| 18:40 | <TabAtkins> | Only because the XML spec says "here there be dragons". |
| 18:40 | <TabAtkins> | Calling that "not violating" is pedantry. |
| 18:41 | <Ms2ger> | *shrug* |
| 18:41 | <Hixie_> | having an XML serialiser not output XML, or output non-conforming XML that literally cannot be parsed by an XML processor, seems Very Bad for such an API |
| 18:41 | <Ms2ger> | Sure |
| 18:41 | <Hixie_> | it would, indeed, call into question the very existential purpose of this API |
| 18:41 | <Ms2ger> | Sure |
| 18:42 | <Hixie_> | i don't like giving APIs existential crises |
| 18:42 | <Ms2ger> | Sure, and I don't like my spec being dry science fiction :) |
| 18:42 | <Hixie_> | i recommend fixing the browsers. |
| 18:42 | <Ms2ger> | The browsers don't want to fix |
| 18:42 | <Hixie_> | i don't see how this could be a compat issue, since the output is pointless. |
| 18:42 | <Hixie_> | bug #s? |
| 18:42 | <Ms2ger> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23460 |
| 18:44 | <Hixie_> | where is the "don't want to fix"? |
| 18:45 | <Ms2ger> | smaug____, want to say that? ^ |
| 18:45 | <Hixie_> | are we sure it's not you who wants this changed? :-P |
| 18:47 | <smaug____> | oh, note, there is that question mark. All the browsers do something, and spec says something else |
| 18:48 | <smaug____> | so following the reality kind of makes sense :) |
| 18:49 | <Hixie_> | the reality here is bogus, unless we can't change it we really should change it. |
| 18:49 | <smaug____> | (and the reality let's browsers to do some heavy optimizations, like https://bugzilla.mozilla.org/show_bug.cgi?id=923913 ) |
| 18:49 | <smaug____> | I'm not ready to try to change it |
| 18:49 | <TabAtkins> | smaug____: That's just a matter of changing from "throws on invalid" to "silently loses data on invalid". |
| 18:49 | <smaug____> | if some other browser vendor wants to, and there are no problems, I think Gecko would follow |
| 18:49 | <Hixie_> | i don't mind us returning the empty string or something instead of throwing an exception, but returning invalid data is bogus. |
| 18:50 | <Hixie_> | i mean, specifically here, if we return invalid data, it is unusable. |
| 18:50 | <smaug____> | ah, empty string would be find too |
| 18:50 | <Hixie_> | it's not like in HTML mode, where the parser will muddle through. |
| 18:50 | <smaug____> | s/find/fine/ |
| 18:51 | <smaug____> | I definitely could accept empty string easier |
| 18:51 | <Hixie_> | Ms2ger: empty string? |
| 18:51 | <Ms2ger> | Could live with that if people want to implement |
| 18:55 | <jsbell> | Chrome requires the new operator when constructing XMLHttpRequest(), Firefox & IE allow it to be called as a function (e.g. xhr = XMLHttpRequest()). Anyone know the story? (context: pinged about how TextDecoder should behave) |
| 18:55 | <Ms2ger> | annevk wants to break the no-new form |
| 18:56 | <Ms2ger> | I think that's silly |
| 18:58 | <zcorpan> | jgraham: so long story short, request.unparsed_uri should be consistent in both modes. |
| 19:04 | <zcorpan> | Hixie_: Ms2ger: isn't empty string ambiguous for Element.innerHTML? surely that's supposed to mean that the element is empty? |
| 19:04 | <zcorpan> | null? |
| 19:04 | <Hixie_> | null might be even better, yeah |
| 19:05 | <Hixie_> | TabAtkins: i figured out why you were able to come up with a sanish solution for 'display' in CSS3 Display! You just ignore the two hard bits ('run-in' and 'compact')! :-P |
| 19:06 | <TabAtkins> | Hixie_: Nah, both of those are easy to put *into* the display-* framework. Their insanity is localized to their actual behavior, not their interaction with the other longhands. |
| 19:06 | <Hixie_> | i'll believe that when i see it :-P |
| 19:06 | <zcorpan> | what does compact do? |
| 19:06 | <TabAtkins> | But also, fantasai came up with a sane definition of run-in that I'm planning to put in. 'compact' is terrible and nobody will mention it. |
| 19:06 | <TabAtkins> | zcorpan: Go look at CSS2 and see if you can figure it out. If you can, write a spec plz. |
| 19:06 | <zcorpan> | does anyone implement compact? |
| 19:06 | <Hixie_> | 'compact' might be dead now, yeah. back when i tried doing this, i was trying to include 'compact' which is what made it so hard to do. |
| 19:06 | <TabAtkins> | Not really, no. |
| 19:07 | <Hixie_> | ('compact' would be really useful in a lot of cases i run into in <dl>-like scenarios in UIs and documents) |
| 19:09 | <TabAtkins> | It's basically magic abspos, fitting into the margin of the following block if possible. |
| 19:09 | <TabAtkins> | If not possible, it's a normal block box. |
| 19:15 | <zcorpan> | foolip: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23469 |
| 19:18 | <Hixie_> | a surprisingly large part of my life over the past decade and a half has been taken up just reading bugzilla e-mails. |
| 19:18 | <Hixie_> | i don't know what i feel about that. |
| 19:21 | <Ms2ger> | Surprisingly? |
| 19:29 | <Hixie_> | given that i've moved between employers and changed from QA to spec writing and so forth, yes. |
| 19:44 | <zcorpan> | MikeSmith: what does "untested" do? |
| 20:03 | <Hixie_> | MikeSmith: re https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 - should we leave bugs in Unwelcome open, so they come up in searches more? |
| 20:12 | <abarth> | Hixie_, TabAtkins: There's a CL under review to fix some of those cases |
| 20:12 | <abarth> | I just need to some whiskey before studying it |
| 20:12 | <TabAtkins> | abarth: Come on down to the mtv office and we'll hook you up. |
| 20:15 | <Hixie_> | some of which cases? |
| 20:16 | <TabAtkins> | outputting malformed xml |
| 20:16 | <abarth> | < inside <script> |
| 20:16 | <abarth> | i can find the bug |
| 20:16 | <abarth> | https://codereview.chromium.org/26193002/ |
| 20:17 | <abarth> | its from someone named pwnall |
| 20:17 | <abarth> | which makes me think I should read it carefully :) |
| 20:26 | <Hixie_> | ah, cool |
| 20:26 | <Hixie_> | well, consider returning null instead of firing an exception :-) |
| 20:26 | <Hixie_> | hopefully someone who cares about this filed a bug... :-) |
| 20:26 | <Hixie_> | bbiab, lunch |
| 21:05 | <Hixie_> | smaug____: really? the key is the weak part? woah. what's the point of it then? |
| 21:05 | <Hixie_> | smaug____: like, how do you use it? |
| 21:05 | <smaug____> | that is the whole point |
| 21:05 | <Hixie_> | or why would you use it? |
| 21:05 | <smaug____> | you can add weak object->value references |
| 21:06 | <Hixie_> | so it's basically only useful as a way to annotate objects? |
| 21:07 | <smaug____> | https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap#Why_WeakMap.3F |
| 21:08 | <Hixie_> | sure, once you said it was keys all that was obvious |
| 21:08 | <Hixie_> | it doesn't answer the question of why you would use it though... |
| 21:08 | <Hixie_> | why not just hang your annotation off the object directly? |
| 21:08 | <Hixie_> | like, if it's an HTMLElement, you could just use ._mydata or whatever |
| 21:08 | <Hixie_> | set a custom property on the object |
| 21:09 | <Hixie_> | wouldn't that do exactly what WeakMap does? |
| 21:10 | <smaug____> | so you can do thing like does something belong to a set |
| 21:10 | <smaug____> | though, you could indeed just add foo._myState |
| 21:19 | <jsbell> | Hixie: if you can hang a property off something, then yes it's equivalent. |
| 21:20 | <jsbell> | In the cases where you can't - the object is frozen, or the thing you're setting on the object is secret, or two instances need to set properties, etc then it's necessary. |
| 21:21 | <jsbell> | It could be implemented in the VM by setting hidden properties. |
| 21:27 | <Hixie_> | what's a frozen object? another new ES6 thing? |
| 21:27 | <Hixie_> | i don't understand what you mean by "secret". it's just code. and two instances can just use two properties. |
| 21:37 | <jsbell> | Hixie: Object.freeze in ES5, e.g. var o = {}; Object.freeze(o); o.p = 1; alert(o.p); ==> undefined |
| 21:38 | <Hixie_> | what's the use case? |
| 21:38 | <jsbell> | Most of this (including WeakXXX) came out of the Caja/SES work |
| 21:39 | <Hixie_> | smaug____: the e-mail i posted when i added this was http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0013.html |
| 21:39 | <smaug____> | ok, thanks |
| 21:39 | <smaug____> | I was just looking for PortCollection in the messages |
| 21:39 | <jsbell> | Short version: you're trying to implement a sandbox |
| 21:40 | <Hixie_> | (for the record, i really don't care what the solution is here. i just think we should have a solution that doesn't involve essentially requiring a memory leak.) |
| 21:40 | <Hixie_> | jsbell: that sounds like a wackamole exercise in frustration... |
| 21:47 | <smaug____> | we just can't expose gc behavior |
| 21:47 | <smaug____> | once we do that explicitly, it will creep into other APIs too |
| 21:56 | <zewt> | Object.freeze seems pretty horrible if it doesn't throw |
| 22:27 | <Domenic_> | WeakMap => truly private state |
| 22:27 | <Domenic_> | Object.freeze throws in strict mode (which everyone should be using) |
| 22:28 | <Domenic_> | Without WeakMap it is impossible to have high-integrity objects in JS, like e.g. platform objects |
| 22:31 | <Hixie_> | what's the use case for high-integrity objects in JS? |
| 22:31 | <Hixie_> | i mean it sounds good and all, but it's not clear what the point is |
| 22:31 | <Hixie_> | to me at least |
| 22:31 | <TabAtkins> | Explaining the platform, and introducing new things similar to the current platform. |
| 22:32 | <Hixie_> | you can explain the platform without it, and you can introduce new things similar to the platform with it it too |
| 22:32 | <Hixie_> | we've been doing both for decades |
| 22:33 | <TabAtkins> | Different definition of "explaining", and no you can't, at least with sufficient fidelity. |
| 22:34 | <Domenic_> | saying "you must use C++ if you want private state" is kind of O_o |
| 22:36 | <Hixie_> | TabAtkins: ok, let me put it another way then: i disagree that those use cases are valuable :-) |
| 22:36 | <Hixie_> | TabAtkins: what's an end-user use case? |
| 22:36 | <TabAtkins> | We know you do. You've said that over and over again in the past. |
| 22:36 | <TabAtkins> | And we've just ignored you and worked around it. ^_^ |
| 22:36 | <Hixie_> | yeah... not helpful |
| 22:37 | <Hixie_> | why not just explain why it's useful? |
| 22:37 | <TabAtkins> | Sorry, but you've repeatedly stated your disdain for "make APIs that look and act the same as native ones" as a use-case. |
| 22:37 | <Hixie_> | that's because it's not a use case... |
| 22:37 | <TabAtkins> | And that's why it's not worth explaining to you, because your suggestion of "just make the API not look like the platform" isn't useful. |
| 22:37 | <Hixie_> | it is often brought up as a use case as if it is obvious on its face why it's valid, but it's not obvious at all, and no attempt seems to have been made to explain it |
| 22:38 | <Hixie_> | it's like something you have on faith or something |
| 22:38 | <Hixie_> | faith-based API design considered harmful :-P |
| 22:38 | <TabAtkins> | I'm sorry you don't understand why it's useful for users of a library to have the library act like the rest of the platform. |
| 22:39 | <Hixie_> | that isn't helpful or constructive |
| 22:39 | <Hixie_> | seriously, if you can't articulate why something is helpful, maybe it's not. that's all i'm saying. |
| 22:39 | <Domenic_> | i think it's been articulated, but not to your satisfaction, just to many other peoples'... |
| 22:39 | <Hixie_> | where? |
| 22:39 | <TabAtkins> | I did articulate it. I, and others, have done so many times. You just don't accept it. Shrug. |
| 22:41 | <Hixie_> | it just seems crazy to me that ES is getting a ton of APIs that i see as essentially pointless, and the only argument in favour is "we said it's important, but you won't believe us" |
| 22:41 | <TabAtkins> | "Because a consistent platform is good" is the basic reason for lots of things, including stuff you've found very valuable, like specifying the parser. |
| 22:41 | <Hixie_> | the parser spec is useful to get interop and that's good to avoid concrete security bugs. |
| 22:42 | <Hixie_> | consistency is not, and has never been, a compelling use case. there's tons of stuff we haven't added to HTML because consistency was the only argument. |
| 22:42 | <TabAtkins> | It's also helpful for authors, because it means a lower cognitive overhead. |
| 22:42 | <Hixie_> | more APIs doesn't mean a lower cognitive overhead. |
| 22:43 | <Hixie_> | i mean, it really doesn't. it's easier to understand classical mechanics (which isn't internally consistent) than quantum mechanics (which is), as a simple example of that. |
| 22:44 | <TabAtkins> | Le sigh. No, but having libraries do things in a way similar to the platform *does* mean a lower cognitive overhead, as opposed to library users having to learn to do things in 2+ different ways because some things are "native" and some are "JS". |
| 22:45 | <Hixie_> | but again, authors don't have to do that. it's quite possible to write libraries that work close enough to the platform that authors have no troubles, without any of this stuff. |
| 22:45 | <TabAtkins> | And some patterns, like private state, which are extremely useful, currently require either giving up on real privacy (using naming conventions, for example), or costing a bunch of memory (using closures for private state on objects). WeakMaps address the problem easily and properly. |
| 22:45 | <Hixie_> | unless you have a concrete counter-example? |
| 22:45 | <TabAtkins> | Not off the top of my head, because I just stumbled into this argument. |
| 22:45 | <TabAtkins> | And I'm trying to code some Python right now. ^_^ |
| 22:45 | <smaug____> | poor you :) |
| 22:46 | <Hixie_> | it's not "real" privacy. all this code is running in the same security context. |
| 22:46 | <Hixie_> | user privacy isn't in the slightest bit affected. |
| 22:46 | <TabAtkins> | "Privacy" clearly has different definitions, and I'm not using that one. |
| 22:47 | <Hixie_> | what definition are you using? |
| 22:48 | <Hixie_> | i'm just baffled by this. It seems like a clear case of user>author>spec>theory being turned on its head. |
| 22:48 | <TabAtkins> | ...the one that means private state on an object? |
| 22:48 | <Hixie_> | what's the use case for that on the web? |
| 22:49 | <TabAtkins> | The same as its use-case in any other programming language, ever. |
| 22:49 | <zewt> | the idea of putting state on an object in a different object seems pretty seriously nasty, at least from a code style standpoint (granted that it may be the same under the hood) |
| 22:49 | <TabAtkins> | I refuse to explain the concept of private state to you. |
| 22:49 | <TabAtkins> | zewt: It's a little funky at first, but not bad once you've seen it once or twice. |
| 22:50 | <Hixie_> | TabAtkins: ok, but then don't complain that it's "not worth explaining to you" when you won't explain it |
| 22:50 | <Hixie_> | just admit you don't want to and move on |
| 22:50 | Hixie_ | continues to be baffled |
| 22:50 | <TabAtkins> | It's... not worth explaining a basic computer science concept to you. You can use Wikipedia for that. |
| 22:51 | <Hixie_> | (note that i can't think of any other language that has a way to add private state to an object the way that WeakMap does.) |
| 22:51 | <Hixie_> | are we talking about local private state? |
| 22:51 | <Hixie_> | because that doesn't seem to be what WeakMap gives you |
| 22:51 | <Hixie_> | or freeze |
| 22:51 | <zewt> | i think WeakMap does give that, if we mean the same thing by "local private state" |
| 22:52 | <Hixie_> | i mean, i am an object, and i have state i don't want public. |
| 22:52 | <TabAtkins> | Yes, the actual code you write to assign private state via WeakMap is slightly different. Rather than obj[key] = val, you write map[obj] = val. That's not a material difference. |
| 22:52 | <Hixie_> | WeakMap seems to be a way to secretely annotate other objects. |
| 22:52 | <zewt> | hixie: right |
| 22:53 | <zewt> | if you want private state in the object itself you still need to stash it in a closure |
| 22:53 | <Domenic_> | that's... not in the object itself, that's in an external data structure called "scope" |
| 22:53 | <Hixie_> | i'm all for JS having classes with private blocks and all |
| 22:53 | <Hixie_> | but that seems completely orthogonal to this |
| 22:53 | <zewt> | Domenic_: no difference as far as API structure is concerned |
| 22:53 | <Hixie_> | this being WeakMap and the frozen object thing |
| 22:54 | <Domenic_> | zewt: big difference... but maybe i'm not understanding...? |
| 22:54 | <zewt> | fwiw I don't have a strong opinion on whether it's worth it or not, but I agree with hixie that this is not analogous to private state inside an object, this is external to the object |
| 22:55 | <Domenic_> | right, it is strictly more powerful than other languages' private state abstraction, which is tied to e.g. classical models |
| 22:55 | <Domenic_> | but it is in the end a private state abstraction |
| 22:55 | <Hixie_> | my opinion is not "strong", it just the default opinion of "there's no use case -> no need to have it" |
| 22:56 | <zewt> | it doesn't seem to support the private data model of other languages at all, so I'm not sure that it's more powerful |
| 22:56 | <Hixie_> | it doesn't seem more powerful at all... it seems entirely orthogonal |
| 22:56 | <Domenic_> | es7 will probably have syntax so that e.g. obj@key = val <-> map[obj].key = val |
| 22:56 | <Domenic_> | zewt: it definitely does support that model, let me dig up some example code... |
| 22:56 | <TabAtkins> | A better term for what WeakMaps give you is "uncollidable" state. |
| 22:56 | <Domenic_> | zewt: here you go https://gist.github.com/domenic/6736258 |
| 22:56 | <TabAtkins> | Which you can use to implement cheaper private state than just using closures. |
| 22:56 | <zewt> | Domenic: to do that you'd need to stash your WeakMap in some place that itself can't be accessed--which means you're back to closures |
| 22:57 | <Domenic_> | sure, of course, or modules. |
| 22:57 | <zewt> | so it's a class that essentially exists so you don't have to use closures, which you have to put in a closure :) |
| 22:57 | <zewt> | (yeah, I know there's a difference in performance, depending on how you do it) |
| 22:57 | <TabAtkins> | zewt: Yup, closing over just a WeakMap around the constructor function is better than having to close over every bit of state. |
| 22:58 | <Domenic_> | the big difference is you can control who has access. they don't have to share a scope. so e.g. prototype methods can access the private state. |
| 22:59 | <TabAtkins> | And the even smaller WeakSet object is *solely* for branding - no chance of collision, secret if the set is secret, and doesn't accidentally leak. |
| 23:02 | <zcorpan> | man, i didn't realize css stack wasn't supported in background-image in blink |
| 23:02 | <zcorpan> | er, svg stack |
| 23:03 | <TabAtkins> | zewt: If you're familiar with Crockford's method of doing instance-private state, it requires defining fresh copies of the prototype methods directly onto each instance, so they'll be defined in the correct context. That's a big memory hit. |
| 23:03 | <zewt> | seems clumsy, if the main use case is basically in-object private state, compared to traditional private member mechanisms |
| 23:03 | <zewt> | (not to claim I know how any of those could be applied to JS in a web-compatible way) |
| 23:03 | <TabAtkins> | With WeakMap, you can just define things as normal, with a closure wrapping the class definition to contain the weakmap definitions. Then each prototype function can just use the weakmaps to attach and access private state on instances. |
| 23:04 | <TabAtkins> | Yeah, exposing privacy in the same way as other type systems is really difficult, because JS's type system is so light. |
| 23:04 | <Domenic_> | i think it fits pretty well with JS, given JS is all about object literals and prototypes and not classes. but yes, slightly clumsy for the classical case, just like classes in JS generally are. |
| 23:05 | <Domenic_> | but, just like ES6 gives us class sugar to make it less clumsy, ES7 will probably give private state sugar |
| 23:08 | <zewt> | not sure that "it's clumsy, but that's normal for JS and we'll pave over it later" is a very good sales point :) |
| 23:09 | <TabAtkins> | Heh. The issue is that the non-clumsy way doesn't decompose to real JS. |
| 23:09 | <TabAtkins> | It requires more structure than actually exists. |
| 23:09 | <TabAtkins> | So you have to start with the low-level one and add sugar for it after. |
| 23:09 | <zewt> | python's __name mechanism could probably work conceptually, but wouldn't be web-compatible (also it's painfully ugly) |
| 23:10 | <zewt> | (makes me feel like I'm reading a C++ STL header, and that's ... bad) |
| 23:10 | <TabAtkins> | Right, nobody wants that. |
| 23:10 | <TabAtkins> | (Had a near-miss with people trying to make Symbols work that way.) |
| 23:45 | <Hixie_> | TabAtkins: i think it's worth noting that the use case that the discussion ended up describing has nothing to do with simulating host objects |
| 23:45 | <Hixie_> | TabAtkins: (and if the use case is instance-private data, i really don't think it's a particularly good mechanism compared to other languages') |
| 23:45 | <TabAtkins> | No, it most certainly did. It was all about private state, which host objects can have. |
| 23:47 | <Hixie_> | it lets you get private state (in a weird way) with a slightly better memory story than you could do with closures. it doesn't give you private state that you couldn't get before, and it doesn't get you anything like the memory story that C++ native code has. |
| 23:47 | <Hixie_> | i don't understand how it can be described as something needed to simulate host objects. |
| 23:48 | <Hixie_> | or "explain the platform" |
| 23:48 | <Hixie_> | you can "explain the platform" with closures too |
| 23:48 | <TabAtkins> | "slightly better" is a misnomer. It goes from "too much memory wasted to consider for production systems" to "perfectly fine". |
| 23:48 | <Hixie_> | both of those are exaggerations. |
| 23:48 | <Hixie_> | but "lower memory usage" is a fine use case in and of its self |
| 23:49 | <TabAtkins> | Per-instance methods are completely unacceptable when you'll be creating thousands of instances. |
| 23:49 | <Hixie_> | why would you do per-instance methods? |
| 23:50 | <TabAtkins> | Because that's what you need to do if you want the methods to be able to *access* the per-instance private state. |
| 23:50 | <TabAtkins> | You can't just attach the methods to the prototype like normal, because then they're not in the instance's closure that captured the private variables. |
| 23:51 | <Hixie_> | isn't that going to be solved by a real class system? |
| 23:52 | <TabAtkins> | No, JS is not introduce "a real class system". Producing two completely different ways of having a class would be ridiculous and bad. JS is producing a class *syntax*, which desugars into the existing prototype-based stuff. |
| 23:53 | <TabAtkins> | (Or to put it another way, JS already has a real class system. It's different from some other class systems, but has its own benefits. It's not going to introduce a second one.) |
| 23:54 | <Hixie_> | ugh |
| 23:54 | <Hixie_> | see, this is what drives me crazy. we're introducing crazy things like WeakMap and freezing objects and so on, and not fixing the real pain points with JS, with are amongst others that authors just hate prototypes. |
| 23:55 | <TabAtkins> | Coming from the dude who's maintaining one of the largest piles of legacy hacks in existence. ^_^ |
| 23:55 | <Hixie_> | and you can't "explain the platform" when you're desugaring into an entirely different model than the platform is built on, either |
| 23:55 | <Domenic_> | who hates prototypes? |
| 23:55 | <TabAtkins> | And no, prototypes work just fine. Most people don't give a shit about the specifics of the class system, because almost no one does anything complicated with classes, ever. |
| 23:55 | <Hixie_> | Domenic_: who doesn't |
| 23:55 | <TabAtkins> | What they hate is the syntax, for good reason, and we're fixing. |
| 23:55 | <Domenic_> | Hixie_: web developers? |
| 23:56 | <Hixie_> | yeah, web developers |
| 23:56 | <TabAtkins> | And if you do care about the class system, prototype-based systems have some nice qualities. |
| 23:56 | <Domenic_> | vm writers hate prototypes (so they go off and build dart) |
| 23:56 | <Domenic_> | but web devs like them |
| 23:56 | <Hixie_> | it's by far the #1 issue i hear about when it comes to web devs complaining to me about JS-related topics |
| 23:56 | <Domenic_> | O_o |
| 23:57 | <zewt> | (as a web developer, i've never found a single thing to like about JS's class model compared to, say, Python) |
| 23:57 | <Hixie_> | ^ that's what it looks like when phrased politely |
| 23:57 | <Hixie_> | usually i don't hear it phrased so politely |
| 23:57 | <TabAtkins> | Every prototype-related complaint I've heard has been about the way you do classes in the current syntax. |
| 23:58 | <TabAtkins> | I've never heard anyone complain about the actual mechanics, except for people who geek over class systems and are just discussing relative merits. |
| 23:58 | <TabAtkins> | "class Foo extends Bar { ... }" is in ES6, and it fixes the syntax complaints entirely. |
| 23:58 | <Hixie_> | TabAtkins: what i find is that the people who are complaining about the syntax often don't understand the mechanics, and when you try to explain the mechanics to have them understand the syntax, they switch to complaining about the mechanics, usually with looks of contempt and disbelief. |
| 23:59 | <TabAtkins> | Hixie_: Most people don't have any clue how class systems work at all in the first place, and have only a surface understanding of what OO even means, particularly that it's just a loosely-connected set of primitives that are all separable. |