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

61–70 of 78 posts

Re: Pylon – Declarative layout primitives for CSS and HTML

#61

Post by ysavir »

Vanderson wrote: post #52
aldoushuxley001 wrote: post #51

Earlier quoted context omitted.

Only problem with grid vs flex is browser support. I opt for flex still because it's got better support.

Since the topic is "new framework", I would not advise investing in a system that is not ideal long term just because of a very minor support percent difference today. (looks like 6% of the world based on caniuse.com, but your audience may vary of course) The benefit of an assumption like "everything by default is vertical", then the few people without grid support, but with flex, will have a "mostly" ok display. Als…

I feel like this would actually be one of the strengths of using a framework. I can abstract away my own styling to the framework, and the framework can upgrade from flexbox to grid without requiring me to change any of my own code.

Re: Pylon – Declarative layout primitives for CSS and HTML

#62

Post by ben509 »

shaki-dora wrote: post #30
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?

One answer reveals itself by just switching two lines around: > Why were tables declared evil? > Granted, we develop for a fixed screen width. Personally, I was always more disturbed by the anti-semanticism of the layout use of tables. But I guess at some point the web developer community just really stopped caring about such issues. Or at least that's my takeaway of the common atrocity of style attributes on individ…

> But I guess at some point the web developer community just really stopped caring about such issues.

Any plan that depends on people caring won't survive contact with actual people.

Re: Pylon – Declarative layout primitives for CSS and HTML

#63

Post by nine_k »

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…

Sometimes simplicity is more important than expressiveness, when the scale is small. See markdown for an example.

So I for one like this super-compact and simple language, it's good for making simple interfaces quickly. It's unlikely to break in subtle ways on mobile, or so I hope.

Internally a solution like this may use CSS grids, flexbox, or any new hotness that makes thing easier to implement.

Of course this is going to get ugly, or outright break, if used at a large enough scale. But very often you manifestly do not have a large scale, and never going to.

Re: Pylon – Declarative layout primitives for CSS and HTML

#64

Post by ben509 »

lioeters wrote: post #31
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,…

> And the rabbit hole goes deep: the XML/HTML syntax is actually able to represent "programs" in a Lisp-like manner.

XML was always a poor man's s-expression.

And for all the sins of SGML, tags lend themselves beautifully to templating because they can represent code as data just as Lisp does.

Re: Pylon – Declarative layout primitives for CSS and HTML

#65

Post by jermaustin1 »

philshem wrote: post #57
sametmax wrote: post #15

Fun idea. The naming is weird as pylon used to be a python web framework but since it's not going to have any chance to become popular, overriding it seems alright.

I don’t know. Any package name that contains the string py makes me assume it’s python.

I felt the same way, I was thinking this was some sort of rendering engine to use with python to generate html layouts

Re: Pylon – Declarative layout primitives for CSS and HTML

#66

Post by folkrav »

mixmastamyk wrote: post #32
folkrav wrote: post #22

Earlier quoted context omitted.

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

You're right, they are indeed considered inline elements, not blocks. My bad.

Re: Pylon – Declarative layout primitives for CSS and HTML

#68

Post by dmitriid »

shaki-dora wrote: post #30
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?

One answer reveals itself by just switching two lines around: > Why were tables declared evil? > Granted, we develop for a fixed screen width. Personally, I was always more disturbed by the anti-semanticism of the layout use of tables. But I guess at some point the web developer community just really stopped caring about such issues. Or at least that's my takeaway of the common atrocity of style attributes on individ…

There’s nothing non-semantic about inline styles. And most css-in-js convert thise inline styles to a separate stylesheet with classnames.

I’d say web developers care much mire about semantics now than they did ten years ago. At least now you can finally have meaningful conversations around accessibility and screen readers.

Re: Pylon – Declarative layout primitives for CSS and HTML

#69

Post by _ZeD_ »

sanbor wrote: post #37
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?

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/

I really need to tell you... html is already only presentation. The content is in the backend system

Re: Pylon – Declarative layout primitives for CSS and HTML

#70

Post by jandrese »

shaki-dora wrote: post #30
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?

One answer reveals itself by just switching two lines around: > Why were tables declared evil? > Granted, we develop for a fixed screen width. Personally, I was always more disturbed by the anti-semanticism of the layout use of tables. But I guess at some point the web developer community just really stopped caring about such issues. Or at least that's my takeaway of the common atrocity of style attributes on individ…

I think the people really pushing for the Semantic Web kind of gave up. You hardly ever hear that term anymore.

I guess the value proposition of "You can add a whole bunch of complexity to your webpage that won't affect what people see so robots can scrape your page easier" didn't really resonate with developers. Also, the proposals I saw were much too granular and focused on people writing scientific papers on the web. It wasn't a good mesh for the "garbage" web, which is like 99% of everything.

Post reply on HN