> Do you remember ever enjoying using/reading a website with more than two columns? I don’t.
Another one of the things I really miss about the pre-JavaScript, pre-CSS, document-oriented (as opposed to the current experience-oriented) web is being able to make my browser window half or a third of my screen, and having documents be eminently readable. That was really, really nice. Try it now, though, and nothing really works correctly. Which is weird, because a third-width window on a laptop or desktop has roughly the same proportions as a phone in vertical layout.
Another one of the things I really miss about the pre-JavaScript, pre-CSS, document-oriented (as opposed to the current experience-oriented) web is being able to make my browser window half or a third of my screen, and having documents be eminently readable.
Man what I remember was doing multiple columns using Tables in HTML which never worked in anything under a 700px resolution.
Yeah but you could scroll your window horizontally to only keep the useful column visible.
Now it's "HEY I SEE YOUR SCREEN ISN'T WIDE ENOUGH TO FIT TWO COLUMNS OF ADVERTISING ON THE SIDES. HAVE THE CELL PHONE LAYOUT WITH FULLSCREEN POPUPS INSTEAD!"
Not to mention if you're actually on a cell phone it's "HEY YOU JUST CLICKED ON A LINK, BUT SINCE YOUR PHONE IS SO SLOW AND MY SITE IS SO BLOATED, BY THE TIME YOUR CLICK WAS REGISTERED SOME OTHER CONTENT LOADED IN THAT LOCATION. YOU ACTUALLY MEANT TO CLICK ON THIS AD, AMIRITE?"
This is a UI sin that should trigger public shame of developers.
It really should be handled at the OS level for apps, or at the browser level for web sites: If I click anything on the screen, it should react as if I clicked on what was there 300ms ago, maybe 400 or 500ms or longer.
The fastest (typical) human reaction is around 300ms. If I'm clicking on something that appeared less than 300ms ago, then I'm NOT intending to click on it. Maybe the delay should be configurable, or maybe it learns the behavior for a particular user? An elderly person surfing the web might have a 1000ms propagation delay between deciding to click and clicking on a button or link. But my reflexes are closer to the 300ms point if not better on a good day.
No matter how fast a human is, if a button is covered by an ad 100-200ms before they click, there's no way to not click on it. And that's bad UI.
Even my (our?) favorite search engine, Duck Duck Go, is guilty of this: I will frequently accidentally click on the "WikiPedia summary" popup which has just replaced the actual top link that I wanted to be clicking on. Bad web duck!
Heh. I've never thought of solving that via a delay before but it's a brilliant idea. I can't think of the site at the moment (but it was a popular well respected one) but yesterday I got caught 3 times in a row by this issue. I just kept thinking to myself "how could you have so little respect for your users?"
A quick Google finds numbers from 250-280, with record reflexes as low as 110ms. I've done less than 180ms on a "hit the button after the light goes on" game at a science museum (hardware designed for it, so no built-in latency).
300ms is a good lower limit, though, if you take into account complex video processing and standard brain activity when browsing; when hitting a button when you're browsing, your brain isn't wound up and ready to react as quickly as possible. Getting that extra fast reaction really requires short circuiting some of the mental processing you'd normally do. I'm pretty sure I'm remembering 300ms from the cognitive science/UI classes I took in college.
And don't forget the hardware lag in your own body. ;) The signal to click the button takes ~10ms to get from your brain to your fingers. When you think about things like sports where the accuracy of, say, releasing a ball when throwing it, needs to be in the 0.1ms range to hit your target, but your brain is actually giving the command 10ms before the ideal release time... Makes my brain hurt just contemplating how it works.
Pro tip: Don't think about this while trying to throw a ball accurately.
+1. My pet hate at the moment is the RunKeeper app. Every morning I fire it up to start my exercise. The interface loads up, and the 'Start my Walk/Run' button pops up at the bottom of the screen. The button waits there for around one or two seconds, then slides up about a centimetre and another button saying 'Sign up for our Pro paid edition' appears in its place.
I swear the the delay between appearing and sliding up is always timed and changed each day to cunningly coincide with my finger tapping on the area where the 'start' button used to be so that I almost always tap the 'pay us $$$' button instead !!!
I wouldn't be surprised if it feels random because it is loaded after a network request with variable timing checks to see if you have the pro version or not.
This happens so often, on so many different sites, that I can't just chalk it up to unfortunate coincidence. I used to think it was conspiracy-theory territory to call it deliberate, but on reflection - could blind A/B testing in the unthinking pursuit of "click-through rates" and "conversions" actually push developers towards this behaviour, even inadvertently?
I think it's intentional - just like the placement of display ads next to autoplay videos. People spend time mousing over and 'looking' at the ad as they're hunting for the mute button. Increases interaction metrics and makes the ad slot look more valuable to prospective ad buyers.
EDIT: While we're at it, there's a publishing group that displays all news articles as popovers over the main page.
People accidentally click out of the articles and get dumped on the home page, containing expensive "site takeover" advertisements.
Can't remember the name of the company - they have a bunch of US-based local news sites.
It doesn't even have to be clicking a link, it can even be scrolling. And you don't even need a slow phone to experience this behavior on a daily basis.
Most of the web was more usable on mobile before mobile sites started pandering to low IQ people who couldn't figure out how to pinch zoom and scroll. Now it's only the largest sites that can afford the developer know-how to make their mobile site actually usable. (And not all of them bother.)
If you are a small operation that still makes your mobile web site usable, then power to you.
Really? Websites I built up until like 2004 were optimized for display at 800x600 -- still roughly 50% of users at the time. This meant most of my content was somewhere around 640-700px width.
It wasn't until 2008 when 800x600 was below 10% of users and I finally started using a 900 grid.
I started designing web pages in 1995. While they weren't works of art, I really miss the simplicity and utility of the internet back then. Also, most content seemed to be really enthusiastic and less economically motivated. I wish we could get back to that.
Interestingly, most the themes I tried didn't render well on my screen. Elements clipping or rendering on top of each other in funny ways, stuff like that - all the typical stuff that happens when the designer didn't consider how the page might render on a smaller screen than the one they have.
I'm rocking a 13" MacBook with the browser in full screen mode, so I suspect my screen's dimensions are well within the range of typical users. The fact that I encounter sites like this on a daily basis is an eternal source of wonder.
I think because CSS layout without the aid of a CSS grid is so @$@% obtuse.
Or at least, try as I might, I've yet to find a clear and comprehensive explanation of how to do it properly. So, despite thinking CSS Zen Garden is a work of beauty, for my own part I just throw bootstrap at it and get on with my life, and I'm not ashamed about it.
If your content won't flow/flex into a grid well, then those parts should have custom CSS @media queries to begin with.. it's a matter of learning that.
Alternatively, you can use something like react with event triggering on window resize, and use the actual window size as part of your rendering... for example, I'll put the event to trigger my redux store so that state.window.size.height/width are set, I'll sometimes also do the window.scrollTop in the events as well.. this way I can use that in code for my components...
render(props) {
if (props.window.size.width < 600) return null;
if (props.window.size.width < 1024) return <div>...</div>;
...
}
Or similar changes in rendering... assuming something like redux with react-redux's connect. It's actually a pretty slick way to handle this. In this example, [1] I'm using the value to also adjust visual configuration from inputted configuration.
The problem there is, I have no incentive to continue to part 2. Every time I've tried, it's been a frustrating mess that ends in failure.
I suppose it's easy for me to punt because I'm not a front end developer. To be honest, though, CSS is such a bizarre layout system that I don't think I can blame the pros for doing it, either. Part of being a professional is finding the most profitable use for your time, and I doubt that most people will notice the difference.
Yesterday I needed to look some stuff up while on an RPi with just Ubuntu server. Using Lynx on Google and Wikipedia brought that back a little bit. It was nice.
I have two screens, one of which is vertical. It's the one I usually use for web browsing, because reading is just nicer if the columns aren't too wide and lots of stuff fits vertically (I can see an entire page of Google search results, really nice!).
Tons of sites assume a width of something that is obviously greater than 1080 pixels and break in awful ways.
of what? that you don't need a separate mobile site (or js) to show a most basic wall of text?
open up amazon.com or walmart.com and see how your justification holds up. certainly, there are simple layouts with sparse content that can be made responsive easily (blogs, image portfolios, etc) but this is a far cry from proof that a broad statement is at all applicable.
I find this funny now because HN used to be awful on mobile, due to an inflexible tables-for-layout design. One that couldn't easily be changed, either, because everyone's clients relied on the exact structure of the markup for screen scraping.
> One that couldn't easily be changed, either, because everyone's clients relied on the exact structure of the markup for screen scraping.
This doesn't seem like that hard a problem. Presumably the robots all sent their own distinct UA strings (as scrapers only get written to imitate browser UA strings if you ban non-browser UA strings.) So why not just filter your logs to find all the known scrapers, serve anything with those exact UA strings "legacy" table-based responses, and serve everyone else the new layout?
There are plenty of ecommerce sites doing the mobile/desktop split generally well (and making millions of sales in the process). HN is literally text-only.
HN is terrible on mobile. Their column sizes are just slightly too big for my screen (not adaptive), so I have to scroll to read the last word of every line. And on desktop, it just expands to the whole page width, even through everyone knows you should never have a line of text that's longer than 600px.
No, HN has a responsive layout - it works well on any screen size. (Well, hitting the correct arrow on mobile is still hard, but at least there's an undo button now).
Use a browser that reflows text then and complain to the creators of your current browser that they don't support the integral feature for small screen web enjoyment.
It looks vaguely like that. Notice how all the menu links are clumped together? The same is true for all the action links anywhere eon the site. I may be old (38) and fat fingered, but I often will tap the wrong thing because they're just too close together and the targets are too small (plus they are text links, and not buttons.)
Actually reading text is not the worst part (though if I want to zoom at all then stuff scrolls off the page, since it won't reflow on iOS when you zoom, and browsing becomes miserable then.) The worst part is trying to interact with the site on mobile. I basically just don't do it.
It is great on my Samsung Galaxy S. If I zoom in, long lines simply reflow to fit the screen. It means that I can dynamically adjust the font size to suit any accessibility needs or situation.
Same for me on on iPhone 6 - comment text is tiny and I have to zoom in and to be sure of hitting controls accurately. Text does not reflow on zoom. :(
That's correct for many websites, but others such as Facebook have such a complicated but still correct UI on a desktop that it's appropriate to have two different websites.
Nope. That was true about a year ago, but not anymore. Facebook UI on a desktop is horrible. Try using it with 1024px wide screen - most apps/games aren't fully visible because they give 760px to the canvas and the rest of their UI is not responsive - so either the ad space on the right or the content (app/game) has to suffer.
It certainly needs more love - another problematic part is when you have messages open but you want to see stuff on the column to the right of the newsfeed. Its design leaves some to be desired.
I run my monitors in portrait orientation, so I see everything in 1080x1920. Almost everything works fine.
I do occasionally run across a site which uses fixed width divs and either won't squish down past 1280px, or gets all messed up because they plainly didn't test on narrow windows, but they're in the minority.
The Margin (* + *) and Font Size (font-size: calc(1em + 1vw)) declarations are really cool, it's the first time I read about them.
What do more experienced designers think of them? Handling spacing between elements is usually a pain (should I add margin on the top, or the bottom?), and font sizes proportional to the display width is IMO genius, so why aren't these declarations used more often?
EDIT: the article title is a little unfortunate, I thought it was about the modern Javascript ecosystem and that every tool has to have some kind of plugin system, modularity, extensibility, and require a ton of boilerplate to fit your 3-file website. Or that's what I expected, anyway.
I want to love every technique like this (or their more involved cousins like a typography "vertical rhythm" system)... but when it comes time to build sites with some visual and/or layout complexity (for a business client, not a blog that's a relatively simple stream of primarily-text articles), I always wind up with so many exceptions to the rule that I find these catch-all declarations to just be one more thing I'm working around.
For me, the single most useful technique I've discovered in the past few years has been "drop the 'C' in 'CSS'" and instead think in terms of modular components with virtually no cascading or selector nesting. E.g. BEM. Getting over the aesthetic ugliness of "class-itis" in my markup has freed me from a ton of agony trying to reason about why certain elements on the page are being styled a certain way.
Yeah, this is why the "You won’t need many" line is where I stopped reading. Developers who say "most of your LIs are gonna be indented" and "most of your elements will need a top/bottom margin" or "your font sizes will all be relative to the font size of the container" aren't building even slightly complicated UIs...but that doesn't stop them from passing around these "just write CSS, dummy" posts once every few months.
If you write CSS for your personal blog and want to mass-apply styles to save time, go for it, but I think the majority of people who write CSS as a part of their daily work will find that this attitude creates more headaches than time savings.
> when it comes time to build sites with some visual and/or layout complexity I always wind up with so many exceptions to the rule
I've been looking for a LONG time for articles about consistent design and typography applied to UIs and boring CRUD apps. 99% of the article about vertical rhythm, spacing, typography and general design are about designing blogs and text-heavy sites.
I need something that teaches me how to design a functional, beautiful and user friendly reactor control dashboard.
Thanks you for sharing CSS structure guide, It is very interesting, but I found a drawback based on my experience when the role of "person responsible the look & feel" is shared between team-mates. Some developers (who raised up when jQuery was must-be library in any project) have practice to supply implicit class selector i.e. when they search elements with class name '.link' via document.querySelector. I like the rscss(-like) way, because BEM which is very difficult to follow for newbies (especially now, when react is so popular). But, hey is it a next competitive standard as in famous xkcd [1]?
Thanks. rscss seems really interesting. I've mostly used BEM but I like the syntax in rscss more.
One thing I'm not sure about though is the child selector. I often have intermediate layers between the root of my component and the elements. Wrappers and stuff to make certain positioning possible. This won't be possible with child selectors only.
Your advice about dropping the "C" in "CSS" is good. I've done this and felt inferior because my CSS isn't as "good" as others. It made me feel like a hack for a long time before I finally started trusting myself and doing things the way I want to.
I've been saying for years that CSS is more trouble than it's worth if you're not writing your pages by hand. If I know that this element is an address field, I can style it like an address field, then and there. (Maybe optimize by using a uniquely-named class, or maybe not - pages are sent gzipped, that may well be good enough). Reusable, self-contained components are a great idea - but to be truly self-contained they need to include their styling.
This is the idea behind the new-ish "shadow dom" feature that is slowly being implemented by browsers. (Part of the larger "web components" concept that will hopefully become a thing at some point).
In the meantime... with some discipline you can keep things self-contained just by using unique classes for each component (like what BEM and other similar naming conventions espouse). Could also look into CSS linters to keep you and your team honest.
Thanks for the pointer. I'm actually a big fan of Vue.js and use it in several product sites/apps. However, if one is just wanting some componentization/isolation in their CSS and not actually building a javascript app, then it's kind of overkill.
Also, while it does allow you to keep your component code in different files, by the time the browser is using your CSS it's still all in one big "global namespace" (so to speak), so you still need to enforce some discipline on your css class names, even if they're in different files.
(Or perhaps I'm wrong about this and vueify modifies your classes or selectors or something to avoid this?)
Adjusting font size with vw is fun, but often the rate at which the font scales is kind of loopy especially when compared to small type. This article takes the example you mentioned above and takes it much further. https://www.smashingmagazine.com/2016/05/fluid-typography/
Have used * + * before. It creates this huge dependence on the placement and ordering of your html you can't create psudo elements to pull off some style trick, there are often a bunch of exceptions when using it too that it kind of defeated the purpose of using it in the first place. Best to have a .class * + * in front of it to relegate it to a specific area.
That font size declaration stood out as a really clever way to get a 'responsive' page with minimal work.
My one concern is that it might get weird on mobile. Android apps, though maybe not mobile pages, have all kinds of awful problems with any font that isn't a convenient integer multiple of pixel size. I'm curious whether this renders gracefully.
The font size method is a little bit ambitious, sites I've worked on will always have caveats.
The margin application though is very clever and the right way to go about it, even in complex designs you'll be able to apply this to most components (maybe not using the body selector though).
These aren't used more often because many developers aren't very familiar with the complete power that CSS has to offer, take BEM for example it completely eradicates the most powerful feature that CSS has to offer.
This is coding 101: Write/include only the code you need. No more, no less. To quote ESR (as much as I hate doing so), "Don't just do something, stand there!"
And yes, security and error checking are necessary. Anybody who says otherwise should be drawn, quartered, shot, and fired.
As much as I like this post, a framework sometimes has some value. If you're writing a true SPA, it'll only be loaded once, and something like React or Mithril is nice for a bit of structure. Mithril in particular, due to its small size, is handy.
I don't see the post as arguing against a framework per se, but arguing against pulling in and using code for things you can do as well or better without it, and only pulling out the heavy guns where it's actually necessary.
> To quote ESR (as much as I hate doing so), "Don't just do something, stand there!"
I tried to figure out what ESR meant here and after a minute of Googling I'm guessing it's Eric S. Raymond[1]. Please consider not using uncommon acronyms on online forums, it obscures your meaning.
I hope you're complaining about "ESR" instead of "esr", because his initials, much like "rms" et al. are common acronyms, especially on online forums like Hacker News.
<label><input type="checkbox" name="checkbox1"> My checkbox label</label>
I'm sure there are styling implications, but often one doesn't care about those. "Don't repeat yourself" seems like a rule that goes along with "write less code".
There is goodness to putting your label tag, with the for attribute that points to the input, AFTER the input tag in the DOM that you may not be aware of!
Here are some selectors you can use with that setup:
Those selectors let you style the label based on the STATE of the checkbox, and they work all the way back to IE7. This stateful CSS is very powerful because you can make the input tag visibly hidden and style your label tag to appear as a custom widget or checkbox - and have it look different when toggled. Take a look at html5 boilerplate's visuallyhidden CSS class to see a particularly ninja way of hiding an element. Think of what can you achieve with just CSS and markup that maybe you needed jQuery or JavaScript to achieve in the past!
By the way, using the visuallyhidden class is the ideal way of hiding a tabbable element like a checkbox while keeping it adjacent in the flow to its related elements. This method of hiding is especially kind to low vision users of your site who use tab to navigate your forms.
From an accessibility standpoint, having label-with-for is helpful to screen readers of varying quality out in the wild. label-with-for ensures the screen readers will never be mistaken about which label goes with which checkbox.
.visuallyhidden, input:checked, label-with-for, and the +, ~, and > combinators, plus WAI-ARIA attributes can be used to make visually appealing, yet accessible, widgets without JavaScript.
Thanks for all this; I was hoping for some replies like this when I posted my comment. I guess I haven't needed to hide stuff in precisely that way. Of course there's no parent selector in CSS, but if we have something like this:
Right, the span in this case is an extra tag that you don't need. Nesting an input tag under label has always struck me as having ambiguous meaning. Are you saying that the checkbox "belongs to" the label, or maybe "is a child of" label? Shouldn't it be the other way around, if anything?
One of the accessibility guidelines of the WCAG is that content in your markup MUST flow in the same direction as it is rendered on your page. This is recommended so that screen readers will read the page aurally in the same way as a sighted-user would read the page visually. If you follow that guideline, then placing your input tag before the associated label tag in the DOM usually makes sense because that is a common visual ordering for those elements.
The 'for' attribute in the label tag has semantic value that the span doesn't, you're just adding that span so that you can use the CSS combinators. If I squint, you're DRY, but once I unsquint I think YAGNI. :)
Seriously though, it really is a social good to strive to make your page content accessible both stylistically (for the low vision users, color blind users, etc.) and semantically (for the screen reader users).
It's not a matter of screen readers catching up, it's a matter of blind folks not having the latest tech or being stuck on an ancient version of a screen reader/browser combo. They maybe don't have helpful IT resources in their lives or money to help them upgrade? It's actually a big bummer. There is virtue in making pages that gracefully degrade but still deliver the goods on legacy platforms.
I believe the :checked pseudo-selector is only useful on radio and checkbox. It's just serendipitous that the common visual ordering matches the useful DOM element ordering for CSS styling in those cases.
I would expect label to come earlier in the DOM for other types of form elements so we could be compliant with the WCAG and we would still rely on the for attribute to link the two tags together for the screen readers.
Implicit label association was documented in 1997. [0] It is unlikely that screen reader software from that time is still in use; is anyone still using Windows 95? Web developers have at times been fairly ruthless in ending support for e.g. IE 8 based on empirical measures of browser use. [1] Blind users are already a relatively small percentage of all users, and the quality of available "opt-in" screen reader surveys seems a bit lacking, so it seems possible that the problems you describe are actually experienced by very few people. The other possibility would be that commercial reader distributors in "maintenance mode" spend more time lobbying accessibility organizations and discouraging the use of standards-compliant free software than they do maintaining their own software. Whatever the case, ISTM developers who care about blind users might better use their time helping to improve the screen reading capabilities of standards-compliant browsers rather than redefining standards to coincide with the capabilities of outmoded screen readers.
Just my two cents; clearly I don't care as much about this stuff as you do. Good luck!
:checked is also relevant for <select>/<option> tags.
Yeah, it is a problem ... blind users on Windows XP or vista is not unheard of. Vista shipped with ie7, if you can believe it.
Modern screen readers are really great and standards-friendly. There are even fully featured free/open source options. The problem really is disabled users stranded on old platforms.
It is very common for users with disabilities to not want to disclose their disabilities to websites. Very common to see low vision users use an independent magnifier tool rather than the browser zoom, for instance. Screen reader software is not detectable on the user's browser. So hoping to get a good count of users with disabilities visiting your site is going to be fraught with difficulties.
The kindest thing you can do from a web design standpoint for people with disabilities would be to read the WCAG, understand the issues and tradeoffs, and make tweaks to the way you form your markup and styles to conform, where you are able.
I learned about all this stuff while working on a public utility's website that got sued by a disabled persons' legal rights group who (legitimately) argued and won a case where they claimed the site was inaccessible to screen reader users. The site was totally atrocious, legacy Struts cruft, and we got to do a full overhaul of the UX, markup, and CSS for accessibility.
I expect more of these types of lawsuits in the future, so it could be useful career-wise to be aware of this stuff.
I love it. Not only were the tricks interesting (I'll have to explore those more to see if they scale in some projects I'm working on) but the advice rings exceptionally true. Well at least in my opinion.
I've done web development for a little over 12 years now and the amount of times I've seen someone pull in a huge framework, fonts, tons of libraries just to make a simple page is astounding. I once worked at a job where they abused ASP.Net to such a degree that they were delivering a page to the user of over 70MB (about 60MB of that was only ViewState!!!) and while the application had its complex pieces that was only on a homepage that showed a very, very crude dashboard with only the functionality to re-order boxes. Boxes!
Frameworks have their place. Libraries have their place. They're helpful. But you don't need to bring them in every single time you write a web site or application. That code eventually has to be downloaded and viewed by a user and if you can do it with as few dependencies as possible your users will subconsciously thank you.
Because developers today grow up in a world of computing abundance. They don't realize what it's like to develop on limited resources. There needs to be a balance between bare bones and throw everything at it that you can find on Github.
> I've seen someone pull in a huge framework, fonts, tons of libraries just to make a simple page is astounding... But you don't need to bring them in every single time you write a web site or application.
I'm a back end developer. I learned JS in the context of Node. The amount of time it would take me to learn some useful CSS would decimate my ability to get something out the door compared to just pulling in bootstrap. It's often the case that there simply isn't enough to be done to necessitate hiring someone correctly suited for the job. Additionally, whenever I leave my company and they find someone to replace me, there's a strong chance that person knows bootstrap. There is a balance to be had with user joy and developer joy.
> The amount of time it would take me to learn some useful CSS.
What's with the myth that CSS is hard? It's perhaps the easiest thing about web dev.
Learn flexbox, learn units of measurements, learn specificity, learn media-queries - 5 hours max (a week of lunch at the desk) playing around in JSfiddle, and you're most of the way there.
Bootstrap is fine but pulling in a framework that has 656 classes seems a little unnecessary most of the time.
I appreciate that he practices what he preaches here.
Perhaps I've been made cynical by my experience with several other sites, but I was half-expecting to have to enable JS from a bunch of other domains just to get the content to render correctly, if at all, and still be blocking a bunch of ads and social media plugins atop that. There would be a disappointing irony were that the case.
But no, the whole site loads quickly and correctly with no intervention on my part. The only thing uMatrix is detecting _to_ block is Google Analytics, and blocking it is having no impact upon the content on the page.
HN is pretty good after the update that introduced tree collapsing, except that the up/down arrows are implemented weirdly. So on my Windows tablet, and occasionally on Android, when clicking on the arrow the browser decides to snap to the nearest clickable link instead, which is the userid.
I'm also intending to build a scraper simply so I can determine what my highest voted comments of all time are.
This is a specialization of "let's form two tribes so we can argue about stuff." "Argue" is not a perjorative here; productive argument is a good thing. We must generally, though treat the other tribe as a customer to aid in making said discussion productive.
Perhaps with Web protocols, things are ... entangled in inconvenient ways ( for, you know, ... reasons ) such that the formation of two tribes is a solution.
I don't generally build Web things. When I do build a GUI, I intentionally give it an old style, because I'm really a systems programmer ( eek, a third tribe! ) and this invites someone else to express the resulting inevitable disgust in a replacement. But meanwhile, there's an interface for it.
To anyone who's planning to use this or Atwood's article on writing less code as a little red book:
For the love of god, please use some common sense when repeating mantras like "write less code." I've seen this used to justify all sorts of ridiculous shit, like dropping basic security measures (write less code! YAGNI! Why would someone try SQL injection/XSS against our site anyway?!?).
If I propose something and your thought-terminating cliche response is some form of "YAGNI," I hate you.
"If I propose something and your thought-terminating cliche response is some form of "YAGNI," I hate you."
This has been my experience too. While the concept has value, I find most people that throw the term around do so as a justification for not thinking much.
To armchair psychologize a bit, I think that enthusiastically embracing an acronym which, whatever its conceptual merits, is just so lame-sounding correlates negatively with taste, and taste correlates, albeit imperfectly, with programming skill, especially the skill of writing readable code.
Applying YAGNI to security should be an immediate red flag.
As I say in a cousin comment, good taste is just 3rd order laziness. You're doing less by avoiding future trouble.
To armchair psychologize a bit, I think that enthusiastically embracing an acronym which, whatever its conceptual merits, is just so lame-sounding correlates negatively with taste
Wouldn't you prioritize conceptual taste over aesthetic taste? YAGNI probably sounds goofy because it was created in the late 90's. It was part of the original Extreme Programming formula. The concept is as solid as such concepts get, however.
> Wouldn't you prioritize conceptual taste over aesthetic taste? YAGNI probably sounds goofy because it was created in the late 90's. It was part of the original Extreme Programming formula.
Sure, my point was they're related (usually).
> The concept is as solid as such concepts get, however.
It's useful in many cases, yes. Solid? No. It requires far too much attention to context, and experience, to apply it wisely all the time. That is to say, YAGNI is invoked in defense of bad decisions as often as it is of good ones. That was the grandparent's point.
Sounds a little like you generally stop at the aesthetic level. The map isn't the territory, and the signals aren't the actual internal mental state of the person. Since you say "usually," how have you been accumulating data about this relationship?
It's useful in many cases, yes. Solid? No. It requires far too much attention to context, and experience, to apply it wisely all the time.
Hmmm. You should be making exactly this sort of decision all the time. The major task of a developer, as I see it after doing this for 36 years, is to pay a lot of attention to context and apply what you've learned by experience wisely. Erring on the side of caution and waiting until there's evidence you need something isn't a bad 1st order heuristic. I would label people who consistently stop at the 1st order heuristic and go no farther as "shallow."
> Sounds a little like you generally stop at the aesthetic level.
No, it doesn't sound like that at all. You've just decided to read it that way and make an ad-hominem argument instead of engaging with the statement itself.
> Hmmm. You should be making exactly this sort of decision all the time. The major task of a developer, as I see it after doing this for 36 years, is to pay a lot of attention to context and apply what you've learned by experience wisely. Erring on the side of caution and waiting until there's evidence you need something isn't a bad 1st order heuristic. I would label people who consistently stop at the 1st order heuristic and go no farther as "shallow."
I agree with everything you said, and have not said anything that contradicts it.
It's a good heuristic. And it's only that. And lots of people apply it poorly.
You've just decided to read it that way and make an ad-hominem argument instead of engaging with the statement itself.
Well, no. You've said a lot of things in this thread that seem to indicate that a 1st order heuristic only has value if it can be used in place of cognition. If there are more than 2 possible answers, a 1st order heuristic that was correct 40% of the time could still have value.
And lots of people apply it poorly.
Applying it properly is taking it as, "We need more evidence to justify the cost/benefit." That's conceptually more precise, though it manages to sound even more awkward than YAGNI. But from what you've been saying, it seems like "YAGNI" is simply the end of discussion.
OK, but at the same time by automatically dismissing a YAGNI objection as a "thought-terminating cliché" you'll end up with different sorts of ridiculous shit.
IME, the YAGNI principle is most useful with new-ish developers who've been taught certain patterns but haven't grasped the motivation for them and so can't judge when the overhead is worth it. In Java-land we'd be talking about the old every-class-must-implement-an-interface-and-come-from-a-factory clichés. It's not that it's a bad pattern, just that until you have multiple implementations and/or a need for DI it probably isn't worth the source bloat.
In that situation I think YAGNI is exactly the right objection, and I'm not sure what would take its place if it became widely Considered Harmful.
Sorry, I should've clarified - I'm not opposed to the principle, in moderation of course. You're hitting on places where it is quite useful.
It's incredibly mind-numbing when it's being used to justify laziness and short-sightedness. Worse, it's not exactly a misuse of the phrase, as per the original XP article:
> Always implement things when you actually need them
Security is, as an example, one of those things where you'd face a disaster if you just implemented it when you actually needed it (i.e. when an attack occurred).
YAGNI is incredibly short-sighted in situations where rectifying the situation later will be an absolute nightmare (or just impossible). An ounce of prevention is worth a pound of cure, and all that.
The proper YAGNI reply to this would be to use a proper library or work in the right abstraction layer so that you don't have to worry about SQL injection. For instance, Django provides the csrf_token which can be dropped in. That's still less code and secure.
Right. There's a world of difference between a mature, well maintained database library and some random goofy thing to post to social media written by newb coders. A corollary to writing less code is doing less debugging -- and furthermore, exploiting freely available code that represents 1000's of hours of debugging already done for you.
It's perfectly logical -- the same words can have different meanings in different contexts (here, the phrase "no code" has two meanings). Un-epigramming it, you'd have something like: "No code snippet exists that is as good as the complete absence of code"
In parent's formulation, the phrase "no code" acts as a polyseme, carrying slightly different meanings each time it appears. It seemed like an attempt at word play, which I thought could be improved by pitting that interpretation against another strictly monosemous one that would be tautological once the ">" relation was changed to ">=". However it seems I've been overruled.
Let me just say, for an article about writing less, this is sure a roundabout way of saying something that could be said in 1/3rd of the length.
No, I don't want to hear you ramble on with the discourse of someone who thinks they are hilarious and likes the sound of their own voice too much. Just get to the point. /rant
While I'm all for writing less code, it seems like most development teams are optimizing for maximum number of people working on code at the same time over writing less code.
This way the label magically works, similar to H2, also, the nested span is so that you can target `input[type=checkbox]` with `+ span` in order to do custmized glyphs for checkboxes without JS.
...
For fonts, have a base size for `html, body` then use `rem` everywhere else.
A lot of it has to do with the sloppy tricks people are trying to implement to get multimedia ads and whatnot on their sites. We are bombarded with ads in our day-to-day life and people's attention is more-and-more difficult to grab. Unfortunately they don't realize form follows function and their function is getting fucked. The internet is more about money and less about spreading ideas nowadays.
I assume the author meant to emphasize reading. And when you try to speed-read/browse multi-column layouts, it's becomes slower because your eye needs to cover a larger horizontal area.
For example, when Flickr transitioned from a single-column to the current row-by-row clusterfuck, it became much harder to quickly find a particular image in someone's photostream.
You write less code by:
- Removing dead code
- Applying a coding standard to emphasize code consistency, so similar problems have similar solutions.
- Once you have similar problems, you can generalize code to solve a family of problems instead of a single problem. Otherwise known as code reuse.
- Diminish coupling so code can be reused as much as possible.
There is nothing quite as pleasurable (with reference to technical work) as sending large amounts of obsolete code to the bit bucket. I often judge my refactoring decisions based on how much code gets removed. If a change results in the removal of code at many locations then I take that as confirmation that I made a good decision.
My take: one single column that the rendering visible area can figure out how to render. No hidden agenda. only and just information worth reading: learning, discussing, agreeing ir disagreeing.
(my first papers were from a teletext or a stencil or a typewriter they were of the information I wish for to read today at least 3-4 times a week. instead of 3-4 days go by for one.)
Not when you're writing consumable services IMO. The less you write in building a REST API, for example, the _more_ opportunity there is for someone to break it. It's important to catch exceptions, write detailed models, write tests for fail/success cases etc...
It's a good principle (optimizing for less code), but not always.
I like the sentiment of the article, not just with CSS, but also with imperative code: use really light weight frameworks like Spock or Sinatra and build in just what you need.
That said, I have been using Bootstrap, which is heavy weight, but I like how my mobile web sites also look nice on the desktop and on tablets.
To Heydon: Good article, especially love your simplicity and typography of your own site, very easy to read.
You should consider updating your WP Supercache or maybe just WP? to have a max-age longer > 3. Maybe you have a use case I am unaware of that effectively voids browser cache though.
I know this article is mostly about web development, but if you're interested in writing less Java code I encourage you to consider Lombok: https://projectlombok.org/
While I agree with a lot of the author's points, I've actually grown to like hero images, when they're done tastefully, relate to the product, and are optimized for mobile devices.
Based on my non-comprehensive empirical study, that describes about 3% of hero images in the wild. That is, unless almost all products are deeply related to fashionable twenty-somethings using a laptop in a coffeehouse surrounded by cute stationery with interesting organic textures.
One distinction that should be made is when some elements are the same intentionally while others are the same by coincidence. I see no problem with duplicate code in the latter case.
> Not only is the following checkbox implementation verbose HTML, but it needs a JavaScript dependency to control state changes and to follyfill standard, basic behavior*
I see no other comments mentioning this. Nobody else thought the font was way too big and when zooming out until about 50% it's finally a nice size to read?
Dreamweaver let you try to do things that wouldn't play nice with HTML and it would use the limited tools available at the time to make bloated sites that still didn't look right in most browsers.
Then since Dreamweaver was garbage people decided that any WYSIWYG HTML-editor is guaranteed to be terrible and nobody ever tried again.
There's a disruption possibility. CSS is now good enough and browsers are now compliant enough that a WYSIWYG HTML editor is feasible again. The parent article points out that you barely need Javascript any more. Lay off those overpaid "web designers".
Another one of the things I really miss about the pre-JavaScript, pre-CSS, document-oriented (as opposed to the current experience-oriented) web is being able to make my browser window half or a third of my screen, and having documents be eminently readable. That was really, really nice. Try it now, though, and nothing really works correctly. Which is weird, because a third-width window on a laptop or desktop has roughly the same proportions as a phone in vertical layout.