Mastodawn

@h Jan 11, 2020

I think Zed's presentation is worth watching for anyone who has an uneasy feeling about the current state of the smell of rottening things coming out of the kingdom of w3c.
I also agree with Zed that HTTP is a useful thing, and I agree that Javascript is evil.

The bits you agree on may vary, this is intended as a pretext for picking your brains, and not assume the web is anywhere near good design or that it's the only possible form of hypertext we will ever see.
https://mastodon.social/@haitch/103462704629217625

alcinnz Jan 11, 2020

@haitch First thought reading that toot: There's certainly a lot of OOP in JavaScript's DOM APIs, and I hear webdevs noticing the performance degradation that's caused!

@h Jan 11, 2020

@alcinnz Javascript yes. HTML as we know it got slow as molasses in part because of Javascript, not the other way around, that's what I think.
Javascript was something that Brendan Eich invented when he worked at Netscape, it wasn't a fundamental part of the WWW as originally intended.
There was no OOP whatsoever in the original WWW design, there was no Javascript, and no CSS.
Tim Berners-Lee borrowed heavily from SGML, a different world entirely.

@h Jan 11, 2020

@alcinnz Zed blames OOP for all of the web's failures, mostly because Sir Tim used Objective C to build his original prototype. But that argument doesn't hold much water in my view, because there was no OOP whatsoever in either HTTP or in HTML 1.0.

I do agree with the diagnosis that the web is fundamentally broken though, but for different reasons altogether.

@h Jan 11, 2020

@alcinnz Whether OOP is a failed philosophy or not, I think that's a different discussion, and Zed makes the mistake of conflating two different broken things.

I agree that class-based Object Orientation is broken. (Zed makes this point, but he fails to note that Javascript is not class-based)

I agree that the WWW as it currently stands is fundamentally broken.

I don't think these things have anything to do with each other.

@h Jan 11, 2020

@alcinnz But Zed still makes other good points about CSS and HTML and other horrible things that should make any decent designer blush.

alcinnz Jan 11, 2020

@haitch We've got grids and easy centering now with CSS...

@h Jan 12, 2020

@alcinnz You've always been able to lay out elements on a page, by one method or another. This is obviously well known for anyone who had to lay out pages using <TABLE> elements since times immemorial.
The point is not that you can't get anything done, but that the way things are done are evil.
Layout is a separate concern from style, CSS has no business providing layout functionality.
The more CSS does, the more CSS breaks.

alcinnz Jan 12, 2020

@haitch I'm sorry, I don't see it that way. I think things would be more broken if HTML (or it's equivalent) took on the layout task.

And judging by existing browser implementations I'd happily throw away float in favour of grid/flexbox. Though float does do unique & useful things.

@h Jan 12, 2020

@alcinnz And of course, HTML shouldn't have to take the responsibility of doing layout. We can agree on that, because content is not layout either.

Hypertext should have distinct, separate information that helps to lay out content. (aside and separate as well from the styling information that helps to render content)

alcinnz Jan 12, 2020

@haitch O.K., thanks for clarifying that up, I think we're getting on the same page.

It would be interesting if designers could specify their own formulas for laying out the style tree! I don't know how that would look, but I'm sure you do.

Would also mean I don't have to implement those formulas myself for a visual browser.

@h Jan 12, 2020

@alcinnz I learnt a lot from designers like Khoi Vinh. This is something I've been thinking of for a very long time.
https://www.subtraction.com/

Subtraction.com

Khoi Vinh’s Web site

Subtraction.com

@h Jan 12, 2020

@alcinnz There are, however, edge cases in modern design where designers must be able to break rules and content flow must adapt dynamically to the shape of other content.
(say, something like the attached image)

Those rules, should also be defined from a layout-specific set of instructions which should determine the source of the layout shape to be computed during "runtime".

@h Jan 12, 2020

@alcinnz I'm sure modern CSS has something like this as well, but again, nothing of it should be part of CSS.

alcinnz Jan 12, 2020

@haitch I think of Adobe pushing for that feature, but that just comes back to what complaining is wrong with the modern Web!

Tell you what, design such a layout DSL (as long as it isn't turing complete) with sample code and I'll consider implementing it next year. Once I've got hypertext and forms working nicely in Rhapsode.

Right now though, I think I'll need to research an entirely different layout question for work...

@alcinnz This an old and very rough draft in need of being updated, but it should help to show what are the basic premises I've been working on:
https://github.com/haiitch/xtxt

haiitch/xtxt

Extended Text 1.0. Contribute to haiitch/xtxt development by creating an account on GitHub.

@h Jan 13, 2020

@alcinnz Essentially, in this framework, every hypertext document is made from an "extended text", or "multiplexed text".

At its most basic, an extended text is identical to UTF-8 text. Things change when you extend it adding the concept of text streams.

In the case of hypertext documents, apart from the content stream, the other four components are parallel multiplexed text streams. When all five streams are combined into an extended text document, we have an hypertext document.

@h Jan 14, 2020

@alcinnz Forgot I had been working on these slides back in 2017, more than two years ago.

#xtxt #extendedtext #mtxt #multiplexedtext #hypertext

@h Jan 14, 2020

@alcinnz That particular example of an hypertext document doesn't have a layout component, but it's easy to see how a parallel :layout component could easily be added to inform the location of the content to be rendered on the page.