[HN Gopher] CSS Zen Garden
___________________________________________________________________
CSS Zen Garden
Author : eniz
Score : 339 points
Date : 2020-03-19 13:02 UTC (9 hours ago)
(HTM) web link (www.csszengarden.com)
(TXT) w3m dump (www.csszengarden.com)
| coreyp_1 wrote:
| Honestly, these designs are so refreshing. There is no place for
| ads. No popups asking to subscribe to their newsletter. No
| breaking because I have Javascript disabled.
|
| Looking through some of the designs made me happy... and a bit
| nostalgic. :)
| mythz wrote:
| CSS Zen Garden was a treasure back in the day, one of the most
| inspirational CSS sites showing the power and flexibility that
| can be achieved with CSS over semantic HTML.
|
| I still remember the original design from Dave Shea fondly:
|
| http://www.csszengarden.com/001/
| jklinger410 wrote:
| Yes! This brings back memories! This site inspired me to learn
| CSS. I was doing free Xanga themes in high school, lol.
| klenwell wrote:
| One of my quixotic personal projects was reproducing this
| design for my Myspace profile.
|
| Ha, I found the blog I was keeping:
|
| http://myspacecivilized.blogspot.com/2006/09/css-moshi-garde...
|
| It includes a small screenshot.
| sbergot wrote:
| I used to love it but know I can't help to notice that there is
| no max width and the font is way too small.
| GavinAnderegg wrote:
| I remember this blowing my <table>-addled brain in 2003. This
| site was what convinced me to really dig into CSS, and not just
| use a few inline styles as hacks. This also opened my mind to
| JavaScript at the same time (as I looked into "DHTML"). It was a
| pretty different web back then!
| schoen wrote:
| I'm amused at how I glanced at your comment and my mind sort of
| yelled "hey, that opening tag never gets closed! that's going
| to invalidate everyone else's comments below by making them
| part of that element!".
|
| Maybe I'll say </table> here just in case. :-)
| martin-adams wrote:
| This is the same for me. When you came from a table based
| design approach, it was hard to know how powerful CSS was. This
| was to prove that an help developers overcome their fear. I
| loved this site!
| TiredGuy wrote:
| Separation of html and css can still be a useful paradigm and
| does not have to be incompatible with separating your code into
| components.
|
| For medium-sized projects, I have found it useful to have general
| (or "base" and "cosmetic" a la MCSS) styling in a central place
| with all my variables. For my components, I strive to balance the
| "structure-" and "container-" -like (similar to OOCS) styling
| they need while not trying to make them so general that they are
| over-engineered. To that end, I am comfortable enough using the
| central variables within my components and even some central
| classes, recognizing that when I do want to re-use my components
| across projects there is occasionally ad-hoc
| refactoring/customization.
|
| Also, Css in JS is only one way of building components. You can
| keep your component-specific css separate from the rest without
| using JS.
| greggturkington wrote:
| Why is this the top post of the front page? Is there a front-end
| dev that didn't see this when they were 15? Sure it's a nice
| demonstration of CSS but...
| Tade0 wrote:
| At the age of fifteen I didn't yet even have an internet
| connection.
| suprfsat wrote:
| Ugh I can't believe not everybody was born in 1988 and learning
| CSS at age 15
| carapace wrote:
| https://www.xkcd.com/1053/
|
| > I try not to make fun of people for admitting they don't know
| things. Because for each thing "everyone knows" by the time
| they're adults, every day there are, on average, 10,000 people
| in the US hearing about it for the first time. Fraction who
| have heard of it at birth = 0% Fraction who have heard of it by
| 30 ~= 100% US birth rate ~= 4,000,000 year Number hearing about
| it for the first time ~= 10,000 day If I make fun of people, I
| train them not to tell me when they have those moments. And I
| miss out on the fun. Person #1, about to have a messy fun time:
| "Diet coke and mentos thing"? What's that? Person #2, in a
| delightfully pro-knowledge mood: Oh man! come on, we're going
| to the grocery store. Person #1: Why? Person #2: You're one of
| today's lucky 10,000. {{Title text: Saying 'what kind of an
| idiot doesn't know about the Yellowstone supervolcano' is so
| much more boring than telling someone about the Yellowstone
| supervolcano for the first time.}}
| kodt wrote:
| People who were older than 15 when it launched?
| dsego wrote:
| This gets posted every few months and the HN crowd loves it.
| Somehow all the technical geniuses here are still mesmerized by
| CSS from 20 years ago. Learning all the nuances of the Rust
| borrow checker doesn't leave any room for much else, except for
| HTML tables, that stuff got embedded too deep. Set a reminder,
| it's an easy way to reap the sweet karma.
| jonfw wrote:
| Many of us are either young, not front end devs, or both!
| saagarjha wrote:
| According to Wikipedia, when this launched I was about four
| years old. It's new to me!
| talkingtab wrote:
| My immediate response, as someone who does not know css that well
| and is trying to learn, is to open developer tools, choose
| responsive design mode and then iPhone 6. Only looking at the top
| four, none of these are that great. Where is a way to navigate?
| They don't seem to be using vw which I expected. Are there good
| examples that work well with responsive, provide navigation and
| don't use horizontal scrolling.
| randomdude402 wrote:
| The site predates smartphones by maybe five years. Mobile
| friendly wasn't a thing yet.
| dullroar wrote:
| Still love the retro theater design - so fun:
| http://www.csszengarden.com/202/
| m23khan wrote:
| Hehe, I remember impressing my Web Development Professor 11-12
| years ago by using CSS designs based off this website.
|
| I am still impressed by the beauty of some of the designs.
| cromulent wrote:
| Ah so many memories. This was my favorite:
|
| http://www.csszengarden.com/099/
|
| Dave Shea mentioned that it was no longer relevant back in 2013.
|
| https://www.awwwards.com/why-the-web-doesn-t-need-another-cs...
| teddyh wrote:
| "This video is unavailable."
| dbtc wrote:
| The zenist of css designs for this web page is:
|
| body { max-width: 800px; }
|
| Done. Now go do nothing.
| Tade0 wrote:
| All those who repainted their pages in dark mode should take
| lessons from "Steel".
|
| Not all fonts are readable when displayed white-on-black, and
| some seem to forget about that.
|
| Also this is something that's being slowly undone by ideas like
| Styled Components and Tailwind. My take is that those two are a
| step back.
| TekMol wrote:
| Would be nice if the designs would display the date when they
| were created.
|
| Digging around in the source code and on the sites of the
| designers, it seems they have stopped adding entries around 2013.
|
| I wonder why.
| maverick74 wrote:
| aaaahhh good old and amazing CSS Zen Garden!!!
| olivermarks wrote:
| this era broke me as a web designer. Dom walking etc. i need to
| get back into current trends so this discussion is useful.
| cousin_it wrote:
| Encoding page layout in text is a bad idea, and CSS is a bad
| implementation of that idea.
|
| What could be better, you ask? Open up Google Slides. You can
| make a slide that looks the way you want it. The learning curve
| is nonexistent. Then you can share it online and it will look
| okay to anyone on any size screen. There's no reason why building
| websites should be a hundred times harder than that.
| bmn__ wrote:
| This does not come close to the Web's design goals.
| uk_programmer wrote:
| I really like CSS Zen Garden and it had a profound impact of how
| I think about front-end work. I see a lot of back-end developers
| trying to force the markup and their styling to conform to what
| they want.
|
| If you understand how the document flows, separate your CSS from
| your markup, write clean and valid markup and keep everything as
| minimal as possible. There is really a "zen" like element to it
| which I think is kinda lost today.
|
| However when it comes to code I am a minimalist and tend to do as
| much as possible with Vanilla JS.
| crad wrote:
| I recently brought this up with my team. As an "old-school" web
| developer, I buy in to the whole CSS as design thing, while the
| front-end engineers @ work switched to using styled react
| components. As we look to make substantive design changes, now we
| have multiple places to make the CSS changes, only now it's the
| SASS project and all of the React components / projects. I must
| be missing something about how hip and cool styled components
| are, but they'll never be as cool as the CSS Zen Garden :)
| exclipy wrote:
| I also started coding when CSS Zen Garden was the best thing
| ever but sorry, CSS in JS is better.
|
| With classes and a separate stylesheets, there are no
| statically analyzable connections between them. You typo a
| class name? Too bad. You're no longer using that class
| anywhere? No compiler will tell you it's dead code. You want to
| increase the padding in this one place? There's no way to be
| confident what else it will affect.
|
| And all the "benefits" that stylesheets tout are also offered
| by components. No one is adding <font> tags on all on all of
| their headings. With components, you just set the font once on
| the heading component.
| dntrkv wrote:
| Same, started doing frontend back in the CSS Zen Garden days,
| and CSS-in-JS has been a godsend. Having the tooling do
| static analysis on your components and their corresponding
| styles has made life so much easier. Reference a color that
| doesn't exist? Error. Reference a component that doesn't
| exist? Error. etc...
|
| Also, in response to GP: CSS-in-JS does not take away the
| ability to roll out global CSS changes without updating
| individual components. It actually gives you more tools to
| easily share styling across components.
| e12e wrote:
| > No one is adding <font> tags on all on all of their
| headings.
|
| Ok? I'm not sure the official documentation is encouraging
| factoring out things like font styles to a central place, so
| you for example easily change the look from serif to sans, or
| adopt a signature font?
|
| Am I missing something?
|
| https://reactnative.dev/docs/text
| exclipy wrote:
| The original argument for CSS from 20 years ago was:
|
| Instead of saying: `<font size="20"><b>Some
| heading</b></font>` 100 times, CSS proponents would tell
| you to just write `<h2>Some heading</h2>` 100 times with
| styles defined separately as `h2 { font-size: 20pt; font-
| weight: bold; }` so if you need to change it to 22pt, you
| can make one change instead of 100.
|
| Components give the same benefit. Just write `<Heading>Some
| Heading</Heading>` 100 times with the definition `function
| Heading(props) { return <h2 style={{fontSize: 20pt;
| fontWeight: bold}}>{props.children}</h2>; }`. If you need
| to update it to 22pt, it's still just one change; not 100.
|
| * replace `style=` syntax with your CSS-in-JS framework of
| choice for better performance.
| e12e wrote:
| Right, but in the example linked from the official docs,
| the css/style is in the component. So you need to change
| all your comp, rather than the body font style?
|
| (obviously you can mix and match, it just seems that the
| official documentation/sentiment is towards self
| contained components that don't support page/application
| level theming/styling)
| exclipy wrote:
| You're subscribing to the notion that it's _good_ to put
| all your styles for all components in one file. Since the
| invention of variables, that is wrong.
|
| Theming is no longer a valid argument for centralized
| style sheets. If you declare one central set of variables
| for, eg., colours or fonts, then you can still do
| "application level theming" (changing those colours/fonts
| in one place), without having to mash all the styles for
| every element in the entire app together in one file.
|
| The advantage of using JS variables to represent this is
| you can easily ask your IDE to "find all references" to
| that variable. It's much easier for humans than reasoning
| about CSS inheritance and the cascade.
| earthboundkid wrote:
| I think different parts of the page need to be treated
| differently.
|
| In a typical webpage, you'll have lots of "chrome" (menubars,
| sidebars, footers, logos, etc.) and "content well" of some
| sort. For the content well, the content is probably going to
| come in through some sort of CMS with Rich Text Editor that can
| handle bold, italics, links, headers, blockquotes, etc. by
| outputting plain HTML.
|
| The content well should be designed to work without classes on
| the items. It should be able to take the <a href> and <em> tags
| and make it look correct. The tags themselves have a semantic
| meaning, and you can imagine this same content surviving
| through multiple redesigns of the site.
|
| But for the chrome HTML, the tags are only there as part of the
| current design. When you redesign the site, there's no reason
| to expect the same tags to be used. It may or may not be
| possible depending on the goals of the redesign, but either
| way, it's not a goal, the way that reusing the content well
| HTML is.
|
| I think this is what leads to the disconnect. If you're new
| school web dev making CSS-in-JS components or whatever, you're
| expecting your components to be thrown out when a new design
| comes along in five years. If you're designing the content
| well, you expect the HTML to live essentially forever or at
| least as long as the business.
| djsumdog wrote:
| I use to own this physical book!!! .. years and years ago (I
| think around 2008 or 2009). I cite it as my inspiration for a lot
| of my early designs:
|
| https://battlepenguin.com/tech/a-history-of-personal-and-pro...
|
| It might seem dated, but the ideas of using images and flowing
| layout shaped that era, and the simplicity can still be applied
| today (although we can make it look a lot better and cleaner
| thanks to CSS grid, flexboxes and other new tech that's now
| available in most browsers).
|
| There's a lot of good nostalgia here if you go through their
| older designs.
| resters wrote:
| A story like this being at the top of HN is how we know covid-19
| is serious.
| adamwathan wrote:
| This approach is extremely seductive because on the surface it
| sounds so "pure" and "clean" but the reality is that on large
| projects it leads to some of the most horrific, hard to maintain
| CSS you'll ever see, no matter how hard you try to keep things in
| good shape. CSS is just inherently more difficult to maintain
| than HTML, and choosing a workflow that encourages editing CSS
| instead of HTML just makes things harder and harder over time.
|
| Choosing an approach where CSS is treated like a third-party
| dependency that is _consumed_ by your HTML ends up being much
| more practical, maintainable, and scalable because editing and
| maintaining HTML is _easy_ -- every time you change a class on an
| HTML element your changes are local and predictable.
|
| Always thought this article by Nicolas Gallagher did the best job
| arguing this point:
|
| http://nicolasgallagher.com/about-html-semantics-front-end-a...
| embit wrote:
| Agreed. I was a big proponent of the csszengarden way of
| developing sites. Then during the development of my latest site
| [0], I decided to use bootstrap for styling. And now I am
| really liking it. Makes things much easier, at least for me.
| [0] https://embit.ca
| wtetzner wrote:
| I think the approach can work really well for web pages that
| are meant to be documents, but no so well for web applications.
| omegote wrote:
| I cannot believe it's been 15 years, literally half my life,
| since I got my design accepted at CSSZenGarden:
| http://www.csszengarden.com/185/
|
| Incredible, I had never thought of how long it's been...
| mikeg8 wrote:
| I remember seeing your design back around 2009 when I was
| taking my first web "publishing" courses! What a trip down
| memory lane
| wiremine wrote:
| Wow, what a blast from the past!! This was a great source of
| inspiration back in the day.
|
| If you're not familiar with the project, I suggest checking out
| the Wikipedia article:
|
| https://en.wikipedia.org/wiki/CSS_Zen_Garden
| swyx wrote:
| oh nice to see this on the web again! i recently remade this with
| modern web technologies - Svelte, Monaco, and serverless
| functions to pull things from GitHub Gists:
| https://github.com/sw-yx/svelte-zen-garden
| dang wrote:
| Related from 2013: https://news.ycombinator.com/item?id=6076163
|
| https://news.ycombinator.com/item?id=5669601
|
| A bit from 2009: https://news.ycombinator.com/item?id=811468
| piinbinary wrote:
| Seeing this page brings back memories:
| http://www.csszengarden.com/001/
|
| I'm happy that this is still online.
| fiatjaf wrote:
| Some time ago I made https://github.com/fiatjaf/classless, a
| framework for making themes for simple websites (like blogs)
| using the same basic HTML structure.
|
| The idea is: you write HTML that conforms to the structure, then
| you can reuse any of the themes by just including a CSS file (and
| sometimes a JS file) in your <head>.
|
| Turns out I wasn't the best person indicated to push this, as my
| design skills weren't marvelous, but I still think it was a good
| idea. There are 17 themes available, mostly ported from other
| places. A playground where you can see the themes (and test your
| own, if you are feeling like building one) is available at
| https://classless.alhur.es/
| RyanOD wrote:
| Dave Shea (CSS Zen Garden), Eric Meyer, Jeffrey Zeldman (A List
| Apart), Jeremy Keith (DOM Scripting), and others who escape me
| provided the foundation for the CS classes I taught 15 years ago.
| Thanks guys!
| antirez wrote:
| Good memories from 10 years ago (the site looks practically
| unchanged since then). Incredibly how the frontend nonsense of
| recent years allowed us to go backward. Same result but slower
| and more complex without any good reason.
| ChrisMarshallNY wrote:
| I've always enjoyed this site. I see that they post updates here
| fairly regularly.
| ralusek wrote:
| I always thought this was funny. This was the embodiment of the
| original CSS philosophy, which was to "label your html elements
| semantically with what they ARE, and then worry about styling
| those in the CSS." The whole point was to get anything style
| related out of the HTML altogether, the HTML would just be
| semantic/content related.
|
| But then Bootstrap and other CSS libraries came out, and
| completely inverted the philosophy back to what HTML originally
| looked like pre-CSS, which is that you had all of these rules you
| could place directly in the HTML that would directly control how
| the element was styled. In CSS Zen era you could look at my HTML
| and have no idea how I intended it to LOOK, whereas in the
| Bootstrap era you would look at my HTML and see "row" and "col-
| sm-3" and know exactly what I was going for visually.
|
| Now people just make components and will maybe use style
| variables/tokens. Just funny how things change.
| leeoniya wrote:
| > whereas in the Bootstrap era you would look at my HTML and
| see "row" and "col-sm-3" and know exactly what I was going for
| visually.
|
| say what you will about utility classes, but the grid classes
| are absolutely necessary, especially when many elements might
| need specific behavior for different screen sizes and must
| interact gracefully. without the grid classes your css would be
| an absolute nightmare of a thousand often-nonsensical
| "semantic" classnames littered with a crapload of fragile media
| queries.
| nickelcitymario wrote:
| This is no longer true with CSS Grids. The grids are all
| defined in the CSS itself, allowing us to once again separate
| style and content, as well as allowing us to define custom
| templates for different screen sizes (rather than simply
| force them into a single-column, left-to-right order).
|
| I know this is still barely being used, but it's clearly the
| better way to go.
| nitely wrote:
| Sass removes most of the cruft. I made a semantic flex grid
| many years ago, and the result was a lot more clean than
| using utilities, even in the css side [0]. This was before
| CSS Grid Layout was widely supported, nowadays you can use
| plain CSS grids and get similar results.
|
| [0] https://github.com/nitely/semantic-flex-grid/
| penneyd wrote:
| <handgrenade>tables handle grids quite nicely</handgrenade>
| rimliu wrote:
| I think this reversal is sad, actually. Even sadder, that one
| of the driving reasons was people just giving up on CSS ("too
| complex/weird") and going for spaghetti and a wall approach.
| Then trying to use tools to plug the knowledge hole.
| gridlockd wrote:
| Even with the most powerful CSS methods, you simply cannot
| completely separate the structure of the HTML from the
| layouting.
|
| It's better to give up on this ideal right from the beginning
| than to build something that ends up getting complicated with
| work-arounds and edge-cases.
| sbergot wrote:
| It is only sad when you have not worked on a medium sized
| website/webapp.
|
| For a small document like css zen garden where the goal is to
| produce a diversity of design without changing the html? css
| selectors are perfect. But how often is that the goal of the
| UI team?
|
| The goal of a ui team is to have a consistent ui that is easy
| to change. Components helps with consistency. It also helps
| in separation of concerns: you can have someone writing the
| component library and someone else using it.
|
| The goal of a ui team is also to minimise the amount of ui
| bugs, and the amount of ui code. If you let people go wild
| with css selectors, you end up with badly scoped class names
| and very painful integration phases where selectors breaks
| the ui across the whole application. When fixing bugs people
| are too afraid to remove anything because it means that they
| have to test a huge scope.
|
| The trend I see is not spaguetti (except in places that don't
| care). It is the use of a very restricted type of selector:
| .class_name. Some people use css BEM or functional css and
| write those names themselves. Some people use a css in js
| library that generates them.
|
| We have started adopting css BEM two years ago and now we are
| considering using a css in js library. I had to manage a css
| library update recently and 90% of the issues were in place
| where people didn't have this kind of methodologies.
| z3t4 wrote:
| Just like with programming you have to limit scope. And
| avoid using global scope. Its fine to have a "private" base
| style for components. The power of CSS however is that
| users can overrule those styles. Its however important to
| organize the css in a cascade and not have rules for the
| same element spread out all over the place with !important
| everywhere.
| echelon wrote:
| You used to see CSS frequently used by hobbyists making
| personal websites. As a result, you'd see a lot of posts
| about what cool stuff they could create, their opinions on
| how to structure things, semantics, etc.
|
| Now these same people are mostly doing it for the paycheck.
| And there are a lot of new people doing it as well. In fact,
| dozens or hundreds of authors may be maintaining the same
| stylesheets. You just have to get your changes in.
|
| People get older, begin to care less. The web has surrendered
| to commercial platforms. It's not as exciting.
| klodolph wrote:
| Honestly I say the reason it's sad is because of the idea
| that CSS promised something it couldn't deliver. The sad part
| isn't that people gave up on CSS, the sad part is that people
| believed it could work this way in the first place.
|
| Writing CSS stylesheets by hand is like writing HTML pages by
| hand. It just doesn't scale, and you run into a million tiny
| problems every time you change something in a medium size
| project. So for HTML we use templates and components. For
| CSS, we want the CSS for a component right next to the
| component itself in our VS Code window, so that actual humans
| have good insight into what styles will affect a particular
| component. The alternative--keeping the CSS separate--
| requires its own set of tooling to plug the holes, like all
| those fancy web developer tools built into browsers these
| days.
| wtetzner wrote:
| I always thought the approach of returning XML from your
| web server and having it refer to an XSLT stylesheet made
| the most sense. Unfortunately, XSLT is a very verbose and
| clunky style language. If it had been a better language, I
| think it could have been a good solution.
| klodolph wrote:
| I think component systems like React are the closest we
| have to achieving that dream. This is why Vue, React,
| Angular etc. all look _something_ like writing your own
| tags and then implementing them in terms of, eventually,
| standard HTML tags.
|
| You can even swap out the web browser front-end, to an
| extent. I know that some mobile apps are done this way.
| jguffey wrote:
| I've long thought about this too. Eventually I've come to the
| conclusion that CSS Zen Garden was more about "Hey you can do
| all of this with pure CSS" than it was "You should do it this
| way". At the time that I discovered Zen Garden, CSS was in it's
| more early, primitive days. As a front-end developer, it was
| easy to say "I can't achieve this design without changing the
| HTML Structure". Zen Garden showed us that this was just an
| excuse, (just about) any design could be achieved without a
| requirement to fundamentally change the HTML of the page. It
| was eye-opening to see some of the ways theme authors
| rearranged content, broke down those box boundaries, and used
| design tricks that stretched the limits of CSS and HTML in that
| era.
|
| It was awfully inspiring, and I think the point was never -
| "this is the way you should encode pages" it was more about
| taking excuses away.
| regularfry wrote:
| The point absolutely was "this is the way you should encode
| pages", or rather "this is what is possible _if_ you encode
| pages this way ". The purpose of Zen Garden was to highlight
| the separation between style and content; that separation is
| why we've got CSS as a separate language to HTML in the first
| place.
| jtms wrote:
| No, it was absolutely about the way you should "encode" your
| pages. I would choose the word "markup" here instead as
| that's what it is, but it was 100% a recommendation on the
| benefits of separation between markup and presentation.
| gridlockd wrote:
| Semantic HTML has never been something that businesses asked
| for. HTML has never been a good format for structured data.
|
| Things have simply moved towards what's actually manageable in
| a production environment, not what some ivory tower designer
| thought was good practice.
| jacurtis wrote:
| The ultimate anti-pattern of this philosophy is Tailwind.css
| (the newest, "coolest" css framework). Not trying to hate on
| it, but I find it ironic that the whole point of Tailwind is
| that you can basically style your entire website within the
| HTML, without needing to customize it with CSS.
|
| For someone who learned CSS during the CSS Zen Garden era where
| we were told to only use the HTML document for structure and
| never style, it makes Tailwind cringe-worthy.
|
| Yes, I know lots of people customize it and stuff, but the idea
| still stands that 95% of styles are done within the HTML
| document through tens of thousands of ultra-specific css
| classes which basically just tweak a single css property.
| Ayesh wrote:
| Totally agree with this. It's faster to prototype with
| Tailwind though, if you remember the class names well.
| jfengel wrote:
| Unfortunately, prototypes are rarely thrown away.
| Prototypes become production code, because code that works
| is usually more important than code that's clean.
| Cleanliness comes with refactoring.
|
| And that's actually OK, most of the time. In some
| situations you have to be certain you get it right the
| first time, but the web encourages you to try, deploy, and
| fix later. It's messy and has long-term debt, but a lot of
| that debt rarely comes due. You might just be the one
| holding it when the bill comes in, and that's no fun, but
| people do this because on the whole the amortized cost is
| less.
|
| Just don't fool yourself into thinking that this is just
| the prototype. Unless you have specifically allocated
| resources to throwing it out and starting over, acknowledge
| from the beginning that this is going to be production
| code. That way you make fewer of those "Oh, well, it's a
| prototype" decisions. Not zero, just fewer.
| JJMcJ wrote:
| > prototypes are rarely thrown away
|
| Fred Brooks' admonition to plan to throw one away almost
| never happens. Instead more and more features are force
| fit onto the prototype.
|
| For CSS/HTML, speaking of Fred Brooks, this is an
| essential complexity, the tension between style and
| content.
| allover wrote:
| In the context of Tailwind though, the situation isn't
| really "that".
|
| Tailwind allows you to "feel" like you're just quickly
| prototyping, without afaict compromising maintainability
| at all.
|
| If you're concerned about the ability to reuse an HTML
| fragment and associated styles (or just a bunch of
| styles), they have decent docs on that:
| https://tailwindcss.com/docs/extracting-components/
| skellera wrote:
| Sure you could do everything on the HTML with Tailwind but
| they do recommend composing component classes for regularly
| used things. I'm not saying that solves all your concerns but
| it helps.
|
| Abstracting out CSS into utility classes can make it much
| quicker to get a consistent looking site up while still
| giving you a little more control over the look and feel. Of
| course you can misuse this but I think people who don't
| understand standard CSS make a much bigger mess of it than if
| they have something like Tailwind.
| keithnz wrote:
| Checkout Adams (tailwinds author) reasoning
|
| https://adamwathan.me/css-utility-classes-and-separation-
| of-...
| adamlett wrote:
| The gospel of separating styling from content comes from an
| era when most web sites were comprised of collections of hand
| crafted HTML documents, when it was a pain to make site wide
| changes to styling because it meant updating each of these
| documents by hand.
|
| These days web sites are mostly comprised of HTML pages
| rendered on the fly by some type of web app which composes
| pages from nested templates injected with content from a
| database. In this scenario separating the styling from the
| markup gains us little, because to change the styling site
| wide you only have to update a few templates, not every
| single page that uses these templates.
| [deleted]
| leppr wrote:
| That arbitrary separation never made sense, when HTML always
| harbored presentation information. From controlling the
| cascading of styles to spatial layout, your HTML and CSS are
| tied.
|
| The separation of concern that actually makes sense, and on
| which we ended up, is structured data (JSON) piped into a
| presentation layer (SPA lib like React). That's what XML
| tried to do before it became gimped as HTML.
| uk_programmer wrote:
| Not at least with HTML 4 and XHTML. HTML didn't harbour
| presentation information. It told the browser the structure
| of the document.
|
| If you look at other document writing system such as LaTeX.
| You will see that there are Sections, SubSections etc.
|
| The link to the CSS simply told the browser how these
| should be presented. LaTeX has something similar as you can
| create a document class and Word has different styles you
| can import.
|
| Having a concept of a document structure with a set of
| styles attached which you can change easily is a good idea.
|
| The HTML document should make sense without a style sheet
| and if you write/generate semantic markup it does work
| properly.
| olalonde wrote:
| > Not at least with HTML 4 and XHTML. HTML didn't harbour
| presentation information. It told the browser the
| structure of the document.
|
| I disagree. Unlike JSON which is truly presentation
| agnostic, the position of the HTML elements always did
| affect the layout and some designs were pretty much
| impossible to achieve without having to move HTML
| elements around. Despite the popular claim to the
| contrary, HTML was always part of the presentation layer.
| [deleted]
| rglullis wrote:
| > position of the HTML elements always did affect the
| layout and some designs were pretty much impossible to
| achieve without having to move HTML elements around
|
| The results you see on CSS Zen Garden show that this is
| not true at all. It was hard, but not impossible then and
| nowadays grid layout and CSS3 fixed a lot of the issues.
| thinkloop wrote:
| To achieve that tho you need a ton of superfluous non-
| semantic html wrapping everything in triple so that you
| have the flexibility to do what you need.
| rglullis wrote:
| Again, not true. Take a look at the HTML from the Zen
| Garden page and you will see it is very semantic.
|
| Also, just anecdotal: I am working on a Vue.js component
| which I want people to customize the styling however they
| want. This is forcing me to drop the CSS part of the
| components. I am not adding any cruft HTML and yet I did
| manage to get a "basic" theme and a good chunk of the
| "materialize" look already. Two themes, two separate SASS
| projects. It can be done.
| thinkloop wrote:
| The main (only?) way html affects style is containment -
| the hierarchical nature of it and the ability for
| components to be "inside" other components. I feel like I
| already bump into this issue quite often with something
| as basic as whether an <input> should be inside the
| <label> or next to it. The only way, I believe, to
| resolve containment issues is with absolute positioning
| (right?). Given enough time and change requests, every
| element will eventually have to become absolutely
| positioned, which would become a mess - do you agree with
| this and how do you handle it?
| rglullis wrote:
| I am not a frontend specialist, but "display:grid" solved
| a lot of these issues for me. You can define even
| template areas and make things responsive with align-
| self, justify-self and related directives.
| uk_programmer wrote:
| At the time CSS wasn't as feature rich as it was today.
| The problem was a lot of the time the designs didn't
| respect the medium at all. There were even designs that
| were impossible. The technology was being pushed to do
| stuff it wasn't really supposed to do.
|
| You are complaining about the wrong thing.
|
| > Despite the popular claim to the contrary, HTML was
| always part of the presentation layer.
|
| Not at all. It is document format. Designs that do not
| respect that doesn't change it's intrinsic nature.
|
| This is like complaining that a shoe isn't a very good
| mallet.
| olalonde wrote:
| Apart from the false dichotomy (the fact that HTML is a
| document format and that its structure plays an important
| role in browser layout are both true), I totally agree
| with you. HTML was indeed never meant for that but it was
| often sold as such by evangelists, hence the last remark.
| I wasn't complaining about HTML as such but about that
| common misrepresentation.
| iimblack wrote:
| I don't use Tailwind much, but couldn't you still use the Zen
| Garden style of CSS with Tailwind's @apply?
| rvense wrote:
| I also grew up in the CSS Zen Garden era, and I've become a
| big Tailwind proponent.
|
| To me what is cringe-worthy is hanging on to ideas about what
| this medium is that just no longer apply. For better or
| worse, the web stack has been appropriated into an
| application framework. I am not making documents that have
| styles applied to them. It's just not a metaphor that works
| anymore.
|
| The HTML, Javascript and CSS in a single-page application are
| not separable in any meaningful way. Maybe for some parts of
| your app, you can maintain this separation of you try, but
| it's not something that adds any value at all. Even if it
| could work, there would be absolutely no reason to try. The
| type of redesigns I do on this type of code affects HTML,
| Javascript and CSS equally, always.
|
| Tailwind, to me, solves a bunch of very real ergonomic issues
| when working with large web applications, and results in far
| clearer code.
| rglullis wrote:
| This seems backwards. Desktop/GUI application developers
| have separate layout/theming engines and you don't see them
| asking for theming frameworks to be intertwined with
| components properties.
| Benjammer wrote:
| >The HTML, Javascript and CSS in a single-page application
| are not separable in any meaningful way
|
| This is orthogonal to the issue. It's still possible to
| separate the functional layers of a website or application,
| even if the entire stack is JS or whatever.
|
| I don't see how single page apps invalidate the base
| concept of separating data, structure, and styling into
| separate layers, regardless of the format or code language
| of those layers.
| dasil003 wrote:
| SPAs don't invalidate the concept of separating structure
| and styling, but as with all technical architecture
| decisions there are tradeoffs. Whenever you add another
| layer you are paying some base overhead cost with the
| goal that each individual layer ends up simpler. Whether
| or not this is a net win depends largely on the interface
| between the layers (see also: microservice trainwrecks).
| Content and style is tightly coupled and application-
| dependent, so abstract principles that sound good may
| make zero sense in a particular use case depending on a
| whole slew of technical and operational concerns about
| how the markup and CSS are generated and served.
|
| In the old days, website were primarily documents, and as
| browser formatting grew more sophisticated the ratio of
| content to styling markup grew lower and lower, and when
| you're formatting simple documents the amount of
| redundant styling is very very high. Because HTML was
| designed with a small number of elements that provide
| pretty good coverage over basic documents, and because
| most documents were created by hand, the original CSS
| design and philosophy behind CSS Zen Garden was an
| absolute slam dunk for content creators of the era. The
| assumption is a small amount of CSS covers styling for a
| huge library of markup documents, minimizing overall code
| size.
|
| As web apps evolved to be more dynamic, first with bits
| of AJAX and then graduating into full SPA with more and
| more functionality ported to client-side APIs, we found
| the semantics of HTML which were tied to more universal
| concepts of written documents (heading, paragraph, list,
| quote, etc) did not cover the semantic needs of
| describing UI widgets. At this point CSS is still useful
| but the optimal structure is not as obvious. Essentially
| there are two extreme approaches: 1) create very specific
| markup for each UI element, which optimizes markup size
| and clarity, but leads to a huge amount of duplication of
| CSS; or 2) create UI-oriented classes that are then
| tacked onto a dense tree of nested divs, which optimizes
| CSS size and clarity, but leads to markup bloat and
| "class-itis".
|
| This fundamental problem was attacked from many different
| angles, lots of code generation, web components, OOCSS,
| BEM, Sass, etc. I consider Nicole Sullivan's work in this
| area to be seminal, leading to the optimal approaches
| large web products use at scale, and directly informing
| the design of React and modern SPA approaches. The reason
| Webpack processes markup, css and javascript all together
| is because things are so tightly coupled in practice,
| that you need tooling to optimize overall code structure
| and legibility. Purist approaches don't work very well
| for large projects because HTML & CSS were not designed
| to build GUIs.
| Benjammer wrote:
| >Essentially there are two extreme approaches: 1) create
| very specific markup for each UI element, which optimizes
| markup size and clarity, but leads to a huge amount of
| duplication of CSS; or 2) create UI-oriented classes that
| are then tacked onto a dense tree of nested divs, which
| optimizes CSS size and clarity, but leads to markup bloat
| and "class-itis".
|
| Really, only two approaches are viable? There's no middle
| ground here? What would be the point of highlighting the
| extremes?
|
| It's as if the entire tech industry has lost the ability
| to tell a designer to sit down and come up with a basic
| typography set and color palette even. Obviously you
| can't just create the entire style sheet set in one pass,
| but can't there be an iterative approach rather than
| throwing the entire thing out and building giant systems
| just to let picky designers pointlessly tweak small
| pieces of the application, in isolation?
|
| What does a complex, "dynamic" widget have to do with not
| using standardized typography and colors in your
| application? Once you start there, can't you just evolve
| the styles to meet product needs? It just seems to me
| that 99% of the time, the point where it's decided that
| this whole thing should be thrown out, is almost always
| the point where someone wants to put "built a component
| system" on their resume...
|
| Another grey area:
|
| >create very specific markup for each UI element
|
| vs.
|
| >create UI-oriented classes
|
| There's another middle ground here where you just have
| really big CSS selectors, and many things share styles,
| while still pointing to structure-oriented html classes.
| Can you achieve a middle ground better than individual
| styling, without resorting to UI-classes?
| dasil003 wrote:
| That's exactly my point, the two extreme approaches are
| on a continuum, and the interface between the two is very
| tightly coupled, leading to the optimal approach for a
| typical SPA being very different from the approach being
| touted in the Zen Garden era.
| dsego wrote:
| If you look at some talks on ideas behind oocss you can
| understand that a lot of elements share similar styles. It's
| all boxes in the end. There is this one talk about refactoring
| a huge pile of css into a small number of reusable visual
| styles, I think it was for facebook. The semantics of an
| element might be a comment box, but visually it's a box with a
| shadow and a chat box or sidebar might share the same look,
| thereby it would make sense to assign them the same class
| (classes are intended for extracting common visual styles).
| Doing styles the zen garden way was usually done via long
| selectors to target the elements and you would end up with css
| code that is tightly coupled to your markup. Moving html
| sections would cause the styles to break. Using strictly visual
| styles (ie functional classes) makes it easier to distinguish
| the style aspect from the content and HTML is already a
| presentational medium.
| saagarjha wrote:
| > classes are intended for extracting common visual styles
|
| No, they're intended to group together semantically similar
| elements. There's no reason that a blue button and a blue
| link should be related-what if I want to make the button red
| later?
| sbergot wrote:
| What about a classes like primary-color, secondary-color,
| danger-color & success-color?
|
| Having two elements share the same color creates a relation
| between the two elements. If you have decided to use the
| same color for both elements it is probably because this
| color has a specific meaning. If the color of one of the
| elements changes it is probably a good idea to also change
| the other element.
| uk_programmer wrote:
| If you call things what they are it works out better e.g.
| a class for a call to action class="btn-cta". Want a
| large call to action button class="btn-cta btn-large" or
| similar.
|
| I really should write something on forgotten simpler CSS
| / JavaScript techniques.
| saagarjha wrote:
| That sounds like an excellent use case for CSS variables.
| dsego wrote:
| Those were not supported across all browsers for a long
| time (recently IE11). Also, a variable only covers one
| property and is not adequate to extract many shared
| properties. Less/sass mixins and inheritance are a good
| way to extract reusable parts shared between components.
| bromuro wrote:
| Well I think it went that way because CSS is lot of frustration
| and not much zen.
| williamdclt wrote:
| Because it was "the whole point" doesn't mean that it was a
| "good idea", especially when the web changed so much since
| then.
|
| It's not necessarily a good idea to completely separate what
| things are and how things look. It indeed makes easier to do a
| complete redesign, but how often does it happen? And if it does
| happens, what are the chances that it actually won't require
| markup changes?
|
| I find the approach by Bootstrap (or better, Tailwind) much
| easier to work with: compose utility classes to make up higher-
| level components. It still require some encapsulation of these
| higher-order components (with a Web Component, React Component
| or even just a class with @apply), but it allows much much
| faster development, less spaghetti styling, less cross-browser
| concerns and less code all around. Ultimately I code faster
| with less bugs and easier maintainance: I take it as a
| subjectively better approach.
| uk_programmer wrote:
| > It's not necessarily a good idea to completely separate
| what things are and how things look. It indeed makes easier
| to do a complete redesign, but how often does it happen? And
| if it does happens, what are the chances that it actually
| won't require markup changes?
|
| If the markup is done properly in the first place. It is
| incredibly easy to restyle and you typically don't to rework
| much markup. It just ends up working.
|
| > but it allows much much faster development, less spaghetti
| styling, less cross-browser concerns and less code all
| around.
|
| I have seen no evidence of this in practice. This is only
| true if you design is basically a skin of these frameworks.
| If you have anything remotely custom you end up overriding so
| much you might have well just started with a normalise/reset
| style-sheet. So for some internal application that never seen
| on the outside, you can use bootstrap and slap something
| together quick sure. However if you are actually building
| something with a unique it just doesn't really work.
|
| If you think about what you are doing instead of just jumping
| in and coding. You can break stuff down properly without the
| need for hundreds of classes that typically come with these
| CSS frameworks. You do end up with clean CSS and the markup
| is clean and you do have less code.
|
| By doing things properly i.e. you markup and css is correct.
| You have less cross browser bugs. I end up in my current
| being asked by a coworker to pick up IE bugs (yes we still
| support IE9 upwards). Only 10% of the fixes are actually
| problems with IE. 90% of the problems are correcting the
| markup (making it valid) and cleaning up the CSS and it just
| works cross browser. Sure you will have to work around things
| like you don't have flexbox and other niceties and you have
| to use an alternative style-sheet. But fixing the markup
| normally gets it from "not rendering properly at all" to
| "rendering only slightly wrong".
| ratww wrote:
| _> I have seen no evidence of this in practice. This is
| only true if you design is basically a skin of these
| frameworks. If you have anything remotely custom you end up
| overriding so much you might have well just started with a
| normalise /reset style-sheet. So for some internal
| application that never seen on the outside, you can use
| bootstrap and slap something together quick sure. However
| if you are actually building something with a unique it
| just doesn't really work._
|
| I had the opposite experience. I've build a few projects
| with Tachyons and Tailwind, and I rarely have to create
| custom CSS. In one of the largest ones (that actually had a
| 100% custom UI toolkit with over 40 widgets) we only had
| about 120 lines of custom CSS, pretty much just overriding
| colors and adding some utility classes for animations,
| custom drop shadows and some weird hover states.
|
| The reason we need so little extra CSS that is that those
| frameworks use the same defaults that designers use:
| everything is a multiplier of 4px/8px, font sizes are
| proportional, and it follows design principles. Actually,
| if you work with a designer chances are most of your CSS is
| already very repetitive, because designers love patterns.
| uk_programmer wrote:
| I've heard all this before. I am extremely sceptical and
| tbh I wouldn't want to build a site this way at all.
|
| It goes against what CSS was supposed to do and generally
| the results are IMO hard to work with because you have
| the overhead of having to learn how the framework works
| rather than just using the fundamental principles of what
| you are working with. Also the markup is horrendous to
| read.
|
| With modern CSS you are given so much control. Your
| style-sheets aren't complicated anyway.
| hinkley wrote:
| Bootstrap still gives me an eye twitch. It didn't handle color
| customization properly until at least 3.0 (oh you could color
| many things, but you want light text on a dark background and
| you'll have to override a ton of stuff).
|
| I was ordered to use a version that didn't even handle
| responsive design properly. Right after we had agreed to make
| the app responsive.
| kevin_thibedeau wrote:
| It's a shame that Foundation never caught on fire because
| they were/are way ahead of Bootstrap in these and other
| areas.
| bmn__ wrote:
| To "become popular" is just "caught on", not "caught on
| fire".
|
| https://www.lexico.com/definition/catch_on
| wdb wrote:
| Personally, I find the mixes of class names like with Tailwind
| really confusing and need to keep looking it up when using it.
| Doesn't really make things easier imho
| crispyambulance wrote:
| > ...in the Bootstrap era you would look at my HTML and see
| "row" and "col-sm-3" and know exactly what I was going for
| visually.
|
| Part of the blame for this has to fall onto the lap of CSS
| itself.
|
| Up until CSS-grid it has been too damn hard to get layout to
| "just freaking work" with CSS.
|
| To be fair, it was even more of a dumpster fire back in the
| early naughts when almost everyone just used HTML tables to do
| their layouts. The folks behind CSS should have caught on at
| that time and focused on making layout better and eliminate
| thousands of person-years of frontend people grinding their
| gears... BUT NO, not until 2018-ish did we get CSS-grid.
| thomascgalvin wrote:
| I've seen people seriously recommend marking up your document
| like this: <div style="display: table;">
| <div style="display: table-row;"> <div
| style="display: table-cell;"> </div> </div>
| </div>
|
| How in the nine fires of hell is that better than just using a
| table?
| HideousKojima wrote:
| Probably to avoid the dumb limitations on having forms within
| a table? Still an awful and ugly way to do it
| mgr86 wrote:
| This makes me cringe. I may have been 12 but I was making
| websites in 1998. And they were decent--I mean, it was a lot
| of right click > view source copying. But I fell in love with
| the Web Standards movement. I was probably the only 13 year
| old whose book shelf included books on perl, css, xml, and
| the like.
| carldaddy wrote:
| I feel the same way. It's probably because I'm 90s kid and
| nostalgia, but I wish web standards were taken seriously.
| hinkley wrote:
| CSS Zen Garden seemed to have a message that you don't need
| tables for everything, but it was astonishing how few of the
| featured designs ever handled responsive layout properly.
| Getting text to fit into a rectangle by cheating was very
| common and you'd see bleed everywhere at a different
| resolution.
|
| Until flexbox, there was no way to fix this without resorting
| to table cell behavior. It ultimately soured me on the
| Garden. And thankfully I got to use CSS3 shortly after.
| gridlockd wrote:
| Even with "display: table" or flexbox you couldn't do
| something as simple as colspan.
| hinkley wrote:
| Oh man, I had blotted that out. There's a somewhat arcane
| set of table styles that will give you proportional
| layout of blocks that is more powerful than colspan. I
| found that it was often worth the trouble of reaching for
| the more sophisticated solution.
| djsumdog wrote:
| Keep in mind Zen Garden was written WAAAAAAAAY before
| mobile layouts were a thing. Back then, you had mobile
| sites .. for people with PalmOS, BlackBerry or flip phones
| with tiny browsers. I think my edition of this book came
| out before the first iPhone (I remember owning it when the
| girl behind me at work got the original iPhone EDGE), so
| responsive design wasn't a thing (I don't think media
| queries even existed in the CSS standard, or if they were,
| few were using them yet).
| hinkley wrote:
| I was pitching responsive (or at least, fluid) design by
| 2011, and I was not blazing trails. I started using the
| iPad as an example but tiny laptops were an issue, and in
| a business setting, most production projectors were only
| 1024 pixels, hardly anyone had the 1280s, and the cheap
| ones were 800x600 native with terrible interpolation.
|
| Wikipedia has this timeline:
|
| > Cameron Adams created a demonstration in 2004 that is
| still online.[46] By 2008, a number of related terms such
| as "flexible", "liquid",[47] "fluid", and "elastic" were
| being used to describe layouts. CSS3 media queries were
| almost ready for prime time in late 2008/early 2009.[48]
| Ethan Marcotte coined the term responsive web design[49]
| (RWD)--and defined it to mean fluid grid/ flexible
| images/ media queries--in a May 2010 article in A List
| Apart.[2] He described the theory and practice of
| responsive web design in his brief 2011 book titled
| Responsive Web Design. Responsive design was listed as #2
| in Top Web Design Trends for 2012 by .net magazine after
| progressive enhancement at #1.
|
| And while the Garden was indeed around long before that,
| IMO it didn't get properly cool until maybe '07. And once
| fluid and responsive came in it wasn't keeping up.
|
| The point, I thought, was to be able to send people there
| to learn, and I was afraid of having to fix that kind of
| smoke and mirrors in our production code so I stopped
| telling people about it, other than other seasoned UI
| people fora particular design, and half the time it was
| to laugh at one, not learn from it.
| gshdg wrote:
| Heck, when the Zen Garden was first released, you
| couldn't even browse the web on a Blackberry. 1024x768
| monitors were a luxury. 760px wide was all you could
| count on for a browser window once you accounted for
| window edges and scrollbars on the average user's 800x600
| monitor (a few years later as 1024px monitors became more
| common, a 960px site width became the standard); and I
| had co-workers who were still getting by with 640x480.
| hinkley wrote:
| I was fighting my coworkers with 1440 monitors to make
| sure we still worked on 768 width (plenty for 800px +
| scrollbar, or portrait on the brand new iPad). UI people
| like to maximize negative space in their mockups and it's
| not uncommon for them to use extremely short example text
| to emphasize that effect. Like how your living room
| looked so big until you put all of your crap into it.
|
| And the thing is, even if you had a 16XX monitor, who
| wants to maximize a tool that you might be transcribing
| data in or out of? I might actually need two windows side
| by side to facilitate that work.
| jandrese wrote:
| Virtually every CSS Zengarden site was filled with exact
| pixel counts and page offsets. As an art project it was
| neat, but practically speaking it was a disaster.
|
| When I was first learning CSS I was trying to replicate a
| very easy 3 column layout where the middle column would
| grow and shrink with the screen and consist of multiple
| variable sized elements arranged neatly in a column. What
| should have been one of the most basic layout styles turned
| out to be quite a challenge to achieve with CSS. I wasn't
| even trying to have anything fancy like columns that
| disappear on super narrow screens. Just the most basic
| three column layout that didn't leave wasted space on the
| page. In my struggle to get it to work I went to sites like
| CSS Zengarden to figure out how they did it and was
| extremely disappointed to discover that they hadn't found
| the solution either. My thought was it couldn't be
| difficult because it was so easy to do with tables and
| literally everybody online was telling me that tables for
| layout were completely surpassed by CSS. Plus I was working
| with CSS 2, so any glaring deficiencies like this from CSS
| 1 would have definitely been fixed by then. I mean this was
| the point of CSS right? To do layout?
| dsego wrote:
| Ah, the three column layout with equal heights, the holy
| grail.*
|
| *https://en.wikipedia.org/wiki/Holy_grail_(web_design)
| hinkley wrote:
| One of my big coups was fixing the reflow on our
| multicolumn layout. The page I fixed it on was survivable
| as it was, but a whole third of our UI would not have
| worked at all without it.
|
| The first time I got to use flexbox in production
| (different project) I was happy as a pig in shit.
| gridlockd wrote:
| Something about accessibility and screen readers that people
| virtue signal about, but never actually test for.
| djsumdog wrote:
| There were a lot of grid base frameworks which did this.
| Foundation 5 was unique in that it still used these rows, but
| you uses scss to assign those attributes to your elements.
| Your pre-compiled CSS looked clean and your HTML looked clean
| and your final CSS was a minified blob of crap you tried not
| to thing about.
|
| Really CSS Grid does the same thing; there's just more in CSS
| now and it's a whole lot cleaner.
| spdustin wrote:
| Because assistive technologies (like screen readers) won't
| interpret it as a table, but the browser will, giving you the
| ease of table-based layouts without the accessibility hang-
| ups.
| lisper wrote:
| The right way to fix that would have been to add a simple
| annotation that the purpose of the table was for styling,
| not semantics, something like: <table
| type=for-display-only ...>
| extrapickles wrote:
| You can do this already with ARIA attributes:
|
| <table role="presentation" ...>
|
| [edit] See https://www.w3.org/TR/wai-aria-
| practices-1.1/#presentation_r... for details
| goto11 wrote:
| Why do you consider that better? If I understand your
| suggestion "type=for-display-only" would semantically
| turn the <table> into a <div>. Why not just use a div in
| the first place?
| lisper wrote:
| Because it's DRY. With the top-level annotation, the rest
| of the table spec remains unchanged, so if you change
| your mind and decide that you really want a display table
| to be a semantic one or vice-versa you only have to
| change on thing whereas if you used DIVs you now have to
| change not only the top level but also every row and
| cell.
| goto11 wrote:
| You don't decide on a lark if you want some content to
| have table semantics or not! Tags are selected to
| indicate the semantics of the content. Content don't
| change semantics unless you rewrite it to actually be
| something different.
|
| In any case, you might just as well decide the table was
| a list item or headline then, right? So you would need
| <table what-i-actually-mean="ol">...
| lisper wrote:
| So two things...
|
| First, one of the reasons HTML has been as successful and
| widespread as it has been is that mere mortals are able
| to use it, not just trained software engineers and
| designers. Mere mortals may not make such decisions on a
| lark, but they might make the decision incorrectly and
| have to go back and change it for that reason. Why make
| more work for yourself than necessary?
|
| Second, making changes is not the only reason to make
| code DRY. Re-using TR and TD tags is analogous to
| operator overloading. If you want to add two numbers you
| want to be able to write x+y and have the compiler figure
| out whether that means an integer add, a floating point
| add, etc. You don't want to have to write (say) x II+ y
| if you want to add two integers, x FF+ y to add two
| floats, x LL+ y to add two longs, etc. It's the same for
| table rows and cells. The mental distance between tables-
| for-layout and tables-for-structure is smaller than the
| mental distance between integers and floats. It's just
| annoying to have to keep telling the computer over and
| over and over again "this is for layout" or "this is for
| structure" particularly in a case where the number of
| repetitions can be very, very large. There is no value
| add in forcing someone to do substantially more typing
| when the thing being typed contains no additional
| information that the system does not already have.
| csnover wrote:
| At least VoiceOver on Safari uses the `display` CSS
| property to decide how to describe an element unless you
| explicitly give an element a different ARIA role in the
| HTML, so this isn't 100% correct in practice (although it
| obviously should be!). [0]
|
| [0] https://bugs.webkit.org/show_bug.cgi?id=197786
| 98codes wrote:
| A11y hang-ups? It's a _benefit_ that it makes it less
| accessible? That doesn 't make any sense to me at all.
| e5india wrote:
| I think they mean to say that sometimes you might want
| the visual structure of a table but you don't necessarily
| want it announced as a table via screen readers since it
| isn't data that's being represented.
| vntok wrote:
| You have it the wrong way round, it's a benefit that it
| makes it more accessible.
|
| Abled people benefit from a system where their browser
| considers that div as "table-like" in the way content
| flows through it. Likewise, disabled people benefit from
| the fact that their screen-readers consider the div as a
| simple container without imparting any sort of tabular
| semantics ie expecting some data organized in rows and
| columns.
| runawaybottle wrote:
| Once upon a time every website layout was defined via the
| Table element. Your side bar would be a cell spanning
| multiple rows, and inside the sidebar you'd have another
| nested table that defined more layout. The shift to table-
| less divs came almost as a massive over-correction to the
| abuse of nested tables.
|
| We are in similar egregious territory now days with how we're
| doing styled components directly in the javascript and
| totally forgoing some of the principles of CSS (we are
| effectively in-lining styles , for everything). That's
| alright, we go through this upending in frontend every 3
| years anyway.
| wvenable wrote:
| NetObjects Fusion allowed you to create pixel-perfect HTML
| layouts before CSS using just nested tables. It was both
| amazing and frightening.
|
| https://en.wikipedia.org/wiki/NetObjects_Fusion
| goto11 wrote:
| Depends - if the content isn't semantically a table (data
| points with a two-dimensional relationship) but you just want
| a table-like presentation _and_ you want to conform to
| accessibility guidelines, this might be totally fine.
|
| Sure it might be more elegant to do it with a stylesheet, but
| for a one-off situation it is not that bad.
|
| There is a persistent attitude that presentational
| information in the markup is Bad and Evil. This is only
| partially true.
|
| Misusing semantic html elements (like using <table> for
| purely layout purposes) is bad because it hurts accessibility
| for other people. But putting CSS directly in the HTML does
| not hurt anybody but yourself. If you do it all over the
| place it becomes a mess to maintain, but in particular cases
| it might be the simplest solution.
| jstummbillig wrote:
| This is straight out of the CSS renaissance: There used to be
| a world, where the only sensible way to get something look a
| certain way on the web was using tables. But since using the
| actual table element, for anyone who cared about html
| semantics and accessibility, was a no go, assigning "display:
| table" to a non-semantic element was the next best option (or
| rather the least bad).
|
| It will not surprise you to learn that this concept was not
| exactly well understood (to be fair, most things were not
| well understood, including js) and people started building
| all sorts of actual data tables out of divs with "display:
| table" applied, because apparently that's how you were
| supposed to do it.
|
| Nowadays this is obsolete, of course, mostly thanks to
| flexbox but also grid.
| castis wrote:
| I am convinced that people who recommend things like that
| have no idea where we are or how we got here.
| tylerjwilk00 wrote:
| So long as structure and design overlap there will always be
| some inescapable coupling. The choice is deciding which one
| should master over the other.
| [deleted]
| arkh wrote:
| And now we're back to table-based design and flash-like but
| less powerful javascript based application.
| lazyjones wrote:
| People are far too concerned with these things anyway, IMO. All
| ways work well enough and perhaps I'm just ignorant, but in the
| past 25 years I haven't seen a single good example of a
| situation where someone won against the competition because of
| better presentation or better choice of frontend framework.
| That excludes those who shot themselves in the foot with Flash
| though.
|
| IOW, put the effort into backends / core functionality and not
| elegant styling or elaborate frameworks.
| hcarvalhoalves wrote:
| Because every 10 years you have people who haven't been around
| for the past 20 years (re-?) inventing things.
| jakearmitage wrote:
| http://smacss.com tried to push this, but failed
| hinkley wrote:
| Can't remember which, but there was someone who made a CSS
| library that patterned like a fluent interface.
|
| They had lots of selectors that were adjectives, and most of
| them composed. So you could have a class="tiny button" or
| whatnot.
| mpranjic wrote:
| Perhaps Semantic UI?
| hinkley wrote:
| YES. That's the one. Thanks.
| purmac wrote:
| I enjoyed browsing CSS Zen Garden and read Eric Meyer's CSS
| articles when I was still in school 15 years ago. Time flies and
| so as Front-end stack.
| andre-lima wrote:
| I truly believe this is still the way to go if you want to have
| any hopes of keeping your HTML/CSS maintainable and easily
| customizable.
| theandrewbailey wrote:
| I wrote my blog's HTML[0] semantically, and I'm glad I did. I
| have a different style when someone fires up a new instance. I
| was already going for a retro "vaporwave" aesthetic there, and
| that recent Windows 93 post[2] pushed me over the edge. I apply
| those styles to my main site as an Easter egg when you view it in
| the Japanese locale.[1]
|
| [0] https://theandrewbailey.com/
|
| [1] https://theandrewbailey.com/?lang=ja
|
| [2] https://news.ycombinator.com/item?id=22463415
| saagarjha wrote:
| Semantic HTML also happens to work quite well on even the most
| anemic browsers! I am somewhat proud that a non-HTTPS version
| of my website (which is designed for modern browsers) is
| navigable and fairly usable on the original WorldWideWeb, aside
| from some of the <head> content poking through.
| austincheney wrote:
| http://mailmarkup.org/zen/
|
| This is my Zen Garden attempt. According to the HTTP headers it
| is from 20 October 2008.
|
| You can see how font rendering has changed over the years. When I
| wrote this all columns were the same height and alignment cross
| browser.
| bendotero wrote:
| It looks great. Nice job. I miss the web from this era. Sites
| looked so much more unique. People posted to their own sites
| and syndicated content. Feed readers were useful. Sigh.
| hackbinary wrote:
| From Dave's current site:
|
| http://daveshea.com/projects/zen/
___________________________________________________________________
(page generated 2020-03-19 23:00 UTC)