Hacker News new | past | comments | ask | show | jobs | submit login

"Others are questioning whether or not this kind of layout is needed on the web at all — they aren’t sure that well-known websites will use it."

Would it instead be possible to exclude anyone with that attitude from a discussion about an open standard? I know this sounds toxic, but I would argue that approaching public design this way is ultimately more toxic wrt the outcome and those affected by it.

Or maybe I misunderstood that part since everyone seems to not be bothered by it at all here...




> Would it instead be possible to exclude anyone with that attitude from a discussion about an open standard?

That attitude is rather critical and important to the discussion.

I don't think it's the browser, or the standards bodies, responsibility to have built-in support for every possible feature we can imagine. Instead, the standards need to be simple and extensible so that that libraries (Javascript or WASM) can do creative layouts. (IE, instead of waiting for Masonry layout in CSS, you should be able to grab a Masonry layout library and include it with your web site.)

Otherwise, we're building a system where the standards (CSS in this case) are so complicated that it's getting harder and harder to implement the standards; and are too inflexible to support what tomorrows' developers can imagine.


Why? When developing standards it's very good to have good gatekeepers. Not everything should be built inside the browser if you can achieve the same with existing technologies like JS.

Otherwise your browser(standards) might become too complex.


That is an orthogonal discussion.

I need masonry layouts a lot and tend to be on the "we don't need another display class" side in this debate. But that's unrelated to my "rant".


For what it’s worth, I found masonry layout always detrimental to my use of a site. I would prefer CSS not to encourage it by providing built-in support.


Why? Any feature is a liability, so it's good to question whether a feature has to be implemented, and whether it should be in this way and position, or maybe somewhere else.


Where is the connection to "well-known websites"?


I assume, with "well-known", they mean popular. Which means they (also) measure the worth of this feature by the number of users which might benefit from it. This is a very legit metric for this kind of situation.


Surely questioning the real world usefulness is not "toxic"?

CSS is already very complicated. Adding more options needs proportionally strong justification.


No, but basing capabilities solely on what they imagine "well-known websites" might want is.


And how would you do it sans imagination?


You misunderstand. I don't think that using "well-known websites" is a good metric in the first place.

That's a recipe for stagnation.


I mean the actual point of the article is to ask everyone, not just "well-known" examples.

So it seems there were some reasonably forces in the discussion that align with my stance without the unnecessarily antagonistic (and rhetoric) primer I should've probably left out.

Seems like a good approach to widen the discussion and improve the design.


I can totally understand the quoted comment. I mean, we are talking about CSS as a language here. Anything that is formalized is expected to be implemented and supported by browser engines and vendors. Browser engines are already extremely complex, so it's fair to think closely about formalizing new things when it's not apparent that there is a big enough need.

I'm not claiming this is the case with the Mansory layout; I just understand that adding unnecessary complexity for a small target user base is a valid concern.


I totally get that. But for me there is a fundamental difference between "big enough need" and "well known websites need this".

How are potentially thousands of niche websites less of an argument than "instagram and co don't need it"?


Well-known == highly visited == native implementation will have large accumulated impact on end users (their performance, energy consumption, improved usability ...).


I heavily agree!

This take is imho dangerously conflates personal taste and motivation with "should a heavily generalized and clearly purposed layout system be complicated with some magic keyuword options to serve your specific intents?", and misappropriates the assumption that people like and use this form layout as a reason to approve the latter.


Questioning whether something new is actually needed is absolutely worth doing, so long as it’s done respectfully.

This is a standard that affects billions of people and many implementations. It’s great to ask if something is really needed or if it’s just adding bloat.

We shouldn’t just grow the standard without first asking if the growth and added complexity carry their own weight. If someone proposing something can show that, then wonderful.

But yeah, just straight up trying to block these people from being able to ask these questions totally is toxic. As long as they’re asking and participating respectfully there’s no need to be a jerk toward them.


Again: when did "well-known websites use this" become the motivating factor behind standard design?

The blink tag was used by well-known website and it's universally recognized as a bad decision.


It’s fine if you disagree with the premise of the question. But it’s also fine to ask the question, since presumably the asker wants to know the feature would get enough usage to justify its addition to the specification, and an easy way to show it gets usage is by showing some well-known sites would use it.

But what is not fine is trying to exclude people from the conversation and silence them just because you have a disagreement.


And honestly, that's a ridiculous claim. Two very popular websites I can think of right away are Pinterest and VSCO. (Perhaps VSCO on the web isn't as popular as the mobile app, but the company continues to use masonry as the design evolves.)


Lots of sites that return a ton of images, like an of the image search sites (Google, Bing, DuckDuckGO, loads of porn sites etc.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: