kenbellows | 6 years ago | on: Microsoft Edge preview builds for macOS
kenbellows's comments
kenbellows | 7 years ago | on: CSS grid garden
kenbellows | 7 years ago | on: Prions, Nearly Indestructible and Universally Lethal, Seed the Eyes of Victims
kenbellows | 7 years ago | on: Robert Langlands: The Greatest Mathematician You’ve Never Heard Of?
kenbellows | 7 years ago | on: JavaScript Equality Minesweeper
> true == 1
-> true
> false == 0
-> true
Do you get something different? Or is the game claiming something different?kenbellows | 7 years ago | on: JavaScript Equality Minesweeper
if (Number(myNum) === 2) {}
For me this also extends to using `Boolean(val)` instead of `!!val`, etc.; though I understand the appeal of those nifty one-liners, I think they cause confusion in many places and don't communicate intent nearly as well.kenbellows | 7 years ago | on: A file that’s both an acceptable HTML page and a JPEG (2012)
kenbellows | 7 years ago | on: The Ethics of Consciousness Hunting
kenbellows | 7 years ago | on: Twitter's Secret “Guest Mode”
kenbellows | 7 years ago | on: Show HN: Rb – Turns Ruby into a command line utility
Am I way off base here?
kenbellows | 7 years ago | on: 1/0 = 0
kenbellows | 7 years ago | on: 1/0 = 0
kenbellows | 7 years ago | on: Understanding JavaScript Objects
kenbellows | 7 years ago | on: Understanding JavaScript Objects
1. create a new empty object; call it `newObj`
2. call the constructor using `newObj` as its `this` context, so that `this.a = 1` is effectively `newObj.a = 1`
3. if the constructor has a `prototype` property defined, invoke `newObj.__proto__ = myconstructor.prototype` to establish the prototype chain on the new object
The critical distinction here is between `constructor.prototype` and `object.__proto__`. For exactly this reason, it bothers me a bit that the article uses `Prototype`, with a capital "P", to mean "the thing that `object.__proto__` points to". This is completely different from the `prototype` (small "p") property of a constructor, which is essentially just a holding place for the `__proto__` property of any objects created by calling this constructor with the `new` keyword.Hopefully that all made sense!
kenbellows | 7 years ago | on: Understanding JavaScript Objects
let vertebrate = {hasSpine: true},
mammal = {hasHair: true},
dog = {sound: 'bark'};
sparky = {name: 'Sparky'},
jumbo = {name: 'Jumbo'};
mammal.__proto__ = vertebrate;
dog.__proto__ = mammal;
sparky.__proto__ = dog;
jumbo.__proto__ = dog;
console.log(sparky.hasSpine); // true
console.log(jumbo.hasHair); // true
console.log(sparky.sound); // 'bark'
console.log(jumbo.name); // 'Jumbo'
When you access `sparky.hasSpine`, the JS engine first checks whether `sparky` has an "own property" called `hasSpine`. It doesn't, so it checks `sparky.__proto__.hasSpine`, which is the same as `dog.hasSpine`. No luck, so it checks `sparky.__proto__.__proto__.hasSpine` (i.e. `mammal.hasSpine`), and finally `sparky.__proto__.__proto__.__proto__.hasSpine` (i.e. `vertebrate.hasSpine`), which resolves to `true`.This entire structure of objects linked through their `__proto__` property is what we call the "prototype chain". Does that answer your question?
kenbellows | 7 years ago | on: Show HN: Font Playground – Play with variable fonts
kenbellows | 8 years ago | on: HTML 5.2 Recommendation
In my (very personal) opinion, an HTML tag or attribute, and more generally a feature of any design/development framework, should be considered possibly harmful if it:
- presents possible security problems; for examples, consider some of the points listed here: https://html5sec.org/
- promotes poor usability or accessibility; e.g. interactive tooltips with links or controls in them, for example, are quite difficult to make accessible, and I wouldn't want an HTML <tooltip> tag without a lot of discussion about accessibility
- promotes anti-patterns; e.g., at this point I think <marquee>-style scrolling informational text is an anti-pattern in a web context, since it can the text much harder to read, especially on small screens
Of course, none of these concerns should lead to immediate removal of a thing as soon as they're pointed out, but they should be discussed and considered. It's a cost-benefit analysis: what does this feature actually buy us that isn't easily achievable with other features, what problems is it causing and how severe are they, and are the benefits worth the problems?
As for <menu>, my guess, though I haven't been able to find the actual discussion, is that it was removed because its semantics are somewhat in conflict with <nav>, and probably its most common use was custom context (aka "right-click") menus, which bring a lot of accessibility problems with them. I don't know that I agree with the decision to remove it altogether, since I think its use to semantically identify and group web application controls is very valuable and not covered by any other tags (though I'd love to be corrected), but I do think that context menus, which to me seems like the most common use for the <menu> tag, are a very problematic design element. Again, it's a balance; is it worth the problems it causes? I guess the authors decided it wasn't.
(Just to reiterate, I don't know why <menu> was removed, I'm just guessing. If anyone can find any of the discussions about <menu> and the problems with it, I'd love to read more.)
kenbellows | 8 years ago | on: Lindy effect
kenbellows | 8 years ago | on: It is easy to expose users' secret web habits, say researchers
kenbellows | 8 years ago | on: Google Has Dropped Google Instant Search