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

21–30 of 78 posts

Re: Pylon – Declarative layout primitives for CSS and HTML

#21

Post by playpause »

masklinn wrote: post #14
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.spe…

The Custom Elements spec requires all custom elements to have a hyphenated name.

Re: Pylon – Declarative layout primitives for CSS and HTML

#22

Post by folkrav »

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?

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

Re: Pylon – Declarative layout primitives for CSS and HTML

#23

Post by matt-tingen »

masklinn wrote: post #14
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.spe…

Custom element names must contain a hyphen for forwards-compatibility, and these do not.

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

Re: Pylon – Declarative layout primitives for CSS and HTML

#25

Post by dosy »

joncfoo wrote: post #24

Wow. So many kill-joys in this thread. I think the project is neat. It certainly is an opinionated way of doing a layout and it reads quite nicely. If CSS classes were provided as an alternative I think the project might have more adopters. Good work :)

This is HN. Of course there is haters on someone's work. And of course they pretend they're justified in it. Hater News.

Re: Pylon – Declarative layout primitives for CSS and HTML

#26

Post by ziroshima »

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?

Re: Pylon – Declarative layout primitives for CSS and HTML

#28

Post by speps »

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?

> Why were tables declared evil?

If you use them for layout, you're not respecting the semantic meaning of tags.

Re: Pylon – Declarative layout primitives for CSS and HTML

#29

Post by pjc50 »

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?

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.

Re: Pylon – Declarative layout primitives for CSS and HTML

#30

Post by shaki-dora »

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?

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 individual elements that css-in-js approaches frequently produce.

Post reply on HN