7 ms·

It's funny how we've come full circle from using CSS the way it was intended to be used to that being "considered harmful" and now we have the Javascript framew

It's funny how we've come full circle from using CSS the way it was intended to be used to that being "considered harmful" and now we have the Javascript framework equivalent of < img src="spacer.gif" />, an anti-pattern I was using back in 1999. The reality is that frontend is messy, browsers are still inconsistent with respect to how they treat CSS, and creating new layers of abstraction to handle trivial considerations like adding space on a display are just a way of denying that reality by fixing something that isn't broken. Creating new, completely useless components to "bring us closer to how designers think" completely flies in the face of separating view from the program layer. And in my experience, "designers think" everyone has a 27" Thunderbolt display, or now increasingly a Pro Display XDR, so I wouldn't really put too much stock in what they think. If you disagree, I would propose spacer.gif as a much more succinct and widely accepted alternative to all the harm being done here.

jpochtar 7y ago
> completely flies in the face of separating view from the program layer HTML is the view layer. The "program" layer is JS manipulating JSON (ultimately fetched from a DB). Separating HTML and CSS made sense when content lived in HTML, and styling lived in CSS. Content hasn't lived in HTML in a long time— it lives in a DB now. (Maybe markdown if you're making a static site.) Separating HTML from CSS is separating view layer from view layer— just an unnecessary and expensive indirection
WrtCdEvrydy 7y ago
> everyone has a 27" Thunderbolt display Insert Game of Thrones too dark meme here...
quotemstr 7y ago
> browsers are still inconsistent with respect to how they treat CSS Are they? CSS seems to be rock-solid and consistent now. The days of IE6 randomly breaking the box model are far behind us.
- nessunodoro 7y ago
  grid and flexbox are still not carved in stone, so catering to tbe lowest common denominator sometimes means e.g. nesting divs to mimic functionality in another browser
- henriquez 7y ago
  Yes, some examples: - margin-top inconsistent between Firefox and Chrome in some cases, usually near the start of a container element. - specifying percentage height for absolutely positioned elements inconsistent in some cases between Firefox and Chrome (bugged in Chrome) - SVG elements or CSS backgrounds are handled inconsistently by Chrome, Firefox and Safari. Which can depending on the use case can lead to issues like exceeding max-width, failure to apply aspect ratio, or in the case of Safari full page reflows every frame where an SVG is animated. - Chrome incorrectly renders any scrollable element with backface-visibility: hidden. Requires non-scrollable nesting div. - Everyone has a different way of specifying custom scrollbars. On some platforms you need to leave room in any scrolling design for a scrollbar which will reliably be an unpredictable width. Chrome and Firefox still have inconsistent non-standardized css proprties. Or (some) Apple users get the self-hiding scrollbar. In practice this needs to be detected and fixed after the fact with Javascript. - position: sticky unusably broken in Safari I'm sure there are others, but my point is the browsers are quirky and better to just face it and get over it.
- nwmcsween 7y ago
  CSS is still a big mess of hacks if you try to have consistent styles across browsers, it's not ie 7 zoom level hacks but you still need various extra properties to make things work.
ggreer 7y ago
At almost every job I've had to push back on designs with low contrast and large fixed headers for UI elements. These things look fine on a 27" 4k screen in office lighting, but they're horrible on a 13" laptop with glare from sunlight. Similar to Facebook's 2G Tuesdays, I'd love to see what designers would come up with if you made them spend one day a week using a 13" 1366x768 200 nit TN screen.
seanwilson 7y ago
> 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.
mrzool 7y ago
Exactly my thoughts, I had to check twice make sure the article was not parody. This will probably come across as provocative, but it's my honest feeling: I'm glad I got out of whatever frontend development has become.
- pikelet 7y ago
  You will have to elaborate I think. The article seems to me to simply be saying that rather than an individual component being responsible for the margins around itself it should not make assumptions about the context it is used in and should instead let the context or container decide the margins/spacing. That seems sensible does it not? I don't think it really has anything to do with components or using CSS in a non-standard way, it's just about good structure. Why do you think it's so crazy?
hjanssen 7y ago
The article does not suggest any of those ideas you think it presents (especially, it does NOT suggest an react equivalent of "spacer.gif") and your comment completely misses the point of the article.
goto11 7y ago
Beware - what this article calls a "spacer component" is nothing like <img src="spacer.gif">. Rather it is a container that specifies the spacing between its child components. The article just argues that spacing between sibling components should be specified by the container rather than by the individual components. This makes sense in some contexts where you have a uniform spacing between components. In other contexts, like an article with headers and paragraphs, it doesn't make sense. But you probably wouldn't use React for that in the first place. In CSS you can do both and the article is not pro or con CSS in any sense.

jpochtar 7y ago

> completely flies in the face of separating view from the program layer HTML is the view layer. The "program" layer is JS manipulating JSON (ultimately fetched from a DB). Separating HTML and CSS made sense when content lived in HTML, and styling lived in CSS. Content hasn't lived in HTML in a long time— it lives in a DB now. (Maybe markdown if you're making a static site.) Separating HTML from CSS is separating view layer from view layer— just an unnecessary and expensive indirection

WrtCdEvrydy 7y ago

> everyone has a 27" Thunderbolt display Insert Game of Thrones too dark meme here...

quotemstr 7y ago

> browsers are still inconsistent with respect to how they treat CSS Are they? CSS seems to be rock-solid and consistent now. The days of IE6 randomly breaking the box model are far behind us.

nessunodoro 7y ago
grid and flexbox are still not carved in stone, so catering to tbe lowest common denominator sometimes means e.g. nesting divs to mimic functionality in another browser
henriquez 7y ago
Yes, some examples: - margin-top inconsistent between Firefox and Chrome in some cases, usually near the start of a container element. - specifying percentage height for absolutely positioned elements inconsistent in some cases between Firefox and Chrome (bugged in Chrome) - SVG elements or CSS backgrounds are handled inconsistently by Chrome, Firefox and Safari. Which can depending on the use case can lead to issues like exceeding max-width, failure to apply aspect ratio, or in the case of Safari full page reflows every frame where an SVG is animated. - Chrome incorrectly renders any scrollable element with backface-visibility: hidden. Requires non-scrollable nesting div. - Everyone has a different way of specifying custom scrollbars. On some platforms you need to leave room in any scrolling design for a scrollbar which will reliably be an unpredictable width. Chrome and Firefox still have inconsistent non-standardized css proprties. Or (some) Apple users get the self-hiding scrollbar. In practice this needs to be detected and fixed after the fact with Javascript. - position: sticky unusably broken in Safari I'm sure there are others, but my point is the browsers are quirky and better to just face it and get over it.
nwmcsween 7y ago
CSS is still a big mess of hacks if you try to have consistent styles across browsers, it's not ie 7 zoom level hacks but you still need various extra properties to make things work.

ggreer 7y ago

At almost every job I've had to push back on designs with low contrast and large fixed headers for UI elements. These things look fine on a 27" 4k screen in office lighting, but they're horrible on a 13" laptop with glare from sunlight. Similar to Facebook's 2G Tuesdays, I'd love to see what designers would come up with if you made them spend one day a week using a 13" 1366x768 200 nit TN screen.

seanwilson 7y ago

> 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.

mrzool 7y ago

Exactly my thoughts, I had to check twice make sure the article was not parody. This will probably come across as provocative, but it's my honest feeling: I'm glad I got out of whatever frontend development has become.

pikelet 7y ago
You will have to elaborate I think. The article seems to me to simply be saying that rather than an individual component being responsible for the margins around itself it should not make assumptions about the context it is used in and should instead let the context or container decide the margins/spacing. That seems sensible does it not? I don't think it really has anything to do with components or using CSS in a non-standard way, it's just about good structure. Why do you think it's so crazy?

hjanssen 7y ago

The article does not suggest any of those ideas you think it presents (especially, it does NOT suggest an react equivalent of "spacer.gif") and your comment completely misses the point of the article.

goto11 7y ago

Beware - what this article calls a "spacer component" is nothing like <img src="spacer.gif">. Rather it is a container that specifies the spacing between its child components. The article just argues that spacing between sibling components should be specified by the container rather than by the individual components. This makes sense in some contexts where you have a uniform spacing between components. In other contexts, like an article with headers and paragraphs, it doesn't make sense. But you probably wouldn't use React for that in the first place. In CSS you can do both and the article is not pro or con CSS in any sense.