I 100% expect the general public to be able to write HTML.
You know what's unreasonable to expect from the general public, though? Knowing the rules to baseball. That shit's complicated.
There are many reasons why HTML is bad, but user friendliness is not one of them.
@enkiv2 I've got a bit of a different attitude.
1) I don't expect the general public to directly edit any plain text format. There's a widespread fear of such "coding".
2) I think there's something beautiful about HTML/CSS which gets lost under all the event handlers & <div> soup. And webdev education having entirely misplaced focus on tools like React rather than what browsers provide natively.
I don't disagree exactly, but:
1) the fear of coding is unfounded & spread by an apparatus that protects the elevated position of mediocre programmers at the cost of general code quality, so I refuse to treat it as anything but fundamentally stupid
2) HTML+CSS is better than the big bloated frameworks, but that's a very low bar; HTML is fine as a document format (albeit a little bloated), but trying to style it or auto-generate it immediately puts it way beyond the level where it's an appropriate technology. So, even though it's not the absolute worst, the world would be better if neither HTML nor CSS existed (or if only the parts of HTML that overlapped with features of standard markdown existed).
3) there's a beauty to twisted perversions that's much like the beauty of ill-considered optimization; I can appreciate the beauty of an ugly hack while also thinking it should never be used. basically all web-tech falls into this category for me.
@alcinnz
people are afraid of writing code in a text editor the same way they're afraid of great white sharks, and it's a toss up which fear has a greater negative environmental impact
Yeah. Just the html, body, b, i, ul, ol, li, table, th, tr, and td tags.
The a tag should not be included because it makes people think that html is compatible with hypertext systems, which it is not.
@enkiv2 @BillSeitz I'd include plenty more tags, in fact I'd say the more the merrier...
What I like about HTML/CSS is how readily they can adapt to alternative mediums within which to present the text! Braille, audio, various forms of visual, etc!
Without having the seperation between semantics & style you loose this versatility. Then again requiring JS also removes this versatility...
@enkiv2 @BillSeitz Also I have complex thoughts regarding CSS, so I'll drop that aspect.
Let me just say I"m sure Xanadu would've become as much a twisted perversion of itself just as much as the web has, if it had been the one to become popular. And I'm not all that sold that it was a better conception.
I like the ideals of the CSS Working Group even if I admit they've never really been realized. I hope to realize them myself, and am having some luck.
@alcinnz @enkiv2 @BillSeitz The thing I find interesting about CSS is how frustrating it has been to do things which are conceptually very simple, like 3 columns all the same height, or making text scale to fit a container. While a lot of things have been fixed with grid and flexbox, it took a long time to get there.
@alcinnz @enkiv2 @BillSeitz And TeX was the same. We eventually got to ConTeXt, and it became possible to do grid-based layouts without massive hackery, but again it took 18 years to get there. And as for PostScript, don't get me started.
I can't decide whether there's something fundamentally difficult about page layout, or whether the people tasked with implementing it on computers just do a terrible job every time.
Layout is really counterintuitive.
Then, when you have an algorithm to do a "good enough" job at it (like an HTML renderer has), all the knobs for changing default behavior end up being even more counterintuitive, because other behaviors will interact with whatever you change in unexpected ways.
I worked on ZZOGL, which had a very simple layout system that I quite like, but it was tough to get grid-like patterns with it unless you created invisible objects that overlapped visible ones (which I introduced to the spec specifically to make these layouts easier).
@enkiv2 @mathew @alcinnz @BillSeitz where it comes to CSS, i remember there was a huge amount of resistance to adding *any* layout capabilities to it, or html, under the belief layout should be the client’s responsibility.
so it got hacked in using features that were not designed for layout and now it’s hacks on top of hacks
@zens @mathew @alcinnz @BillSeitz
honestly, i would have been on team "no layout capabilities". html is at its best when there's no formatting of any kind; if you need to print something then tex exists.
@enkiv2 @mathew @alcinnz @BillSeitz i think the web needs layout capabilities.
i think putting them into css was a massive mistake
@zens I haven't decided on my stance here...
@alcinnz @enkiv2 @mathew @BillSeitz the selector:properties construct is fine for typographic settings, especially for top level tags.
by encouraging doing layout in css, it’s created a situation where html and css are tightly coupled via classes which sorta defeats the whole point of having them be seperate files
@alcinnz @enkiv2 @mathew @BillSeitz it would have been better if there were a seperate layout language with containers to contain plain unadorned html, and determine for each cell what css to use
@alcinnz @enkiv2 @mathew @BillSeitz this would preserve the versatility of the html as a client could simply ignore the layout file at its discretion
@zens @alcinnz @mathew @BillSeitz
Arguably, the tag hierarchy of HTML already defines layout. Any functional layout override for HTML would need to be able to get rid of the hierarchy and make it flat again.
@enkiv2 @zens @alcinnz @mathew @BillSeitz Maybe DSSSL then? There's no reason this stuff has to be slow or write-only!
my extremely unpopular opinion: start with plain text, and then have a separate set of formatting rules that operates on byte offset pairs.
@enkiv2 @zens @alcinnz @mathew @BillSeitz Sure, like Xanadu links. Do you have a prototype of your offset-markup layout approach running?
@radehi
Yeah.
I don't have the one I did for Xanadu up, since it's not open sourced yet, but here's something that translates between a span-based format and tkinter's mark-based format: https://github.com/enkiv2/misc/tree/master/mtv
(It's more complicated than it needs to be, because tkinter has a coordinate system for text positions that's fiddly and underspecified.)
With the one we did for xanadu, there's a little more flexibility because we were rolling our own layout & formatting code, so in theory, the ODL could be used to place individual chunks of text in arbitrary relation to other chunks of text.
(Actually, text layout was sitting on top of ZZOGL, which itself is extremely flexible -- intentionally supporting everything that you could do with pasteup and more, since it's in three dimensions. But by default, we have 'page'-like structures called slabs, oriented in parallel, with translucent ribbons between them, and text is put on the front surface of the slabs.)
The 3d support was straightforward but getting fast hardware-accelerated text rendering for large quantities of text that was portable across a large variety of cards was really complicated, to the point where we had to drop the project. 90% of the logic could be applied to a single plane with simple perspective + parallax and just dropped into SDL, but we were too fried at the time to implement that.
@enkiv2 @radehi @zens @mathew @BillSeitz Very much against what I'm seeking to accomplish!
@alcinnz
yup, hence unpopular
@radehi
noooooo
we don't need to bring in *more* slow/bloated/write-only languages
@zens @alcinnz @mathew @BillSeitz