Company Culture & Trouble in Basecamp

The team at Hey recently decided to publish an announcement about their internal company operations. You can read it here.

The blog post itself clearly articulates both a cultural and societal point of view.  However it also points out that such discussions don’t make sense within the company.

First and foremost – Basecamp gets to choose their culture, and how they cover such topics.  That being said they are using their platform to signal a significant shift and choosing to do so in public. It would seem that they are inviting debate.

No more societal or political discussions – The point of a company is to create a profit and generally provide some type of benefit. These benefits tend to be for the benefit of society. Not being able to discuss society seems problematic.  Politics and company product decisions tend to go hand-in-hand.  Privacy, security, censorship, are both product questions and political discussions.  On January 6th Amazon, Twitter, Apple, Google, Facebook and others made technical product decisions that had massive political implications.   The politics of a company speak to its culture and values and it helps both employees and customers decide if they want to support a particular company.  Staying silent, actually speaks volumes. 

I’m not suggesting that internal company discussions should focus on politics. It’s reasonable to encourage such discussions to move to other platforms but asking for zero political or societal discussion seems broken too. 

No more paternalistic benefits – Benefits are there to help employees.  When done well, benefits allow employees to concentrate on work.  Health benefits, medical, dental, child-care, 401K, fitness benefits, etc.  The whole point of these types of benefits is to provide mutual benefit to the employee and company.  If done well these can provide huge financial, health, family and mental wellbeing and productivity impacts that individuals are unlikely to seek out on their own.

Focusing on financial funds implies that money is not just an important thing, it’s the ONLY thing that matters. 

No more committees  – It’s great to be able to have accountability within a company. The problem can be that individuals can impose norms onto an entire company.  Committees can provide a voice to people who are otherwise either un-heard or marginalized.  There are many topics that benefit from diverse voices. Having one person steer the ship makes sense but having many people helping plot the course and looking out for icebergs is even better. 

No more lingering or dwelling on past decisions – Lingering on past decisions is not productive but it’s also a signal that something else could be wrong.  This tends to happen when you don’t have team consensus or commitment to a decision.  If you have consensus culture rather than an authoritative culture then decisions that are unpopular will end up being toxic to the organization.  Organizations that are top-down will tend to repel employees who seek to be heard.  The “My way or the highway” attitude can work for some things but it can close you off from hearing the problems.

Basecamp’s is very unique company.  I don’t always agree with them but they spark good discussions.  This is one where I think they missed the mark in terms of culture, values, and vision. I suspect this was prompted by something internal but the “fix” seems to be misaligned with the root-cause.  

Companies have politics, committees and dwelling on decisions… Even if you say that they don’t, they still will. Solving the root issues around accountability, trust, and product vision will be the only thing that actually helps the company spend more time building better products.

Follow up video as more news emerged…


Building a Command Line Application using GPT3

GPT3 allows a simple and accessible API for accessing and using AI in an application. The application I wanted to create was a command line utility to quickly lookup commands and associated command line switches.

Cbot, available on Github.

The language processing of GPT3 is well suited to process natural language questions and provide results across a wide multitude of obscure commands that would otherwise be difficult to memorize.

Getting Started

The development process starts in the playground of the OpenAI website. The examples section provides a number of examples, my command line bot was a modified version of a translation example.

You provide a number of examples and can then modify the options within GPT3 to increase or reduce randomness and provide alternatives for start/stop sequences. The beauty of GPT3 is that you don’t need to provide a lot of examples for the software to get really good at knowing the types of responses that you want.

With 5-6 samples the application was reliably producing useful results. The OpenAI playground makes it easy to export the API call as either a CURL command or as a short block of Python code.

The resulting Python code uses a library called openai and is otherwise six lines of code, two of those are actually unused. (yes I reported this bug.)

Google Colab

I had never previously written much Python code and Google Colab tool was a great way to get started. It’s essentially an interactive Python editing and debugging tool, and since it’s interactive and in the cloud there isn’t much setup needed.

I copied the exported code and started playing around. If you have a GPT3 API key you can try my initial version here.

In playing interactively, I was more easily able to figure out how to parse the JSON and I realized that including the platform name (Mac, Windows, Linux) helped the bot determine the appropriate platform specific commands and platform specific options and folders. This really improved the quality of results.

OpenAI API and limitations

The current version of the software doesn’t allow fine-tuning of the GPT3 completion API using your own database. For use-cases such as customer service or email completion, the ability to further train GPT3 on specific large data sets would be particularly useful. I do think this is coming as fine tuning was part of GPT2, but it hasn’t yet made its way into GPT3.

The other thing to note about the API is that it does take some practice and exploration. When providing a set of examples, it was difficult to unit-test the examples against known and desirable results. Very subtle changes in the prompts would yield very different results and the software would occasionally get stuck in a loop, feeding off of its own content.

Building the bot

Once I had the basic code working in Google Colab, I was able to get a version running on my computer. I had never programmed in Python and I ended up actually using GPT3 to help “auto-complete” some of my functions. I would do this by going back and forth with the playground with blocks of code. It wasn’t perfect but it felt much more natural and collaborative than the alternative of jumping back and forth between StackOverflow pages.

The core bot used the basic prompt from the playground example and a SQLite database to keep track of requests/responses and act as a local cache. This is likely overkill at this point but I thought it could be interesting if a general database of questions and answers could be compiled, filtered, enhanced and sorted over time. The database also acts as a speed and cost buffer since the GPT3 API is not free and not always the fastest.

Some examples:

$>cbot "How do I count the number of lines in a file?"
  wc -l filename.txt

$>cbot "How do I get the mime type of a file?"        
  file filename.txt

$>cbot "How do I create a file with the text 'hello world'"   
  echo hello world > hello.txt

$>cbot "How do I open php in interactive mode?" 
  php -a

$>cbot "How do I set my email using git config?"
  git config --global "[email protected]"

$>cbot What is the current date

Advanced Tricks

After using the bot for a few weeks I started to add some more advanced functionality.

The -x option allows you execute the command directly. The -c option allows you to copy the answer into the clipboard (a little safer than just executing it.)

$>cbot -x "how do I put my computer to sleep"
  Sleeping now...  

The -g option allows you to ask general questions.

$>cbot -g "Who was the 23rd president?"
  Herbert Hoover  

Lastly, you can use cbot to save command shortcuts. So if you’ve remembered an obscure command you can save it for later.

$>cbot -s listall "ls -la"
  Saving Shortcut
$>cbot -x listall  

Open Source

While this code is open source, the problem is that currently OpenAI isn’t available openly and that API keys are only available to select developers. This makes it currently impossible to publish open-source software that is meant to be used by typical end-users.

I am hopeful that end-user API keys will be made available so that open-source AI software and tools can be made more broadly available.

Watch the YouTube Video

Try the Code

Follow me on Twitter


I made an eInk newspaper

I took a 32″ eInk display and turned it into a digital newspaper that updates every day. It’s silent, wireless and can run for months without being plugged in.

The display is based on the Visionect 32″ place and play display. This works by running two components. The eInk display acts as a thin client and has very little processing power. The eInk requires no power and the rest of the hardware just listens on an open port drawing very little power.

The display is 99% more power efficient than a traditional LCD, so the display can run for months without being charged. Because the display is a thin client it requires two external components to make it work. The first is an HTML rendering server. This fetches web-pages and renders them as a headless browser. It can then push images to the display. The second is an application server that fetches newspapers from around the country, downloads the PDF’s and turns those into images and HTML that can be processed.

The HTML rendering server runs off of a docker container provided by Visionect. A standalone server would be ideal but I couldn’t find documentation on the client/server protocol. This may be a future exploration.

Unless you are technical, I wouldn’t recommend running out and buying one. The server is setup via a docker container and I was able to get it running on my home Synology NAS backup server. The second part is the part that I wrote to fetch newspaper files from online sources like, a non-profit, that works on the first amendment freedom of the press issues.

The newspaper portion runs as a simple web-application fetching large format PDF files and resizing them to fit the large format display. You can find code for the project on Github. The result is a display that is both engaging and passive. There’s no buttons, no UI, nothing to touch or fiddle with… The newspapers cycle every 10 minutes. In the morning there’s always a fresh front-page to skim. The beauty of eInk is that it’s 99% more efficient than traditional displays like LCD. This means that the display can run for months and when it needs charging I can simply top-it-up.

Why did I build this? I saw something similar online a few years ago and I couldn’t find it for sale so I decided to built it myself. I worked on a newspaper when I was in college and my editor in chief Mike Bossi would always tell people to read multiple newspapers. He said that the truth is never in one paper or one story. Every writer has bias. By getting multiple perspectives you get a better picture of the truth.

This digital display is a little reminder of that. While most websites are powered by content management systems and templates. Traditional newspapers are sill designed by hand.

The design principals that work well in newspapers can also be applied in the design of our digital products. Balance, Prominence, Margins, Columns and more. A great newspaper design helps readers skim, read, digest and understand and when you can understand without any UI at all, that’s something special.

Like this post? Use my affiliate link if you decide to purchase the Visionect Place & Play Display:


CSS Still Sucks

In 2006 I wrote a blog post about how CSS sucks. The post was popular and somewhat controversial. It’s been 15 years and the core of the problem remains. CSS has certainly improved but it’s still holding back designers and engineers.

I’ve reposted the blog post with the original comments from blogger as the original site was taken down.

Sept 25th, 2006 – CSS Sucks

CSS is certainly an improvement on plain old HTML but its limitations are staggering and the lack of industry support will continue to hold back designers for many years to come unless we begin to build and design something better.

  1. For all that CSS has been able to do it’s a technological failure. CSS just doesn’t work as expected. How can I say it’s a failure when millions of sites use it? CSS can be used to style basic text attributes but browsers aren’t consistent in how they use this technology. Even though there is a “standard” and some browsers partially adhere to the standard to truly be a useful standard you need two things: Predictability and Consistency. CSS has neither. Any designer who has tried to create a large and complex site using CSS will tell you that all popular browsers interpret the standard differently.
  2. CSS is ‘markup centric’ not ‘design centric.’ I have this idea that designers should spend more time designing great looking sites and less time fiddling around with markup tags and browser compatibility. When I say ‘markup centric’ I mean that every CSS design tool forces users to go into source code mode to create an attractive modern site. Many designers take pride in hand coding CSS. Tools for designers should be design centric. PDF/postscript is a good example of a design centric markup , (unfortunately not very suitable for the web.) Designers don’t argue about how to create semantically correct postscript tags they just create great designs using great design tools. CSS sucks because it forces designers to think about how to make it work technically rather than how to make it work from a design perspective.
  3. Why on earth do we think that cascading is a useful feature? The way that styles cascade from one level of layout to a deeper layout makes it difficult to figure out why a particular item is styled in a certain way. By contrast non-cascading style sheets would be equally powerful and more predictable. The cascading makes it harder to interpret the page for both the designer as well as the web-browser. In fact the complexities in cascading is one of the reasons why so many browsers screw up the standard. In theory cascading could save bandwidth but in practice it creates bloated documents to get around the cascading issues.
  4. The box-model is too simplistic. The high level idea of CSS is that you can create attractive pages using margin, border, padding and content attributes. While this is a nice theory, it’s primitive in its understanding of both layout problems and design. Highly developed design tools have layout engines that offer multiple layouts, non-rectangular margins, proportional layouts, dock-able layouts, table layouts, column layouts, etc. etc. It’ll be years before these features make it to CSS and many more before browsers implement them with any consistency. If browsers keep spending so much time on CSS they’ll have a well polished turd. Tools like Aldus Page Maker had better design tools, font tools and layout capabilities 10 years ago. This is because good design tools start with the design, not the markup.
  5. When writing software you learn what works and what doesn’t. You get new and better ideas and you throw away the old ones. This process of starting fresh is absent from the current CSS way of thinking. Each version of CSS builds on the previous one without acknowledging any fundamental flaws. CSS and its HTML sibling are the ultimate designs by committee. Any enhancements to CSS/HTML are piled on top of the old standards. This makes it progressively harder to create powerful, compatible and consistent browsers. This also makes it harder for designers to create sites that target the new platform because they are constantly trying to satisfy the compatibility with older browsers. Version compatibility has to be all or nothing. If you support V3 it has to be 100% supported and tested. Supporting some of the features actually makes things worse.
  6. There shouldn’t be multiple right answers for a visual design. The way CSS works there can be many ways to do the same thing. In fact there seem to be endless debates about the proper way to hack together trivial things like rounded corners. Rounded Corners? I mean really! Again I refer you to Aldus and even MS Word circa 1997. These features are not that hard to develop but getting them to work in a “standard way” seems to be all but impossible.
  7. CSS captures styles not semantics or design intention. A design intention would be something like: “I want to balance these two columns” or perhaps “This text should line up with the logo image in the first column.” When designers do things like this:

    They are capturing the style specifics not the design intention. Why 32 pixels? Why 40%? Perhaps the logo is 32px tall? Perhaps the other column is 60% wide? When the logo changes size or placement how will you know what styles to touch? There is a basic concept called parametric design that can be used to specify the parameters of the design. This concept helps embody the design intention as a set of rules that can then be preserved as the design changes. Even a very simple parametric design allows you to preserve design intention rather then hard coding sizes and dimensions.

  8. Design should be declarative not interpreted. Again CSS has to process a large number of rules before it can figure out where things are supposed to go. After these rules are interpreted this data is thrown out and each and every browser that opens up the web-page has to re-interpret the data. This is incredibly inefficient. First of it makes web-pages load very slowly. Even when you’re on a fast connection the browser can’t figure out where to place objects until the entire web-page has finished loading. Secondly this interpretation is very prone to errors. A declarative design isn’t open to as much interpretation allowing it both render quickly and consistently.
  9. CSS is a pain to work with. Take a look at some of the designs over at CSSZenGarden. The designs are both attractive and sophisticated. A good designer could take these designs and mock up similar designs in PhotoShop or Illustrator in a matter of hours but take the same designs and ask for it in CSS and it may take a couple days. Each time you make an edit to your CSS you have to refresh your browser to see what it’s actually going to look like. Then after you get one browser working you need to double back and get the other browsers working.
  10. If you can’t get consistency across browsers then you can’t rely on CSS to accurately and properly design your site. If you can’t get the site to look exactly the way you want on every single browser then how can you claim that CSS is a good design tool or even a success? The fact that there is no alternative to create attractive websites doesn’t make CSS a good tool. There are two ways to solve the problem. The first is to continue to hammer on standards and CSS asking for a better solution. This has been happening for the last 10 years and it just doesn’t work. The alternative is to realize that CSS is flawed in it’s intrinsic design and begin to ask the questions of how could you do it better?


Archived comments from the original posting


39 Archived Comments:

Chris Moritz said…
Well put. Someone had to say it.Not that I’d recommend heading back to table-land…



September 25, 2006

Jordi S. said…
Greg, I think the problem is not exactly CSS but the lack of good CSS tools; advanced CSS editors should manage cascading, consistency, etc.Yes, editing CSS “by hand” is really painful, but no more than editing an image pixel-by-pixel; that is what tools are created for.


And about this:

“If you can’t get the site to look exactly the way you want on every single browser then how can you claim that CSS is a good design tool or even a success?”

Ups, “to look exactly the way you want”? That is not what a web site is for. What about usability and accesibility? Users should be able to change font size; and they may have big or little screens; or … If you want control what users exactly see, give them a paper-sheet.

September 26, 2006

Greg Raiz said…
Jordi S. – The lack of a tool is certainly a problem but Adobe/Macromedia is quite capable of creating high-end design tools. The reason that HTML/CSS is a disaster isn’t because Dreamweaver isn’t a good tool, it’s because it’s trying to design a tool around a technology rather then creating a great design tool then figuring out how to express that freedom using technology. The formula is backwards, it’s markup centric and that’s the flaw.The web is for creating designs that look exactly as designers want. Don’t believe me? Just take a look at any high-end site like espn, msn, yahoo, abc, nbc, microsoft, apple, dell, amazon, etc, etc. All these sites are all designed down to the pixel and they all care about usability and accessibility. It’s not a trade-off you can have good design, accessibility and usability.
The problem is that it’s a an enormous pain with css.


I didn’t touch on accessibility but let’s call it a potential #11. People abuse css by turning lists into hover menus, fixing font-sizes so they don’t scale when the font increases and all sorts of other tricks that are totally not-accessible.

September 26, 2006

Jordi S. said…
well, I use Dreamweaver and let me tell that it’s not ‘great’ editing CSS. It’s probably better than any other editor, but there’s a lot of things that could be improved (although it’s a hard hard work).Sorry, I don’t exactly know what you mean by ‘high-end site’ (poor English, you see), but let’s take the model-for-ecommerce one: Amazon.


In Amazon users can change font size, the design ‘flows’ depending on screen-size, … Well, if you mean that designers want exactly “an usable design”, then I agree with you 🙂 But Amazon is not controlling design to the pixel (and they are doing right!).

Yes, you’re right: CSS may be wrong used against usability. But… it’s powerful, so it’s dangerous (as nuclear power is).

So I won’t say CSS sucks… No more than some tools suck, or some designers suck. CSS simply is not perfect 🙂

September 26, 2006

Ross Johnson said…
“The web is for creating designs that look exactly as designers want. Don’t believe me? Just take a look at any high-end site like espn, msn, yahoo, abc, nbc, microsoft, apple, dell, amazon, etc, etc. All these sites are all designed down to the pixel and they all care about usability and accessibility.”Most of those sites are fluid and/or scalable sites. When you start designing sites that look differently dependant on browser/text size you are far far from pixel perfect design.


Every time I read posts such as this there always seems to be more of a “frusteration” than a good understanding and criticizm.

Your proposal to design a tool around the technology is a bit unrealistic. Shall we just convince all browser makers (including the ones that can’t even get CSS right) to just adopt a new technology?

Oh but wait, there is flash – and flash has it’s share of problems as well.

Once you get the hang of CSS it all makes sense and it is not frusterating anymore.

September 26, 2006

Mike G said…
This is a very, very good article. CSS is a disaster.
September 26, 2006

Montoya said…
Sorry Greg, but your post only shows how little you understand about the technology and the implementation of it, as well as the nature of the web and information exchange. Your “design centric” view of web design is limiting you and preventing you from adapting to a technology that offers improvements, not setbacks.It’s easy to argue about problems in any language, be it programming, markup, or a description language like CSS. Your post sounds very similar to an inexperienced programmer having trouble with the intricacies of the C language or someone who has never dealt with OOP before and encounter Java for the first time. If you had the experience, you wouldn’t blame the tool, but rather you would recognize that all of your complaints are the fault of both the implementation and simply the young age of the technology.


As a junior educator contributing to a college course with over 100 students learning CSS based design (as well as PHP programming), I can assure you that CSS is neither hard nor painful; if 100 students can learn it every year, and produce highly flexible, lightweight, and attractive designs with it, then maybe you just need to go back to school (and I say that without intending to offend you).

September 26, 2006

Greg Raiz said…
Montoya – Sorry but I do understand CSS, Java, OOP, C++, PHP and other languages. I don’t consider myself a CSS guru far from it but I do know the technology well enough to know it’s flaws and limitations. I’m also pretty familiar with it’s implementation having worked at Microsoft and having worked on a project for Firefox.I know that it is possible to create great looking designs in CSS. That’s not the point. The point is that creating these great looking CSS sites take significantly longer in CSS then in most other design tools even if you are a Guru.


I can design something for print production in roughly 1/10th the time it takes to design something for the web using CSS.

The fact that you are blaming me for not understanding is just funny. Your own portfolio proves my point:

html { font-size:100.01%; }

As a designer you shouldn’t have to fight the CSS and the browser to get what you want.

September 26, 2006

Montoya said…
greg: If someone came to you with a rant about C and all the intricacies of it, and posed those as problems in C and complained that something new and better is needed, you probably wouldn’t waste much time with them, but simply explain that if they understood the language better they would understand the how and why for everything.I never said you were not an expert in everything *other* than CSS, but my point still stands: you don’t know much about CSS. For people who learn it (and I can tell you, it’s not hard to learn when you have a good teacher), the development time is significantly less than what could ever be achieved with tools like Dreamweaver or Frontpage. Time spent fixing bugs, on the other hand, is not the fault of the technology but the fault of a certain browser which is 8 years old. Anyone in the software world knows that 8 year old software is very difficult to deal with, and blaming a new technology for problems with outdated software is putting the blame in the wrong place. An example like:


html { font-size:100.01%; }

wouldn’t be necessary if it wasn’t for IE 6 being so common, but who do you blame that on? The W3C CSS group, or Microsoft? Mind you, it’s a bug in Microsoft’s software. Maybe that will help you shift the blame in the right direction.

You said: “I can design something for print production in roughly 1/10th the time it takes to design something for the web using CSS.” Will your print design scale to the user’s window size? Will it allow the information to be used by multiple user agents (machines as well as humans, including humans who access the web in alternative ways rather than just visually)? Will it offer multiple styles? Will it be easy to modify in the future?

Or are we comparing apples and oranges?

The truth here is you don’t understand the web. You understand print design, and client side software, and even browsers, but that doesn’t give you any knowledge of how the web works. I still challenge you to really learn the medium, the technology, the research and the philosophy behind modern web design practices and why things work the way they do. If you did, you would understand why “problems” like cascading are actually features, and why this new way of looking at websites is a step ahead, not behind. Until then, you are entitled to your opinions, but you have no credibility to back them up.

September 26, 2006

Anonymous said…
I 100% do not agree with you.
September 26, 2006

Greg Raiz said…
To those that don’t agree…I don’t mind that you don’t agree. The fact that there seems to be a range of opinions means I touched on something that is perhaps partly true. I doubt that I’m 100% wrong but I’m fairly sure I’m at least partially right 😉


Counter all 10 of my points if you want. Explain how a markup centric
language is better for design. Explain why consistency is not a problem. Explain why cascading is a good thing. Explain how things like CSS hover menus are a good for accessibility.

Go ahead and convince me. I’ll try to keep an open mind.

September 26, 2006

Scott said…
Nice job stirring the pot Greg. Hope it gets you some business. I’ve taken the time to
rebut your ten points on my own blog (not trying to spam; I felt it would get a bit long in the tooth to do it in your comments section).Mr. Montoya is corrent. You have a limited understanding of the medium. (Oh, and his website kicks ass.)


September 27, 2006

Greg Raiz said…
Scott, good comeback.I didn’t write it to be provocative. I think CSS limits what designers can do. I see these limitations everyday. There are many designs that are difficult to do in CSS but there are others that I have found impossible.


I believe CSS limits the creativity of designers by imposing technological constraints on visual designs. This may be because I come from a print background but that doesn’t change the fact that I still feel limited.

While CSS can be incrementally improved I personally think it’s important to think about how to make large improvements rather then incremental ones.

September 27, 2006

Michelle said…
These are very valid points. I’ve actually seen people praise a website redesign that was nothing more than a small menu, background gradient and an input box on the page. I think there is an “elitist” attitude when it comes to table-less CSS sites that is getting in the way of advancing this technology. If you speak up about the problems with CSS and how you have to learn all these hacks and tricks to get a somewhat usable site, you get the typical answer that it will get easier in time. How long do we have to keep waiting? The reality is that most people don’t have time or patience for complex workarounds. Designers and developers should demand better.
September 28, 2006

Anonymous said…
CSS is merely a means to an end, and the best one for the way the WWW is supposed to be at that.CSS has nothing to do with design whatsoever IMO, and thus shouldn’t be judged by design.


Also, it is very easy to make your website look the same in all browsers.

September 28, 2006

Brett Mitchell said…
And your alternative? You’d prefer to use tables?CSS is a standard, which all browsers (with the exception of IE) try to adhere to. As they get closer to meeting that standard (like Opera9, the new Firefox 3 (Gran Paradiso), the ability for code to be handled identically across platforms and browsers is getting better.


Of course, IE is and always will be the exception. While it is consistantly behind the other major browsers, support is slowly improving.

The point of the internet has evolved to be a source of information and entertainment that is widely available to everyone, everywhere – be it on a cell phone, by a visually impaired person with a braille keyboard, or your average citizen.

The internet isn’t a newspaper. You don’t have absolute control over what your viewers see. You seem to miss the point that the fact your viewers ultimately have control is the benefit of the internet – it’s customizable by individuals to meet their needs. If they need the font size larger, if they need to lower or raise the contrast, or they can’t see and they can have a browser speak to them.

CSS isn’t the be-all and end-all of design – you’re correct. If you want a design that aligns down to the pixel and has the perfect colours on every monitor/browser/platform, HTML is not your best bet to start with, and NO interactive language with the flexability of HTML could do that anyway.

HTML and CSS are easy to learn, cheap on bandwidth, viewable in every browser made in the last what, 6 years, including PDAs/cellphones…

What is your alternative?

September 29, 2006

Phillip Ryals said…
Greg, as I read your thoughtful list, I came to the same conclusion that Montoya has voiced… that you are essentially a print designer who might not fully understand the web world.I absolutely agree that web design using CSS is horribly lacking from a design perspective, but just because it doesn’t give a designer a WYSIWYG interface doesn’t mean it sucks.


You push the idea that ‘something better’ should be created, either by fixing CSS or replacing it outright. I challenge you… how would YOU create this fictional superior method of describing a complicated design using RAW TEXT?

You see, from a designer /and/ programmer’s perpective, CSS is a very good tradeoff. No, I can’t draw a few boxes, apply some drop-shadows, scale some fonts, and see the results in a web browser. That’s life. Vector graphics for the web has been tried before in many many ways (anyone remember the Xcalibur BBS?) but it’s never taken off because it still requires more processing power than just rendering raw text.

The point is, you’re not going to get an easy-to-use method of creating complex designs. They’re complex, and so the method for creating them is complex. While CSS rendering isn’t predictable across all browsers (NOT the fault of CSS), it does indeed make many things possible that would otherwise never work.

September 29, 2006

Dean Hall said…
Clearly CSS is not perfect. Greg touched on some good points like cross-browser compatibility. I certainly agree that CSS does not offer me and my clients a complete solution. Frankly, I don’t give a damn if it helps anyone else or not – I’m about getting my projects completed.I still use CSS, but I note the fact that it doesn’t work the way I need it too. Ie. When I design a site using CSS, I have no assurance it will look and perform the same across browsers and technologies. I t goes some way to this though, and I still use it. But I still use tables for some projects too.


My rule of thumb is “Consistency, Consistency, Consistency” when it comes to a GUI. Neither CSS or anything else gives me an assurance of that. So I do what all developers do and I do whatever works. If CSS works for a project, then I use it. If it doesn’t look like it will, I use tables.

I thought this was a good article, with some valid points.

October 04, 2006

Anonymous said…
CSS’s strongest argument is only its swarm of fanboys. At least with tables, when I resized my browser window, it didn’t break a site’s design or make it completely unreadable. It kept the content locked in an accessible place. It says a lot about CSS when Photoshop’s table slice-generater, though it creates nightmarish html – it can autogenerate readable code and looks the same on every browser. If CSS can’t even claim what the joke “Adobe Photoshop’s HTML” could accomplish, it’s simply pathetic.
October 17, 2006

Anonymous said…
Totally agree with what Montoya is saying, nothing to add.Greg I just want to ask you what if I told you that Quark will no longer be supporting style sheets? Would you be ok with that? Even if you were working on a 120 page document? I’d be pissed, just like I would be pissed if they took away CSS.


October 20, 2006

Anonymous said…
All these people repeating that Greg’s a “print designer who doesn’t understand CSS” just don’t get it.They have adopted themselves to the css mentality, instead of adapting the technology to design needs.


Most miss the point altogether, like:

Greg I just want to ask you what if I told you that Quark will no longer be supporting style sheets? Would you be ok with that? Even if you were working on a 120 page document? I’d be pissed, just like I would be pissed if they took away CSS.

This is irrelevant. Greg has not talked against the general idea of stylesheets, he talked against the CSS concept and implementation in particular. His points are specific and razor sharp, and could be used in designing a BETTER stylesheet language for the web. Like this point:

CSS captures styles not semantics or design intention. A design intention would be something like: “I want to balance these two columns” or perhaps “This text should line up with the logo image in the first column.” When designers do things like this:
#content{position:relative;top:32px;left:20%;width:40%;}They are capturing the style specifics not the design intention. Why 32 pixels? Why 40%? Perhaps the logo is 32px tall? Perhaps the other column is 60% wide? When the logo changes size or placement how will you know what styles to touch? There is a basic concept called parametric design that can be used to specify the parameters of the design.

Right on!

And since a lot of web pages nowadays are “web apps”, are you “css people” familiar with actual programming for GUIs? If you know GTK, QT, Java or what have you, they all have MULTIPLE layout models. CSS only has one, and a cripled one at that, the box model. A single model cannot solve all needs. (btw, almost all languages offer a table or grid layout manager, without sacrificing “fluidity”).

Some points:

a) The concept of styles is correct. It’s CSS that has it all wrong.

b) Design should be intention based and parametric. Hell, CSS does not even have parameters! If I want 20 design elements in my stylesheet to be 200px (or 20% or anything), I have to repeat myself 20 times over. When I want to change it to 200px it’s 20x times the work actually needed).

c) A lot of stuff should have been built in, in CSS and HTML and easier. Rounded corners? Blow me, just have something like:

#box {curve-top-right: 20px }

or have a way to define such effects in code blocks and share them.


October 21, 2006

Anonymous said…
I partially agree. But at the same time, a number of the problems I have personally faced with CSS is browser compatibility. But I really can’t blame CSS for this; it is the browser’s fault. If an alternative to CSS came out, the browsers are still capable of fudging it up and making it difficult for the designer.I would say CSS could be better, but I would not say it sucks entirely. For every language, there are flaws and limitations and drawbacks. I can’t really appreciate the suckiness of CSS, or the lack thereof, until there are more alternatives to choose from.


October 21, 2006

Nick Presta said…
c) A lot of stuff should have been built in, in CSS and HTML and easier. Rounded corners? Blow me, just have something like:#box {curve-top-right: 20px }


Oh, you mean like CSS3’s border radius property?

October 30, 2006

Anders said…
“b) Design should be intention based and parametric. Hell, CSS does not even have parameters! If I want 20 design elements in my stylesheet to be 200px (or 20% or anything), I have to repeat myself 20 times over. When I want to change it to 200px it’s 20x times the work actually needed).”Or you can learn what cascading in CCS means and how to implement it.


October 30, 2006

Rich C said…
It says a lot about CSS when Photoshop’s table slice-generater, though it creates nightmarish html – it can autogenerate readable code and looks the same on every browser. If CSS can’t even claim what the joke “Adobe Photoshop’s HTML” could accomplish, it’s simply pathetic.Photoshop’s supported CSS slice-generation for a while now.


Web sites I build using CSS positioning for images are a lot more readable and maintainable than those I used to make using table-based layouts.

October 30, 2006

Greg Raiz said…
To the previous comment. even if you know CSS this still doesn’t address the lack of parameters. You can work around some of this with cascading classes but it’s not a great solution.a declarative approach would have:
.logo {height:logoh;}
.titletext {top:logoh+smallmargin;}


I’m using the $ show how you could declare a parameter/variable. This is still declarative so it’s not an ideal solution but at least it demonstrates how parameters could allow you to do things that are difficult or impossible to do via traditional cascading.

October 30, 2006

Anonymous said…
@Anders said…“b) Design should be intention based and parametric. Hell, CSS does not even have parameters! If I want 20 design elements in my stylesheet to be 200px (or 20% or anything), I have to repeat myself 20 times over. When I want to change it to 200px it’s 20x times the work actually needed).”


Or you can learn what cascading in CCS means and how to implement it.

Erm, cascading != parametric.

In the case I describe, for example, who told you that the 200px always refers to the same attribute (like width?). It could 200px of width for this element, 200px padding for the other, et al, used for implementing a consistent grid.

Or I could want a yellow background-color in one item, and a yellow foreground in some text or a yellow border in another. Cascading does not offer a way to define all these cases depending on a single color definition.


October 30, 2006

Daron said…
Well, Greg, in truth, it’s the entire technology of the web that sucks.Your comparison to Postscript and the evolution of Page layout programs is spot on.


HTML, CSS, Javascript and all their evil offshoots are a result of:

* an inadequate and limited initial definition of the “web page” problem domain

* a crude, fatally flawed but simple to use initial technology (HTML)

* which lead to designers and programmers crufting up a mind boggling array of workarounds to fill the gaps (Tables and Spacer gifs)

* which spurred a belated attempt to redefine the underlying technologies by rigid academic edict mainly by non-designers (Cascading Style Sheets, XHTML, Widespread Deprecation)

* which was anyway largely undermined by the piecemeal and incompetent implementation of the new technologies in browsers and development tools (all of them)

* which is now all welded into place by the network effect, endless inert committees and monopolistic self interest. (Welcome to the Great Leap Backwards)

We are stuck with a kludge built on a kludge until we have a disruptive technology.

And Flash wasn’t it.

October 30, 2006

bjk2007 said…
HAHA!!! Disable CSS and take a look at this page! If this site doesn’t show how great CSS is, then what does? All you see is a perfectly fallen apart page, just like you should see with a CSS site. Just take a look at the source.
December 06, 2006

Greg Raiz said…
bjk2007 – Just because you ‘can’ make a site work with CSS doesn’t make it a good tool. The CSS for this blog came straight from Google’s blogger tool (2006). It’s full of all sorts of silly things that show just how hacked it is,Yuck! Yes there are certain things that CSS can do well, and it’s certainly better then plain old HTML of 1996. But as a generalization, it still sucks.


December 06, 2006

bjk2007 said…
First off, I’m sorry if my last comment was a little offensive. Tables vs. CSS is a controversial web design topic. I came across this blog entry following the post of a member of a web design forum. Let’s just say he can act really stupid sometimes and I came here pretty upset after being personally insulted by him.
I did take the time to read it again after I had calmed down. I would have to say that while I disagree with you on several points, I do agree that CSS hasn’t done as well as it should have. Why? Simply browser support (IE). If we can’t get them to support CSS, how can we ever assume that they’ll support the newer and better theoretical CSS replacement language?
I guess the rest of my disagreements with you lie in a coder/designer mentality. You seem to be more of a designer while I’m actually a person whose strengths lie in coding, so we’re bound to disagree on how things should work.
December 07, 2006

Anonymous said…
You all must be joking. CSS is without a doubt the future of web design. WHY because css is exactly what xhtml needs to work and xhtml is going to be the future. WHY because it is (finally) a consistent DOM markup that will be able to be used by many varying systems.
Not Microsoft, Netscape, Mac whatever can stop a standard being created, fact is those “browser companies” don’t make websites or web application (well they do make some) and developers NEED a standard so they aren’t writting 12 different lines to support 12 different venues. With these 2 standards (CSS2 and XHTML) we will have easier to maitain websites, portable applications, accessibility features for the blind/hearing impaired and about a million other applications.
December 12, 2006

Anonymous said…
The CSS Design When it comes to a fulfledged dynamic site it has more cross browser conflicts which are not easy to fix.


December 18, 2006

josh said…
CSS is terrible. I’ve spent countless hours learning it and no matter what, the results are different from browser-to-browser.I can’t stand learning it, but at the same time I love the way some of these Css-driven sites are put together. I think to myself “I want that!” But it never happens. CSS is driving me insane. It always will drive me insane. Has potential, but it sucks.


December 22, 2006

John Nagle said…
You’re absolutely right.With Dreamweaver 3 and tables, it wasn’t necessary to look at HTML to lay out a page. With Dreamweaver 8 and CSS, the page designer must understand CSS, HTML, and probably Javascript. That’s was a big step backwards.The CSS system is just too programmer-oriented. And I’m a programmer. (Programmer as in MSCS from Stanford, the Nagle algorithm in TCP, inventor of ragdoll technology, real-time robot vehicle control, not programmer as in “writes some Perl”. And my first web site went up in 1995.) It’s not that CSS is hard; it’s that CSS is bad.


CSS is, simply, a badly designed layout system. Even the rather simple system in Tk which lays out dialog boxes and windows is better. Tk is a nested-box system, but both “pack” (like CSS “float”) and “grid” (like tables) layouts are available in the same system. This is enough to handle most cases. Which “float” and “clear” are not. Page layout is forced to fall back on absolute positioning far too often.

The clever way to do layout would have been with a constraint system. Each box has four edges and four corners, and it would be possible to bind corners and edges to create any desired relationship between boxes. This is something one could express easily in a click and drag graphical tool. Want three columns the same height? Tie their adjacent bottom corners together.
Want to fill the page? Tie the outside corners to a page edge. Ten minutes to explain to an artist. Advanced use would involve priorities on constraints, so if something had to give in “fluid design” as the page size or type size changed, you could pick what gave first. (This could be extended to allow curved boundaries, even splines, but that might be overdoing it.)

The browser would have to have a constraint engine to resolve all the constraints, but there are known solutions to that problem.

Too many people drank the Kool-Aid on CSS. It’s just not that good a technology.

January 07, 2007

frostbyte said…
You missed the biggest problem of all. CSS dogma. We’re now at the point where questioning CSS is no longer politically correct. Just look at the anger in the replies. (Especially Scott’s. Check out his blog, you’d think you just insulted his mother. Warning: Horizontal scrolling)If you question CSS at all, you’re immediately laughed off as just another unskilled newbie who doesn’t understand, or some old timer who can’t get past tables. Even half the people who agree with you felt the need to clarify that they only agree with some points, “please don’t think I’m in the same camp as the anti-CSS crazies”.We’ll never get past CSS because it somehow became dogma and you can’t question the dogma.


January 09, 2007

John Nagle said…
The worst problem with DIV-based layout is that the layout system is too weak. There’s no form of “grid” layout. There’s no way to relate a DIV to anything but its predecessor, its parent, or an absolute position. The system is just too dumb. That’s why people have to stand on their head just to get three columns to work.Tables actually are a better designed layout system. Table layouts allow table cells which span multiple rows and columns. If all tables could do were simple grids of cells, the CSS approach might make sense, but tables are more general than that. And they’re well supported in Dreamweaver.The fundamental limitations of DIV-based layour are obscured by an excessive number of attributes and the occasional use of Javascript when the attributes aren’t enough. But underneath, the fundamental approach is just too weak.


If CSS had a grid capability, it wouldn’t be so bad. But it doesn’t.

January 10, 2007

Anonymous said…
Greg – thanks for this spot-on article. After working the Web for 10 years, and still struggling to get decent CSS layouts that work with php includes, I was beginning to feel that I was getting stupid in my ‘old’ age. In fact, CSS is far less intuitive than our previous nemesis (Tables) and especially difficult when you introduce any “includes’ into CSS design layout. And on this note, Dreamweavers Layer layouts only work when using plain vanilla .html files. Try making absolute layers stick in place if you use includes with Dreamweaver layer layout – a hair pulling exercise that forces one back to Tables very quickly!
January 27, 2007

Anonymous said…
Whether you like it or not BROWSERS and specially IE mandate what we use in the market. Check the logs of your web servers and then disagree with that.Read this was part of the workgroup for CSS and what we tried to do back then has nothing to do with what people fight about today.


It was about separating format from markup to create data semantics.

Greg you are right on the nail. I wonder how many of these so called “CSS Designers” have the BIG profitable accounts.

Can you make the money with CSS on these sites using CSS, I dare you?
Look at these:

Go on, make one of these (CNN for example) using CSS no hacks, js, pure w3c css. Publish the markup as a test and let us see that you know your css stuff.

Montoya you are the teacher, or is css only for the graphics blind? Prove Greg wrong, go ahead and make my day.

CSS can not do what the tables and flash can here. Forget semantics, forget standards, come and visit me for a little while in reality land. Bottom line people, hard cold cash it’s what matters.

Montoya get off you high horse and do something about it. Rewrite the standards so is more workable.

Use what works, and if you can separate format from markup with css and if tables have to be used so be it and format them in your css.