| I suppose clarifying on my own post shouldn't be problematic, and so I will expound. What I have produced presents a unique method of manipulating and 'wrangling' the simplistic rectangles that are what 'really' makes up HTML. The most interesting inclusion in the program, and a rather seldom used choice, is the tripartite selection system. It is very different to use than the far more common, and, let's face it, ubiquitous bipartite selection system. In short, I will explain that each part that we are working with in the program is a member of one and only one of the three groups (the groups are indicated by colouration). So for the motion, we can move an entire group together without having to select each part explicitly per action. There are so many advantages to a tripartite selection system. We can apply any function to the tripartite group. We can move focus to the first member of the next group. And three is few enough for a quick cycling. My view (though perhaps biased as the writer) is that this system is a 'glove-fit' for HTML because it also lends expertly to the artistic standard, giving a foreground middleground and background. The idea extended very naturally into two crucial systems (which are nearly identical in code), one for managing document ordering (manual reflow using the 'v' key, and reflow with a group preference), and secondly, for managing z-index (likewise). Of course, we can still move things up or down in the z-index, and ceiling or floor... but then additionally those same ways within the group. So, enough of that... What am I looking for? What do I want to get out of this post? A little bit of exposure? Sure. Additionally, if there is some rogue expert roaming the posts, just check it out, have a look, and see whether you might be able to distinguish what the natural branches from this foundation would be. That's how I'm looking at this, as a foundational component upon which a GUI will be laid. Right now it's on the keys, no GUI yet. I see the development of any prospective GUI button menu thing as being completely directed through the developmental branches which might naturally arise following careful consideration what is presented. I'm looking to avoid the every dangerous 'pigeon-holes' that might corner my branches. So, I'm looking for the fairest break on the branches that can go so many ways. I will admit that I do not have the ability to know what specializations might share characteristics in a branch from this project. Study and consideration of potential branch structure would be helpful in my further improvement and consideration of the foundational structure (aside from general code cleanup). |