4 ms·

> CSS is a complete utter crap that failed to solve the problems for which it exists. Huh? Do you not remember/know what it was like to style webpages with FON

by antod 11y ago

> CSS is a complete utter crap that failed to solve the problems for which it exists. Huh? Do you not remember/know what it was like to style webpages with FONT elements before CSS? CSS was a godsend. That was the separating content from presentation breakthrough. The problem for which it existed wasn't layout. CSS1 (1996) didn't even have anything in it for layout. >- About Tables: 15 years ago everybody switche to tabless layouts for the purpose of separating markup from presentation. Using tables for layout was the original hack. Likewise using floats to avoid it was also a hack. Neither of those features were designed for those purposes. You can possibly blame the CSS standard for being incomplete, but you can't blame it for designers creating elaborate hacks out of it. > A few years later we got access to the table display mode in CSS because, well, not a single one from the other solution worked well to build layout. Qo we got offered the option to emulate html tables in CSS. You make it sound like table display was added after the failure of other layout methods. Not so - table display was there right from the beginning when CSS first added layout (CSS2 in 1998). It was IEs failure to implement it for nearly a decade that meant nobody was aware of or could use it for many years.

lmm 11y ago
> Huh? Do you not remember/know what it was like to style webpages with FONT elements before CSS? CSS was a godsend. That was the separating content from presentation breakthrough. Have you tried using FONT recently? (Or indeed, any time this decade?) When you're generating your pages programmatically it's really easy to separate content and presentation concerns in code but then combine them when finally rendering the page. You can use a normal programming language which is much clearer than CSS selectors. CSS was necessary in the days of hand-written HTML, but once you have a CMS you might as well use FONT and inline styles (possibly using CSS just with single classes, as a kind of "cache" to avoid repeating the same inline styling block everywhere).
- rubbingalcohol 11y ago
  What if you don't want to use a CMS?
  - iopq 11y ago
    Then just hand-code your layout logic
- antod 11y ago
  No thanks. FONT is listed as "obsolete, non conforming, not to be used" in the HTML5 spec. It couldn't do very much in terms of styling anyway. I would rather keep styles in a reusable cachable resource than bloat out the HTML. I would rather styling changes NOT turn into coding exercises, especially ones that cause a massive 'WTF?' for some future maintainer.
- olavk 11y ago
  Seriously, you think programatically transforming a document into presentational html is simpler than using a css selector?
  - lmm 11y ago
    I already build up my HTML programmatically from reusable components, following DRY (Don't you?). That means the markup for what it means to be e.g. a paragraph heading is already in one place. It's no trouble to style it there, with a font tag, and if I want to change it then I can change it there. And if I want to abstract out a particular piece of styling and reuse it across several components, it's just code, I factor it out the same way I would anything else. So yes, seriously, it's simpler than using a CSS selector.
0x4a42 11y ago
>You make it sound like table display was added after the failure of other layout methods. Not so - table display was there right from the beginning when CSS first added layout (CSS2 in 1998). Yes I mis-formuled it. >It was IEs failure to implement it for nearly a decade that meant nobody was aware of or could use it for many years. No it wasn't only IE, display table was also broken in Firefox and Opera. There were plenty of layout that you couldn't obtain in CSS but worked well with HTML tables.
nikatwork 11y ago
> Using tables for layout was the original hack. A simple and practical hack that worked (and continues to work) identically across all browsers without the need for elaborate edge case code. I'm curious, with the new libraries, can CSS yet do: <table width="90%" align="center"><tr valign="middle"><td width="20" valign="top">menu</td><td width="100">leftcol</td><td width="*">content</td></tr></table>
- akie 11y ago
  Ehm, yes?
  - nikatwork 11y ago
    Yeah, nah. Prove me wrong. I double dog dare you. Your answer must be cross and backwards compatible to count.
- olavk 11y ago
  The display:table css properties are exactly equivalent to the display model of html tables. They were specified in CSS2 which became a recommendation in 1998, which is 17 years ago (!). But due to the IE6 dominance and abandonment it took many years before this part of css was broadly supported by browsers, so developers had to either use html tables (even when not semantically appropriate) or use hacks like floats (which was not designed for this) to achieve a table-like layout. So the age of hack was due to browsers not supporting css, not to to deficiencies in css as such. That said, html tables never displayed identically across browsers before css. There were lots of corner cases e.g. with the interaction of fixed and flexible columns. Which is not really surprising since the display model for tables were never specified in the first place before css.
  - nikatwork 11y ago
    > display:table The delicious irony is that CSS had to emulate the old table model to overcome its default layout deficiencies. And IIRC it still can't natively handle mixing relative and fixed widths, and consistent vertical centering. > html tables never displayed identically My bread and butter used to be slicing photoshop comps into websites. My table layouts were pixel perfect on every browser without hacks. I do agree there were a few things that had to be accomodated using   and spacer gifs - but it was painless compared to elaborate and fragile CSS hacks. I shouldn't still care about this stuff - I moved to IOS dev thank goodness - but I still nuture a burning hatred of CSS years later :)

by antod 11y ago

lmm 11y ago

> Huh? Do you not remember/know what it was like to style webpages with FONT elements before CSS? CSS was a godsend. That was the separating content from presentation breakthrough. Have you tried using FONT recently? (Or indeed, any time this decade?) When you're generating your pages programmatically it's really easy to separate content and presentation concerns in code but then combine them when finally rendering the page. You can use a normal programming language which is much clearer than CSS selectors. CSS was necessary in the days of hand-written HTML, but once you have a CMS you might as well use FONT and inline styles (possibly using CSS just with single classes, as a kind of "cache" to avoid repeating the same inline styling block everywhere).

rubbingalcohol 11y ago
What if you don't want to use a CMS?
- iopq 11y ago
  Then just hand-code your layout logic
antod 11y ago
No thanks. FONT is listed as "obsolete, non conforming, not to be used" in the HTML5 spec. It couldn't do very much in terms of styling anyway. I would rather keep styles in a reusable cachable resource than bloat out the HTML. I would rather styling changes NOT turn into coding exercises, especially ones that cause a massive 'WTF?' for some future maintainer.
olavk 11y ago
Seriously, you think programatically transforming a document into presentational html is simpler than using a css selector?
- lmm 11y ago
  I already build up my HTML programmatically from reusable components, following DRY (Don't you?). That means the markup for what it means to be e.g. a paragraph heading is already in one place. It's no trouble to style it there, with a font tag, and if I want to change it then I can change it there. And if I want to abstract out a particular piece of styling and reuse it across several components, it's just code, I factor it out the same way I would anything else. So yes, seriously, it's simpler than using a CSS selector.

0x4a42 11y ago

>You make it sound like table display was added after the failure of other layout methods. Not so - table display was there right from the beginning when CSS first added layout (CSS2 in 1998). Yes I mis-formuled it. >It was IEs failure to implement it for nearly a decade that meant nobody was aware of or could use it for many years. No it wasn't only IE, display table was also broken in Firefox and Opera. There were plenty of layout that you couldn't obtain in CSS but worked well with HTML tables.

nikatwork 11y ago

> Using tables for layout was the original hack. A simple and practical hack that worked (and continues to work) identically across all browsers without the need for elaborate edge case code. I'm curious, with the new libraries, can CSS yet do: <table width="90%" align="center"><tr valign="middle"><td width="20" valign="top">menu</td><td width="100">leftcol</td><td width="*">content</td></tr></table>

akie 11y ago
Ehm, yes?
- nikatwork 11y ago
  Yeah, nah. Prove me wrong. I double dog dare you. Your answer must be cross and backwards compatible to count.
olavk 11y ago
The display:table css properties are exactly equivalent to the display model of html tables. They were specified in CSS2 which became a recommendation in 1998, which is 17 years ago (!). But due to the IE6 dominance and abandonment it took many years before this part of css was broadly supported by browsers, so developers had to either use html tables (even when not semantically appropriate) or use hacks like floats (which was not designed for this) to achieve a table-like layout. So the age of hack was due to browsers not supporting css, not to to deficiencies in css as such. That said, html tables never displayed identically across browsers before css. There were lots of corner cases e.g. with the interaction of fixed and flexible columns. Which is not really surprising since the display model for tables were never specified in the first place before css.
- nikatwork 11y ago
  > display:table The delicious irony is that CSS had to emulate the old table model to overcome its default layout deficiencies. And IIRC it still can't natively handle mixing relative and fixed widths, and consistent vertical centering. > html tables never displayed identically My bread and butter used to be slicing photoshop comps into websites. My table layouts were pixel perfect on every browser without hacks. I do agree there were a few things that had to be accomodated using   and spacer gifs - but it was painless compared to elaborate and fragile CSS hacks. I shouldn't still care about this stuff - I moved to IOS dev thank goodness - but I still nuture a burning hatred of CSS years later :)