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…
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…
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.
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…
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…
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…
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…
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…
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…
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…
That is the question: https://github.com/nbubna/HTML/issues/1
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.
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 have a different…
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.
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 the…
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…
Good idea! I'll do that.
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…
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... :)
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. :)
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.…
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.
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…
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…
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.
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…
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…
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…
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…
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…
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…
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…
That is the question: https://github.com/nbubna/HTML/issues/1
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.
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 have a different…
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.
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 the…
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…
Good idea! I'll do that.
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…
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... :)
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. :)
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.…
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.