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

71–78 of 78 posts

Re: Pylon – Declarative layout primitives for CSS and HTML

#71

Post by detaro »

jandrese wrote: post #70
shaki-dora wrote: post #30

Earlier quoted context omitted.

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 w…

"Semantic Web" and using the semantically correct tags for HTML aren't really the same thing.

Re: Pylon – Declarative layout primitives for CSS and HTML

#72

Post by nwienert »

Why have the alignment done relative to the direction of the stack? I’ve wondered the reason for this with Flexbox as well.

It’s very hard to remember and unintuitive. My guess is something to do with responsiveness?

To me, alignX and alignY (with an align shorthand) are always clear. And the amount of times I’m changing between the two is nearly 0 so far in a large app.

Re: Pylon – Declarative layout primitives for CSS and HTML

#73

Post by yellowapple »

the_other wrote: post #54
sheeshkebab wrote: post #47

Earlier quoted context omitted.

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.

It’s really not nonsense. Make a text file with line breaks to force a line length, and then make a non-trivial edit to the content. You’ll have to move all the line-breaks too. It’s awful. If you’d instead left presentation to the display tool, you’d only need to change the content. The HTML presentation/content argument is this scaled up.

> Make a text file with line breaks to force a line length, and then make a non-trivial edit to the content. You’ll have to move all the line-breaks too. It’s awful.

But Emacs does that for me if I press M-q.

Re: Pylon – Declarative layout primitives for CSS and HTML

#74

Post by lozenge »

pjc50 wrote: post #45
madeofpalk wrote: post #42

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…

All the table elements just have special values for the CSS "display" property. You can apply these to divs or any elements and get table layout.

Re: Pylon – Declarative layout primitives for CSS and HTML

#75

Post by Vanderson »

ysavir wrote: post #61
Vanderson wrote: post #52

Earlier quoted context omitted.

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.

Yep, I agree, seems like we are on the same page. I made my own framework based on my specific uses, so I even get to control when the fallbacks are removed, and deal with any of the fallout if there's issues.

I kind of think that at one point, everyone that works a lot with front end web development should make their own framework. It helps you learn to make long term decisions, deal with design iterations where you have lots of wide spread use of older systems and many other things that help you make wiser decisions in day to day interface design. But also it can help you see where things like Bootstrap are helpful and where it is not.

Re: Pylon – Declarative layout primitives for CSS and HTML

#76

Post by kjeetgill »

wongarsu wrote: post #58
sheeshkebab wrote: post #47

Earlier quoted context omitted.

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.

In the specific case of html and css I agree that it rarely works. There are a few examples like subreddit css, but in general html does to much layout to meaningfully separate content from layout. Xml and XSLT is a much better separation, with Xml containing pure content and Xslt transforming that into XHTML with CSS for presentation. But that never got much adoption. In other domains separating content from present…

Agreed. The real answer, as you noted, is that presentation really is HTML+CSS. You can join it with content in JSON (or XML if you want) via client or server side templating.

It actually gets you pretty close to MVC or whatever MVVC is maybe? Is that still a thing?

Re: Pylon – Declarative layout primitives for CSS and HTML

#77

Post by the_other »

yellowapple wrote: post #73
the_other wrote: post #54

Earlier quoted context omitted.

It’s really not nonsense. Make a text file with line breaks to force a line length, and then make a non-trivial edit to the content. You’ll have to move all the line-breaks too. It’s awful. If you’d instead left presentation to the display tool, you’d only need to change the content. The HTML presentation/content argument is this scaled up.

> Make a text file with line breaks to force a line length, and then make a non-trivial edit to the content. You’ll have to move all the line-breaks too. It’s awful. But Emacs does that for me if I press M-q.

Exactly!

Your editor is also your presentation tool here, and it knows where all the line breaks should be, so it can do the edits for you. It works those around the content. If you hadn't included the line-breaks in the first place, it wouldn't even have needed to do that (well, ok, it would to "soft-wrap").

If you passed/copied the file to someone who prefers a 78 character line to your 100 character line (or uses a machine from the early 80s for retro-cyberpunk chic), when they render the file, several things could happen: - their viewer/wditor might add temporary line-breaks to soft-wrap, in which case they'll see some short and some long lines - their viewer/editor might add hard-wrap line-breaks at 78 chars. This would remove all your 100 char ones, and could potentially break your content because it might not see the difference between a "wrap" and a "new paragraph".

In the second case, when you get the file back later on, the content wont suit your preference for 100 character lines.

When the presentation is kept out of the content, none of this happens.

My point was that even in something as simple as a text file, adding presentation commands (line breaks), adds work, or hinders accessibility.

Scale that up to HTML and the wider range of possible presentation options. Say you used the old-school inline colouring options. Maybe you find green text on red backgrounds really fun to read. You encode that into the content (the markup). Pass this file on to someone with red-green colourblindness (c7% of XY-chromosome carrying humans[0]) and they wont be able to read your file at all.

[0]: https://www.colour-blindness.com/general/prevalence/

Re: Pylon – Declarative layout primitives for CSS and HTML

#78

Post by okcando »

pjc50 wrote: post #45
madeofpalk wrote: post #42

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…

There is such a thing in CSS. Display: table, table-cell, etc. It's supposed to make content render exactly as if it were cast in an Html table.
Post reply on HN