Search posts, tags, users, and pages
Thanks. I didn't know about :target.
And things could probably be simplified by wrapping it
function loopHTML(container, element, arrayContent)
{
do {
el = container.createElement(element);
el.innerHTML(content);
} while (content = arrayContent)
}
But gets more tricky if you need call to content creation from within again, making it recursive. Avoiding all this isn't as easy in a real case scenario making enterprise applications.
Jeez I made many grammar mistakes lately
Emil Moe Have a look at my DOM-JON implementation for Elementals. There's a newer version on the way (hopefully in two to three weeks, depends on my paid workload) but the .make and .write routines of elementals (which will be combined to one function in the next iteration) does a lot of what you are thinking.
elementalsjs.com/reference/DOM_JON
So if elementals was in use, well, take the example:
.make('div#test', {
content : [
[ 'h2~This is a DOM created subsection' ],
[ 'p', { innerHTML : 'A child paragraph <strong>that can use markup!</strong>' } ],
[ 'p', [
'A child paragraph',
[ 'strong', 'that directly assigns the <strong> tag.'],
[ '~ Note that markup is escaped when you pass a normal string!' ]
] ],
[ 'div.details' , { content : [
[ 'span' : '13 November 2017' ],
' Jason M. Knight'
] } ]
],
last : document.body
});
Ends up equivalent to having this in the markup:
<div id="test">
<h2>This is a DOM created subsection</h2>
<p>
A child paragraph <strong>that can use markup!</strong>
</p>
<p>
A child paragraph <strong>that directly assigns the <strong> tag.!</strong> Note that markup is escaped when you pass a normal string!
</p>
<div class="details">
<span>13 November 2017</span>
Jason M. Knight
</div>
</div>
...again, whilst it supports innerHTML it is not recommended to use it.
And yes, it does use recursive calls to work, but really if you are making/adding a DOM structure that goes deep enough for that to be an issue, there is something horrifyingly and terrifyingly wrong with what you're doing. There is usually little reason for nesting to go more than 8 deep, and recursive calls shouldn't have stack size overflows until you hit the thousands, nor should any performance penalty be noticeable. Particularly if you use VAR instead of LET or CONST, since VAR's "lifting" reduces stack thrashing.
note, elementalsjs is a library, not a "framework". The mere use of the term "framework" these days automatically raises the hackles on my hackles, having such a negative connotation since people assume they need something to magically do all the work "for them" -- ending up making more work in the process.
Maybe, maybe not. I haven't given it thoughts if there is. I make stuff that is highly customisable to beyond my imagination, so there is a lot of deep nesting and the users accept that slower page.
Wouldn't it make it both easier to read, write and more speedy if using <template> ? Your code isn't as maintainable as how I see it with Vue and that's a big issue.
Also your hate against components seems a bit too much outrage. The theory of reusable code should never be denied, the implementation can maybe be debated.
I make stuff that is highly customisable to beyond my imagination, so there is a lot of deep nesting and the users accept that slower page.
I have the feeling you're not giving much thought to your semantics when you do that... but I operate on the principle that content dictates markup, content + markup + device capabilities dictates layout. I have the feeling you're starting out worrying about what it looks like and playing endless games with that appearance instead. I might be wrong, but wild guess from the way it sounds.
Wouldn't it make it both easier to read, write and more speedy if using <template> ? Your code isn't as maintainable as how I see it with Vue and that's a big issue.
Not even sure what you mean by that, but since that looks like a tag, which means markup... and you seem to be talking about scripting, you've already violated one of the separations of concerns, encouraging a bad practice, and possibly even creating accessibility issues.
Also your hate against components seems a bit too much outrage. The theory of reusable code should never be denied, the implementation can maybe be debated.
the thing is if your HTML and CSS is "so complex' you need to turn it into "components' you're doing something wrong -- like probably using JavaScript for things that has no business on a website. You want to play those games with JS server side or in a standalone application built with electron, whatever. But you cross the line into websites with that nonsense and you've pretty much told -- as I keep saying -- large swaths of users to bugger off.
Lemme ask you this, how much of what you build on "websites" results in working pages when client side scripting is disabled, blocked, or otherwise unavailable? Did you build as if JS doesn't even exist first like a good little doobie then enhance with scripting, or is JS your only means of delivering content and functionality?
Cause if it's scripting only, stay away from certain industries in certain countries, or you will find yourself in court for WCAG violations under the US ADA and UK EQA.
I'd actually be interested to see some of your work, though if I did a audit like I do for my clients you might ... react negatively. Take what I said in the "making subsequent pageloads faster" thread about hashnode, and multiply by a factor of ten, and you have what I give prospective clients during negotiations.
Usually when I get a client they're already in trouble and need me to tell them what to fix and how, so they are ready for a laundry list of failings... because business is business.
You give the normal person such a list and they freak out like it's a personal attack. Honestly the way some people react to a simple list of problems makes me wonder how they made it out of grade school, much less not end up rocking back and forth crying in a corner at an actual workplace.
I profile my stuff once in a while, but what I do, as I said, is more comparable to applications served through the browser than a standard presentational website. If turning off script, it wouldn't work at all. End of story. It's specialised software and therefor a requirement that some technical specifications are met. Usually that's as "simple" as Chrome, Firefox, Edge, IE11+.
If I was to make marketing pages trying to appeal to everyone, that would be a whole different story. The audience is an important factor as well.
Some things I have made, might not, from your technical perspective, but 100% efficient, but from my client's perspective I probably saved them 1,000 working hours per year. From there we can talk about technical optimisations. Even if they had to buy a new computer to someone, just to run my "website" it would still be a good deal for everyone.
I wouldn't design a piece of software to solve a direct issue for a client with specific needs, to run on any kind of Operating System. If 99% of my clients use Windows, that would probably be the only supported platform.
The template tag I mentioned is this, and is a completely valid tag: developer.mozilla.org/en-US/docs/Web/HTML/Element…