13 March 2018 -
Back in the Saddle Again, Elementals 3.6.2 Relased!
By Jason M. Knight (aka Deathshadow)
Whilst this was released last friday, I wanted to wait until all the ducks were in a row before tossing up an article about it and doing the usual socail promotion. I know it has been some time since I've done any news updates -- I've been off working on freelancing projects for clients and leaving elementals.js in the hands of what I had hoped was a competent team. It turns out one of the team members (or should I say FORMER team member?) messed things up a bit not doing updates to the site, documentation, or making announcements; as well as banjaxing several parts of the codebase.
My bad for taking my hands off the wheel and trusting cruise control. That's not happening again. Live and learn.
So now that I've got the time I've spent the past three weeks belting out release after release of bugfixes. In addition code optimizations for size and addition of even more functionality scrapped the notion of 3.5 being the 'last of new functionality'. Now that I have two dedicated people helping to test and a battery of tests to be run before deployment, I've also been able to scrap the "three weeks of RC before production release" schedule. For the time being -- until technology and browser changes warrant an all new 4.0, or other issues arise -- elementals is operating on a tick-tock release cycle of an internal beta followed by a public production release.
This release is probably about as good as it is going to get for some time with the current functionality. It's been bugtested to the best of our abilities, though like ANY other system no plan ever survives contact with the end user. I am certain there are corner cases I didn't think of, so please if you try it (please do!) and have issues, report them through the contact form on the official site.
So what's new in elementals.js since the last news post here?
The array and object format passed to the
_.Node.write functions started to reach the point of being a viable JSON structure. Documenting it piecemeal between the two underscore methods was getting unweildy, so I decided it is time to codify it as its own specification. By nesting arrays of arrays, strings, and objects you can pass instructions to build complex DOM structures in the browser, without resorting to the use of the (bloated, slow, insecure)
The calling syntax of
_.make has also been modified so that you can pass it JUST a DOM-JSON Array of entries, and it will create everything on that list returning a boolean true if successful. The old convention of passing a selector-style first parameter (now called a delimited selector string, or DSS) and an array of DOM-JON style command attributes is retained, as well as some options for passing strings and more values in the "DSS".
Tracking of elements created when they have ID's
The _.ids object contains any and all ID's created using
_.Node.write. The ID of those elements is the property name on the object, with the value being a reference to that element. In addition you can add the
data-elementals-idParse attribute to your
<body> tag so that when elementals.js loads, it will add all existing elements with ID's to the _.ids object. This behavior is optional since if you have a really large DOM walking the entire tree can take a while... but if you need it, it's there. Referencing the object ends up in some browsers faster than a document.getElementById, and it's also nice to be able to just access them after a
_.Metrics Element information
This object contains methods for pulling live information about an elements position and size. For the most part pulling these values is highly inconsistent cross-browser so these wrappers greatly simplify the process for you.
_.Node.text - a better
textContent -- and its IE cousin innerText -- are so agonizingly different in behavior cross-browser.
Element.textContent can return wildly different results even in modern browsers, limiting its utility. This is probably ANOTHER reason people dive for the problematic innerHTML for "everything".
_.Node.text walks the DOM from the parent element adding together all textNodes with all whitespace treated as HTML would, reduced to a single space.
In additon there is
_.Node.textFormatted which returns the text content, but any block-level tag endings or
<BR> are converted into a proper line-ending (CRLF) in the output, attempting to preserve at least some of the formatting. This behavior MAY be expanded upon to process things like
<OL> properly if it can be implemented underneath the codebase's "hard ceiling limit" of 8k once minified and gzipped. For now beware the latter is in development, which is why it is NOT in the general documentation. I may split this out into its own "module" like I did with eFlipper and eSmooth. Was thinking it might be cute to make a script that can convert the contents of the DOM into something like markdown... not a fan of markdown, but would be a nice way to remember Aaron's contributions.
Polyfills and Object Extensions
Over the past three to four months a slew of new polyfills have been added.
String all have a number of ECMASCript 5 and 6 polyfills in place that work all the way back to IE 5.5. New functions both static and prototype have also been added to those as well as
Object to fill in some -- IMHO -- obvious blanks" in the specification.
So what's next?
A more reasonable approach is to wait for the timer to 'rollover' -- aka change its value, you then run for a FIXED period of time tracking how many times you can loop. This removes that timer granularity from the process giving a clearer picture of what's going on.
eBench will be using elementals to dynamically generate result tables, and have a full/proper interface in place for handling starting the test, test progress, and relations of speed across tests.
The next thing on the aganda is buckling down to write a PROPER tutorial / guide to elementals fully explaining the more useful core features like DOM-JON and
_.make for beginners. Right now we have a really good reference and a couple of loose articles filled with sound advice, but no actual tutorial for going from zero to hero.
Still all in all, this is a solid release with lots of cool new features, without violating the basic policy of keeping the size as small as possible. In fact with a major under the hood change in how polyfills are applied there's now over 320 bytes until the gzip/minified hard ceiling, which works out to hopefully around 1.8k of room for new code/features. I've written entire 16 bit operating systems -- well, glorified bootloaders providing a rudimentary filesystem and console handling -- smaller than that!
Updates are also in the works for this site. In particular a article about problems with optimization tools like PageSpeed and Yslow is in the works, as well as a larger project that, well... Let's just say that whilst the W3C and I have never seen eye to eye, I've utterly lost confidence in their relevance, direction, and any percieved benevolence.