4 ms·

> completely flies in the face of separating view from the program layer. Why do people stick to this concept like a religion as if it's the only right way th

> completely flies in the face of separating view from the program layer. Why do people stick to this concept like a religion as if it's the only right way that has no tradeoffs though? If you want a heavily designed look to your website or UI, at some point you're going to have to add annotations to your data for purely presentational reasons either because of limitations with CSS (e.g. there's no way to style the first word of a paragraph with only CSS) or because there's no semantic reason one piece of data should look different from another other than it "looks nicer that way" (e.g. adding a line break in the middle of a heading because you want a two word brand name to appear at the start of a line). You might be able to avoid presentation-only HTML markup by preprocessing the HTML, modifying the HTML with JavaScript, using some CSS hack, excessive annotations that might never be used (like wrapping all brand names in tags) etc. but is it worth if for this purity of separating data from styling? It has tradeoffs.

henriquez 7y ago
I wasn't arguing in favor of separation of view and functionality as gospel. On the contrary, bringing them together can often be more performant _if done correctly._ However, in the context of adding layers of abstraction, I believe it should be a one way trip, ie. we can abstract code functionality from the view, but we should not abstract view functionality into code (and then back into the view at render time). That's like crossing the street twice and ending up where you started.
- seanwilson 7y ago
  > I believe it should be a one way trip, ie. we can abstract code functionality from the view, but we should not abstract view functionality into code (and then back into the view at render time). That's like crossing the street twice and ending up where you started. Can you give an example to illustrate this approach?
  - henriquez 7y ago
    The OP gives a good example: https://seek-oss.github.io/braid-design-system/components/Stack/ https://seek-oss.github.io/braid-design-system/components/St... This is overengineering, something that should be handled in a view with a CSS class, instead of an abstraction that ends up translating back into a CSS class after the overhead of parsing the abstraction. I think in the case of your original comment to me, you're arguing something different. You want to bold the first word of an article or apply a line break after the first two words. For a use like that, there's nothing you can do other than to put some kind of view-related functionality in your code, and I agree. But handling that in code isn't fixing something for the sake of fixing it, because there's no way that it could be handled natively by the view in the context of whatever data you pipe into it dynamically. A CSS class that provides margins to items in a div can be handled natively by the view and should.
    - cercatrova 7y ago
      I get type safety with that example, I don't with CSS.
      - henriquez 7y ago
        Type safety for a CSS class? What?
        cercatrova 7y ago
        Type safety for CSS properties. See TypeStyle for instance: https://github.com/typestyle/typestyle https://github.com/typestyle/typestyle
        henriquez 7y ago
        Now I've seen everything. Clearly I'm past my prime. I'm going to give up web development and go live in a cave or something.
        cercatrova 7y ago
dmwallin 7y ago
>>> e.g. adding a line break in the middle of a heading because you want a two word brand name to appear at the start of a line However using a   in your brand name would likely be a better way to handle this, and makes actual semantic sense in your html. It's also coincidently more robust to changes in your layouts. Purity for it's own sake is problematic, and definitely sometimes there won't be a good semantic approach. But thinking through cases a little deeper and trying to represent things better semantically can pay off big dividends by increasing the robustness of your solutions.
- seanwilson 7y ago
  > However using a   in your brand name would likely be a better way to handle this, and makes actual semantic sense in your html. It's also coincidently more robust to changes in your layouts. I don't see how Brand Name is any more semantic than <div class="no-line-breaks"> Brand Name </div> though. Either way, I can't see how there's a general solution for that example. - Maybe for another heading, the break in the middle of the brand name will look better because otherwise the previous line would contain only a single word. - Or the   approach works okay for short brand names but not very long ones (e.g. Department for Work and Pensions). - Or maybe for one heading we want a break only because otherwise the brand name is going to overlap with the eyes of a person in a background photo. CSS doesn't even have anything built in to do nice looking justified paragraphs yet (like LaTeX has), let alone simple stuff like dealing with text widows and text orphans. You could conceivably come up with a general algorithm that encodes some of the design heuristics above but that's in the realms of automating graphic design and there's always going to be exceptions. My point is, there's no clean separation between content/data and styling if you want your data presented in a very specific way. For heavily designed pages, this is underscored by it always being unavoidable that you'll end up modify the text content because you want it to look more presentable e.g. changing a heading so it to fits in a tight space or line breaks in a pleasing way.
  - mwcampbell 7y ago
    I think the answer is to give up on wanting things to be presented in a specific way. The user may want, or need, for it to be presented a different way anyway. So just provide the content and let the user agent lay it out as the user needs or wants it.

henriquez 7y ago

I wasn't arguing in favor of separation of view and functionality as gospel. On the contrary, bringing them together can often be more performant _if done correctly._ However, in the context of adding layers of abstraction, I believe it should be a one way trip, ie. we can abstract code functionality from the view, but we should not abstract view functionality into code (and then back into the view at render time). That's like crossing the street twice and ending up where you started.

seanwilson 7y ago
> I believe it should be a one way trip, ie. we can abstract code functionality from the view, but we should not abstract view functionality into code (and then back into the view at render time). That's like crossing the street twice and ending up where you started. Can you give an example to illustrate this approach?
- henriquez 7y ago
  The OP gives a good example: https://seek-oss.github.io/braid-design-system/components/Stack/ https://seek-oss.github.io/braid-design-system/components/St... This is overengineering, something that should be handled in a view with a CSS class, instead of an abstraction that ends up translating back into a CSS class after the overhead of parsing the abstraction. I think in the case of your original comment to me, you're arguing something different. You want to bold the first word of an article or apply a line break after the first two words. For a use like that, there's nothing you can do other than to put some kind of view-related functionality in your code, and I agree. But handling that in code isn't fixing something for the sake of fixing it, because there's no way that it could be handled natively by the view in the context of whatever data you pipe into it dynamically. A CSS class that provides margins to items in a div can be handled natively by the view and should.
  - cercatrova 7y ago
    I get type safety with that example, I don't with CSS.
    - henriquez 7y ago
      Type safety for a CSS class? What?
      - cercatrova 7y ago
        Type safety for CSS properties. See TypeStyle for instance: https://github.com/typestyle/typestyle https://github.com/typestyle/typestyle
        henriquez 7y ago
        Now I've seen everything. Clearly I'm past my prime. I'm going to give up web development and go live in a cave or something.
        cercatrova 7y ago

dmwallin 7y ago

>>> e.g. adding a line break in the middle of a heading because you want a two word brand name to appear at the start of a line However using a   in your brand name would likely be a better way to handle this, and makes actual semantic sense in your html. It's also coincidently more robust to changes in your layouts. Purity for it's own sake is problematic, and definitely sometimes there won't be a good semantic approach. But thinking through cases a little deeper and trying to represent things better semantically can pay off big dividends by increasing the robustness of your solutions.

seanwilson 7y ago
> However using a   in your brand name would likely be a better way to handle this, and makes actual semantic sense in your html. It's also coincidently more robust to changes in your layouts. I don't see how Brand Name is any more semantic than <div class="no-line-breaks"> Brand Name </div> though. Either way, I can't see how there's a general solution for that example. - Maybe for another heading, the break in the middle of the brand name will look better because otherwise the previous line would contain only a single word. - Or the   approach works okay for short brand names but not very long ones (e.g. Department for Work and Pensions). - Or maybe for one heading we want a break only because otherwise the brand name is going to overlap with the eyes of a person in a background photo. CSS doesn't even have anything built in to do nice looking justified paragraphs yet (like LaTeX has), let alone simple stuff like dealing with text widows and text orphans. You could conceivably come up with a general algorithm that encodes some of the design heuristics above but that's in the realms of automating graphic design and there's always going to be exceptions. My point is, there's no clean separation between content/data and styling if you want your data presented in a very specific way. For heavily designed pages, this is underscored by it always being unavoidable that you'll end up modify the text content because you want it to look more presentable e.g. changing a heading so it to fits in a tight space or line breaks in a pleasing way.
- mwcampbell 7y ago
  I think the answer is to give up on wanting things to be presented in a specific way. The user may want, or need, for it to be presented a different way anyway. So just provide the content and let the user agent lay it out as the user needs or wants it.