nadabu

8 ms·

1.
by nadabu 13y ago
You're wrong about each(). I do use it in the demo twice. Writing each() was the main challenge and goal in my development process; the most enjoyable part of it. Look at the code itself and how much of core.js is devoted to giving
2.
by nadabu 13y ago
If you want to use those, use them, then HTML.ify() the results or not. Either way, the point here is to encourage DOM use and eschew wrapper APIs. If you want to use HTML.js's find() or dot-traversal, you must accept that your decisio
3.
by nadabu 13y ago
Yep. You certainly can misuse it. You are supposed to do: allMyPageHeaders.only(0), because that works on a node or node list in HTML.js.
4.
by nadabu 13y ago
I'm hoping it returns undefined. Dot-traversal on a list goes into the first item, the first item should be empty. I have had some issues with the demo, since it hacks some things for presentation's sake. What did you expect?
5.
by nadabu 13y ago
Why would you have no idea? If you're querying by id, you have one, if you're querying by anything else, assume you have more. Once you assume you have more, you use each() to operate on all or only() to narrow the list. Those fun
6.
by nadabu 13y ago
Yes, code that's unprepared for variable input can break when input varies. So use code that is prepared for it, like each(). And thank you for your anecdote, but i have never and will never stop doing something merely because some guy
7.
by nadabu 13y ago
And you missed mine. I made a willful-and-fully-knowledgable choice to conflate nodes and lists. I understood then and still understand that it shifts complexity from the call to the return value. How is explaining motives for that decision
8.
by nadabu 13y ago
I gave a solution (each()). You say it adds complexity. But adding it to what? The DOM gives you NodeList for querySelectorAll and an Element for querySelector. Is choosing between those at runtime and working with the results simpler than
9.
by nadabu 13y ago
By all means, use the plain old DOM interface! That's kinda the point i'm driving at with this library. We don't really need jQuery anymore (at least not all of it). Small components like HTML.js can still be handy when you w
10.
by nadabu 13y ago
Wrappers actually have their share of subtle problems, we've just gotten used to the jQuery way of coping. Hmm, i sense another blog post coming... :) At root, the issue is that without widely available Proxy implementations (wildcard
11.
by nadabu 13y ago
That is the question: https://github.com/nbubna/HTML/issues/1
12.
by nadabu 13y ago
Those are below the jump. I've not had time to polish that demo further. The library went viral a bit earlier than i'd hoped. Work is in progress.
13.
by nadabu 13y ago
Event handling is in the works, either bundled or separate: https://github.com/nbubna/HTML/issues/1 HTML is the root element (<html>), so it cannot be a function. HTML.ify() is only needed if you hav
14.
by nadabu 13y ago
Yeah, i agree, which is one reason heavy-weight DOM manipulators are losing ground to small components. There will always be some need for working with the DOM though.
15.
by nadabu 13y ago
1) i can reliably assume HTML.find('#foo') is a node, and HTML.find('.foo') must use each(). These things get even easier as web components and shadow DOM become widely available. I'm aiming at the future here, not
16.
by nadabu 13y ago
In cases where the return value type is actually unknowable, you can reliably use each() on the results. The whole point here is to use the DOM, not a wrapper. I'm open to pull requests if you have a way to have consistent interface a
17.
by nadabu 13y ago
Good idea! I'll do that.
18.
by nadabu 13y ago
Yes, the performance has been fixed. Further improvements are possible (prototype extension), but come with tradeoffs so i'm hesitant. Apart from the dot-traversal technique (both fixed and enhanced), everything is different in HTML
19.
by nadabu 13y ago
Yeah, i'm still hacking on this a lot. It's not v1.0 ready. The Chrome tests pass again, but the alter module still needs some work. And the new event module needs docs, and so on and so on... :)
20.
by nadabu 13y ago
Eh, not a wrapper, sorry. It's a helper that directly extends the DOM to provide syntax sugar. Yes, it is not pure DOM interface, but if it were, then the library would be a whopping 0KB. :)
21.
by nadabu 13y ago
I appreciate all the attention. Just FYI, i was not ready to start publicizing this, someone randomly found it and started that ball rolling without me. There are a bunch of changes in the pipeline for the near future. (see the github sourc
22.
by nadabu 13y ago
If you don't know, use each() and only() to act on the results. They're always available and don't care if it is an element or array of elements.