3 ms·

Am I alone in thinking that the way we're doing brochures as layering multiple complicated ad-hoc layout constraint languages on top of a markup language that i

Am I alone in thinking that the way we're doing brochures as layering multiple complicated ad-hoc layout constraint languages on top of a markup language that itself hasn't much changed in 20 years is absurd? What is really gained by such a powerful, yet highly idiosyncratic construct that not only can insert and/or delete content elements, but also rearrange the order in which they were specified in the input document in the first place, weighed against the complexity this brings to authors and implementers? Is the HTML+CSS stack victim of self-imposed, arbitrary principles of separation of structure and presentation? I can see the practical use of grids and subgrids etc., but who really authors an HTML document with the expectation that it should render as a traditional hierarchical and flow-based layout, and a grid-based layout at the same time? Translated to the domain of programming languages, CSS is to HTML what eg. ten times the amount of LOCs of annotations are to regular Java code. Why not just use a responsive table layout based on revised HTML tables when, clearly, the author's intent is to layout page elements in a tabular fashion?

hdfbdtbcdg 7y ago
We often have a different order in desktop and mobile 'versions' of the responsive HTML site.
- tannhaeuser 7y ago
  Yes, I know that, and am doing it, too, on my sites. Still, squeezing everything into a single HTML page, then applying CSS (and JS) fu to arbitrarily rearrange, add and drop content doesn't seem rational when website design processes draw upfront desktop, mobile, etc. breakpoints and sketches. Rather, CSS complexity seems a manifestation of organizational boundaries (eg. W3C specifying CSS and WHATWG specifying HTML) to me. Or even a post facto rationalization of the road not taken with HTML. Eg. almost all responsive designs used today can be achieved much more easily using adaptive techniques where there is a device/breakpoint-specific page layout for desktop, mobile, and maybe tablet, resp., with the page template documents pulling in content wherever it fits. It's just that HTML lacks mechanisms for page composition such as SGML's and XML's entity references. Arguably, responsive grids are not only more complex than needed, they're also inefficient wrt. network utilization, as every device has to receive every bit of content, just to hide it away when it doesn't fit the layout. Of course, large sites use JavaScript and visibility events to pull content on-demand anyway. I'm not pissing on W3C's (fantasai et al) work here. CSS is very much a work in progress as we all discover new UI idioms for digital media, and I'm a sucker for it. I just think CSS grids and flexbox is bordering on intellectual brain wankery, when the solution could be achieved much, much simpler, and in a way that doesn't send newbies into a world of cluelessness, doesn't question our ability to consume our own digital media in the future due to over-complexity, and retains the qualities of the web as a medium for simple self-publishing even for a layman.
  - goto11 7y ago
    If you want to embed styling/layout information directly in the HTML you can do that using the "style"-attribute.
yoz-y 7y ago
The main idea, I think is still to keep the data and representation separate, which is advantageous for accessibility, computer representability and alternate representations (text mode browsers). We're kind of halfway there but there is still a lot of layout going on in the HTML "because we can"
stupidcar 7y ago
Arguments like this are basically a huge "fuck you" to anybody with internationalisation and accessibility needs. Yes, if all you care about are able-bodied Western users consuming content on standard devices, then you can get away with just baking your style / layout into the markup like your someone hacking away back in the 90s. The moment you need to move beyond that, you'll start to introduce methods for abstracting style and layout that, eventually, will lead you to reinventing something pretty similar to CSS.
- dsego 7y ago
  Why do you think a different way would be less accessible or couldn't be made accessible by engines that parse the new markup?
- tannhaeuser 7y ago
  Even if you acknowledge a separation of content/structure and presentation, the layering of new ad-hoc languages (CSS) eg. a different syntactic construct, onto markup does not follow from that premise at all. Markup attributes were introduced exactly for the purpose of holding rendering properties, eg. everything that isn't directly presented to the viewer. The ideal of "semantic markup" was only proposed once CSS was established, as a way to rationalize this ad-hoc separation after the fact. Now with CSS we have a million DSLs without type checking, huge cognitive deficits, and every single problem imaginable when a new language is bolted on top of another. All because HTML had to be backward-compatible, and evolution of HTML as a markup language was held back due to unrelated organizational problems. This is not a good outcome when SGML has all the power you want for rigorously developing document formats on a very long timescale. Edit: Look at the comments in this thread. They're mostly about "how flexbox works" and how to apply particular CSS grid features. Nobody actually authors content with the intent of structure/presentation separation.
_the_inflator 7y ago
Context: Tables were used for static content, then came transparent 1px gif, then JavaScript to create a hover effect for buttons. Enter CSS. Today's content is very different. Today complex applications that were 20 years ago bound to the desktop are (re-) created using Web technology. This seems overkill for some apps like landingpages, however complex apps benefit from CSS that reacts to its context. Otherwise you would be very JavaScript heavy on those layout things and that is pretty much the essence: CSS3/4 pretty much did what JavaScript layout tools did but native.
- tannhaeuser 7y ago
  Ok, but you still need tons of JavaScript for webapps, and the trend has been to generate inline styles using JavaScript, JSX/React etc. anyway. Not sure introducing the complexity for webapps, with the content-oriented web as collateral damage, was worth it.
kowdermeister 7y ago
> Am I alone in thinking that the way we're doing brochures as layering multiple complicated ad-hoc layout constraint languages on top of a markup language that itself hasn't much changed in 20 years is absurd? Probably you are not alone, but I'm sure you've just haven't spent enough time building complex or niche things in the browser. For simple brochure sites, CSS3's full feature set is an overkill. Use cases on the other hand are near infinite and there are thousands of developers out there needing unique combination of CSS solutions that you can't think of. Rearranging content for example is a great way to reduce server rendering logic: just generate a bunch of <article> elements and the client will know how to display it. Even the user can make choices based on zoom levels what layout they prefer. Even with JavaScript support it's nice to offload rendering logic to be handled by the browser which renders it directly on the GPU. If you do layout with JS, then there will be a function call doing expensive calculation every 16ms, that not ideal and CSS3 solved it for us in many cases.

hdfbdtbcdg 7y ago

We often have a different order in desktop and mobile 'versions' of the responsive HTML site.

tannhaeuser 7y ago
Yes, I know that, and am doing it, too, on my sites. Still, squeezing everything into a single HTML page, then applying CSS (and JS) fu to arbitrarily rearrange, add and drop content doesn't seem rational when website design processes draw upfront desktop, mobile, etc. breakpoints and sketches. Rather, CSS complexity seems a manifestation of organizational boundaries (eg. W3C specifying CSS and WHATWG specifying HTML) to me. Or even a post facto rationalization of the road not taken with HTML. Eg. almost all responsive designs used today can be achieved much more easily using adaptive techniques where there is a device/breakpoint-specific page layout for desktop, mobile, and maybe tablet, resp., with the page template documents pulling in content wherever it fits. It's just that HTML lacks mechanisms for page composition such as SGML's and XML's entity references. Arguably, responsive grids are not only more complex than needed, they're also inefficient wrt. network utilization, as every device has to receive every bit of content, just to hide it away when it doesn't fit the layout. Of course, large sites use JavaScript and visibility events to pull content on-demand anyway. I'm not pissing on W3C's (fantasai et al) work here. CSS is very much a work in progress as we all discover new UI idioms for digital media, and I'm a sucker for it. I just think CSS grids and flexbox is bordering on intellectual brain wankery, when the solution could be achieved much, much simpler, and in a way that doesn't send newbies into a world of cluelessness, doesn't question our ability to consume our own digital media in the future due to over-complexity, and retains the qualities of the web as a medium for simple self-publishing even for a layman.
- goto11 7y ago
  If you want to embed styling/layout information directly in the HTML you can do that using the "style"-attribute.

yoz-y 7y ago

The main idea, I think is still to keep the data and representation separate, which is advantageous for accessibility, computer representability and alternate representations (text mode browsers). We're kind of halfway there but there is still a lot of layout going on in the HTML "because we can"

stupidcar 7y ago

Arguments like this are basically a huge "fuck you" to anybody with internationalisation and accessibility needs. Yes, if all you care about are able-bodied Western users consuming content on standard devices, then you can get away with just baking your style / layout into the markup like your someone hacking away back in the 90s. The moment you need to move beyond that, you'll start to introduce methods for abstracting style and layout that, eventually, will lead you to reinventing something pretty similar to CSS.

dsego 7y ago
Why do you think a different way would be less accessible or couldn't be made accessible by engines that parse the new markup?
tannhaeuser 7y ago
Even if you acknowledge a separation of content/structure and presentation, the layering of new ad-hoc languages (CSS) eg. a different syntactic construct, onto markup does not follow from that premise at all. Markup attributes were introduced exactly for the purpose of holding rendering properties, eg. everything that isn't directly presented to the viewer. The ideal of "semantic markup" was only proposed once CSS was established, as a way to rationalize this ad-hoc separation after the fact. Now with CSS we have a million DSLs without type checking, huge cognitive deficits, and every single problem imaginable when a new language is bolted on top of another. All because HTML had to be backward-compatible, and evolution of HTML as a markup language was held back due to unrelated organizational problems. This is not a good outcome when SGML has all the power you want for rigorously developing document formats on a very long timescale. Edit: Look at the comments in this thread. They're mostly about "how flexbox works" and how to apply particular CSS grid features. Nobody actually authors content with the intent of structure/presentation separation.

_the_inflator 7y ago

Context: Tables were used for static content, then came transparent 1px gif, then JavaScript to create a hover effect for buttons. Enter CSS. Today's content is very different. Today complex applications that were 20 years ago bound to the desktop are (re-) created using Web technology. This seems overkill for some apps like landingpages, however complex apps benefit from CSS that reacts to its context. Otherwise you would be very JavaScript heavy on those layout things and that is pretty much the essence: CSS3/4 pretty much did what JavaScript layout tools did but native.

tannhaeuser 7y ago
Ok, but you still need tons of JavaScript for webapps, and the trend has been to generate inline styles using JavaScript, JSX/React etc. anyway. Not sure introducing the complexity for webapps, with the content-oriented web as collateral damage, was worth it.

kowdermeister 7y ago

> Am I alone in thinking that the way we're doing brochures as layering multiple complicated ad-hoc layout constraint languages on top of a markup language that itself hasn't much changed in 20 years is absurd? Probably you are not alone, but I'm sure you've just haven't spent enough time building complex or niche things in the browser. For simple brochure sites, CSS3's full feature set is an overkill. Use cases on the other hand are near infinite and there are thousands of developers out there needing unique combination of CSS solutions that you can't think of. Rearranging content for example is a great way to reduce server rendering logic: just generate a bunch of <article> elements and the client will know how to display it. Even the user can make choices based on zoom levels what layout they prefer. Even with JavaScript support it's nice to offload rendering logic to be handled by the browser which renders it directly on the GPU. If you do layout with JS, then there will be a function call doing expensive calculation every 16ms, that not ideal and CSS3 solved it for us in many cases.