| 00:22 | <MikeSmith> | TabAtkins: "current" and "dated" is great (I realize you already decidedーjust chiming in for moral support) |
| 02:02 | <jgraham> | Currant and Dated would have been a better pun |
| 02:15 | <MikeSmith> | jgraham: harhar |
| 02:17 | <MikeSmith> | I think that pun would be completely lost on most en-US-ers |
| 02:18 | <erlehmann> | USAsians? |
| 02:18 | <erlehmann> | currant is a dried fruit |
| 02:19 | <erlehmann> | date is also fruit! |
| 02:19 | <terinjokes> | isn't fig also a fruit? |
| 02:20 | <terinjokes> | wikipedia tells me no, it's not a fruit, and then preceeds to talk about the tree's "editable fruit" so… |
| 02:21 | <erlehmann> | fugggg |
| 02:21 | <roc> | is that a <fig contenteditable>? |
| 02:21 | <terinjokes> | :+1: |
| 02:22 | <MikeSmith> | erlehmann: Thanks I didn't require the explicit explanation myself but I appreciate the consideration |
| 02:23 | <erlehmann> | is currant a mene in here? |
| 02:23 | <erlehmann> | chinese date is fruit! |
| 02:23 | <erlehmann> | fruit is internet mene! |
| 02:24 | <terinjokes> | as the self-proclaimed jokester in here, can confirm |
| 02:24 | <MikeSmith> | terinjokes: your implication that Wikipedia might have some inconsistencies is shocking |
| 02:25 | <terinjokes> | remember, wikipedia is always correct. reality is just sometimes wrong. |
| 02:25 | <MikeSmith> | I cringe pretty much any time I read any Wikipedia article odd any length |
| 02:26 | <erlehmann> | mene is confirmed then |
| 02:26 | <MikeSmith> | *Of any length |
| 02:27 | <erlehmann> | odd |
| 02:27 | <erlehmann> | fug! |
| 02:27 | <erlehmann> | so what is it about currant mene? |
| 02:27 | <erlehmann> | how come? |
| 02:33 | <jgraham> | MikeSmith: I hope you aren't accusing Ms2ger of being American |
| 02:39 | <terinjokes> | anyone know if IE is aware of their evt.defaultPrevented bug and ever plans on fixing it? |
| 02:49 | <terinjokes> | (the property is set to `true` immediately after calling "preventDefault", but is reset back to `false` at some point later |
| 02:50 | <MikeSmith> | jgraham: if I ever suggested he were American-ish at all, it'd only be in a completely positive sense; e.g. having a strong suspicion of authority :-) |
| 02:56 | <jgraham> | MikeSmith: That fig-ures |
| 02:56 | jgraham | gets his coat |
| 02:56 | <MikeSmith> | haha |
| 02:58 | <erlehmann> | > murrican |
| 02:58 | <erlehmann> | > suspicion of authorithy |
| 02:58 | <erlehmann> | you best be joking |
| 03:02 | <MikeSmith> | erlehmann: I'm from Texas. when it comes to be suspicious of, e.g., the national government, we don't joke |
| 03:02 | <MikeSmith> | actually I take that back. we do joke |
| 03:04 | <erlehmann> | MikeSmith i thought that was just some kind of jurisdiction thing |
| 03:04 | <erlehmann> | “i am not against abortion, i am against federal funding for it” and similar |
| 03:05 | <erlehmann> | but all of this is off topic and i am sleepy |
| 03:05 | <erlehmann> | so i won't elaborate |
| 03:05 | <erlehmann> | back to HTML! |
| 03:05 | <erlehmann> | annevk were there notable replies to your HTTPS post? |
| 03:06 | <MikeSmith> | HTML is completed. I guess you didn't see the news. |
| 03:06 | <erlehmann> | oh, yeah. did someone send the W3C a cake? |
| 03:28 | <MikeSmith> | erlehmann: donuts |
| 03:28 | <MikeSmith> | Krispy Kreme |
| 03:33 | <terinjokes> | wat… i'll like some krispy kreme |
| 05:39 | <zewt> | cool, twitter tab in chrome taking 2gb |
| 05:41 | <MikeSmith> | zewt: yeah, you need to leave it open for a bit longer for it to reach 4GB |
| 05:41 | <zewt> | chrome tabs never get that big, so i assume they're all 32bit processes |
| 05:41 | <MikeSmith> | so I just now installed the remote IE thing on my Android phone and it actually works. kinda amazing |
| 05:42 | <MikeSmith> | zewt: yeah? |
| 05:42 | <MikeSmith> | wonder why they do it that way |
| 05:43 | <zewt> | i'd be happy to not be getting daily memory warnings from windows that almost always originate from either firefox or chrome, heh |
| 05:43 | <zewt> | apparently 16 gigs of memory isn't enough these days |
| 05:44 | <MikeSmith> | I seem to do fine with 8GB, even compiling Firefox Nightly and Chromium a few times a week |
| 05:44 | <zewt> | that suggests you're restarting your browsers a few times a week |
| 05:44 | <MikeSmith> | and this is on a 3-year-old macbook |
| 05:44 | <MikeSmith> | nope |
| 05:44 | <MikeSmith> | well yeah |
| 05:44 | <MikeSmith> | of course |
| 05:44 | <MikeSmith> | but not because of crashes |
| 05:44 | <MikeSmith> | just after I recompile |
| 05:45 | <MikeSmith> | so yeah maybe that makes a difference |
| 05:45 | <zewt> | well, restarting browsers has a way of rebooting leakiness |
| 05:45 | <MikeSmith> | sure |
| 05:46 | <MikeSmith> | maybe that suggests a best practice: Don't use off-the-shelf browsers; instead, compile them from the sources several times a week. :) |
| 05:46 | <zewt> | things i don't ever want to do: compile browsers |
| 05:47 | <zewt> | i guess the only possible solution is to find a motherboard that'll handle 64 gigs or something |
| 05:47 | <MikeSmith> | I guess I would notice the compile time/perf costs a lot more if I were actually doing browser development and need to compile often daily |
| 05:47 | <MikeSmith> | zewt: that probably wouldn't cost you much :p |
| 05:48 | <zewt> | probably still need server hardware for that much |
| 05:48 | <zewt> | mostly i just don't want to have to think about memory or micromanage browser memory usage, heh |
| 05:48 | <MikeSmith> | computers suck so much. we really have not right to be patting ourselves on the back |
| 05:49 | <zewt> | which i didn't have to until fairly recently, not sure what changed |
| 05:49 | <MikeSmith> | carelessness happened, apparently |
| 05:51 | <MikeSmith> | one would think that in the 21st century we'd be far along enough that browser projects would be running some kind of CI automation to check for memory leaks and identify possible causes |
| 05:51 | <MikeSmith> | either that or we could be building things with programming languages that don't cause so much memory leaks and/or that at least don't make them so hard to track donw |
| 06:05 | <zewt> | probably more to do with not capping the inherent sloppiness of the web |
| 06:47 | <zcorpan> | annevk: web compat was one consideration but not the only one, and i think the url parser was fine as far as web compat goes |
| 06:48 | <zcorpan> | annevk: i only recall idna2008 disallowing some characters that broke tinyarrows |
| 08:18 | <annevk> | zcorpan: it wasn't, at least not at the point I left |
| 08:19 | <annevk> | erlehmann: not really, some disagreement over whether EV is a scam on Twitter |
| 08:19 | <annevk> | erlehmann: made me find http://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf |
| 08:39 | <erlehmann> | wach |
| 09:12 | <annevk> | http://www.unicode.org/reports/tr51/ |
| 09:13 | <annevk> | "Unicode Version 8.0 is adding 5 symbol modifier characters that provide for a range of skin tones for human emoji." |
| 09:15 | <erlehmann> | those insensitive clods, i am drawing a monochrome font! |
| 09:16 | <erlehmann> | its worse enough that „black“ means „filled“ and „white“ means „not filled“ in unicode. we only have this problem because almost everyone decided to make emoji colorful. :( |
| 09:17 | <annevk> | erlehmann: just place U+FE0E after your emoji to get a text presentation |
| 09:18 | <annevk> | (in a theoretical system) |
| 09:18 | <erlehmann> | annevk i am drawing the symbols |
| 09:18 | <erlehmann> | example http://daten.dieweltistgarnichtso.net/pics/icons/unifont-symbols-emoji.png |
| 09:18 | <annevk> | good times |
| 09:19 | <erlehmann> | i have NO IDEA how to draw 5 different skin tones in a monochrome 16×16 pixel grid |
| 09:32 | <annevk> | erlehmann: they are doing this to spite you |
| 09:33 | <erlehmann> | well, i read the document and i better start doing stippled patches |
| 09:44 | <zcorpan> | erlehmann: nice trollface |
| 09:45 | <erlehmann> | zcorpan unfortunately, my COOL FACE was the only symbol the maintainer did not merge. it did not fit with the style of the other glyphs! |
| 09:45 | <erlehmann> | but i cannot think of a more stereotypical „grinning face with smiling eyes“! |
| 09:46 | <erlehmann> | i found it funny how people can recognize the pictograph for levitating business man |
| 09:57 | <zcorpan> | i'm a bit sad that this hasn't been accepted yet https://twitter.com/zcorpan/status/463577369265971200 |
| 10:01 | <darobin> | an awesome idea |
| 10:02 | <Ms2ger> | Hey darobin, know what'd be an awesome idea too? |
| 10:02 | <darobin> | yes, I need a nap |
| 10:02 | <darobin> | plus, I've finished all the chocolate that jgraham brought me |
| 10:03 | <Ms2ger> | Or reviewing https://critic.hoppipolla.co.uk/r/2985 :) |
| 10:03 | darobin | looks |
| 10:03 | <darobin> | ooh nice |
| 10:04 | <darobin> | not this second but definitely keeping the tab open |
| 10:05 | <Ms2ger> | Thanks :) |
| 10:23 | <zcorpan> | erlehmann: my reading suggests you should probably use the fallback support level, i.e. not combine |
| 10:23 | <erlehmann> | yeah |
| 11:43 | <karlcow> | Pile of poo should have different colors. |
| 11:43 | <erlehmann> | karlcow you are of genious |
| 11:57 | <roc> | we have SVG fonts now. Use gradients. |
| 12:00 | Ms2ger | read "we hate SVG fonts now" |
| 12:28 | <espadrine_> | does the URL standard purposefully ignore IPv4 addresses as hosts? |
| 12:28 | <espadrine_> | context: I was wondering if the 127.1 shorthand was documented anywhere |
| 12:34 | <espadrine_> | by the way, should this work: http://[0:0:0:0:0:0:0:1] |
| 13:03 | <annevk> | espadrine_: it did, but that needs to be changed |
| 13:03 | <Domenic> | Nice, Intent to Implement for Element.prototype.closest |
| 13:04 | <annevk> | espadrine_: yes, that becomes http://[::1]/ |
| 13:04 | <annevk> | Domenic: nice, bz looked into at some point for Firefox, not sure what happened |
| 13:04 | <annevk> | Domenic: perhaps we're afraid of event handlers biting |
| 13:05 | <Domenic> | apparently WebKit has it, so webcompat must not be a big issue |
| 13:06 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=1055533 |
| 13:06 | <annevk> | Already landed in Firefox :-) |
| 13:06 | <espadrine_> | annevk: good! (although for some reason I can't use IPv6 URLs currently, even for localhost) |
| 14:34 | <annevk> | Thanks for the reply hsivonen |
| 14:34 | <annevk> | will keep the bug open |
| 14:59 | <Domenic> | I'm really excited about the possibility of URL getting solid tests + reference implementation that conform line-by-line with the spec. Unsure if peg.js is the right road to that, but it seems like a big win for the spec in general. |
| 15:08 | <annevk> | I'm a bit dismayed by Sam only looking at tests and not the original spec |
| 15:09 | <annevk> | But yeah, hopefully enough iteration will get us someplace nice |
| 15:16 | <Domenic> | Yeah I mean ideally there would be a line-by-line reference implementation of the original spec too |
| 15:17 | <Domenic> | I think you had one at some point but maybe didn't keep it updated? |
| 15:17 | <annevk> | Domenic: https://github.com/Polymer/url |
| 15:18 | <Domenic> | not many algorithm changes since january |
| 15:18 | <annevk> | Domenic: yeah, not sure it's maintained :/ |
| 15:18 | <annevk> | Domenic: it's easy enough to pick up again though |
| 15:18 | <annevk> | Domenic: I'm mostly waiting for browsers to pick up the pace again |
| 15:19 | <Domenic> | annevk: yeah fair |
| 15:19 | <annevk> | Someone is landing patches making Firefox match it a bit better |
| 15:19 | <annevk> | E.g. doing percent-decoding for host names |
| 15:19 | <annevk> | But it's hard since everything is a compat hazard |
| 15:21 | <Domenic> | i mean ideally aligning with some other browser would not be a compat hazard |
| 15:22 | <Domenic> | so if you avoid the cases where no browser aligns with the spec (and ideally fix the spec to align with at least one browser) then the patch should be acceptable |
| 15:22 | <annevk> | I don't think it's that simple. The specification aligns with one browser already as far as I know. However, for things like URL fragments there's a bunch of sniffing going on in JavaScript |
| 15:23 | <annevk> | Presumably for some path and query handling as well |
| 15:23 | <Domenic> | :( |
| 15:23 | <annevk> | And all that sniffing is happening because we haven't had interoperable parsing... It's a nice circle |
| 15:44 | <annevk> | hsivonen: do you think the Encoding Standard needs to change around gb18030? |
| 15:44 | <annevk> | hsivonen: I know Gecko still keeps a distinction |
| 16:19 | <SimonSapin> | espadrine_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26431 |
| 16:20 | <espadrine_> | SimonSapin: thanks! |
| 16:32 | <caitp> | would you say that shift-click navigation has a pretty consistent behaviour across user agents? |
| 16:33 | <annevk> | navigation doesn't, so... |
| 16:34 | <caitp> | particularly the "navigate in a new frame" behaviour |
| 17:04 | <erlehmann> | caitp why the question about shift-click? |
| 17:04 | <erlehmann> | also i navigate using the keyboard (hands hurt if too much touchpad) |
| 17:05 | <erlehmann> | f → follow |
| 17:05 | <erlehmann> | d → follow in new buffer |
| 17:05 | <erlehmann> | some sites hijack text input and make it impossible to navigate away from them |
| 17:05 | <erlehmann> | but my keyboard does have dedicated back and forward keys (thinkpad) |
| 17:06 | <caitp> | if enough browsers want to open shift-clicked links in a new frame, then angularjs should not do any processing on such clicks --- i'm just trying to figure out how big of a problem it is to just abort processing of clicks if shift is pressed |
| 17:09 | <erlehmann> | caitp i can test |
| 17:09 | <erlehmann> | caitp how does angular react with keyboard navigation in general? |
| 17:10 | <erlehmann> | caitp chromium opens a new tab on strg+click and a new window on shift+click |
| 17:11 | <caitp> | https://github.com/angular/angular.js/blob/master/src/ng/location.js#L775-L817 like this --- if it thinks it needs to, it will rewrite the url and prevent default |
| 17:11 | <caitp> | but if you're trying to open a link in a new frame, you probably don't want that |
| 17:12 | <erlehmann> | conkeror does nothing on both shift+click and strg+click, but it is a keyboard-focussed non-mainstream browser |
| 17:12 | <erlehmann> | elinks follows links on strg+click, but not on shift+click |
| 17:13 | <erlehmann> | äh |
| 17:13 | <erlehmann> | i have a german keyboard |
| 17:13 | <erlehmann> | strg → ctrl |
| 17:13 | <erlehmann> | links2 follows on both, without opening new tabs or windows |
| 17:14 | <caitp> | supported browsers are basically relatively modern versions of the big 5, so there isn't too much of a worry about those |
| 17:15 | <erlehmann> | netsurf displays a download dialog on shift-click, interesting. ctrl-click makes a new window. |
| 17:16 | <erlehmann> | caitp i wish i had something that describes the tradeoff of compatibility and accessability on one side and developer time on the other side as well as the related “better fast than correct” |
| 17:16 | <erlehmann> | do you know one? |
| 17:16 | <caitp> | unfortunately I don't :( |
| 17:17 | <erlehmann> | iceweasel (unbranded firefox) opens a new window on shift-click and a new tab on ctrl-click. |
| 17:17 | <erlehmann> | exactly the opposite of chromium (unbranded chrome) |
| 17:17 | <erlehmann> | i would let alt and strg alone |
| 17:17 | <erlehmann> | they are already used by access keys after all |
| 17:17 | <caitp> | on mac, in chromium, I get menu with ctrl+click, new tab with meta+click, and new window with shift+click |
| 17:17 | <erlehmann> | and lots of people use the modifiers |
| 17:17 | <erlehmann> | yeah, it is platform specific |
| 17:18 | <erlehmann> | i think any modifier should stop click capture |
| 17:18 | <erlehmann> | or rather, this should not be measured in clicks |
| 17:18 | <erlehmann> | i cannot copy from google homepage the links anymore |
| 17:18 | <erlehmann> | because they apparently get rewritten on click or something |
| 17:18 | <caitp> | it's why it's really too bad we don't have more information from UI Events, I really liked my idea for event "roles" to indicate what the user agent thinks you're trying to do |
| 17:18 | <erlehmann> | so if i never „click“, i get google tracking garbage |
| 17:19 | <erlehmann> | i think less information would be the way to go here |
| 17:19 | <erlehmann> | write your scripts interface-agnostic |
| 17:19 | <erlehmann> | i write my css interface-agnostic as well |
| 17:19 | <erlehmann> | no click events and so on |
| 17:19 | <erlehmann> | progressive enhancement instead of graceful degradation |
| 17:19 | <erlehmann> | (stopping click procssing in corner cases is degradation) |
| 17:20 | <caitp> | I think something like `if (event.role !== "navigate") return;` is a lot more interface-agnostic than worrying about different combinations of special keys |
| 17:20 | <caitp> | or which button is clicked |
| 17:21 | <erlehmann> | yeah, but you are advocating adding complexity to handle problems |
| 17:21 | <erlehmann> | i am advocating removing complexity |
| 17:21 | <caitp> | I'm not sure anyone has figured out how to really make UI "simple" |
| 17:21 | <erlehmann> | i think different |
| 17:22 | <erlehmann> | for example, i follow the rule that every state has to have a url. |
| 17:23 | <erlehmann> | every state i could care about. no exceptions. |
| 17:23 | <erlehmann> | this means i purposefully ignore stuff that i would not cram into the url |
| 17:23 | <erlehmann> | no tracking |
| 17:23 | <erlehmann> | and no scroll position dependent events or whatever |
| 17:23 | <erlehmann> | it makes life vastly easier and the result easier to reason about |
| 17:23 | <erlehmann> | but of course many people i know ask „but how do i do infinite scrolling then“ or similar stuff |
| 17:24 | <erlehmann> | and i say “you don't. it breaks user expectations about finite documents and scrollbars.” |
| 17:24 | <erlehmann> | i think the key to successful UI is restricting common developers, not giving them more power. |
| 17:25 | <caitp> | yeah, so this is the "documents are not applications" line of thinking, and it makes sense, but I work on an application framework, not a document framework, and at some point someone decided that the web is a great platform for applications |
| 17:25 | <erlehmann> | see podcasts and feed readers. because the format is so limited, they had quite a competition. |
| 17:25 | <erlehmann> | caitp you can have applications. it is only that you need to manage state very carefully. |
| 17:25 | <erlehmann> | i think that if you manage to avoid hidden state, you manage to avoid LOTS of user frustration |
| 17:26 | <caitp> | it's not even a case of hidden state though, it literally is just a URL |
| 17:26 | <erlehmann> | on a related note, avoid state explosion. |
| 17:26 | <caitp> | it's just that for older browsers it's necessary to rewrite the URL, and then you've got this whole virtual URL ugly thing, and there's a need to avoid doing the wrong thing if you aren't supposed to actually navigate |
| 17:27 | <erlehmann> | the url for a long time (before „we break your back button with impunity“ crap) set user interactions |
| 17:27 | <erlehmann> | caitp i have written about that topic http://news.dieweltistgarnichtso.net/posts/hidden-state.xml |
| 17:27 | <caitp> | oh yes, I sympathize |
| 17:27 | <caitp> | history api helps a lot with this, although it's still broken in a lot of cases |
| 17:27 | <erlehmann> | i also recommend the writings of olia lialina |
| 17:30 | <erlehmann> | caitp almost all of the harder problems i see on the web, regardless if with wep apps or web pages or whatever, are about state and state transitions. users cannot always articulate it, but i think berners-lee really hit home with URLs. |
| 17:30 | <erlehmann> | if web apps are the applications, the url bar is the command line of the web |
| 17:30 | <erlehmann> | and if your web app carefully manages its state, that means you can go to every state with the command line |
| 17:31 | <erlehmann> | something that is impossible in most, if not all, other systems |
| 17:32 | <erlehmann> | whenever you break that expectation, you are in for a world of hurt. like a guy i know who had a special cookie-re-issuing function on hitting the back button after some action that should have been a POST (but was a GET with a cookie issued) |
| 17:32 | <caitp> | sure, but the URL isn't the only way of inputting commands into this system --- user interaction also is |
| 17:32 | <caitp> | so if you ahve a user interaction which sometimes wants to change the state, and sometimes wants to open a new browsing context with its own state, you have to know which one to do |
| 17:33 | <caitp> | that user action is a click |
| 17:34 | <erlehmann> | if you have a click system |
| 17:34 | <erlehmann> | or a touch |
| 17:34 | <erlehmann> | if you have a touch system |
| 17:34 | <erlehmann> | or a back button or a f or the enter button or whatever |
| 17:34 | <erlehmann> | a programmer that is sure xe will never get RSI is probably either arrogant or genetically superior |
| 17:36 | <erlehmann> | (i use keyboard browsing because of hands) |
| 17:36 | <caitp> | yeah, click isn't always available, this is true |
| 17:38 | <erlehmann> | the focus on click reminds me of pre-mobile days |
| 17:39 | <erlehmann> | where when one was saying “you should not rely on clicking as user interaction, do not use hover states etc.” people would respond “are you using a text browser? get with the times” |
| 17:39 | <erlehmann> | you were saying “big five” and i suspect you mean firefox, chrome, safari, ie and one other that i don't know. but don't forget that opera was a common browser once too! |
| 17:39 | <boogyman> | erlehmann: and you can say, not everyone in the world can see or hear. |
| 17:39 | <erlehmann> | so compatibility is really hampered by that stuff |
| 17:40 | <erlehmann> | boogyman yes, which is why i focus on progressive enhancement and not graceful degradation. |
| 17:40 | <boogyman> | also, there are many times where your users are not even people. |
| 17:41 | <erlehmann> | yes, which is why i focus on proper semantics and outlines. |
| 17:41 | <erlehmann> | and test everything with curl. if that is too complicated, my interface is shit. |
| 17:42 | <erlehmann> | a friend of mine made something that could literally not tested with curl, because his “REST API” made each call consist of two calls, the first to grab the session |
| 17:42 | <erlehmann> | needless to say, he was the only user of his API |
| 17:42 | <caitp> | that doesn't sound very restful |
| 17:44 | <boogyman> | In my opinion that's okay if the identifier for that session is part of the authentication/authorization mechanism. |
| 17:45 | <erlehmann> | i have never seen a use case where something involving sessions could not be done without sessions, except for hiding the state of the system from the user. |
| 17:45 | <erlehmann> | like tracking cookies. |
| 17:45 | <boogyman> | erlehmann: access control |
| 17:46 | <erlehmann> | boogyman RESTful access control does not need sessions. just send credentials on every request. in before “it is in secure” – yes, not using transport encryption is insecure. |
| 17:47 | <erlehmann> | i think stateless systems vs. stateful systems have the same problem as functional programming vs. imperative programming. one is vastly easier to grasp for many and works well enough for 80% of the use cases. |
| 17:47 | <boogyman> | but, there are many HTTP based API's that claim to adhere to RESTful principles, when really, they are just HTTP based. |
| 17:49 | <erlehmann> | indeed |
| 17:50 | <Domenic> | annevk: in the course of writing this email I've mostly convinced myself that overloading body to allow a function is the least-bad option. |
| 17:53 | <erlehmann> | what |
| 17:53 | <erlehmann> | Domenic explain |
| 17:56 | <annevk> | heh |
| 17:58 | <erlehmann> | boogyman richardson maturity model |
| 17:58 | <erlehmann> | boogyman read http://martinfowler.com/articles/richardsonMaturityModel.html |
| 17:59 | <boogyman> | erlehmann: ? |
| 17:59 | <erlehmann> | boogyman it is a good overview regarding levels of RESTfulness |
| 18:00 | <boogyman> | okay. I'll keep that in my mind when I'm referring others. |
| 18:05 | <erlehmann> | caitp maybe one could manage application state easier with checking querySelectorAll, :target and :focus |
| 18:05 | <erlehmann> | leverage the browser state machine! |
| 19:03 | <annevk> | From the stuff I work on, the Encoding Standard seems to approach stability the fastest, while I would have expected it to take a very long time... |
| 19:04 | <annevk> | Getting to the point of only a few outstanding issues |
| 19:05 | <Hixie> | am i right that all Function objects you create in JS (i.e. those that aren't weird things we provide in the web api) have a [[Construct]] ? |
| 19:06 | <TabAtkins> | Hixie: Yeah. |
| 19:06 | <Hixie> | k, thanks |
| 19:07 | <Hixie> | is it also always true that, assuming you haven't fiddled with it, if F.prototype == O, O.constructor == F? |
| 19:07 | <caitp> | no |
| 19:09 | <TabAtkins> | Multiple functions can share a prototype. |
| 19:12 | <Hixie> | so what does O.constructor return? |
| 19:14 | <caitp> | if B extends A, `new B`'s constructor is B, but if you walk up the prototype chain, you'll run into an object whose constructor is A |
| 19:14 | <Hixie> | by "constructor" you mean "value of the constructor property"? |
| 19:14 | <caitp> | yes |
| 19:19 | <Hixie> | class { constructor () { a() } foo() { b() } } returns a Function that calls a() with a .prototype that has one member 'foo' that is a function that calls b(), and one member constructor that points to the Function that calls a()? |
| 19:20 | <Hixie> | so i can do the same with var q = { foo: function foo() { b() } }; var f = function() { a() }; f.prototype = q; q.constructor = f; ? |
| 19:20 | <Hixie> | are those distinguishable in any way? |
| 19:23 | <caitp> | well, they would be slightly different, but they'd basically behave the same |
| 19:23 | <Hixie> | how would they be different? |
| 19:23 | <caitp> | q would be missing a constructor property, for one |
| 19:24 | <Hixie> | "q.constructor = f;" doesn't work? |
| 19:24 | <caitp> | oh, I must have missed that |
| 19:24 | <Hixie> | k |
| 19:24 | <caitp> | it does work, but is still slightly different, since assignment will set up the property descriptor differently |
| 19:25 | <caitp> | observable difference but you'd have to be pretty nitpicky to observe it |
| 19:27 | <Hixie> | i should use defineProperty instead of assignment? |
| 19:29 | <caitp> | it would be a data property which is not enumerable, is writable and configurable |
| 19:30 | <caitp> | actually, it looks like there are cases in the spec where it's not writable/configurable |
| 19:31 | <Hixie> | how about: var q = { foo: function foo() { b() } }; var f = function() { a() }; Object.setPrototypeOf(f, q); Object.defineProperty(q, 'constructor', { value: f, writable:true,enumerable:false,configurable:true }); |
| 19:31 | <Hixie> | is that distinguishable? |
| 19:32 | <hsivonen> | annevk: no idea about the actual needs re gbk |
| 19:33 | <caitp> | setPrototypeOf will change __proto__ or the internal prototype, not `prototype` |
| 19:33 | <annevk> | hsivonen: okay, since Firefox has this split decoder / encoder setup and the spec doesn't and there's no open bug... I guess I should file a bug to at least track it |
| 19:33 | <annevk> | hsivonen: against the spec that is |
| 19:33 | <hsivonen> | annevk: makes sense |
| 19:35 | <Hixie> | caitp: oh right |
| 19:36 | <Hixie> | how about: var q = { foo: function foo() { b() } }; var f = function() { a() }; Object.defineProperty(f, 'property', { value: q, writable:false,enumerable:false,configurable:false }); Object.defineProperty(q, 'constructor', { value: f, writable:true,enumerable:false,configurable:true }); ? |
| 19:36 | <Hixie> | (and why on earth do those properties have different settings) |
| 19:39 | <annevk> | hsivonen: it seems we should still have a Firefox bug on making them use the same table so we can save memory |
| 19:39 | <annevk> | hsivonen: I can file that too if you agree |
| 19:41 | <Hixie> | can you tell in a constructor if you were called with "new" or not? |
| 19:43 | <caitp> | Hixie: sort of |
| 19:44 | <caitp> | the way people usually use is `function Constructor() { 'use strict'; if (!this) { /* function was just called normally */ }` |
| 19:45 | <caitp> | or `if (!(this instanceof Constructor)) return new Constructor(...)` --- but those methods are fallible |
| 19:46 | <Hixie> | huh, there really isn't a way, it looks like |
| 19:46 | <Hixie> | that's odd |
| 19:47 | <caitp> | each engine has their internal ways of figuring out, but none exposed publicly |
| 19:49 | <annevk> | hsivonen: https://bugzilla.mozilla.org/show_bug.cgi?id=711101 removing IBM encodings is fixed, no? |
| 19:52 | <TabAtkins> | Yeah, it's always possible to trick the "was I called with new?" tests by passing things in via .call(). There's no language-provided way to tell. |
| 19:52 | <TabAtkins> | I usually use caitp's second test. |
| 19:55 | <caitp> | https://esdiscuss.org/topic/new-instantiation-design-alternatives I think there were some ideas tossed around about providing a way to know here |
| 19:55 | <caitp> | but I can't remember, and it was a long thread |
| 19:57 | <Hixie> | if it can be faked, there's not much point checking at all, except for like an assert() or something |
| 20:00 | <TabAtkins> | Hixie: Main use-case for checking is to allow the function to be called with or without "new". |
| 20:00 | <Hixie> | why would you want that? |
| 20:00 | <caitp> | which is the case for some builtins |
| 20:00 | <TabAtkins> | ...so you can call it without "new"? |
| 20:01 | <caitp> | new String() and String() do different things |
| 20:01 | <Hixie> | that seems like a very confusing API |
| 20:01 | <TabAtkins> | One's a constructor, one's a converter. |
| 20:01 | <caitp> | lots of bad decisions were made with JS, but most of them were made when I was less than 4 feet tall |
| 20:01 | <TabAtkins> | Also, sometimes to allow you to construct an object without "new". |
| 20:01 | <caitp> | so, it was bound to happen |
| 20:02 | <TabAtkins> | Like if you have a very simple object that's going to get constructed a lot, the extra noise of "new " can get distracting. |
| 20:03 | <TabAtkins> | For example, my bignum class at https://github.com/tabatkins/bignum would be much harder to use if you had to say "new Z(5).add(new Z(6))" all the time. |
| 20:04 | <TabAtkins> | It's bad enough that you have to do "Z(5).add(Z(6))", because we dont' have operator overloading yet. |
| 20:04 | <Hixie> | supporting both seems like a very confusing API to me, but i guess opinions may vary :-) |
| 20:05 | <TabAtkins> | Disallowing "new" for a constructor would be super-confusing as a consistency break. |
| 20:05 | <TabAtkins> | Not to mention feeling really perverse. |
| 20:06 | <annevk> | I thought new-style would require it to allow subclassing, but I guess that might be changed |
| 20:07 | <annevk> | Bignums should just be part of the language |
| 20:07 | <TabAtkins> | annevk: Well, yes, of course they should be. That's not the point of my example. ^_^ |
| 21:00 | <Hixie> | anyone know how custom elements work? i'm trying to figure out how/whether browsers are supposed to avoid huge bloat from every custom element having its own copy of style |
| 21:02 | <annevk> | Hixie: Domenic prolly does |
| 21:02 | <Hixie> | he's probably at blinkon |
| 21:03 | <annevk> | Hixie: bz maybe |
| 21:08 | <caitp> | what do you mean by "own copy of style"? |
| 21:10 | <Hixie> | i mean its own <style> element, which has to be individually parsed, turned into internal style objects, etc |
| 21:20 | <caitp> | well there's a concept of rare data for a lot of these constructs, so you would have to have a pretty complicated setup to really see it get bad, hopefully |
| 21:24 | <TabAtkins> | There's deduping involved. |
| 21:24 | <TabAtkins> | (I don't know details.) |
| 21:26 | <caitp> | in core/dom/shadow you have ShadowRootRareData which owns a StyleSheetList pointer which may or may not be allocated, raredata itself may or may not be allocated, an element's CSSStyleDeclaration may or may not be allocated, different CSS properties may or may not be allocated, etc etc etc. |
| 21:27 | <caitp> | trading complexity for memory cost |
| 21:29 | <caitp> | but i'll repeat tab, I don't know the details in these cases --- I think on average the cost is probably pretty minimal |
| 21:30 | <Hixie> | apparently the style element's textContent is hashed and looked up somehow so that the style work is all shared |
| 21:30 | <Hixie> | at least in chrome |
