• Haha! Welp, well done. XD I don't know if there's any true way of blocking this stuff. CW certainly doesn't make it easy to restrict things anyway.

  • Glad you've enjoyed these. I did start work on .outerHTML and .innerHTML, which for me is really the final piece of the puzzle as all other functionality would be easily extendable from the work already done. But I haven't played on here in a very long time; I'm into other things now. Feel free to try to make your own kata on it, if you like. I could link it from this one?

  • Yeah, I knew it would, but couldn't be helped if the tests were actually going to make sense.

    Thanks for the heads-up. I've fixed this now.

  • Description: "Any valid solutions will be accepted."

  • Oh, I see. You quoted the whole thing 😅

    I've now added a test for this. Cheers.

  • Again--this isn't to create an airtight test to ensure a perfect implementation. That kind of thing is very hard to pull off in my experience. So instead of trying to get anywhere close, I'm okay with leaving it pretty loose.

    This part of the implementation isn't relied on by other tests or anything; it's purely to suggest they think about it in a different way. If someone really just wants to use a regular Array instead of simply hiding it away, or storing it in a property, that's fine. This test simply discourages that.

  • No worries. I get that when I get round to checking my CW messages, too ;D

    Maybe with proxies you could do this... but that excludes people who aren't clued up on ES6. The important thing isn't "learn ES6"; it's the implementation of a priveleged array. The implementation is going to be largely the same whether you use proxies and classes or a simple function. Which means the kata does its job regardless of the coder's familiarity with ES6.

  • It's not contradictory. They do have an order, but that order is not specified in the spec. This means the order of the attributes is not guaranteed, and is dependant on the implementation itself; it's up to the coder how they order the attributes.

    This mirrors how it works in the actual spec; there is nothing guaranteeing what the order of the attributes is, and there are discrepencies between browser implementations on this.

  • As stated in the description, only features that are defined in the description are tested for. This isn't meant to be a spec-complete implementation of the DOM, but an exploration of what's possible with JS alone. If you'd like to add such features to your own solution, feel free.

  • This isn't intended as a spec-complete implementation of the DOM. It's meant to get coders to think about hwo they could implement similar features.

    So in short, if it's not in the description's spec, it will not be tested for.

  • .parentNode == null is tested for in "should update .parentNode".

    I've now added tests for .nextSibling and .previousSibling settability. Cheers.

  • The reason for this was: "A special object that lets you see what's inside the node, without being able to affect it directly." If it's just an array, it would be possible to change what's in the array. I've tweaked the description to directly state this. And tweaked the tests to make sure that array-like methods do not change the list--making it clearer why it's being tested.

  • Did you figure this out, in the end?

  • Loading more items...