Show HN: My Open Source HTML Drafting Program (opens in new tab)

(github.com)

2 pointsdckimGUY8mo ago1 comments

This program seeks to tackle the problem of there being no drafting solution for HTML. None, Nada, Zilch. Every other type of document has a drafting software that is available, and is open source... Not so with HTML, and I am asking, "Why not?".

I wrote this project initially just for my own reasons... I needed to build a better quality website, and I was sick of writing all of the HTML from a text-editor, constantly guessing about where things are going to end up, and what the final result will 'really look like'. It's a constant guessing game.

From using it to write HTML, I had already become familiar with that old text editor called VI. That program is really a great one, and that's why I have followed it by copying a lot of it's features, and keyboard action. So, my program ended up with HJKL being a standard. That's how parts are moved around, etc. in the program. The other thing that I have essentially 'ripped-off' was the idea of having all of the letter characters work as registers. Only with my program you must use 'f' to pull from the register.

It was challenging to draw up such an extensive program as this, and among the greatest and most difficult of the challenges that I have faced has been that the entire program works offline and inside of the browser.

When I say 'offline' I mean fully offline... No contact with the outside world. Electricity but, no internet. No external APIs. Just written from scratch on a minimum of what Javascript already has.

The real battle wasn't against the programming language or anything like that but, it was against myself. I constantly need to guess what the browser would do, because sometimes it seems to be your greatest enemy, shutting your programming out where you least expect it.

Chat GPT told me that I should write a more in depth post to replace the one that HN revoked somehow. I guess new people are trash around here.

This program, however, is not trash, but is a gem in the rough. There is no GUI menu system yet, and everything is controlled by the keyboard and mouse... mainly the keyboard.

Give it a shot, and see if anything feels familiar. The spacebar give a quick preview method for your finished HTML.

All of my BASH scripts for assembling the program are included, a pretty good package.

I just wonder who will notice this monster first, the online people, or the community down on Yonge Street in North York (Toronto) where I posted physical signs for advertisment of a free open source project?

Is that weird to do? I have already done all the work of writing up the program, why stop at that? I'm going to advertise this thing until the cows come home...

Joke's on you, it was free forever.

Open Source Lives On.

1 comments

dckimGUYOP8mo ago

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).

j / k navigate · click thread line to collapse