Fantasai, an invited expert in the working group has published her feedback on our requests with information on what the Working Group has done about them. It’s unclear to me what will happen next, but presumably they will be considered further now that Fantasai’s report is complete.

She has also published information on the working group’s new charter and an overview of the high priority work that they expect to complete in the next two years.

As part of the outreach work we’re doing in partnership with the W3C’s CSS Working group, we invited all web professionals to tell the Working Group what they want from the next version of the spec.

As the Working Group’s face-to-face meeting is at the end of March, we will close comments on March 10 2008 to give fantasai a chance to gather your input together to take to the group.

How to comment

Please read the original call for participation and add your ideas in the comments. If your idea needs a long explanation or diagrams, please publish them to your webspace and link to it. You can comment as an individual, a representative of a group or organisation or anonymously. All ideas are gratefully received.

After the comments have closed

fantasai will take the ideas to the CSS Working Group and feedback to us once the ideas have been looked at. Meanwhile, the comments that you leave will be migrated to a wiki to be hosted on css3.info for further community development and collaboration.

You can still participate in the CSS3 working group via their www-style mailing list, which is open to everybody.

The CSSWG plans to discuss its charter at our next face-to-face meeting in March. If groups like CSS3.info, the CSS Eleven, and the WaSP and/or individuals like Jeffrey Zeldman and Eric Meyer could organize a collectively-written list of priorities and submit it to us before then, we could take that into account when writing our charter for 2008+.

Source

I’d like to use the comments below to collect your feedback so that fantasai can take it back to the working group. It’s possible that some (or all) will be subsequently imported into a wiki on css3.info for further public discussion, with full attribution of course.

If your comments are very long, require HTML or example screenshots, please post a link to an entry on your own website—the aim is to get a single place for the working group to look at.

The CSS working group’s charter

The charter defines and limits the scope of work the CSS working group is expected to pursue, its deliverables and a timetable. It also defines the logistics of how it operates, how often it meets, and whether it’s public or private.

There’s been a lot of debate recently about whether the current charter is adequate. The CSS Working Group read those, but in order to focus on the work of the group (rather than meta-issues like its constitution), I don’t want to re-open that discussion here; if you have something that hasn’t already been said about the constitution of the CSS working group, please comment on those discussions.

The timetable

The charter contains a list of CSS3 modules and their relative priorities. Remember, this list is from the expiring charter, and indicates the intentions and priorities as of 1 July 2006. (You can see the current statuses in the current work.)

The working group seeks feedback on whether those priorities are correct. Please indicate which features are most important to you, with any explanation you can give to help the group understand the different priorities of various sectors of web professional work.

For example, I’m an accessibility wonk, and I work with public sector organisations, so my emphasis is (by priority and by talent) on the information rather than the aesthetics. So, I can live without the borders module, but I’m very interested in the advanced printing options specified in the Generated Content for Paged Media module so that the large consultation documents and reports that I publish can be more
user-friendly and I can avoid having to dual-publish information in print formats (e.g., Word documents or PDFs).

Your experience will certainly vary—so please tell the working group what you need, and why.

Do you have a new idea for CSS 3?

What do you think should be added to CSS? This is your chance to let the working group know what’s missing. Feel free to link to your own blog with mocked-up screenshots: whatever you need to get the point across.

Fantasai told me

What we really need is to understand what problem needs solving and some idea of how people would like it solved. If someone’s proposing a solution, we need to understand why they’re framing the solution that way—so if we need to flesh out details or design a different solution we can understand what capabilities are important.

… If we can understand what the author is really trying to do, then we can design a feature that makes that possible. If it’s just a list of disconnected features, we won’t be able to identify with the author’s goals and then it’s likely we’ll either misunderstand what they want or not find it compelling.

The definition of the problem is by far more important a suggested solution or syntax.

As an illustration, I propose a new pseudo-element which I called ::line-break. There may be lots of good reasons why this might be bad syntax, but I don’t care whether the syntax is adopted. I just want a solution to the problem I define—that of styling to differentiate between an author-coded line break and one that the browser has inserted (very important if you’re reading poetry or code—see my “What I want from CSS3″ blog entry).

I should point out that there is no guarantee that you’ll get what you want; both the CSSWG and the browser developers have limited resources, so can’t do everything. For example, many people would like parent selector, but this is repeatedly dismissed because it’s too processor-intensive and because it breaks incremental rendering (although whether these are legitimate objections is another discussion).

Fantasai adds

What we work on first is based also on how complicated something is, how much prior work we can leverage, and sometimes other concerns that aren’t as obvious to web designers, like interoperability, accessibility, and internationalization. We know we haven’t been doing very well prioritizing our work or getting web designer feedback, and we want to do better, but practical issues will always be a factor.

Whatever your interest in CSS, here’s a real chance to influence the development of the language. So let’s do it: tell them what you want – what you really really want.

Polish translation by Sebastian Snopek

Of course, the underlying markup of the aStore product leaves a bit to be desired: it is a strange blend of DIVs and TABLEs that offers little semantic value. It’s also not valid HTML, but the validation errors are not difficult to overcome: missing DOCTYPE, unencoded ampersands, etc. (it should be noted, however, that the missing DOCTYPE does throw the page rendering into Quirks Mode, so keep that in mind if you decide to customize an aStore).

Implementation issues aside, the real story here is that a major corporation, like Amazon, is willing to relinquish some control over look and feel of one of their products and that they are using actual CSS to do it rather than relying on a series of color and font pickers (although that is still an option).

What are your thoughts? Would you like to see more products allow this sort of control? What are they doing right? What are they doing wrong? What could be improved? Personally, I’d like to have the ability to customize the markup (microformats anyone?) and then axe the default styles altogether. What about you?

This was by no means the first time it has been done, but it is an incredibly solid implementation and a great tool to have in your utility belt alongside CSS Drop Columns and Browser Size-Dependant Layouts. Lawrence & Christian offer a few suggestions for how to use it, including

• turning a horizontal menu bar into a vertical single list when the font is too large;
• replacing a graphical button with a normal submit on large fonts;
• applying different style sheets to the document according to font size. You could also automatically switch to a zoom layout at a certain stage;
• removing elements when a certain size is reached;
• showing more elements when a certain size is reached (in case the user zooms out instead of in);
• pulling in longer text passages via Ajax when the screen space allows for longer texts;
• increasing the width of a sidebar when the font size changes to keep a consistent line length; and
• centering an element that is defined in em on the screen.

But I’m sure you can come up with more.

• Valid Flash <object> markup: “Flash Satay” by Drew McLellan
• Valid video <object> markup: “Bye Bye Embed” by Elizabeth Castro
• Valid audio <object> markup (with Quicktime): “Object Embedding” by Simon Jessey, et. al.

Here’s the backstory:

Eighteen months ago, I was approached by a longtime friend who works in wedding photography and wanted a proof of concept for serving video (so that he could develop and sell that service, of course). In his previous life this client was a project manager for a Very Large Consultancy and swore by Microsoft platforms, which meant IE-only development over my objections.

This same IE-only development continues as needed, to this day — the video side of my client’s operations has become immensely successful.

Imperative platform limitations notwithstanding, I discovered that producing valid and effective plugin markup is a nightmare. I’ve spent untold hours trying first to learn how on my own, then giving up in frustration and instead searching for tested examples. The list above is my latest leap toward a complete list of such examples.

Update:

Joe Clark points out that he’s been on top of this issue for a couple of years now.

As for SWFObject, it serves a purpose that I might have someday in the face of a tight deadline, relaxed project requirements, or a requirement for the most recent version of Flash. However, I’ve been through every line of SWFObject’s code and can state with confidence that while it obeys the letter of the W3C Recommendations, it totally disregards their spirit.

I would write this to you directly via your site feedback page but it is throwing Access database errors. The email appears to be down as well. So instead, I’m going to write my letter here in a public forum in the hopes that someone from your team sees it and takes heed.

Your so-called redesign is a travesty, a tragedy, and an embarrassment. Your prior store was not only far more beautiful visually, but was a magnificent example of standards-based design. Perhaps more importantly, the site was also accessible under the UK’s Disability Discrimination Act (DDA).

You now have a site that regresses back to all the bad habits that have hurt the progress of Web development and design. Here’s what you can expect from what you’ve done to your site:

• Performance will become slower. Due to the overblown markup and inclusion of massive JavaScripts within each individual document, your site will slow down considerably. Not only that, but because of the table-based layout method, each page loaded has to not only redraw each of those tables (which takes two passes of a browser rather than one) it’s carrying both the presentational and behavioral baggage from page to page. I feel really sorry for your potential customers at large, and even more so for those who are on dialup. I really do.
• Your site will become significantly more difficult to manage. Want to change something in the visual presentation of the site? You now have to change it in every single document. So, instead of opening a style sheet, making a change in less than a minute, and having that change automatically distributed to all pages linked to that style sheet, you will have to search and replace. That adds a margin for critical errors, which can in turn make changes even more complicated. The same holds true of your scripts, which are embedded into each document. You’ve completely lost the ability to effectively manage your site, much less redesign it effectively when the time comes.
• Your site will become more expensive to maintain. Because of the document management issue, money and time will be spent every time a change is required. Your bandwidth costs are going to skyrocket, particularly now as we approach the holiday season as your traffic is likely to increase significantly during this time.
• The site may experience a drop in search rankings across all engines. Even if that doesn’t happen, apparently, according to Google, you are selling a product called spacer gif. What in the world are those? Oh yeah, wait! I remember! They’re an outdated, unnecessary method in today’s contemporary design and development approach. Spacer gifs, in case you don’t know what you’re pimping to the world, are a means of keeping table based layouts from collapsing in on themselves. And now, as Google so clearly tells us, they are part of your catalog. I’m not convinced you’ll get much sales on spacer gifs, but you never know.
• The site is unusable for any blind person who might like to visit. But you know, blind people probably don’t want to buy Disney products for themselves, or their children and families anyway, right?

For taking a beautiful design developed with all of today’s modern approaches that gave you so many benefits, made us proud of you, and provided a shining example of effective use of markup, CSS and accessibility features and re-doing it using outdated and inaccessible methods, I say shame on you and I repeat, this is a travesty, a tragedy, an embarrassment.

Shame on you Disney.

Molly E. Holzschlag, Group Lead, Web Standards Project (WaSP)

[Cross-posted to take your comments, and by all means, someone from Disney please do in fact comment, we'd love to hear your response.]

WaSPs at the meeting were DL Byron and myself. Microsoft was represented by a number of Web platform program managers such as the ever-amiable Brian Goldfarb, Sam Spencer, Rob Mauceri, and the legendary Chris Wilson, the Group Program Manager for IE Platform and Security who has worked on IE since 1995.

We discussed a number of issues including standards support in new software, the role of XAML and the Microsoft agenda, the Acid2 test, SXSW, and last but most decidedly not least, IE progress.

Standards Support in Upcoming Microsoft Products

There are three new tools at the ready for Microsoft, each being developed with the designer and design workflow in mind. The product of most immediate interest to WaSP is code-named “Quartz.” Rob Mauceri gave Byron and I a demo of the software, which produces XHTML 1.0 Transitional out of the box and also supports other relevant DTDs. No tables for layout, all CSS, which is great news and worthy of a hearty round of applause.

Drilling down into the markup and CSS, the tool is not without common problems we’ve seen with other designer environments. The XHTML and CSS generated are not as intuitive and useful as they could be, with lots of span elements, classes up the yin and out the yang, and a tendency toward presentational naming. Fortunately, a skilled CSS designer isn’t blocked by the tool and is in fact able to use it to create leaner, meaner markup and style in much the same way that familiar competitive tools provide.

Not perfect by a long shot, but unquestionably a potential software addition for any Microsoft developer interested in improved workflow along with XHTML and CSS support.

XAML and the Microsoft Perspective

One of the most common questions I get asked when discussing the WaSP Microsoft Task force is “what about XAML!” XAML, the Extensible Application Markup Language, is a Microsoft-specific language that many fear Microsoft will use to leverage its hold on the Web at large.

XAML is at the core of the majority of Microsoft tools development, which does suggest that when in Microsoft, do as Microsoft does. There’s what might be described as a paradigm shift for Microsoft, though. Along with XAML-based applications, Microsoft is concurrently including a subset of XAML that would be more readily useful for cross-browser, cross-platform solutions. The Windows Presentation Foundation Everywhere (WPFE) will enable developers to work within the XAML subset. Sam Spencer describes XAML and its subset broadly as “Two different kettles of fish.”

Chris Wilson digs a little deeper. He describes XAML as “a rich client experience,” and the Web itself as being a rich experience. In simpler terms, XAML provides a rich experience if you’re on Windows and developing for Windows. You’ve got “everything you need to build a Windows app.” According to Wilson, XAML isn’t intended to replace HTML. While it’s a Web language, it’s about platform. A developer would choose a situation and determine whether a XAML application is appropriate, or the WPFE subset, which relies on JavaScript, is more appropriate. “WPFE” he says, “gives you a migration path from a rich experience to a broader experience.”

I can’t say I’m delighted with the approach, as conceptually any Web language that is platform-specific goes against the spirit and vision of the Web. At least Microsoft is strategically providing some alternative that would be more conducive to interoperable ideologies, but only time will tell how this concern really does play out.

Want Some Acid2?

It was very interesting to be able to talk to Microsoft the day after Safari released the first distributed browser version to pass the Acid2 test. With Opera 9 only steps behind, and the KHTML browsers (such as Konqueror) already sporting an updated codebase, the KHTML browsers (such as Konqueror) already sporting an updated codebase, and the upcoming iCab browser already passing the test in its pre-release beta version, the question of Acid2 compliance and Microsoft is at the ready on many a tongue.

WaSP has known for some time now that passing Acid2 wasn’t going to be a benchmark for IE’s development at this time, but Wilson, at least, has always been diplomatic about Acid2’s role. In fact, perhaps more diplomatic than the Firefox team, who have stated that Acid2 came at a bad time and wasn’t really relevant for their development process, despite their interest in and support of Web standards.

Maybe Firefox can take a lesson in diplomacy from Microsoft in this one. Wilson told me that he is well aware that Acid2 “tests a variety of features that Web developers would like to have.” He went on to say that he supports the goal, and complimented the Acid2 guide for being well written and fully laying out for developers exactly what is being tested. He finished up his comments on Acid2 by assuring me that IE will pass the Acid2 test at some time in the future, but to not expect it by IE7’s release.

SXSW

We’ve not yet announced this information to the public, and more details will be forthcoming soon, but WaSP will be holding two important sessions during the March 2006 SXSW Interactive Media Festival. First, we’ll be holding a panel.

WTF? Another panel you say? Well yes! This time it’s the WaSP Task Force panel, in which WaSP and leaders from our Task Forces will be present to discuss what we’ve all been up to in the past months. Expected panel members include myself as moderator, Drew McLellan for WaSP strategy; Chris Wilson (Microsoft) on the WaSP / Microsoft relationship; Jennifer Taylor (Product Manager, Macromedia Dreamweaver) on standards support progress in Dreamweaver and related products; Dori Smith, co-lead for the DOM Scripting Task Force and long-time WaSP member on scripting progress; and Matt May, Accessibility Task Force lead, on WaSP activities related to accessibility.

If that doesn’t sound like an interesting panel, come watch WaSPs buzz in real-time. We’re very pleased to announce that our annual WaSP meeting will be held live and in public under the auspices of the SXSW crew. This will include every WaSP member who attends SXSW plus all task force participants, including significant representation from Microsoft and Macromedia.The first hour is our meeting, following rules of order but open for any member of the SXSW public to observe (we are also hoping to videocast it). The second hour will consist of questions we’ve collected in advance of the event from any interested individual (we’ll be setting up an email address, watch this spot for more information) and the final period will be available for open Q & A from the audience.

We look forward to your participation, whether you’re able to be present in Austin, or not. Again, more details will be forthcoming as the plans, participants, and locations are finalized.

IE Progress

Many readers here also follow the IEBlog (a good practice for contemporary Web developers and designers). Expect significant repairs to most existing bugs, implementation of long-awaited CSS features such as fixed positioning, child selectors, and attribute selectors. Alpha transparency in PNGs? Yes! The XML declaration will now be available without disturbing the DOCTYPE switch, and object handling will be improved with proper fallback.

However, some things simply won’t be there. Generated content? “Won’t make it” Wilson tells us. There’s an overflow problem that probably won’t be fixed, and object for images will most likely not be repaired in IE7.

Wilson remains optimistic and philosophical however, wrapping our conversation up by saying that “I knew when we started IE7 was going to be a challenging release for us, we weren’t going to get as far as people wanted us to get.”

It’s been my opinion all along that Wilson’s perspective is not unreasonable in the least. Anyone who expects immediate gratification for the support problems in IE is simply not realistic. Wilson sums this up himself, saying “I understand we might be the worst offenders today, but hey – I remember back when we weren’t the worst offender.”

And finally, a nod to his team and to the realities of IE’s future:

“The team has done a tremendous amount of work, but we still have a long way to go.”

Good Coffee

The meeting went well, and I’m always impressed by the way that Microsoft interacts with us. Bridges have been built, and we at the hive are confident that we can continue to be an encouraging, supportive resource for Microsoft developers, no matter where their business strategy might lead.

[This entry cross posted to take your comments].

It isn’t often one gets the opportunity to help define the tools you’ll be using in your job, and this is a golden opportunity. There’s quite a thread already started, but really it’s nowhere near as exhaustive as one would expect for such a significant request. Let’s change that, pronto: add your comments to his post and tell all your friends.

We’ve been waiting a loooong time for CSS3. Let’s make sure it’s worth the wait.

• Elvis Presley and Pricilla’s wedding anniversary? (1967)
• Last British concert by Beatles? (1966)
• The first Batman comic published? (1939)

Well yes, but also for the first CSS Reboot 2005.

CSS Reboot will attempt to bring together web professionals who design with CSS and standards in mind to launch their redesigns on May 1st. This way we can both participate and show everyone just how great semantic, accessible design can be.

What strikes me when looking over the complete gallery of entries for CSS Reboot is the wide variety of design compositions and themes. It is easy to appreciate and at the same time (constructively (I hope)) criticise the work of all the designers who have contributed to the event. And that is my point. We are looking at the design, pure and simple, and some damn fine examples included at that.

The fact that these designs have been implemented with web-standards technologies is simply the topping on the trifle. Well worth digging a big spoon into.