Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Either way, it's not as easy as it looks.

And exploring the tradeoffs might lead those exploring to reconsider their preferences going in.

Not directly related to the topic, but I recently did some prototyping on a second iteration of an interface with a similar tension—proliferation of similar but distinct types in a data model, or expanding the set of nuances within each existing type to support refinement within it. Going into that prototyping session, I had a very strong bias in favor of the latter. But after exploring the options, I found it vastly simpler to consume the “bloated” interface, and to reason about the resulting application code consuming it.

I don’t have strong feelings on the topic as it applies to CSS masonry, but I suspect there could be similar surprises in how people think about this tension intuitively versus in practice.

And while I think CSS in particular will have a hard time justifying “bloat” (proliferation of use case specific semantics), I think it’s possible that users do tend to find more difficulty using CSS’s denser APIs (like grid).



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

Search: