CSS Zen Garden is 10 Years Old Today
mezzoblue.com
mezzoblue.com
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.
Hmm... must have been trying to invoke quirks mode.
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.
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.
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.
A semantic web as you describe isn't the current web at all, but a new completely new layer on top of it.
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.
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.
Some associated G+ posts / rants:
Readability: two days in -- VERY nice https://plus.google.com/104092656004159577193/posts/PhQR421e...
Dear Internet Desiners: We need to talk https://plus.google.com/104092656004159577193/posts/NFEFMZdk...
Annoying Web annoyancs are annoying: CSS Interstitials https://plus.google.com/104092656004159577193/posts/j357ACUs...
How things change. Here's to another ten years.
Imagine how difficult it was to just changing the font size on a website before 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.
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.
The 'mission' may be a bit different now, though. Instead of advocating the use of CSS, CSS is now the standard.
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!
However it is bizarre. Rich-Text-Fields are what the customers want, and that combines text, audio and video and all text formatting.
Just make sure your website works without Javascript or CSS enabled.
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?)
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.
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'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.
Oh, right, and I'd also like my history stack to stay relatively private, but you know that's really asking a lot isn't it: https://developer.mozilla.org/en-US/docs/DOM/Manipulating_th...
Meh, whatever. I guess we should just accept the prevailing wind, and learn to cope with its ramifications, no? Is all this so inevitable?
Tools/Edit > Options/Preferences > Content > click "Enable JavaScript" > OK
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.