In 2006, I entered a web design class in a local private school. We "learned" to design websites in Dreamweaver, using tables for the layout. I remember once, the teacher told us that, in order to achieve a particular layout, we had to delete the doctype. It didn't strike me as stupid or even wrong. I was still very new to the web world back then.
We then had a single accessibility class with a guest teacher. He taught us accessibility guidelines, about the necessity to seperate content and design, and eventually told us about CSS Zen Garden to showcase how it was possible to achieve multiple layouts with a single content page. My friend and I looked at each other and had that silent "Waou" look.
This revelation led me to buy a book about CSS, and got me my first job. If it wasn't for CSSZG, I wouldn't have enjoyed web design as much as I did and turned it into my job for 4 years. And I'm sure this simple project has enlightened thousands of other web designers as well.
This is the site that got me to move away from tables. My how time flies! Remember the days when teeny tiny microfonts were in style? Also Photoshop orbs... Everywhere, there were bloody orbs; from gaming forums to "tutorial sites" (that linked to other sites). Part of me feels nostalgic, but another feels it's good to grow out of all that.
In many ways, we were entering a Goldilocks zone for a semantic and accessible web, but I fear we're starting to slip back a bit into a client-side dynamic web phase that isn't accessible, not semantic and overall app focused. Which is fine if you want the web to be a series of apps, but there's a heap of content in there too. And it would be a shame if it only became accessible via apps.
"Webkit-only designs will be discarded with prejudice... Graceful degradation is acceptable, and in fact highly encouraged."
Can't tell you how happy I am to see that they haven't lost any of their sensibilities.
> but I fear we're starting to slip back a bit into a client-side dynamic web phase that isn't accessible, not semantic and overall app focused
I agree with the overall sentiment that content should be accessible; but one thing you aren't taking into account with the above statement are the channels by which we access the content. Today REST APIs are that channel, and serve as the backends for the dynamic heavy client apps, as well as a medium for other services/applications/users to interact with and consume that content.
I'd argue that it allows for an even more semantic manifestation of data and content, since we aren't limited to defining semantics with just a series of tags wrapping content; served to clients in large homogenous blobs of HTML in readonly fashion.
Instead we expand our conceptual space to include HTTP verbs, headers, and URLs to provide an interactive interface to data that far eclipses what the "Semantic Web" movement was ever able to deliver.
even more semantic manifestationexpand our conceptual space
What exactly does all of that mean? REST is just a subprotocol of HTTP. It does add some guarantees about server behavior, but it does not make chunks of JSON any more semantic than if they were served over FTP.
The simplest example of why HTML is semantic (and the underlying benefits) is the very textarea I'm writing this in. I can resize it to accommodate larger messages I'm typing. It does spell-checking. The functionality was developed once and now benefits thousands of people visiting thousands of websites. Moreover, I can rely on it and control it. All of this thanks to semantic difference between textarea and some random div. This wouldn't be possible with some random JSON format or custom JavaScript control.
Fair enough. But then a REST API isn't a panacea since browsers(or content parsing apps) need go through a new iteration from rendering content "as-styled" to "as-meant" for a semantic web. We don't have that yet and it doesn't look like vendors are going down that path any time soon. Then there's the question of text-only browsers like Lynx.
A semantic web as you describe isn't the current web at all, but a new completely new layer on top of it.
Readability, Instapaper, and Pocket all do a pretty good job of "as meant" for sites.
The do this through a server-based solution, with some reliance on standards, but also, I'll suspect, a large number of site-specific parsing and formatting rules.
I wholeheartedly agree with you that CSS / Ajax design are jumping the shark. I've found myself for the past couple of years increasingly fighting websites and their design in the interests of simply being able to read content. I've flagged numerous submissions to HN on that basis alone. And joined the Contrast Rebellion (http://contrastrebellion.com/).
After using element editors to interactively correct issues, userContent.css to override settings (especially font face, and size), and other hacks, I stumbled across Readability. First the bookmarklets and browser plug-ins that simply reformatted pages to be more readable, then finally finding that the full-blown service, including saved reading lists and tags, was worthwhile to me.
Which addresses another failing of browsers: the insanely poor UI/UX of bookmarks management. It's not just the sharing aspect, but being able to enter, arrange, tag, annotate, deduplicate, etc., bookmarks.
I've been seeing a place increasingly for two modes of browser: an app-mode browser for highly interactive sites, and a content browser, whose aim is to provide access to, and management of, informational content.
One mode I've found Readability hugely useful for is in bookmarking, categorizing, prioritizing, and reading a large volume of literature related to research I'm doing. And presenting that information in a way that's tolerable to read. The only downside so far: a per-user limit of 500 tags.
I'd also love to have something resembling Readability (preferably itself) for PDFs, which are absolutely awful to read online, and impossible on mobile (yes, I've got Adobe's PDF reader for Android, it's freaking useless).
ePub and readers such as Calibre and Moon+Reader are another approach to online documents I very much appreciate.
The grey background on posts makes the site harder to read. I'd prefer the color scheme was inverted. It's not quite so bad as those which make me hit "Read Now" (or close tab) reflexively. But it is annoying.
Wow, 10 years is a long time. Getting a design of mine in the CSSZenGarden was one of the biggest accomplishments of my life still to this day. I'm pretty sure that it's responsible for bootstrapping my career.
Same here. I was 16 when I had my design featured in CSSZenGarden in 2005 (it was this one http://www.csszengarden.com/?cssfile=185/185.css) and, although it did not bootstrap my career by any means, it has certainly been something I'm really proud of. Most front-end developers nowadays do not realize how important that website was back in the day.
I remember when I discovered CSS Zen Garden I was astounded at what could be accomplished just changing the CSS of a page, and it was a great inspiration to learn how that worked. Thanks to the creators and the contributors.
Last month, I gave our interns a one-hour overview of HTML and CSS, and used CSS Zen Garden as an example of how you can completely change the look and layout of a page. They were appropriately impressed. :)
I distinctly remember my "A-ha!" moment in understanding what CSS could do. It was while looking at Zen Garden. I spent hours just clicking "next" and examining the source code from each design.
Ah, ten years of separating content from style. It promised then that if designed properly, any page from the last decade can look contemporary by just changing the CSS. I think CSS Zen Garden is itself a proof of that.
Well. Suddenly I'm hit by memories of childhood days thinking FrontPage was the best thing ever... and maybe was it Nvu before or after that? (Who remembers Nvu of all things?) And Java applets taken from a book just to have fancy rollover buttons, the obligatory tables-everywhere, soon enough the rise of Flickr, with the following trends of vowel dropping and glossy images everywhere with Trebuchet MS in hand, or maybe using Flash text replacement, and soon enough we're here.
A dream never realized...(sadly)...that one day websites would be redesigned by only changing the CSS. I'd love to hear everyone's opinion on why this doesn't seem to happen, in practice.
Unfortunately, something that CSS Zen Garden has also demonstrated, however unintentionally, is that to have so much flexibility with CSS you also need a bunch of extra non-semantic mark-up in the original HTML. We've developed a few tricks over the years using things like pseudo-elements to avoid some of this, but the HTML+CSS model isn't quite powerful enough at the moment to really live up to the ideal of complete separation of content from presentation.
Probably because it's extremely rare you change only the visual element of a site. Total graphic redesigns are often accompanied by more traditional upgrades and feature requests.
I frequently change fonts, adjust margins, borders, colors, positions of elements on my sites all the time. I might not be doing anything radical but I am redesigning the site in it's entirety every time I change the CSS.
Imagine how difficult it was to just changing the font size on a website before CSS.
I remember that site back when I was first making web pages in Frontpage (and uploading them on a tripod.com free hosting account i think). I am pretty sure that site was one of the main reasons I wanted to learn css, after realising stylesheets can do more than just style a:visited and a:hover. took a while before it clicked though!
I remember my first design without tables. It was for my private blog and I am not sure how many different designs I looked up on Zen Garden to find out how to do something with only CSS.
After some struggle and building two or three designs I finally understood why this was a good idea. It is one of the resources I am really thankful for.
Dave Shea's ZenGarden, MezzoBlue and AListApart were, and still are, huge inspirations to web designers. I followed those blogs intently in High School. ALA's 2004 CSS sprites post was largely responsible for its widespread adoption.
I've used CSS Zen Garden as a powerful example what CSS is capable of. I did a lot of teaching, preaching and evangelisation for the fellow developers stuck in old ways. I've used wired.com, espn.com, fastcompany.com as an example of "serious" sites employing CSS and Zen Garden as a showcase for flexibility. Good times…
Wow, I feel old! I remember stumbling upon this site back in the day when I was getting educated about CSS and separation of presentation from content.
It was a great inspiration and led to much self-improvement and learning. Some good times, for sure. OTOH, I don't miss IE6 and box-model hacks one bit.
Back in the days I was always amazed of what people pulled off with just CSS. With the enhanced capabilities of today's CSS I look forward to see the results.
The 'mission' may be a bit different now, though. Instead of advocating the use of CSS, CSS is now the standard.
Call me ignorant, and I may be missing the point... but did anyone else notice this does not scale at all on being resized to tablet or even phone resolution?
It's old. In those days tablets didn't exist. Web-enabled mobile phones weren't a common thing (except maybe in Japan) and they were based on specific technology like WAP.
Most of those designs aren't even good designs by today's standards. They're too cluttered with visual decorations. But at that time it was great!
The bizarre rationalization of "make sure your website works without Javascript or CSS enabled" is false, but I understand if it helps programmers.
However it is bizarre. Functional sites are what the customer wants, and that combines HTML, Javascript and CSS. which every browser worth mentioning is capable of rendering.
(if you can't think of why anyone would care about separating content and design, think of a site that needs to work in both mobile and desktop browsers. How can you achieve that without separating design?)
> (if you can't think of why anyone would care about separating content and design, think of a site that needs to work in both mobile and desktop browsers. How can you achieve that without separating design?)
Well, you could serve the normal page (with the normal stylesheets) to mobile browsers and not disable zoom. This would make your web site one of the better mobile web sites.
As an aside, I happened to notice in a recent nightly build of Firefox 23 that they took away the "Enable JavaScript" check box on the options/preferences applet in the Windows build.
If they relegate that setting to about:config that's probably going to alter the broader user perception about what JavaScript actually represents. It kind of pisses me off. I'll probably stop using Firefox because of it.
I'll trade all the global "click here to live in 1998" checkboxes for an Esc button that freezes a site into something indistinguishable from a scrollable screenshot.
That's a superficial (perhaps naive) view of what JavaScript is capable of in a browser like Firefox.
I'm not interested in having heatmaps, timers and other metrics recorded simply because I want to read the news.
Not to mention that I also like to save pages for offline reading, and I expect them to re-render normally, and not trigger background GETS and POSTS and then fail to load.
I'd also like the <a href> tag to behave as I expect it should, and not be intercepted, and changed after I click on it, but before the desired page loads.
Disabling Javascript outright is the nuclear option. Most who really care about managing Javascript are using NoScript, an extension. Those who don't care, or don't have the technical expertise to understand Javascript won't really care where the option to turn off Javascript is located, because it already doesn't matter to them.
Disable it for 30 seconds, while you're using any particular page, and then switch it right back on. No whitelists or blacklists to comb through. Just refresh the page and it takes effect.
Downloading an add-on or an extension is annoying and creates hassle with every upgrade. It's not automatically readily available on every computer you use. In controlled environments with shared machines, desktop support techs don't install add-ons by default, and might actively prevent you from installing them.
Adjusting a global setting that's within easy reach is not an extreme response.
We then had a single accessibility class with a guest teacher. He taught us accessibility guidelines, about the necessity to seperate content and design, and eventually told us about CSS Zen Garden to showcase how it was possible to achieve multiple layouts with a single content page. My friend and I looked at each other and had that silent "Waou" look.
This revelation led me to buy a book about CSS, and got me my first job. If it wasn't for CSSZG, I wouldn't have enjoyed web design as much as I did and turned it into my job for 4 years. And I'm sure this simple project has enlightened thousands of other web designers as well.