CSS fans for some reason seem to think that its somehow better to have rendering/presentational properties in an ad-hoc language. Originally, plain markup attributes where designed to accomodate rendering properties, with type checking and all. The naive dichotomy established by putting "semantics" into markup and "presentational" properties into CSS was accidental, and it didn't make sense back then, nor does it now.
It's very easy to declaim one or another layout system as verbose or inconsistent. Can you suggest a mainstream layout system that offers this feature in a better manner?
I've used a lot of different layout frameworks over the years. Constraint systems are neat but hard to scale. All-code layout definitions are hard to read and reason about. Markup-level layout systems have their issues, but are easier for new programmers to learn and are the most instantly powerful out of the box. Most dewey-eyed replacements for production layout systems that I've encountered quickly founder when they try to cover all the corner cases that a mature framework would need to support. It's shockingly common to just end up with a kind of crappy version of bespoke CSS. Maybe with better syntax. Definitely with fewer features.
Alternately, if you're really complaining about the fact that you define styles in one file and markup in the other...I dunno, seems fine to me. I've seen systems that try to do all of that in one file (you can do it in HTML if you want to). They're not very readable. Splitting the styling from the basic structure is not a "clean" split, but it does simplify things enough to make your files much easier to scan. Sure, it doesn't live up to the old, pure idea about separating content from styling, but...who cares?
Here's the fundamental problem with separating styling from content: styling is content.
Layout matters. Layout carries semantics. Right here on HN is an example, where the comment reply chain is indicated with indentation. The meaning of a comment such as "I disagree" varies depending on what it is replying to and therefore where it is in the layout.
Other examples where layout is content: Captions for photos. An online store where each price describes the cost of whatever item it is next to. Sports box scores and other statistical presentations. Interviews in question-and-answer format where the layout indicates who is speaking.
That's why we've gotten our layout engines so mixed up with our content and markup, because layout is content. How would one devise an abstraction for layout for all of these? You would need to express the semantic relationships within the data, like "comment-replied-to" and "photo-with-caption" and so on. That sounds tantamount to a full implication of natural language processing.
Ugh, no. Layout is one way to express those relationships, but those relationships already exist in the HTML. This is important because different layouts can express the same relationship. I can put a caption below, above, beside, or over a photo and have viewers understand what is meant but which option is appropriate can depend on a number of factors that have nothing to do with the actual content or relationship being expressed. Blind people read the Web too. Having multiple layouts for different kinds and sizes of device is super useful. Being able to attach a caption to photo in HTML and express the exact spatial relationship later through CSS is much more versatile than hard baking layout into the document.
" You would need to express the semantic relationships within the data, like "comment-replied-to" and "photo-with-caption" and so on. That sounds tantamount to a full implication of natural language processing."
No you wouldn't and no it is not. It's dead simple:
Sure, it's dead simple for one particular semantic case already with its own specific definition in HTML. But you cherry-picked that from my examples. HTML doesn't express semantics for comment-replies or sports scores or so on. It has a generic notion of a hierarchical tree, to which CSS can apply layout (like indentation for HN comments), but that's not quite the same thing. Nothing in the HTML-CSS stack expresses general-purpose semantic relationships and we tend to make an inner-system-effect mess of it when we try.
I'm going to cherry-pick your examples again and point out that sports scores actually an ideal use case for actual tables because they are generally actual tabular data. But frankly I just disagree when you say that a hierarchical tree isn't a mechanism for expressing general-purpose semantic relationships, when it's at least as good as spatial positioning on a page. In fact, I can use classes with semantic names which make my meaning perfectly clear to anyone reading the source. It might be invisible with a bad or default stylesheet, but that's a relatively easily resolved problem.
> Right here on HN is an example, where the comment reply chain is indicated with indentation.
<div class=comment>
<span class=user>T-hawk</span>
Right here on HN is an example, where the comment reply chain is indicated with indentation.
<div class=replies>
<div class=comment>
<span class=user>random28345</span>
HTML is a tree of element nodes, the identity of the post being replied to can be determined by
the position of element in the tree
<div class=replies />
</div>
</div>
</div>
Good points, and I definitely don't have an answer re: best layout engine. But my critique wasn't aiming that high and was merely about placing CSS syntax outside markup.
CSS design genesis seems to be "ok we have this and that HTML presentation attribute; let's put it in an entirely new item-value format and separate HTML attributes/CSS properties syntactically".
From this arbitrary decision in language design the idea developed that markup attributes are part of the "semantic" content of a document, and not for styling, when, to the contrary, markup attributes were specifically designed for styling and other properties.
As a consequence, CSS has numerous redundancies, asymmetries, and absurdities such as CSS shapes, SVG properties you can style with CSS, the "content:" property, dogmatic and implementation-driven limitations for using presentational attributes on elements, etc.
Well, that's a bummer. I was hoping for a good example of nicely built websites with the older technologies. All my examples have disappeared into the ether as well.
Originally, it was not known that HTML pages would be so finely designed. It is not a naieve dichotomy, it is an attainable ideal that has had a very positive effect on the state of the web. We owe huge thanks to this movement that lead both to the demise of proprietary browser extensions (like flash) and to the awesome technologies in browsers today such as these CSS features, new HTML elements and transport protocols.
These things, while beneficial, don't owe their existence to CSS. Instead, introducing eg. CSS shapes or `content: ` (as two extreme examples) was the way of least resistance/guerilla tactics, as opposed to putting the functionality into SVG proper, or aligning the layout box model better with the DOM model, resp. Now what we're left with is a way overcomplicated mess for generations to clean up. There's a reason Mozilla spent the better part of the decade to come up with a new web renderer.
Don't get me wrong. I praise CSS for it has given designers ways to come up with new UI idioms (something I'm personally fascinated with). But I will say this has happened in spite of, rather than because of, CSS's qualities. Designers other than outright CSS nerds are struggling with CSS, and CSS is lacking badly from a basic maintainability perspective IMHO. CSS as a language puts an unnecessarily high cognitive burden on casual web developers by lacking a construct to capture the "intent" of a couple coordinated CSS rules; as a result, unless you're doing CSS every day, you're easily lost in your (or someone else's) CSS.
This isn't helped by seemingly arbitrary decisions as to what goes into CSS vs. HTML. For example, responsive images eg. the `picture` element became an HTML element, but arguably should have been subject to CSS media queries instead.
Which is kindof my initial point: that the HTML/CSS dichotomy is accidental and pointless from a language theory PoV.
I don't get what your point is with mentioning CSS shapes and `content`.
What I am talking about is CSS Zen Garden and the movement around it of frontend web developers professionalizing, rejecting table layouts and non-standard browser features.
This was enabled by CSS being barely powerful enough, and people creative enough to make it work. Eventually the movement won, non-IE browsers won market share and the way was paved for a more healthy evolutionary path of the web which has yielded these new features.
You look at CSS from a perspective that it's hard, as if there exists a solution somewhere that is easier. Before CSS there were simply the less powerful HTML features, the 'easier' but less semantic and non-adaptive tools like Flash or SVG, and the always present and expertise requiring method of simply imperatively coding the styling in WinForms or whatever.
This is not a tables-vs-CSS thing. Hey, I'm looking forward to servo and applaud Mozilla devs for it; but the reason they found it worthwile to invent an entire new programming language for implementing it certainly is telling about CSS's insane complexity.
GPU vendors invented an entirely new programming language for drawing triangles. Creating a new programming language to a solve a task doesn't mean that task is overly complex.
CSS has its problems (I'm the first to admit that), but on balance I think it's the best layout language that has been devised for documents.
I agree. Most of the HTML I write is to create structure for CSS to use. For example, a `div` is a container, but we put it on the content side.
What would have been better would be a flat map identifier -> binary (or string or whatever, your choice) as the content, and then "CSS" (quotes because it wouldn't be the CSS we know now) would declare the layout/look and would read the content map for insertion into placeholders declared in the "CSS". I've omitted programmable considerations cause this is a HN comment and not intended to be formal proposal. Not surprisingly, the web has kinda already shifted towards this, through the use of JSON APIs in JS.
The DOM is more than the proposed content map, because it also creates structure. I think the proposed idea is to basically create a structure without any content, then apply the content into that structure.
The current split is CSS is presentation while HTML is content + structure. Unless I'm misunderstanding, this proposal would separate content and structure. I'm not sure where presentation would go; you could certainly make a case for it being grouped with either.
There's also plenty of questions around what's content and what's structure and what's presentation. For instance, a section heading is potentially all three. I personally would probably go for grouping presentation with the content, and call structure "layout" to disambiguate it. A section heading is maybe structure, but it's definitely not layout.
I'd be curious if there are any existing example implementations that you think demonstrate this - I'm having a hard time wrapping my head around how flattening the structure would make things better.
A tree node structure for mapping content seems like it'd be the most efficient in all the ways I can imagine it.
I suppose I'm thinking of something like ASP.NET `ContentPlaceHolder`, where you create some layout and identify holes into which the content will be placed. Except that, unlike ASP.NET and HTML, only layout elements would be permitted? This would likely be an entirely new language -- thinking of it like HTML except without text doesn't really work. Think of it more like defining panes on the screen, and the content (like HTML) is injected into those defined panes.
How the panes are laid out could be accomplished through any number of methods. Absolute, flow, flex, grid, constraint solving... Or even parent panes using different methods for their sub-panes!
The point isn't to flatten the layout. The layout can be as complex as desired. The point is to remove content from the layout; a named mapping is just an easy way to associate content to layout panes for injection.
I feel like that's because XSLT introduced so much complexity that mere humans found it impossible to work with. I've searched in vain for a decent XSLT editor to help me; the ones I've tried have themselves been incredibly complex.
The idea was good, but the implementation is the stuff of nightmares.
> I feel like it all started to go downhill, fast, with the background gradient syntax
I'll take background in CSS over tiled 1px-wide gradient background images any day. The responsibilities being piled to CSS keep increasing, but I believe it is being done in good faith to at improve/formalize what people in the wild are already doing with hacks. Remember DHTML?
Oh I do, I do... and I agree that many of the things CSS does for you today are vastly better than the ad-hoc solutions we had in the past (if you ever have to create an HTML email - and thankfully I am able to outsource all of that sort of work to someone who actually takes a perverse pleasure in it - that's always a nice reminder of how silly HTML and CSS were in the late '90s before CSS was actually broadly usable).
But still... some of the syntax we have now, not to mention the sheer breadth of verbiage, is insane. CSS feels like it's been groaning under the weight of all of this guff for quite some time now, and adding new obscure units and funny things in square brackets isn't really going to improve matters.
> But still... some of the syntax we have now, not to mention the sheer breadth of verbiage, is insane
I had somehow missed that your gripe is with the syntax - I fully agree with you on that! CSS definitely feels kludgey, especially for larger/complex apps or sites. I now think of real CSS as a target that my build system generates as I mostly write in Sass or LESS. I find those superior to vanilla CSS in maintainability and composability.
I couldn't go back to vanilla CSS. Even with just its basic nesting features, SCSS enables a much more modular, compartmentalized, and parsable format, with a clear view of the overall hierarchy via imports
CSS would have been so simple if it had just adopted a plain LISP syntax. It is so difficult to memorise all the special and inconsistent syntax for every new thingamajig that browser vendors choose to introduce. Need to painfully look up a CSS reference if you haven't used that special rule in more than a week as it just doesn't seem to get retained (at-least for me) into long term memory.
I don't advocate using it, I just posted it for historical reference (actually I'm hesitating to post anything LISP here because that will easily derail a thread into becoming off-topic).
But what the snippet shows is how eg. the DOM is traversed explicitly, as opposed to CSS's multiple implicit measurement and layout passes over the DOM. CSS sure is more compact, but doesn't begin to reveal anything like the above snippet.
For one thing, if the rest of the representation of the document (the HTML and script part) was in the same language, maybe the CSS could be condensed with macros, or otherwise procedurally generated on the client side, all in the same syntax.
Some sort of uniform, same syntax for representing all of HTML, CSS and the browser-side scripting language would have been a good start instead of this hodge podge of different notations clumsily embedded in each other.
Lisp for just CSS with all else same: lukewarm idea.
CSS would be nothing more than built-in functions to traverse nodes and change attributes. The latter of which would have already existed by virtue of having a programmatic interface with the DOM structure, and the former would have been invented in some form to build on whatever primitives existed, a la jQuery.
Kinda makes me wish I lived in that alternate universe.
You say "css fans" like we have a choice in the matter :)
I am a fan of building websites, and css is the only way to achieve that. Yeah it sucks, but it's all we got. Grid spec solves a LOT of problems so even if the syntax is ugly, it's existence in the world is beautiful.
Sorry I didn't mean it to sound like that. I'm saying this to myself just as to everyone else (I'm using CSS all the time). The post was more an expression of dissatisfaction of CSS's ad-hoc nature, and in particular of how we've come to rationalize this HTML/CSS/JS trifecta after the fact as a sound and dogmatic edifice, when in reality it is just the result a 10 days code jam in 1996.
Yep. I think the right approach is to expose the browser's primitives and just have people write their own markup/layout/style languages if they want to. Keep HTML/CSS as a fall-back and because a lot of work has gone into optimizing their performance, but start the long-needed move to opening up mainstream browsers on a lower level. Also, of course, leave JS as a fall-back but introduce a lower-level language. Re-implement HTML/CSS/JS on top of the new exposed primitives in order to expedite moving to the new standards. So you'll be able to use either original, optimized HTML/CSS/JS, or the new HTML/CSS/JS that has been re-implemented on top of the new exposed primitives, or just new stuff built on those primitives.
I agree plus the "there's more than one way to do it" motto is dangerous. There is a reason everyone dropped Perl. It was self obfuscating. And these constructs are so opaque that they don't even know the name of their own 'fr' unit.
IMO, HTML/CSS have always been missing a middle layer. It really should be:
- HTML for pure information
- Something else (template/view?) for layout and (possibly) forms
- CSS for styling in terms of fonts, colors, etc.
This would easily handle layouts, but it would also have some NLS-like capabilities where you could switch from one way of presenting information to another without changing the actual docment.
This was the role that XSL tried to fill but it never caught on. Part of the reason is that it's still very dependent on what information is in the source document; if it's not there you can't lay it out, and if you don't need it then it was a big waste of database time. This ends up reversing the dependency, so the contents of your "pure information" layer end up depending on what your "layout" layer needs, and in the end the difference between the layers is only nominal.
XSL was not envisioned as a middle layer between HTML and CSS. Plus, it was a quintessential design by committee, trying to cater to a bunch of conflicting use cases with no overall vision or conceptual elegance.
If we all had something like Display Postscript, this layout thingamajig would be delegated to libraries, and we wouldn't have to ask the browser deities to bestow new gifts upon us. Good adaptive layout would be closer to a new version of jquery and less Windows XP Service Pack 51.0.2b.
(We also would have more sites that looked liked late 90s Flash, but then again, we're moving that direction anyway, just with more effort and convoluted design)
If we're lucky, we might get exactly that with Houdini. It's a proposed spec that -- if implemented -- will allow programmatic control of the browser's styling and layout process. Check it: https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m...
> Are we finally at the tipping point where everything you build, will be built with JS from soup to nuts?
That doesn't sound implausible. In fact, it sounds like a great idea. As long as performance and security don't suffer, more and more browser internals should be opened up to JS developers so that we don't have to wait for all browsers vendors to implement specific features before we get to use them.
While that would probably work fine for display and layout, but it doesn't work so well with the semantic document model that the web is built on. For example accessibility would suffer greatly unless every "jquery" (using your analogy) out there were to implement its own accessibility. (That's not to say things are absolutely peachy wrt. accessibility these days, but they'd get a lot worse if everybody had to implement their own.)
I don't know if developers even care about semantic markup anymore, just have your 5 meg of JavaScript squirt out a bundle of divs and to hell with accessibility.
Just render a png file, server side. The only way to ensure pixel perfect layout, and it's even going to use less bandwidth than most JS frameworks these days.
This is a joke, albeit with many web pages I get the suspicion that they'd indeed be better off serving a PNG or PDF file instead. Not to mention that PNG renders much, much faster than javascript orgies.
Haha, that's too light, I think :) I'm planning on having articles on how to do things that you're currently using libraries for with vanilla JS, though.
I think there's a distinction to be made between "web pages" and "web apps". Web pages like news articles and blog posts fit well in the semantic document model of HTML. Web apps extend past this model -- something like DPS would make more sense for them.
>For example, is Facebook a web page or a web app?
Is this a trick question? :) On the scale from pages to apps, where one end is someone's static geocities page about their cats and the other end is, let's say, github: Facebook is definitely an app.
It's kind of a trick question in that my point is that it is a more of a scale than a binary opposition, and that the ability to mix document-like parts with program-like parts is what made the web so incredibly successful.
Exactly. Also happens when people talk about would-be DSL that they made on top of existing language and mention that you can always fallback to using it. But that's the whole point of the domain-specific language that it is not a generic purpose one!
Sometimes less is more and constraints are good, there are things that you shouldn't shoehorn.
> this layout thingamajig would be delegated to libraries
This is actually happening. The major vendor libraries are working on API's to give JS library authors the ability to hook into the browser layout process and define their own layout mechanisms
This is excellent. And with the fast pace of browsers, and the improved habits of users (or automatic updates), it should be available for 95%+ of users within a year (It's in the current Safari Technology Preview, so Safari should get it with the next macOS point update).
This is also a good moment to remind people that you don't need Bootstrap and the like as much as you used to. Grids were 90% or the reason people started using these frameworks, and CSS (already with flexbox I'd argue, but definitely with grids) has caught up and is now easier to use and more flexible than any framework was.
It's also time to reconsider the atrocity that is class="col_xs_12". I've never undestood why people would lynch anyone using style="..." but happily littered their code with those grid classes. With the invention of sass at the latest, actual semantic class names should have once again become the only acceptable best practice. With html5, there's also a range of semantic tags[0], and using them improves both code readability, as well as allowing all sorts of new ideas in clients (not just browsers, but also text-to-speech and other accessabiity tools, or spiders, or brosers on new device classes)
Since you included the <time> element in your list, something I wish browsers provided is a way to automatically format time elements based on user's preferences. I just want to provide the value in ISO8601, and let the browser take care of it.
Luckily, Intl.DateTimeFormat [0] seems to finally allow a reasonable degree of i18n in the browser. If you can live with the limited Safari availability, of course.
>something I wish browsers provided is a way to automatically format time elements based on user's preferences
That'd quickly get awkward. I live in Norway where the default format is DD/MM as opposed to MM/DD used in the US. This works fine for us in general, we know to expect the first one when we read something in Norwegian and the second one when we read something in English. If a computer formatted a date based on a default preference and considering that most websites probably don't specify the lang attribute, I think it'd get messy quickly. Also, different date formats will lead to different sentence structures making sense. For example you might say "ever since 9/11 something something" but you wouldn't naturally write "ever since 11. September 2001 something something" (you'd write "ever since the 11th of September 2001 something something") and likewise you also wouldn't naturally write "ever since 2001-09-11T08:46:40-0400 something something".
I'm, for one, completely fine with the last example.
On more serious note, such functionality is meant for formatting freestanding dates/times (eg. contents of table cell labeled "last modified") not dates in flowing text.
Sometimes you need to show times and dates in a timezone different from the local browser tz (for example you have customers around the globe and want to see relevant timestamps in their local tz).
What you suggest would make that difficult if not impossible. Already it is unnecessarily hard, as JS Date object automatically uses local tz and cannot be coerced otherwise.
> it should be available for 95%+ of users within a year
only if you don't have enterprise customers. Those will continue to run IE11 for the foreseeable future as IE11 will remain supported in Windows 10 until 2025.
While Microsoft is pushing Edge as an IE replacement, Edge is still lacking features and looks too different from IE for companies to feel comfortable pushing it to their users without retraining them.
> only if you don't have enterprise customers. Those will continue to run IE11 for the foreseeable future as IE11 will remain supported in Windows 10 until 2025.
We're still supporting IE9... It was a glorious day when we could finally give up on IE8.
I once sent feedback citing security as a moral hazard that someone would get fired over, as the reason IE8 needed to be ditched.
Chrome showed up a few months later, I'm guessing once they'd tested group policies and install scripts (which I think google makes very easy these days). No idea if it was because of me but it was certainly welcome
It's not a problem in this particular case, as CSS Grid was introduced by Microsoft, in IE10. So, more or less, four years ago.
I chuckle when Google announces that Chrome will support this feature as the next big thing, while it was clear years ago that this approach is much better than flexbox. But, I'm glad it finally lands in all browsers.
It's not about vendor prefixes; MS IE implements a very old version of the CSS Grid Spec. But I guess MS will update the implementation now that CSS Grid is Candidate Recomendation. Actually, Rossen Atanassov (Microsoft) is one of the current authors of the spec.
My caveat is that currently @supports is far more heavily supported than grid layout which is not fully available in any current browser. As usual, only IE is the major holdout for @supports and most likely we'll be doing special things for IE until it totally dies out anyway.
If you are speaking of people manually inserting style attributes into their code then there's a point for the resistance to that. It's horrible in comparison to classes.
If you are speaking of JS framework dumping code into the style attribute on the fly then there's a smaller point for the resistance to that. There are features of CSS that are not available through the style attribute. Plus, it's just plain inefficient.
Makes you wonder why HN won't budge with those <table> tags in the source code. One day I hope to see "Table layouts are back with <table> tags" and the HN programmers would have saved themselves so much work.
Flexibility is what allowed webpages to be "responsive" before media-queries even existed, and semantics is what allows accessibility, search engines, and other html parsing tools ("readability" in Firefox and Safari, ...) to function better.
The only advantage it has is that it's old and predictable. That's why it's still used to format emails for instance, it's reliable and works on most supports.
I mean, it is semantic, if you want a table. One of the most baffling things to me is people trying to use not-tables when they're literally trying to display tabular data.
I laughed when I had to make a minor change to an old web application, and found our tabular, scientific data was being displayed in a series of DIV and SPAN elements, with the CSS table styles applied to them.
I changed it to a real TABLE, since that's far more accessible -- most users can cut and paste into their spreadsheet, and a screen reader might give options to avoid reading out all the data.
Another time, a web developer changed all my <i>Homo sapiens</i> to <em>Homo sapiens</em>.
To be perfectly semantically correct (which he was no doubt attempting, as I is a purely visual/appearance tag, and EM connotes some meaning), he should have used
<i> is the correct element, so <i lang="la"> if you wish. A taxonomic designation is the first example given in the specification:
"The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts."
Well, I should specify I meant that in most cases using <em> is preferred over <i> in terms of the traditional sense of what <i> was used for in the past. These days both have their specific uses, but in most cases one would more likely to use <em>.
For example, further down the page:
"Authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term."
As an element it used to be the way to italicize text, to emphasize that text, before CSS. These days it has had a semantic reason for its existence applied which is a slight variation of its original purpose under the HTML4 spec.
Sometimes it's worth it. A real pain with tables is that you can't have it be positioned relatively. So if you want to display an absolutely positioned tooltip next to a row it becomes a gigantic pain and i'd argue impossible — or extremely hacky — without using JS.
Those are not semantic because divs have no inherent semantic meaning, while using tables for layouts is not semantic because tables have an inherent semantic meaning that's incorrectly applied to a layout.
Exactly this. How are DIVs more semantic than TABLE? And who is reading the source? Your developers and a web spider. The web spider doesn't care (I wrote one and getting it to parse DIV content and TABLE content wasn't much effort)
As far as I am aware no spider is looking at the DIV and gathering semantic information from it. Sure, it may look at the TABLE and initially assume it has tabular data in it, but a tiny bit of logic fixes that.
> And who is reading the source? Your developers and a web spider.
Or blind people using a screenreader?
DIVs aren't entirely semantic, but table is semantically wrong for how it's being used. It'd be like if I asked you to "get me the pencil off that thingie" and pointed at a chair with a pencil on it. As opposed to "get me the pencil off that table" while pointing at the same chair with a pencil on it.
Screen readers and spiders do look at tables as semantic content though. Tables are simply the wrong idea.
That said, CSS layout should have been based on tables/grids from the get go, ie. specify a set of blocks as rows and cells, with colspan and rowspan. It took way too long to get to this point.
This argument was over a decade ago and it's because it's a nightmare to work in tag soup.
I still have to deal with tables for layout on mail templates, bloody Outlook, and that extra 2 layers of tag nesting you have to do on every level quickly turns the code into an incomprehensible mess, even with careful indentation.
And if you're not very careful with indentation it turns into an utter nightmare.
It's not. There were a few arguments against "table layout", some of which apply to hn as well IMNHO. Added tags without semantic value (just as your div-soup above also illustrates). Layout speed (in reality not much of an issue now - and also an issue with deeply nested tags with complex layout).
Both are fixed in modern html5 which moves (back) towards simple, semantic, document layout (html-body-article-heading-etc).
With flex-box layout it's also quite easy to have the article/main content come first (possibly preceded by a header) - followed by sidebars and footer -- all as their own "top-level" boxes/containers.
In a classic table layout, there's an extra top level element in addition to "body" - the surrounding table.
And finally table layout is generally verbose and messy for other types of content than tabular data.
I look forward to trying modern flexbox and grid layouts. I have not had the privilege (?) to work with either yet; our customers are not necessarily on the bleeding edge of browser releases so I have to stay a little behind the curve. Hence, a lot of div soup and ridiculous indentation levels.
Honestly, for what I'm doing (a pretty complex web app with an almost desktop-style GUI with a bunch of buttons, text inputs and checkboxes everywhere) a Bootstrap-style div layout gets at least as verbose and messy as a table layout would. I especially hate having to always do HTML comments with class/id names after every </div> so I know what closes what when I'm near the bottom of the file. At least with tables you get </td></tr></table> instead of </div></div></div>.
But of course a div layout is at least partially semantic and mobile/small screen friendly.
In a classic table layout, there's an extra top level element in addition to "body" - the surrounding table.
In practice, any bog-standard div layout today has a <div class="container"> at top level which contains nothing but other divs and sets size and positioning for the whole page. This is roughly equal to a <table>, no?
> for what I'm doing (a pretty complex web app with an almost desktop-style GUI with a bunch of buttons, text inputs and checkboxes everywhere)
Right. There's different contexts between an application an a (hyper)text document.
What's good semantic markup for one, will generally be bad for the other.
It's admirable (and desirable) to strive for adaptive layout and accessibility in applications - but they need a different type of framework than documents made for browsers. The browsers straddle this divide rather uncomfortably - being in part hypertext document browsers, and in part virtual machines for running general applications.
Approaches like web components[1] might help us move toward a standardised reality for "applications that happen to run in the browser", while css and html are still (more and more anachronistically) (hypertext) document markup and layout tools.
If you want to make a Web page/site (like alistapart.com) that's great. Swim with the current and draw inspiration from stuff like css zen garden[2]. With flex box, you can burn[4] most of the old complicated grid layout stuff, and comparatively easily make great sites.
That doesn't really help if you're a "front-end developer" making "apps" though. Even the few that make an effort to color within the lines are still fighting the browsers and the standard, trying to fit a code-on-demand app into a REST shoe[3].
[3] https://news.ycombinator.com/item?id=13500635
(I've said it before - the true tragedy isn't that too few read Fielding's thesis and never understood REST - It's that so many ignore that he covered a lot of other architectures that are more suitable for many applications than REST is)
The "container" is common, but typically not needed.
Sometimes it's a redundant stand-in for "body > .content" or similar (eg: divs dropped directly in body) - and is prevalent because developers don't understand and care about css selectors (or there's that one person on the team that doesn't -- don't get me wrong -- I realize the real world is full of real co-workers, and making a change isn't always easy).
And partially it can be an artifact of abusing floats for "grid layout". Most typically though, the "container div" just ends up being a completely redundant extra "body" element.
It's not, clearly. Modern "grid-based layout" frameworks are just the next generation of table-driven web layouts, and they're frequently shoehorned into webpages in ways that hearken back to the olden days before CSS was invented.
<div class="container"> is one of my least favorite things to see in HTML, in particular. No shit it's a container; all HTML tags are containers. HTML5 introduced all these wonderful semantic elements precisely so that we don't have to pollute HyperText documents with thousands of divs.
Also, that "text-center" class drives me to drink :)
That's a problem for sure but last week I looked into creating a family tree with the basics of HTML and CSS and the following nested lists seems to be the best solution according to forums. Now, try to add into these nested lists some siblings(the people kind) and some new branches as you discover people in census reports from 100 years ago. Now add in a newborn. Is this the best we can do? (apologies, but I haven't the time to tab this correctly, link to Codepen at the end):
Lifted from there, but with broken indentation :) In fact with correct indentation, you see that this goes down 4 levels (instead of the seeming 14 the current rendering seems to indicate). That's significantly better, and once you get used to the structures of lists it's actually relatively straightforward to understand a list like that. Moreover, it's trivial for a computer to understand a list like that as nested lists of lists.
Side note: the top-level div isn't really necessary; you can just apply the `tree` class directly to the `ul` with a small tweak or two to the CSS.
Absolutely, but try researching a family tree and then implementing it using that model and see how quickly you get lost in the nested list structure. The, as I said in another comment, try adding a child born after you started the lists, ie, before the first UL. Then add a divorce and a new spouse and see how easy that is to logically display the relationship.
To illustrate how HTML so ill suited to this structure, I had another look at the problem and found Treant, because yes, the easiest to do this on the Web and maintain it is to write an entire API.
It is, but it also illustrates the problem of drawing a simple diagram for the web. It was in response to user mattmanser's illustration of diabolical nested tables and user einar's nested divs. HTML is problematic for anything complex. I suppose the best way to represent the data is to not use HTML at all, but instead use an image (SVG? for scalabilty) or a big PDF that opens a new tab?
I googled for a solution that I could add to and maintain myself and this was what The Internet threw up as the best solution, but it is far from good.
I would say that best for drawing diagrams in html pages would be to use a DSL like plantuml or dot and some javascript library to transform it into a SVG image.
You can mitigate this about 50% by switching from pure Bootstrap to something like Bootstrap-Sass and inheriting selected rules on something semantic like <article>.
(But then you'll hit a wall as you try to deal with the containers and subcontainers.)
No there is, try using a screen reader, it reads out the header in front of every cell, its really hard to understand vs a semantic document with css styling for people not living with disability.
Accessibility is dead, alas.
It is extremely sad to watch what is happening with the web right now. All the good initiatives are being forgotten in the chase for the latest fad. "You were so excited that you could that you've forgotten to think if you should" can describe a lot of movement in this space.
Even without the accessibility in mind, go to http://csszengarden.com/ and try to replicate that with tables. Barely ten years have passed and the idea that not everything on the web is an app and sometimes it is nice to have ability to change the presentation without even touching the markup.
Nothing. But tables are for tabular data. Laying out a page using a table to divide it up and make it look pretty (or in lots of cases, lay it out so it performs some kind of sales based task) doesn't make much sense. Hence the preferred CSS route, even if the markup is just as verbose (as mentioned in this thread).
Web apps aside [sigh], if one was to disable CSS (and thus all the blocks making it look pretty), the page should still make sense. An H1 as the main header, copy in paragraphs, headers dividing up the content, blockquotes, navigation in lists - and tabular data in tables (etc, etc).
It doesn't always work like that in practice, but that's the aim.
And webpages are a document presentation format. If jamming applications into documents made the web an application platform, than jamming grid layouts into tables made them a grid widget.
Calling a SPA a "page" is a larger and more ridiculous lie than calling the table tag a grid layout widget. Anyone still committed to the table tag lie should move all their apps out of the browser today.
Web developers can work around the table tag, but not the fact they're jamming apps into documents. So one of these lies is taken more seriously than the other.
I'm on a crap connection, and it's not unusual for the styling content to not make it (whether it's CSS or javascript). The ones that follow these principles remain usable, the ones that don't, don't.
It is broken. Every single comment is announced (in Voiceover at least) with “Row x of y. Column 1 of 1”. With proper markup you could either avoid that entirely, or announce a correct relationship with ARIA attributes.
Potentially, although it’s not VoiceOver but what the browser exposes as an accessible table. Chrome and Firefox have horrible hand-coded algorithms to determine what should be a data table or not:
I'm pretty familiar with Flex but I simply don't understand and the diagram doesn't help. What does 'rhythm' mean in terms of layout?
Taking a guess (which I shouldn't be), I can make https://developers.google.com/web/updates/images/2017/01/css... with flex, but I'd have header and rest-of-page as columns, then have rest-of-page as a row with nav and content, then content as a column with content and footer. I think the article is saying:
> CSS grid means I can do it all at once rather than continually having to make rows and columns.
But it doesn't actually say that anywhere (and again I'm guessing).
Right. With flex you can create elements whose height is equivalent to the elements to the left and right, or whose width is equivalent to the elements above and below, but not both at the same time.
Yes but that just uses it in the commonly understood sense of repetition. And you can very obviously achieve vertical and horizontal repetition using flex. Either they have a more specific meaning or they're trying to say something that's not quite apparent.
rhythm, or perhaps repetition is one of the core tenants of graphic design. Once you start looking for it, you'll see it lots of places. It's kind of like the wilhelm scream sound effect. It's not hard to find strong examples, but most stuff is divided into a natural harmonic, 1/3 1/4 or 1/5. movie posters are an easy example.
Anywho, google helps a bit, [1]. So, yes, you're absolutely right. it's just quite a bit more widespread than typography
Except anyone with accessibility requirements, no? As far as I know tables are horrible for anyone with a screen reader. Can you annotate tables somehow to work for accessibility purposes?
The problem with screen readers is summarized "Screen readers assume the content inside a table is tabular". Are divs better just because they are undefined? It seems to me that the problem would more easily be solved by adding some attributes to skip tabular treatment or to add captions, rather than ditching tables altogether. Table elements like <caption> could even be used to identify and access parts of the UI pages.
> Screen readers assume the content inside a table is tabular
I'm curious to hear from screen reader users. I recall that the gap between "what web developers think screen readers do" and "what screen readers do" has always been sizable.
Windows based screen readers (more sophisticated than Mac's VoiceOver), let the users treat only data tables as tables and ignore layout tables.
Also users can adjust announcement of only column headers, only row headers, both or none while navigating through the data table.
Using tables for layout is so commonplace, I think most screenreader makers basically gave up and don't treat a table as a table unless it includes headers (<th>). Of course people who choose to use tables for layout also skip using more semantic elements, have a lot less flexibility to make layout changes (because their choices are expressed in HTML instead of CSS), and have a lot more trouble making their designs responsive.
Most of the raised in the accepted answer to that SO question can in fact be applied equally well to div/css layouts as they're practiced in the wild. CSS Zen Garden is awesome and all, but I'm yet to see a fronted professional who does things that way.
For instance, arguments about ease of change (single place to modify) are irrelevant, because in both cases the single place to modify is the code that renders the layout.
Also, personally I'm not buying the whole separation of layout from content thing. It's an implicitly understood fact people seem reluctant to admit out loud: form is a part of content too! These are not orthogonal things.
The (theoretical) issue here is that a "table" has a certain semantic meaning ("a container for tabular data"), and that using a table for something outside that semantic meaning can introduce confusion, be it for fellow programmers (including your future self!) or for those who are interpreting your page in weird ways (robots, people using screen readers, etc.).
In the few times I actually bother with frontend "design", my goal is usually for my actual HTML to contain as few hints about how said HTML should be displayed as possible, and to let CSS handle the display specifics. This usually means that I don't touch `div` and I don't touch `class` unless absolutely necessary. CSS provides more than enough selectors for "absolutely necessary" to be false in the vast majority of cases.
Of course, this ain't for everyone. Some people stick with tables. Some people use div/class for everything. Some people just treat Javascript like the new Postscript and generate pages on the fly. You do you. However, these tend to have their share of downsides, among them being a tendency to deviate strongly from the semantics of HyperText documents.
Tables ought to be responsive anyway, though, even if that just means "add a horizontal scrollbar if the screen is below a certain size". I'm pretty sure that's already possible through CSS, but it involves overriding a lot of the work the browser does for you, and unless the data encapsulated by that table is indeed meant to be tabular, you're probably better off with divs (or better yet, with more specific HTML elements).
OK, so tables have semantics of tabular data. But the shit ton of semantically meaningless divs that are sprinkled around the structure to provide hooks for CSS declarations in the "usual" style of doing layouts is somehow better? It's much larger, much less readable, much less obvious, and breaks the "separation of content and layout" rule even stronger than tables. So again, why is this better?
And yes, I've been in this space for years, and this is one of the better example why I feel most of the webdev world is cargo-cult advice that's internally inconsistent if you look at it carefully.
Using an element that lacks semantics (<div>) is always better than mis-using an element that has semantics (<tr>, <td>). Why would you need to use more divs than table elements to achieve the same visual layout? I feel like you're not comparing apples to apples. What's so readable and obvious about tables nested 3-4 levels deep?
Anyone who really thinks about how CSS can be used is also going to be against div-itis but it's still less-bad than tables for layout. They're also going to be against excessive use of classes and class names that connote style (class="red") rather than purpose (class="alert").
"But the shit ton of semantically meaningless divs that are sprinkled around the structure to provide hooks for CSS declarations in the 'usual' style of doing layouts is somehow better?"
No, it's not, as I thought I made plainly clear in my comment. HTML5 introduced a smorgasbord of new tags to avoid that.
You're right that a lot of modern web development fashion is silly, but there are alternatives besides just sticking to tables for everything.
Great! If it ain't broke, don't fix it. If you don't have users with screen readers and don't have any issues with search engines parsing your web page, then you do you.
w.r.t. avoiding div and class, how do you make sense of the element <-> rule mapping? There's definitely enough specificity to make such a mapping, but I just end up with a big bowl of spaghetti.
EDIT: I guess I'm mostly talking about class, HTML5 semantic elements takes over much of the utility of divs in this usecase.
I usually just base it on whether or not an element is a direct child of some other element. For example, the header of the page itself will usually have a different style than the header of an article or aside or something, so I can use CSS' child selectors for that.
This often does indeed result in a bowl of spaghetti, but said bowl is in CSS rather than HTML. Things like SASS/SCSS help tremendously.
I remember when I switched away from tables, it was due to a performance issue(back in 2008). I could have the div based layout render about 700ms faster. I never went back to full table layout, but I never ditched tables for layout purposes entirely.
Of course this is anecdotal, but I wonder wether it'd be just easier for browsers to just improve table performance.
There was a particularly extreme trend back then (well - probably more during the 90s) where websites were mainly big Photoshop images sliced up into a lot of nested tables of dizzying complexity. Screen readers off course struggled with that as it was rather hard to determine the order of the content. I'm not sure how much trouble they have with more minimal use of tables for presentation.
> where websites were mainly big Photoshop images sliced up into a lot of nested tables of dizzying complexity
Replace "nested tables" with "nested divs", and this is exactly how web development today still looks, at least if your company employs a designer. Slicing is still a thing.
I seriously wish it'd survived and been enhanced. Much AJAX in practice is used to replicate the effect of <frame>s, but slower, buggier, and with more battery drain.
I agree. My understanding was that it had 2 major problems. 1) you could load other sites or 3rd party content in a frame which caused confusion - browsers should not have allowed that. 2) search engines had problems with them - that's not my problem, they should have gotten smarter. May have been helped by eliminating the first problem.
I've used grid layout a fair amount in the last 6 months or so. It's very exciting but it can feel quite daunting; the new mechanics and new grammar do not make the spec an easy read.
Fortunately, I've found that it's quite easy to get to grips with - especially if you have been around long enough to have sliced designs into table layouts!
Now for a rather shameless plug for my own article on the subject (I hope with a closer to real world example):
The biggest game-changer to me seems to be the last example, with `grid-template-areas`. I could probably explain this in a matter of minutes (as opposed to flexbox).
Edge had better get support this year or I'll consider placing a warning on my website to all Edge users that the layout won't work. I'm over supporting lagging browsers.
This doesn't really fix much - if the idea is to continue to use pixel-based positioning. I've got devices with a range of dot-pitches (surface 4 pro, external older monitor, cellphone) - with various physical screen sizes -- A "150px sidebar" doesn't work the same across these devices - and more importantly, for a low-resolution 24" screen I'd probably want a similar 3" side-bar as for a "retina"-resolution 24" screen?
But at least we seem to be moving forward from the abuse of [ed:float]-layouts for grid-systems...
There is no requirement that the units be pixel-based. You can and should still use em/rem/vh/vw/vmin/vmax depending on your needs, along with media queries.
I am wondering if this layout engine also has issues with half-pixel placements? With Flexbox, if you position an element in a way that it lands on a half-pixel, it becomes blurry.
I've been waiting for the WPF/UWP/XAML grid to come to the web for years and am delighted to see that it's finally happening. Best layout container I've ever used.
Does this include subgrids? As I understand, these are necessary for handling some basic use cases[1], but browser vendors were refusing to implement them?
I'm really excited for this. I've been using pure flexbox layouts for a while now, but it still has one major problem, in that your HTML structure still contains layout and positioning information.
Everything is either a column or a row, so in the example layout in the link, you'd need two container divs. Whereas the grid example can be done without any.
It was 2003 on a day like this when I was doing table layout design for one of my websites. Somehow it feels like it holds up well. http://dnalib.sourceforge.net/
If styles are not for layouting, what are they for? Even font-sizes are layouting, no? You propose just scrapping CSS?
The nice thing about CSS is that you can ignore it in "article view" or mobile. You can't ignore HTML in the same way. Don't you see the value in splitting semantic and styling components of a page?
Both Android (ConstraintLayout) and iOS (Auto Layout) use Cassowary. Why not just implement this with CSS as well so we can use the same layout tech for every platform?
My first experience as a young kid in the 90's doing web design was taking the msn.com home page (I thought it looked nice back then) looking at the source, and learning. Turns out layout was done using tables. Cool, putting it into practice though it was really really hard.
The primary force you were always fighting against was inconsistency between browsers. You might get everything perfect in IE, then load it in Netscape and there's huge gaps between your awesome solid colored navigation side blocks. Then making it adjust to the size of the browser was another struggle. After a while I learned to just make everything fixed size. Then content inside continues to nest you have to keep subdividing, and things would start to get out of whack. You adjust one block here, and the side suddenly has these weird gaps. A large part of it was almost certainly the fact that I was about 13 or 14 years old at the time, and I learned only by looking at example code... but It was really difficult.
flexbox doesn't really seem to suffer from the problems that made table layout really suck. I use it mostly indirectly by using the library Bulma, but it's really wonderful.
The primary force you were always fighting against was inconsistency between browsers.
None of the things you're complaining about are table's fault, though.
In the 90s browser vendors didn't target cross-functionality nearly as much as they do now. They could have easily made tables work even better with a modicum of intent instead of plunging us into 2 decades (!!!) of unintelligible nested div hacks that still after all that time weren't up to the task until some arbitrary number of years from today when this feature is actually widespread enough to deploy.
This is one of the things that frustrated me about the web world. Stuff that you could do in 2000 with real UI kits is finally making its way to the browser. Java/Swing and Qt could do this years ago, and more elegantly.
I don't suppose there is any momentum for starting over with something not based on a simple word-processing model, but with a real UI foundation.
IMhumbleO the redundancy is at issue, because CSS is simply nested key pairs and so say that HTML should handle only text and tagged divisions in text with IDs and classes, and leave all the semantics up to the sheets. Folks who point out that style is semantic are correct, so it's redundant to allow all these structural tags in HTML that are intended to give semantic formatting to text, and instead CSS should be reliably the only source of semantic formatting. Therefore, only one HTML element and everything else attributes or key pairs in the sheets.
Also I find js2css works well to keep component style in place with MVC web components.
(This comment is a response to the multiple inevitable discussions on the merits of HTML/CSS and what is bad or good and how it all should be different, great stuff, thanks for it)
Because <table> indicates that it contains tabular data, and implies lots of things about the content that it contains that would be misleading when using table-based layout.
And display: table, which uses CSS to make things look the same, without implying anything about the content, wasn't supported by Microsoft, back when they they were a) the only browser that mattered, and b) trying to hold back the web to protect their monopolies, so people worked around their damage by using the tools that happened to already be available in IE (see also the invention of AJAX)
Once Microsoft caught up, people who understand CSS started using display: table whenever it helped. People who didn't kept complaining that you couldn't just use <table>.
Well the issue of semantics was not exactly solved by turning everything to <div>s. It's still a mess, but a different mess. I would even say it's bad to have display:table-cell because it's reduntant.
If you're using a <div> just so you can lay things out visually, then its lack of semantics is appropriate. Presumably you use artices, headers, paragraphs, asides, links, img, lists etc. within those non-semantic "container" divs to convey the semantics.
I'm not claiming it's perfect, but it's like government data being released as a CSV vs a PDF with a scan of paper document. Structured data is better for lots of reasons, even if it's only minimally structured.
Yes, please. Putting 'styles' in charge of layout was always madness.
Every time I hit the wrong link because the browser engine finally figured out it should move things around one more time just that millisecond, my soul gets blackened by the wish to strangle someone.
I wonder if there is a name for this rage. I did what you did but I did it twice in a row and one of them was an ad that crashed safari. If someone had teleported me into the dev's office during that 10 second period, it would have been an absolute slaughter house.
We had a simpler standard in 1995. It was called tables and it did this exceptionally well and more importantly was easy enough for even amateurs to understand. And then armchair demagogues decided that markup should no longer be used for markup, setting web layout back decades and creating the field of web designers whose major accomplishment was understanding stupid div hacks.
It's pretty amazing, isn't it, the type of infinitely useless brain loops we can get stuck in. Especially when we fail to take a step back and ask the question "Is this really the right way?".
In 1995 I was creating a layout engine for a UI manager (personal project). It was simpler to use and I had better primitives. Had I known then that in 2017 we will still discuss about layouts, I would have face palmed so hard.
In my opinion CSS's worst sin is that it does not include basic experience from other programming languages: variables and name scoping. It's a minefield of namespace collisions and superfluous repetitions.
Every time this subject comes up, someone trots out the old canard that tables messed with screen readers and therefore were irretrievably bad.
Or they say from the highest and mightiest and ivoryest pedestal "separation of semantics and display, thus spaketh the lord" pretending, of course, that modern websites look and behave just like documents when that's demonstrably false, and that tables are therefore irretrievably bad.
And instead you now have, 20 years later (TWENTY! YEARS!) something that only now works as well for layout.
Adding "not-data" and navigation directives to tables to aid screen readers and separate semantics would not have taken 20 years.
And now you'll have to wait another 5 years before this new, "just as good as tables!" feature is sufficiently widespread to actually deploy it without a polyfill shim.
But please tell me more about what I do or don't know.
The problem is so hard because it's not decomposed in a right way. It would be much simpler if there were 1) a pure drawing language like PostScript, very well researched and developed, 2) content, described purely in its own terms, and 3) a way to transform that content so it can be rendered by (1) on screen. This was the idea behind XML+XSLT, as far as I perceive it. CSS is kind of similar to XSLT in its pattern matching capabilities, but is both more complicated and way less powerful.
To compare things: Knuth's TeX has very few basic primitives: boxes, lists, and glue. And it produces very sophisticated layouts. CSS has a wagon of stuff and still cannot produce very basic things. I sometimes remember the old Ventura Publisher software (in 1990 I worked with version 3 of it). It was somewhat similar to the current HTML+CSS: you could have the same source text, but separate style files that would render it very differently for different purposes. 27 years ago.
What CSS really needs is a canonical standard, and a tool for generating CSS compatible styles for ALL browsers down to IE8. Until then, I'm more than happy to skip these new layout techniques.
