Live data from Hacker News

Pylon – Declarative layout primitives for CSS and HTML

almonk.github.io

41–50 of 78 posts

Re: Pylon – Declarative layout primitives for CSS and HTML

#41
post #38

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

Good God man, why did you have to point that out?!?

Re: Pylon – Declarative layout primitives for CSS and HTML

#42
post #29

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.

"Screen reader pedantry" sure is a pretty abrasive way of describing creating websites for people.

Re: Pylon – Declarative layout primitives for CSS and HTML

#43
post #13

So basically you're abusing the fact that (modern) browsers treat unknown tags more or less as divs and built a small CSS framework with these names. I understand how that it can feel familiar to Swift devs, and also realized by reading the source that the upside of using unknown tags means they don't have any base style that you'd have to override. But really, you're breaking all HTML semantics and your markup is no…

Came to say the same thing. Seems odd to me, personally. Why not just make them class names, and you could probably still get an even smaller sized framework (if that was the main goal)?

I think the idea is to also abstract away the choice of elements in favor of familiar container names. Make it only class names and you're back to a simple CSS framework like tons of others already.

Re: Pylon – Declarative layout primitives for CSS and HTML

#44

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?

Aside from the semantic HTML movement, they're clunky and verbose, more difficult to break up into reusable components, and table rendering is more expensive than the equivalent layouts with non-table elements and CSS (at least that was my experience last time I tried profiling a table with hundreds of rows).

Edit: they also have a lot of intrinsic layout behavior that can be difficult to predict once you start getting into more complex layouts than header, sidebar, and footer.

Re: Pylon – Declarative layout primitives for CSS and HTML

#45
post #29

Earlier quoted context omitted.

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.

"Screen reader pedantry" sure is a pretty abrasive way of describing creating websites for people.

You're right, it's unnecessarily abrasive. But it is, as far as I can tell, a very minority use case, and these days most of the reader software has adapted. If you see some of the DOM horrors inflicted by Facebook, then suddenly tables look positively readable.

Perhaps what should have happened was the defining of a "table-layout" tag that behaves exactly the same as "table" except it's understood to be for visual presentation only. Flexbox almost achieves this, but for some reason isn't as popular.

Re: Pylon – Declarative layout primitives for CSS and HTML

#46
I enjoy seeing other people's solution, but since I really learned the power of grid, most of this is overdone with flex.

As an example, here's how you can make a vstack with grid.

  vstack {
    display:grid;
  }
It's ridiculously simple and clean, works with all the elements without extra wrappers, no margins, no cleaning up trailing spaces, etc... add spacing class using "grid-gap" and it's the near perfect solution.

The hstack example is more complicated, because you simply have to choose widths, there is no getting around this, even with flexbox. (unless you want to totally give up control of the layout to "auto".)

The spacing classes are clever, and I may adopt some of this method. (I use grid gap, I only have 2 sizes) With the "Spacers" example, a width of 1fr works using grid.

Flex beats grid with some natural overflow capabilities (row wrap), but other than that, flex is not great for this kind of thing.

Since there's only a few examples, I suspect this person will be adding more in the future.

Edit: For declarative things like this, I think there should be one assumption. I use vertical in web interfaces. This means one less option to remember. (ie, by default everything is vertical)

Edit2: With an unknown number of items, flex is probably preferable for horizontal items for simple columns. But that is only if you don't care about the widths of the columns too much as well.

Re: Pylon – Declarative layout primitives for CSS and HTML

#47
post #37

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/

The whole concept of separated “content” form “presentation” in UI is a bunch of nonsense. Maybe it works somewhere in some very limited sense, but I’ve yet to see anything complex that separates these things.

Re: Pylon – Declarative layout primitives for CSS and HTML

#48

This has issues: Westminster 0.5 miles .... It is more complex then it needs to be, it puts the styling into into the html, it kills all semantic meaning and pollutes the global namespace of element names. It should be: Westminster 0.5 miles .... And then simply style the custom attributes to your liking via css. If these "primitives" would use classnames instead of element names, their styles could be added like thi…

CSS is why we can’t have nice and easy rich UI things in web dev world. And so I downvote you...

Re: Pylon – Declarative layout primitives for CSS and HTML

#49
post #45

Earlier quoted context omitted.

"Screen reader pedantry" sure is a pretty abrasive way of describing creating websites for people.

You're right, it's unnecessarily abrasive. But it is, as far as I can tell, a very minority use case, and these days most of the reader software has adapted. If you see some of the DOM horrors inflicted by Facebook, then suddenly tables look positively readable. Perhaps what should have happened was the defining of a "table-layout" tag that behaves exactly the same as "table" except it's understood to be for visual p…

Brain-washers and adblockers playing catch-up leaving a scorched-DOM behind.

Also, flexbox is very popular in my experience.

Re: Pylon – Declarative layout primitives for CSS and HTML

#50

This has issues: Westminster 0.5 miles .... It is more complex then it needs to be, it puts the styling into into the html, it kills all semantic meaning and pollutes the global namespace of element names. It should be: Westminster 0.5 miles .... And then simply style the custom attributes to your liking via css. If these "primitives" would use classnames instead of element names, their styles could be added like thi…

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

Technically, they should be defined:

https://html.spec.whatwg.org/multipage/custom-elements.html#...

Browsers usually treat undefined nonstandard elements as span-like (flow elements), not div-like (block elements) by default.

Post reply on HN