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

11–20 of 78 posts

Re: Pylon – Declarative layout primitives for CSS and HTML

#11

Post by untog »

Juliate wrote: post #8
heyplanet wrote: post #5

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…

https://en.wikipedia.org/wiki/Extensible_stylesheet_language to the rescue!

I remember playing around with XSL years ago, it kind of blew my mind that more people weren't using it. The bandwidth savings seemed immense. But then I started to run into edge cases, and realised that gzip covered most of the bandwidth difference anyway... but I still maintain it's a super cool idea.

Re: Pylon – Declarative layout primitives for CSS and HTML

#12

Post by Waterluvian »

heyplanet wrote: post #5

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?

Re: Pylon – Declarative layout primitives for CSS and HTML

#13

Post by uhryks »

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 not accessible. It could work as a set of React/Vue/Whatever components or even Web components (probably the best way to achieve what you're trying to do), but as bare HTML it doesn't.

Re: Pylon – Declarative layout primitives for CSS and HTML

#14

Post by masklinn »

uhryks wrote: 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…

> 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.

The spec allows custom elements[0] and pretty much requires this behaviour.

> you're breaking all HTML semantics and your markup is not accessible.

Calling the markup non-accessible is defensible[1], but it doesn't break HTML semantics in any way.

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

[1] though it wouldn't be more accessible as a stack of divs and the custom element can be aria-tagged[2], in the browsers supporting it it's also possible to use customised elements but here there's little of interest

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

Re: Pylon – Declarative layout primitives for CSS and HTML

#16

Post by bluetidepro »

uhryks wrote: 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)?

Re: Pylon – Declarative layout primitives for CSS and HTML

#18

Post by Raphmedia »

uhryks wrote: 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…

This could work with a build system or as a templating engine. The names and logic is sound, but as you said it makes little senses to use those tags as-is in production.

Re: Pylon – Declarative layout primitives for CSS and HTML

#19

Post by heyplanet »

Waterluvian wrote: post #12
heyplanet wrote: post #5

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?

They are not divs. They are whatever you call them. If you mean "Are they styled like divs by default?" then also no. Divs are block elements by default while custom elements are inline elements by default.

Re: Pylon – Declarative layout primitives for CSS and HTML

#20

Post by ggurgone »

The intent is nice, in fact this is what React Native for Web does as well with the difference that accessibility and semantics are preserved because JS comes to the rescue.

That said for pure layout stuff I actually think that this library is cool. is totally fine.

(or a sexier prefix) would even be valid HTML

Post reply on HN