Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pylon – Declarative layout primitives for CSS and HTML

almonk.github.io

Post reply on HN
Print view View original

31–40 of 78 posts

Re: Pylon – Declarative layout primitives for CSS and HTML

#31

Post by lioeters »

pier25 wrote: post #10

The resulting HTML is not great, but the dev experience looks super nice. Maybe we need to introduce HTML transpilers now :)

I've been building and using various forms of HTML transpilers for several years, as part of a build step or "JIT" during server-side rendering.

The main advantage I see is the ability to extend HTML to have layout/templating functions, building up a simple DSL for frontend devs and editors. Since the target userbase is already familiar with HTML syntax, it's easy to learn and gives them "super powers" - for example, an tag that imports another HTML file/partial.

Another use case I've used in a number of sites/applications: chaining a Markdown parser, an HTML transpiler, and a React renderer for the HTML "AST". Among other things, it renders internal links as components of the router.

And the rabbit hole goes deep: the XML/HTML syntax is actually able to represent "programs" in a Lisp-like manner. If the angle brackets are too noisy, one can use Jade/Pug syntax to generate the same AST.

In the end, the traspiler should render the result in standards-compliant HTML. This Pylon project doesn't transpile anything, so the result contains undefined tags which the browser treats as HTMLUnknownElement [0]. The bottom line though, is that it works - and I've seen numerous projects in the wild taking advantage of this behavior.

I'd also like to mention the posthtml project [1]. I haven't used it myself, but a generic HTML transpiler has great potential in my opinion.

[0] https://developer.mozilla.org/en-US/docs/Web/API/HTMLUnknown...

[1] https://github.com/posthtml/posthtml

Re: Pylon – Declarative layout primitives for CSS and HTML

#32

Post by mixmastamyk »

folkrav wrote: post #22
Waterluvian wrote: post #12

Earlier quoted context omitted.

Are those custom elements just divs by default or do you need to define them somewhere?

Modern browsers indeed treat unknown elements as equivalent to divs, but it's officially undefined behavior, up to implementation.

Just tried in firefox and as mentioned above they are not block elements but inline:

    foo
    bar
    div1
    div2
Results in:

    foo bar
    div1
    div2

Re: Pylon – Declarative layout primitives for CSS and HTML

#33

Post by shaki-dora »

pjc50 wrote: post #29
ziroshima wrote: post #26

Earlier quoted context omitted.

I work on an older project with some folks that never got the memo about tables being evil for layout. In my experience, they've actually been quite easy to work with. Granted, we develop for a fixed screen width. Why were tables declared evil?

Screen reader pedantry, I think; also they're "not semantic markup". The idea was that tables should only be used if the content was genuinely a table.

One man's pedantry is another blind man's attention to detail. Or ability to participate in society.

Re: Pylon – Declarative layout primitives for CSS and HTML

#34

Post by tannhaeuser »

folkrav wrote: post #22
Waterluvian wrote: post #12

Earlier quoted context omitted.

Are those custom elements just divs by default or do you need to define them somewhere?

Modern browsers indeed treat unknown elements as equivalent to divs, but it's officially undefined behavior, up to implementation.

And herein lies the flaw of custom elements: that they don't use a declarative mechanism for exposing their presence in HTML to browsers. Instead, they must be declared by subclassing from built-in element representation classes (using ES6+ class syntax which nobody seems to be using anyway). Now the browser must 1. have JavaScript 2. have JavaScript enabled 3. synchronously execute the subclassing/registration script code text before proceeding with parsing (which browsers do anyway, but at least didn't have to in order to even parse HTML as intended).

Not only that: content of custom elements is treated as fallback content (taken when a particular custom element is not available). However, that content is still subject to HTML parsing and tag omission rules, and tag omission is contextually dependent on the parent element's content model (which a custom element doesn't have since there's no way to register such using the JavaScript API).

There was (?) even the sacked mechanism of "customized built-in elements" which would allow authors to define custom attributes and behaviours for standard HTML elements. Except it doesn't work like that with HTML's enumerated attributes such as `selected` which can have shortforms like `` where `selected` is the attribute value not the attribute name, requiring the values of all enumerated attributes be unique among all attributes in a DTD (as in SGML) or at least on a given element.

Sometimes I wonder why the HTML spec authors just had to make every blunder imaginable when there's a very rich theory of formal language and markup languages (eg. SGML and others) dealing exactly with these kind of problems.

Re: Pylon – Declarative layout primitives for CSS and HTML

#36

Post by nickthemagicman »

Siilwyn wrote: post #17
pier25 wrote: post #10

The resulting HTML is not great, but the dev experience looks super nice. Maybe we need to introduce HTML transpilers now :)

https://github.com/posthtml/posthtml

Only one layer of transpilation? Rookie numbers. I can get javascript up to 4 or 5 layers on a good day.

Re: Pylon – Declarative layout primitives for CSS and HTML

#37

Post by sanbor »

ziroshima wrote: post #26
hn_throwaway_99 wrote: post #4

I like this, but my 20 years in web dev can't help but chuckle. Remember when tables were declared evil for layout, so we had the shit show of trying to use CSS floats for everything, so then we added flexbox, and then grid, and here is a nice set of elements that is basically, well, somewhat less useful than tables for layout. Don't mean to bash the poster, I just think it's interesting in the "everything old is new…

I work on an older project with some folks that never got the memo about tables being evil for layout. In my experience, they've actually been quite easy to work with. Granted, we develop for a fixed screen width. Why were tables declared evil?

They mix content and presentation. If you separate content from presentation, then you can have a presentation for desktop an another for mobile. Also, you can totally change the layout without the need to change your HTML, as showcased in http://www.csszengarden.com/

Re: Pylon – Declarative layout primitives for CSS and HTML

#38

Post by cpach »

hn_throwaway_99 wrote: post #4

I like this, but my 20 years in web dev can't help but chuckle. Remember when tables were declared evil for layout, so we had the shit show of trying to use CSS floats for everything, so then we added flexbox, and then grid, and here is a nice set of elements that is basically, well, somewhat less useful than tables for layout. Don't mean to bash the poster, I just think it's interesting in the "everything old is new…

Regarding tables, try view source on this very thread. Some of you might be surprised :)

Re: Pylon – Declarative layout primitives for CSS and HTML

#39

Post by lloydatkinson »

hn_throwaway_99 wrote: post #4

I like this, but my 20 years in web dev can't help but chuckle. Remember when tables were declared evil for layout, so we had the shit show of trying to use CSS floats for everything, so then we added flexbox, and then grid, and here is a nice set of elements that is basically, well, somewhat less useful than tables for layout. Don't mean to bash the poster, I just think it's interesting in the "everything old is new…

And in that 20 years you haven't encountered custom elements/web components, etc, etc?

Re: Pylon – Declarative layout primitives for CSS and HTML

#40

Post by wishinghand »

ziroshima wrote: post #26
hn_throwaway_99 wrote: post #4

I like this, but my 20 years in web dev can't help but chuckle. Remember when tables were declared evil for layout, so we had the shit show of trying to use CSS floats for everything, so then we added flexbox, and then grid, and here is a nice set of elements that is basically, well, somewhat less useful than tables for layout. Don't mean to bash the poster, I just think it's interesting in the "everything old is new…

I work on an older project with some folks that never got the memo about tables being evil for layout. In my experience, they've actually been quite easy to work with. Granted, we develop for a fixed screen width. Why were tables declared evil?

They didn’t flex like flexbox. When smaller laptop screens and eventually mobile devices appeared on the scene, tables would often extend past the screen’s boundaries.
Post reply on HN