Unfortunately inner elements can break rounded borders as Richard Rutter described when using <img> elements inside an element with border-radius. He also provided a useful solution which is webkit only, unfortunately.

Inner elements with background colors can also break border-radius. But there is a way around that too: apply border-radius to the offending inner elements too.

The problem

Here’s an example (view in Firefox 2+ or Safari/Chrome) where border-radius gets broken:

(If you are reading this in an RSS feed reader, you might need to go to the page to see the example properly)

A div containing a blockquote and a paragraph to mention the source of the quote:

Notice the bottom corners aren’t right: the background of the source paragraph breaks through the rounded corners.

The rounded corners are achieved using something like this:

.blockquote-with-source {
  border:1px solid #e8eac8;
  border-radius:10px;
  -moz-border-radius:10px;
  -webkit-border-radius:10px;
}

(The above code is of course slightly more than necessary due to both mozilla and webkit implementing them via their rendering prefixes.)

The ideal solution

overflow:hidden on inner elements should do the trick, but doesn’t work in Safari, Chrome or Firefox (although will work for the webkit-based ones for images as Richard Rutter points out in the above link).

Workaround for non-image elements with backgrounds

There are a few ways to work around this:

Apply border-radius to the inner element breaking the rounded corners

If you are using background color (or background image) on the inner HTML element, you can apply border-radius to them too:

In the case of the above example, we just need rounded corners on the bottom left and bottom right of the source paragraph:

.source {
    border-radius-bottomleft:10px;
    border-radius-bottomright:10px;
    -moz-border-radius-bottomleft:10px;
    -moz-border-radius-bottomright:10px;
    -webkit-border-bottom-left-radius:10px;
    -webkit-border-bottom-right-radius:10px;
}

The final styled quote would then look like this:

(If you inspect the above with Firebug or equivalent, you’ll notice I used slightly different CSS classes so it just fits with the current theme on this blog, but the principle is the same.)

Drawback to the above workaround

The main one I can think of is that you have to maintain the border radius value in more than one place — CSS variables would be nice here

Thick enough borders hide the problem

If your design allows it, thick borders on the element using border-radius may do the trick.

In the example below, I use a thick border on the left side of the containing div, with border radius only on the bottom right of the source paragraph:

The thickness of the border is the same as the size of the radius, though you don’t have to do that.

Drawback to the above workaround

When using one thick border as above, it doesn’t render as nicely in webkit as it does in gecko. Don’t know if that is vagueness in the spec, or what…

However, if all four borders are given the same width, then it seems ok.

Workaround for image elements

As Richard Rutter commented, putting an image as a CSS background image would do the trick, but that isn’t always ideal or possible (e.g. an image that is important as part of the content is better marked up as <img>).

Are there other, perhaps better, ways to deal with this?

Web standards is generally a good thing. When done well, it can help to create lean pages, improve markup quality, provide better accessibility and can be easier to maintain (even while supporting IE6!)

One claim often made in the past to promote web standards is that following web standards (using CSS-based layouts, proper use of heading elements in markup, etc) will improve SEO.

Though this might be desirable, it is not the case; most sites on the web don’t follow web standards and most rank very high in their areas. Search engines are not going to penalize the 90+ % of sites that don’t follow web standards; that’s like shooting themselves in the foot!

As I describe in an earlier post on search engine ranking vs indexing while there are technical things one can do to ensure the site gets indexed well (e.g. URL canonicalization, good use of the <title /> element, etc), for ranking it is mostly about having good content that people will link to.

But as Matt Cutts, head of Google’s web spam team notes in this very short video, using CSS-based layouts or table-based layouts will have no bearing on search engine friendliness:

There are many good reasons to follow web standards principles, to use CSS-based layout and progressive enhancement but SEO, unfortunately, is not one of them.

Update 30 June 2009: A couple of decent articles recently talk about similar things:

1. SEO Best Practices: SEOmoz’s New Policies Based on Updated Correlation Data
2. The Triviality of On-Page HTML Tag Optimization
   

Still, I have been using display:table on a much larger site for about 6 months now, so I thought I might as well post this as it is, and perhaps follow up with more examples later.

Also, about 3 weeks after I started this draft, Rachel Andrew and Kevin Yank wrote a book on CSS display:table for layout, as well as a useful summary article! I do recommend looking at that article for finer details.

No need for css float for layout in modern browsers

For a few years now, web developers doing CSS-based layouts have used floats or absolute positioning for layout web sites to avoid using non-semantic HTML <table>s.

While doable, extra hoops often have to be jumped through (mostly for IE) and some seemingly simple things can be harder than necessary (like equal height columns).

However, for a simpler solution, CSS-based display:table, display:table-row, display:table-cell etc are all usable today across Firefox 2+, Safari 3+, Opera 9+ and IE8.

Example:

Consider the following HTML:

<body>
	<div id="header">
		<!-- header -->
	</div>

	<div id="content-body-wrapper">
		<div id="content-body">
			<div id="primary-nav">
				<!-- some navigation column here -->
			</div>
			<div id="secondary-nav">
				<!-- some additional column here -->
			</div>
			<div id="content">
				<!-- main content here -->
			</div>
		</div>
	</div>

	<div id="footer">
		<!-- footer -->
	</div>
</body>

And the CSS to style it to get equal height columns:

#content-body-wrapper {
    display:table;
    border-collapse:collapse;
}

#content-body {
    display:table-row;
}

#primary-nav, #secondary-nav, #content {
    display:table-cell;
}

#primary-nav, #secondary-nav {
    width:20%;
}

#content {
    width:60%;
}

And that’s it!

The above is just the layout bit of the CSS. Here are some screenshots (click for full size) with content and very basic styling just to see the equal height column effect:

The first is with Firefox 3 and the second with IE8.

You can actually omit extra divs, even the one that gets display:table and the browser is required to create an anonymous table for you.

Isn’t using table for layout wrong?

This is not the same as using the structural html table elements for layout purposes — that indeed is an inappropriate use for tables.

This is using CSS to give table-like display, which is fine as it leaves the HTML (and document structure) in tact.

What about IE 7 and 6?

IE7 and 6 of course remain problems, but you can use conditional comments and give them older techniques that attempt to achieve this.

Some limitations or issues

Some limitations of css display:table I have come across, however, include these:

• Lack of colspan/rowspan equivalents
• Like HTML tables, a CSS cell can expand in width based on content (as well as height).

On the last one I noticed this when using things like <pre> even with overflow:auto with the thought that just like inside floated columns with widths assigned this would result in those <pre> blocks getting horizontal scrolls if they became too wide.

Instead, as with HTML tables, they push out the cell they are in. The only workaround I knew to this was to give a px or em width to such elements. (It also applies to large images in a cell.)

That being said, display:table seems a lot cleaner!

CSS3 has an advanced layout module in the works but there are not any browser implementations of it (that I am aware of), so in the interim this could be a useful approach.

More info

• W3C specifications on CSS display:table
• Rachel Andrew: Everything you know about CSS is wrong

Translations

Update: May 2010. Translated into Belorussian, by PC.de

ASP.NET has been problematic for many web developers/designers trying to do the “right thing”, such as

• Use web standards
• Output semantically meaningful markup
• Develop to standards, rather than browsers for cross-browser development
• Use progressive enhancement concepts to cater for as many user preferences and technology limitations as possible
• Create sites that are as accessible as possible without unnecessary trade-offs with the visual design
• Create sites that are friendly for SEO
• Create lean and optimal markup for quicker download
• etc.

(ASP.NET 1 was far worse, and version 2 allows many of the above to happen, but not all, and not always easily.)

Describing the problems caused by the poor quality and bloated markup and the weird/wonderful/complex/ugly/hacky ways to work around this seems to take ages. Some fans of ASP.NET don’t like to hear it when going into these details, and react defensively. And, to be fair, these problems are not unique to ASP.NET, either.

But recently, I rediscovered a summary explanation to help explain why ASP.NET is often problematic from a web developer’s perspective:

ASP.NET is a leaky abstraction:

That term, “leaky abstraction”, was coined some time ago (end of 2002) by Joel Spolsky, a prominent writer on software development and he was noting the problems with ASP.NET way back then.

In teaching someone about ASP.NET programming, it would be nice if I could just teach them that they can double-click on things and then write code that runs on the server when the user clicks on those things. Indeed ASP.NET abstracts away the difference between writing the HTML code to handle clicking on a hyperlink (<a>) and the code to handle clicking on a button. Problem: the ASP.NET designers needed to hide the fact that in HTML, there’s no way to submit a form from a hyperlink. They do this by generating a few lines of JavaScript and attaching an onclick handler to the hyperlink. The abstraction leaks, though. If the end-user has JavaScript disabled, the ASP.NET application doesn’t work correctly, and if the programmer doesn’t understand what ASP.NET was abstracting away, they simply won’t have any clue what is wrong.

– Joel Spolsky, The Law of Leaky Abstractions, November 11, 2002

I think this is a decent summary description that can be useful for constructive discussion on what to do about it (if anything).

Abstraction without understanding = problems

Of course, this is not just an ASP.NET issue, but a general problem in software development, as Spolsky added:

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.” Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.

And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.

– Joel Spolsky, The Law of Leaky Abstractions, November 11, 2002

This helps explain:

Why non-web developers or IE-only web developers like ASP.NET

It is an abstraction, so you don’t worry about it

Why web developers/designers despise ASP.NET

The abstraction leaks, horribly at times, and you want to worry about what is being abstracted

What is still interesting is that as a software developer (not necessarily a web specialist), Joel has understood some of the problems web developers and designers will have with .NET even though many Microsoft converts and ASP.NET fans do not!

Many software developers look down on web developers, thinking things like HTML and CSS are beneath them (its “just” the UI, or that JavaScript is not a real programming language, etc).

While those attitudes are generally changing, many software/mid-tier/non-web developers I come across still hold some of these views and don’t want to write anything in these languages, preferring the safety and familiarity of their IDE! (To be fair, some of these concerns are quite valid, too, and the principle for supporting the abstraction is actually often good; it is just that with web technology at the level it is at now, some of that abstract necessarily has to leak…)

Negative perception of IE and ASP.NET for Web Developers

It is interesting to note at various conferences like @media, @media AJAX, and on various blogs by noted web developers and designers, Microsoft gets a lot of stick for its IE web browser (as it is recognized as the poorest in quality of all the modern browsers, with the most bugs, biggest divergence from web standards and causing the most headaches for modern web development).

Indeed, since winning the “browser war” IE has stagnated and because of its dominance, web technologies have hardly changed in the last 10 years (we are still on HTML 4.01/XHTML 1.0, CSS 2.1 etc). As I posted earlier, IE has slowed down web development progress in recent years.

Combine that with the poor quality markup typically generated by ASP.NET, there has been a lot of criticism from the web development community aimed at Microsoft for either not caring about standards (or, as with ASP.NET 2 and IE 8) caring about it as an after thought or when threatened by rivals.

Here is quite a telling quote summarizing some of the implications:

I sympathize with your situation, but you desperately need to get your seniors and peers to understand what’s happening, and to assign your team way more resources. IE is a first-impression MSFT product for most web developers, and yet you all continue to underestimate the dramatic spillover effect this poor developer experience has had and will continue to have on your other products and services.

Let me drive this point home. I am a front-end programmer and a co-founder of a start-up. I can tell you categorically that my team:

- Won’t download and play with Silverlight
- Won’t build a Live widget
- Won’t consider any MSFT search or ad products in the future

And the reason is because of IE – because MSFT disregards its most important relationship with us. Until this relationship is repaired, nothing else stands a chance.

Please fight the good fight and drive this point home in your org. Good luck.

– Anonymous commenter to The First Year of IE7, November 30, 2007

It may be seem a bit harsh, as some developers and technical managers at Microsoft certainly seem to “get it”, but for whatever reason it has happened and left a sour taste in the mouths of many web designers and developers.

Leaky abstractions lead to productivity loss and unnecessary trade-offs

As I blogged earlier, the WYSIWYG paradigm that Visual Studio and other such IDEs encourage, is often inappropriate for web development as it encourages bad practice such as non-semantic markup.

The perceived productivity gains of such editors vanish when needing to deal with typical web related concerns (semantic markup, accessibility, progressive enhancement, SEO, etc). In fact, what often occurs is unnecessary trade-offs. E.g.

• A back-end developer uses an ASP.NET control that offers quick development with sophisticated capabilities just by dragging it onto a canvas and setting a few properties.
• A web developer then claims that control is poor from all the web development perspectives and lists a number of things to change.
• The back-end developer resists (especially if it comes from a “lowly” web developer!).
• Trade-offs are then made (or not).
• Reworking in full (if embraced at all) takes a long time.

Even though ASP.NET 2.0 is far better than 1.x, the abstractions still leak; it is too easy to create sites that either

• Rely on JavaScript
• Violate, or easily encourage ignoring, basic accessibility
• Encourage further leaky abstractions because of the ease at which various ASP.NET controls can be created (the idea is good, but the fundamental leakage means that it will carry through to various controls).

So what can people do?

As an overall thought: by its nature, abstracting away HTML is almost guaranteed to result in a leaky abstraction.

Instead, it may be better to embrace the reasons for the leak, and provide cleaner separation while empowering people to work with the markup, given it is so crucial from so many perspective.

So here are some examples of a few ways to deal with the challenge, all with their merits for different purposes. Your mileage with each option will vary according to need. In addition, it is not a complete list; there may be other ways to achieve what you need:

Strict discipline with the controls you choose to use

The controls idea is certainly nice. ASP.NET and others (e.g. Java Server Faces) have put a lot of resources into this approach, and is certainly appealing from various perspectives (packaging components, reusability, productising components, etc).

Despite the problems, trying to stick with the principle of controls based abstraction may still be worth trying to pursue.

If so, I think it would require being VERY careful about third party controls you use, or purchase.

The other problem I see with this is in the case of medium/large teams; this strict discipline is unlikely to hold for too long, and eventually a developer with less experience on web development (or no inclination to do the web bit) will insist on using some poor quality controls that offer perceived productivity gains (“they can fix the problems you highlight to them!”, or “it looks okay”, or “people with accessibility needs don’t use the web, so it doesn’t matter!”).

Your mileage on this option will vary, depending on your team and project, etc.

Inherit and override problematic controls

Don’t like the way asp:label outputs its HTML? Override its Render() method. Same with any other control.

Sounds nice and easy enough, but this option is likely to run into trouble when someone invariably will want to use or integrate a composite, possibly third party, control written elsewhere that cannot be overridden (easily). So ASP.NET adaptors may be a better alternative than this one.

ASP.NET Control Adaptors

Also known as CSS Adaptors (which reveals a fundamental misunderstanding; developers want semantic markup for all sorts of reasons, not just creating CSS-based layouts).

This approach tries to give developers the opportunity to clean up the HTML output by overriding the default implementation.

The kind of problems I see with this approach:

• Code examples I have seen that look awful — lots of string concatenations, obscure configuration settings, etc.
• It may not always be easy to deploy a quick change after initial development (need to recompile a .NET Assembly, for example).

Despite the potential problems, it may still be a useful option if there aren’t any other alternatives.

(Does this approach help prove the abstraction fails?)

Do nothing (wait for Microsoft to fix it)

It may seem odd to entertain an option of “do nothing”, but I often think this is an option that should be considered in many situations, if not just for completeness but because pondering on this may let you think out of the box, so to speak.

Why should this option be entertained for ASP.NET? Well, you could take the approach of:

• It’s not my problem; I just want to create cool apps
• Microsoft will always fix it; we can just wait
• If we get sued (accessibility compliance) or our bosses/managers complain, we can just blame Microsoft
• The abstraction might be leaky now, but that doesn’t mean it always will — look at the improvement of ASP.NET 2 vs ASP.NET 1.x
• I’m so fed up I have lost the will to live and do anything else other than just be assimilated
• Problems? What problems? (Already assimilated a long time ago )

And so on.

Needless to say, I would disagree with many of these perspectives. For example,

• I feel as a web developer, it is out responsibility to use the tools available to create sites that are as accessible to as wide an audience as possible.
• Claiming ignorance, or actively avoiding issues you know are there somehow does not feel right.
• Microsoft may certainly fix these issues over time. Reading blogs and interviews of key people in ASP.NET and Internet Explorer teams certainly gives some hope for the future, but it depends on whether you think you can wait or not (and whether you have enough information on when they will release specific fixes that are important to you).
• The controls paradigm might always be leaky regardless of what is done. I think it would still be important to know the output that is being created in order to fully understand the implications of what you are creating. If there are problems with the site, you are likely to have to sort it out, not Microsoft (or any other vendor/framework you go for).

For many web developers who know exactly what they need, having a tool do it for you, and to a lower quality, will be infuriating. Knowing it can be done better (not just for one’s own ego, but because it is good for the user/customer) can be compelling enough to want to do something about it.

Indeed, a principle behind a number of open source frameworks has been to try and make the web better, and keep it open because it is felt that open standards and related principles will lead to greater choice, diversity and vibrancy of the web. (Indeed, a lot of “Web 2.0″ and the social web has come about because of open source technologies and ideas.)

Use an open source alternative

Those loyal to Microsoft will not like to hear this, but this is a decent option in many scenarios.

As Simon Willison, co-creator of the popular Django web framework said a few years ago, one of the key benefits of the open source approach is you are in charge of your own destiny.

(I’m not going to debate the open vs closed source paradigms here; that is not the purpose of this blog. I will just say that I didn’t use to buy the arguments of open source in the past, but in the last 3 or 4 years I have come to respect it a LOT more — I have not regretted moving to Linux at home recently, one bit, for example, and looking at the types of projects flourishing is quite encouraging.)

Don’t use ASP.NET, but don’t throw the baby (.NET) out with the bath water (ASP.NET)

Okay, so for some scenarios, completely changing platforms may not be an option.

In addition, I have to admit, programming in .NET (C# 2, etc) is nice.

Although Microsoft may be losing credibility with web developers because of the poor quality Internet Explorer browser and because of the problems of ASP.NET from a web designer’s perspective, .NET more generally is actually quite good.

Unlike on the Internet Explorer side of things, the MSDN blogs seem to be more active regarding on-going developments on .NET. Scott Guthrie, for example, has an immensely useful and popular blog on all things about Visual Studio, ASP.NET etc. (Scott Guthrie is General Manager of development teams that build the .NET CLR and the core .NET Base Class Libraries, ASP.NET, Silverlight, IIS 7.0, Visual Studio Tools for ASP.NET, WPF and Silverlight.)

For some projects we have successfully used .NET but by-passed the ASP.NET controls, using XSLT instead.

XSLT — an open standard

Using XSLT to generate the output can be one way to overcome limitations of proprietary frameworks where you lack control of the output (ASP.NET) or where other frameworks may be open source but you have to learn their templating conventions.

XSLT can also make the markup generation simpler to unit test as part of a developer’s daily work, which is not always the case (or not necessarily as simple) in other templating systems, because you don’t have to be dependent on a running web server and all the set up that would come with it (thus making unit tests quick to run as well, increasing the likelihood of them being used and maintained).

Being platform agnostic, XSLT can be an effective part of a View in an MVC framework and be applied to different frameworks and platforms, reducing up-skilling costs in the long term.

If you consult or contract for a number of customers/clients, it would be nice if there was one common skill that is portable across all these frameworks (just like HTML/CSS/JavaScript typically is on the client side). XSLT could be such a thing, potentially, all the while giving you full control of the markup that you need to be create.

In my experience, and those of some of my colleagues at work, using XSLT to by-pass .NET controls has actually been more productive from an overall development perspective because we save time that would otherwise be needed battling the controls trying to force or work alternative markup options, building accessibility, etc. (And we have architected/developed sites for one of the largest online retailers in the world, so the strategies are not merely wishful thinking, but reasonably proven).

XSLT may not always be appropriate in all cases, and many are certainly put off by its oddities or perceived limitations. But, perhaps XSLT deserves another look?

(Indeed, a follow-up post does just that, starting by looking at XSLT in server side web frameworks.)

Do you find these problems with ASP.NET for your sites? How do you overcome them, or do you just stick with it?

Image credits

“Mona Unmasked” reposted with kind permission from gravityx9 from flickr. See the original image at http://www.flickr.com/photos/gx9/354387041/.

However, a number of other posts on this site make reference to this point and I end up repeating myself, side tracking from the point at hand. For that reason, and for the benefit of some readers not familiar with this issue, this post serves as a summary of those concerns.

IE’s dominance unquestioned

There is no doubt that IE dominates the browser market share, from 90 to 60% depending on your demographics. IE 7 usage is on the rise as Microsoft pushes it out more, but IE 6 is still dominant too.

Where did this dominance come from? Was it from good quality software back in the late 1990s when the dominance started? Maybe, but it certainly wasn’t the only (main?) reason: during the browser wars with Netscape, as ZDNet reminds us, in 1998, “the U.S. Justice Department won a major judgment against Microsoft for competing illegally against another browser, Netscape.”

Back in those days of the browser wars, Microsoft was quite innovative. For example,

• They contributed to HTML 4, for example.
• Microsoft’s proprietary conditional comments for example are ironically a good way to separate out all the IE-specific workarounds from the normal code
• They even created the XMLHttpRequest object (XHR) almost a decade ago — ironically it wasn’t until a lot later that it was used on the client side for AJAX. And, while they had used it in Outlook Web Access, it wasn’t until Google and others started using it on a large scale that this technology took off.
• IE 6 (a 2001 browser) introduced Doc Type switching so that if you declared the doc type in your HTML document (and did so properly), it would attempt to render according to W3C standards, not Microsoft’s own quirky implementations (known as Quirks mode). The importance of this one is not to be underestimated (it gave Microsoft a way of retaining backward compatibility while supporting standards rendering going forward).

Of course, both they and Netscape also made some now embarrassing choices, too (Netscape’s, blink and font elements and Microsoft’s marquee, for example!)

But IE’s victory in the browser war for itself in the short term has resulted in created collateral damage, and possibly self-defeat.

Innovation stopped after dominance

Since IE won the browser wars and came out with IE6 with Windows XP in 2001, that also seemed to mark the end of their innovation. To be fair, for its time, IE6 was the best browser around. The problem is, given the speed at which things change on the Internet, it is now the worst mainstream web browser for developers to deal with; web technology has moved on, but Microsoft barely has (on this front).

It wasn’t until the start of the Web Standards Project that this began to change as people started coming together pressuring web browsers to improve, asking things like Why should developers have to waste so much time? Why can’t standards such as CSS be used across all browsers without coding for each browser (that you know of)? Why prevent people using your site?

This growing vocal discontent and Firefox’s rise contributed to the reasons IE7 made some improvements in IE7. Chris Wilson, platform architect for the IE team noted this a while back:

… we prioritized IE7 around 3 things – security, end user experience, and standards improvements in the platform. When I look back at the work my team has done in the platform, we have done only these things. No proprietary features added, just standards improvements…. I feel that we’ve addressed the biggest problems and shortcomings from IE6 for web developers and designers… As I previously stated, our goal is to make the lives of web developers better by improving standards support in IE. I think we’ve done a lot in IE7 to do just that, and I’m looking forward to doing even more.

– Chris Wilson, IE and CSS “Compliance”, August 10, 2006

While IE7 is definitely an improvement, it is still a fair bit behind compared to other web browsers, from a development perspective. In addition, IE 6 remains prevalent.

(Its amazing to think how many problems IE6 has when one of they key focus points for IE7 was better standards support and there is still so much left to do to catch up with the others. If you follow some of the links to other posts, and read their comments you will see how vitriolic some people can get about this, as it is very frustrating for web developers.)

IE stifles creativity (or makes it harder)

While IE 6 stagnated (and IE7 offered only a few improvements compared to what is really needed), other browsers have carried on, making web development through “Web Standards” important and possible (IE6 has enough of the basics to make this possible). Web developers have tried to move on too, but IE has hardly budged, thus slowing down real progress.

Well-known web designer, Andy Clarke, and an “invited expert” on the CSS Working Group at the W3C (where a lot of the specifications for things like HTML, CSS, XML, XSLT etc are made), recently made the following point:

Along with web designers worldwide, I have been creatively stifled by Microsoft’s decision to allow Internet Explorer 6 for Windows to languish in the doldrums for so many years. With their significant market-share, Microsoft should have been at the forefront of technical development and standards support in browsers. That would have fostered an ever increasing focus on what can be possible using CSS. Instead Microsoft allowed their lead to hinder progress and web designers, developers, their clients and their customers have all suffered as a result.

– Andy Clarke, CSS Unworking Group, Stuff and Nonsense, December 14, 2007

In some cases it has stifled creativity, in other cases, it requires a lot of workaround which leads to excess code (and all the costs that are associated with that).

Rather than go into the technical details that plague the browser here, such as the multitude of bugs, lack of CSS support, lack of W3C DOM Support, here are some resources that do just that:

• Quirks Mode by Peter Paul-Koch (ppk) lists all sorts of browser incompatibilities
• Position is Everything to explain CSS bugs
• Gérard Talbot has listed numerous CSS bugs for browsers with IE topping the list.

What’s also interesting about Talbot’s page for IE7 CSS bugs is that it has a number of quotes and rants about IE’s impact on web development:

Until IE is reasonably standards-compliant you can expect no quarter from us. We’ve spent too much time designing web sites that will work for CSS and then work for IE. We’ve destroyed budgets, pissed off our bosses, irritated clients and made development more expensive because of [IE].

– a comment to Chris Wilson’s post, IE and CSS “Compliance”, August 10, 2006

This comment to another post from the IE blog was made back in 2004 and is unfortunately still relevant today:

I author to standards, it takes a few minutes to tweak things to get everything perfect in browsers like Firefox and Safari, and then ages to work around all of Internet Explorer’s bugs and shortcomings. The time to implement a decent XHTML Strict + CSS 2 design would be shortened by at least a third if Internet Explorer wasn’t so buggy. I have measured this personally across a number of projects.

… CSS 2 is over six years old, and Microsoft have had employees in the CSS working group the whole time…. Given that Microsoft are the world’s biggest software company, it looks very much like standards are deliberately being sabotaged. Is it any wonder web developers are starting to get royally pissed off with Microsoft?

– a comment to a post on the IE Blog, I love this browser!, IE Blog, July 21, 2004

Alex Russell, a prominent web developer and creator of the popular Dojo JavaScript toolkit highlights the pain caused:

Here’s a little hint to whoever is the PM in charge of the renewed IE 7 effort: we don’t care. We don’t care how much it costs you. We’ve been cleaning up your messes for *years*. Those of us tasked with ‘just making it work’ have spent so many sleepless days and nights routing around IE brokenness that our empathy and sympathy are entirely tapped out. All that’s left is a combination of despair and loathing. You want us to give a (expletive) that you blog and are ‘engaging with the community’? Fine. Fix your (expletive) browser. That’s the bar the IE 7 team needs to hurdle.

– Alex Russell, How IE7 Can Avoid Irrelevance, January 22nd 2006

“Economic Wastage”

Okay, so the above pie chart (from Marco van Hylckama Vlieg, a web developer working for Yahoo! Europe) is a bit of fun, but reveals underlying frustrations (and while maybe at the time the image was created some CSS layouts were frustrating enough to contemplate table-layout, I think for the past year or two that has not been necessary! Also, if any one knows what Firefox JavaScript space issue the image is referring to, please drop a comment!)

In a way, IE therefore has contributed to a lot of “economic wastage” that others bear the brunt of.

For example, there are

• Unnecessary trade-offs, such as reduced features, less or no accessibility considerations, limited cross-browser compatibility, extra code bloat, etc.
• Extra costs, such as hiring more web developers than actually necessary in an effort to deliver on time, or assigning more time to the project, or just accepting that this is how web development is done, not realizing it can be better if web standards formed the basis of web development.

These costs are borne by companies, organizations, and individuals, not Microsoft.

This results in wasted capital and a slow rate of evolution for the web.

Reading the comments from developers on some of the IE Blog’s recent posts, reveals just how frustrating web development has been at times:

• The First Year of IE7
• Internet Explorer 8 — this was meant to be light humor on how Bill Gate announced that the next version of IE would be called IE8 (a no-brainer?) but the comments revealed the real concern was lack of progress, features, insight into IE development.
• ECMAScript 3 and beyond — although this post is about a wider debate on ECMAScript, the comments reveal frustration at JScript (Microsoft’s implementation of ECMAScript, which we otherwise typically call JavaScript) and its numerous problems

The JavaScript 2/ECMAScript 4 debate is interesting in that another influential player, Yahoo!, has joined Microsoft saying they don’t like the proposed changes (proposed/supported by Mozilla/Adobe/Apple). At a recent conference at @media AJAX, Douglas Crockford said that amongst other things it was IE6 that was holding back real JavaScript improvements (because while it remains a prevalent browser, any changes introduced to JavaScript either won’t be backward compatible enough, or won’t help address fundamental security problems which IE6 in particular is vulnerable to. This is a big enough issue itself, which I won’t go into here.)

How Microsoft can redeem itself?

Microsoft can easily rectify the problem: they have the resources to put people into sorting out the issues if they really wanted to (they will when threatened by competition, as Firefox’s rise showed, but many still regard them as a monopoly and thus have very little incentive to move ahead significantly at this time).

On the plus side, they have people on board, like Chris Wilson, that generally get the grievances developers hold and wants to see progress on this front.

Aggressively supporting efforts like HTML 5, maybe JavaScript 2, etc, will be a chance to start afresh and provide decent implementation.

(Reading posts on HTML 5, there is much skepticism that it will happen in a meaningful timeframe in such a way that it will be used mainstream — not because of the slow standards-defining process (though that certainly may be part of it) but because of IEs dominance and slow movement in these areas.)

None of this is easy by any means, but it has taken some 5 years to get some progress from IE6 to IE7 and it still lags behind the others.

Vendor-specific implementation is okay, (maybe even encouraged?) but standards should form basis from which these extensions are made.

When IE 7 first came out, Microsoft said they would release more frequently, every three quarters to a year would be a new release. One year on from IE7 and the best we have is the announcement that the next version will be called IE 8 and growing frustration at how little information there is now coming out from Microsoft about any solid plans for IE 8.

So maybe their priorities, from a web development perspective, would be to

• Become more open and tell developers what they are planning and when for
• Actually fix all the remaining CSS and JScript bugs
• Complete HTML 4/XHTML 1.0 support (e.g. the <q> element would be nice, as well as the XHTML mime type)
• Provide far better CSS 2.1 support (maybe even start supporting some CSS 3 features)
• Provide far better W3C DOM support to make JavaScript development (and execution) more efficient

This is not a complete list, and there are all sorts of posts on the web and to the IE Blog with better lists, but you get the idea.

Here is one ominous warning for Microsoft of not doing so:

I sympathize with your situation, but you desperately need to get your seniors and peers to understand what’s happening, and to assign your team way more resources. IE is a first-impression MSFT product for most web developers, and yet you all continue to underestimate the dramatic spillover effect this poor developer experience has had and will continue to have on your other products and services.

Let me drive this point home. I am a front-end programmer and a co-founder of a start-up. I can tell you categorically that my team:

- Won’t download and play with Silverlight
- Won’t build a Live widget
- Won’t consider any MSFT search or ad products in the future

And the reason is because of IE – because MSFT disregards its most important relationship with us. Until this relationship is repaired, nothing else stands a chance.

Please fight the good fight and drive this point home in your org. Good luck.

– Anonymous commenter to The First Year of IE7, November 30, 2007

Do we ironically thank Microsoft for this mess?

In many regards, the evolution of the web has been slow, and we should have been a lot further down the line than we are now.

For example, HTML 5 should perhaps be a lot closer to reality, Accessible AJAX apps should be the norm, not the exception, CSS3 should be widespread, etc.

Finally, one thought: would this have really happened without IE’s problems? One can never know for sure. Were it not for the problems IE caused, could it be that the frustration that led to better awareness of web standards would never have been nurtured? Ironically, do we have to thank Microsoft for making our lives so hard that we now have some ideas of how it could be better?!

Image credits

• Internet Explorer Voodoo Doll, by chisa, posted on Flickr
• Rust in Peace, by dasbull, posted on Flickr
• Microsoft World Domination 99, by kelly varner, posted on Flickr
• HTML Cannot Do That, by Noah Sussman, posted on Flickr
• Time breakdown of modern web design via Marco van Hylckama Vlieg

Microsoft’s Outlook has a commanding share of desktop email clients. However, Microsoft announced that Outlook 2007 would use Word’s HTML rendering engine, rather than Internet Explorer’s which seems like a big step backward.

While some may prefer text-only email, others prefer to — or must — create HTML-based email.

The Email Standards Project is attempting to follow the example of the Web Standards Project, but for email clients, web- and desktop-based to try and make HTML-email creation less hit and miss.

HTML-email is a mess

Anyone who has tried to do html email in the past knows that it is an even more mixed beast than regular web development.

These days, on the web, at least there is a reasonable formula of web standards using CSS-based designs, etc. With HTML email, some clients only support text, others only some HTML, only some CSS, no CSS, while others will edit/strip your content.

Outlook 2007 takes a step backwards?

Around January 2007, there was a bit of a storm when Microsoft announced that it’s Office 2007 Outlook client would use Word’s HTML rendering, not Internet Explorer’s for displaying HTML email.

For many web developers, this seemed immensely backward. Word’s HTML output is notoriously bloated and, quite frankly, rubbish.

However, it seems that the reason was for consistency with Word and for between Outlook users primarily, as users were typically using Word to compose such messages and more likely to send to another Outlook user, given its commanding share amongst email desktop clients.

Outlook’s wide usage cannot not just be ignored, so how to developers deal with this?

What about text only email?

In some of the links presented below it is interesting to read the comments on those posts from many people who have very little sympathy for people struggling with the HTML-based email challenges.

My personal view/preference is in favour of plain text email and having switched recently to Linux/KDE and KMail, which only supports plain text, I find it far better than trying to understand HTML emails with disabled images that don’t have alt text or have broken layouts!

However, many people do desire — or require — that HTML-based emails be created, so for them, this can be a real problem.

(Even when HTML-email is required sending a plain text version with the HTML version is important for those who cannot see HTML email or have it disabled.)

Simple HTML Only?

Some advocate using the simplest layout tables in HTML, which are shunned upon by most standards-aware web developers for all the problems (accessibility, maintenance etc) that it causes.

Simpler HTML, limited to just a few headings, paragraphs, lists, etc may offer improved readability over just plain text. However, this also seems to defeat the purpose of HTML email, especially for marketers and advertisers.

The Email Standards Project

The Email Standards Project, in a similar way to what the Web Standards Project did for web browsers and web developers, is trying to get email clients to follow standards better. They have an email client acid test and a report on web standards support in popular email clients.

It will be interesting to see how this works out… Will they get Outlook to change? Hard to tell, although the following may be encouraging (from one of the web standards most well known advocates, Molly Holzschlag, who now works at Microsoft):

Microsoft was very clear in letting me know that if we want a feature and need it and get an organized list to them, those issues will be addressed and prioritized as the new engine develops in response to developer needs, too.

… I’m now working directly with Microsoft, and I can honestly say that their software developers by and large get it completely. They aren’t our problem, and never really have been.

It’s the business decisions that drive the technology decisions.

– Molly Holzschlag, quoted by, and commenting in The truth behind the Outlook 2007 change and what you can do about it, Campaign Monitor, January 22, 2007

What about actually getting the email delivered?

Ensuring your HTML emails look great and get delivered, by David Greiner is a great resource, discussing issues such as spam lists, what you can request from some ISPs, etc.

More information

• The Email Standards Project
• The Web Standards Project’s post on the Email Standards Project (from which I learned about the Email Standards Project). This post is interesting for the various comments the post attracted.
• E-mail is not a platform for design, Jeffery Zeldman (the guy who started the Web Standards move), June 2007.
• About Microsoft’s Outlook 2007 decision and some further details on what this means:
  • Microsoft takes email design back 5 years, Campaign Monitor, January 12, 2007
  • The truth behind the Outlook 2007 change and what you can do about it, Campaign Monitor, January 22, 2007
  • Microsoft Breaks HTML Email Rendering in Outlook 2007, Sitepoint.com, January 10, 2007
  • The Saga of HTML Message Rendering in Outlook, Microsoft Watch, January 31, 2007
  • Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007, Microsoft Developer Network, August 2006
  • 2007 Office System Tool: Outlook HTML and CSS Validator, Microsoft

This post is a summary of day 2, a more technical look at JavaScript and its future.

JavaScript 2 and The Open Web

By Brendan Eich, the inventor of JavaScript.

Good talk on some details about JavaScript 2 which he (and others) have been blogging about recently. He also briefly talked about the “open web” (WHATWG, W3C, etc) versus a “closed one” (Adobe AIR, Microsoft’s Silverlight, etc), which he has also blogged about previously.

He also talked about some of the language features being proposed for JavaScript 2 which would make it look much more object-oriented (namespaces, classes, packages, generics etc). He said the main drivers for JavaScript 2 were better security, better APIs and better programming language support.

Why are these needed? He felt users deserved more support in the language. He lamented that the combination of Microsoft’s domination combined with Netscape’s self-destruction had made the web stagnate. JavaScript hasn’t really changed that much in those years. As web apps were getting more common place, some of these new features could be more important.

A point he and others have made is that while there are better languages out there, most have not really been used as widely as JavaScript, especially from the kind of wide user base that JavaScript has, so the perceived weaknesses of JavaScript can also be its strengths (something Douglas Crockford looked into further — more below!).

Update 1: he has posted slides together with notes and commentary. A useful read.

Update 2: Ajaxian has a decent look at a specific aspect of his talk: JS code bloat and JS2′s improvement, and the performance benefits of JITting.

(Here’s a decent set of slides on the new features being considered in JavaScript 2, actually by John Resig, the next speaker!)

Building Interactive Prototypes with jQuery

By John Resig, inventor of jQuery.

I think this was one of my most favourite sessions, but it should not have been! It should not have been because I have been using the excellent jQuery library for about two or three months now, So I should have found most of this talk familiar and therefore not of that much interest.

Instead, I was really impressed with the quality of the session. John was showing the features of jQuery with code examples, and throughout his talk, people from the audience would ask if it was possible to do various things, and he was always able to answer in a polite, positive way, constantly changing his code on the fly in front of everyone. Many of the seemingly complex things that were being asked were implemented not by one line of code, but one word or two!

The talk wasn’t really about building prototypes, though, more about just using it. (And it isn’t just for prototyping; it is being used in a lot of big places.)

If you haven’t seen it, check out the jQuery site and try it out. It’s really growing on me. While I initially found it weird, it is amazingly powerful, simple, efficient and productive. Its quite different to most of the other popular JavaScript frameworks, especially in how it queries the DOM so efficiently and with hardly any code! I have removed anywhere from 40-60% of some of my JavaScript code when I have used it and I hope to use it more.

Update: Slides for the JQuery presentation are now available.

Metaprogramming JavaScript

By Dan Webb, a JavaScript expert and part of the core Prototype JavaScript framework team

I had bumped into him the day before during a session break, and he was saying he was nervous about his talk with so many experts as speakers!

But he did a great job explaining a decent topic: meta programming; programming JavaScript to augment itself at run time (e.g. to overcome deficiencies such as IE’s limited event handling in an efficient manner). Rather than describe the things he talked about, have a look at his metaprogramming slides.

Dojo 1.0: Great Experiences For Everyone

By Alex Russell, project lead for the Dojo Toolkit

Instead of talking about Dojo, Alex Russell decided to talk about the state of the web in general — which was a great talk!

Interesting points included that the emergence of Adobe’s Flex, Microsoft Silverlight, etc signaled a sign of problems for the web; that it may not be evolving much, that it may be hitting the walls of complexity.

He felt that even JSF/JSP (JavaServer Faces and JavaServer Pages) could be a sign of this pain (these technologies use a component-based approach to develop web apps, similar to ASP.NET, so I’d add that to his concern). His point was that Java developers appear to be afraid of getting their hands dirty with HTML, JavaScript etc, preferring these components to do it instead. Instead, developers do need to care about markup. These same criticisms apply, in my opinion, to ASP.NET. (During the Q & A session just after his talk, a lot of people voiced concerns about Microsoft’s dominance slowing down change.)

JavaScript: The Good Parts

By Douglas Crockford, Architect at Yahoo! Inc, a well known JavaScript guru who also came up with JSON!

Perhaps one of the two foremost people on JavaScript, this talk was interesting, because Crockford, despite his knowledge of JavaScript is known for being against the proposed ECMAScript 4 specification (which would be implemented as JavaScript 2). He feels that while the additions proposed are interesting and good, it makes the language quite different, and so should be called something other than JavaScript (else he seems to be for it, from what I can tell!).

He has written previously that, “JavaScript is a sloppy language, but inside it there is an elegant, better language”, and that was a point he was trying to make again, quite effectively, I thought.

This talk looked at a number of things problematic with the language and also what worked so well (e.g. lambda functions, closures, the functional programming aspects of JavaScript, the dynamic and flexible nature of the language, etc.)

One annoying (even dangerous) mistake with the JavaScript language he pointed out was semi-colon insertion, whereby if you omitted the “;” at the end of a statement, the parser would add it in for you. While this may have been kinda understandable at the time JavaScript came out (to help non-programmers, etc), it had an impact even on code convention:

While in other languages, coding standard/style is typically a matter of preference, here was an example where opening the curly brace on the same line is a MUST for JavaScript:

return
{
    name : value;
}

Is NOT the same as

return {
    name : value;
}

In the first example, because of semi colon insertion, the interpreter will actually do this:

return ;
{
    name : value;
}

(It will add a semi colon after return!)

Bizarre, but rests the debate on where to open your curly brace for JavaScript!!

He mentioned the tool he wrote a few years ago, JSLint, that checks your JavaScript much like Lint does for C etc (it will catch the above issue, amongst many other things!). Will be worth looking into further and possibly integrating it into our build processes (which they do with Yahoo’s YUI, for example).

He also made the controversial statement in the panel discussion that followed, that CSS was shit, which didn’t go down too well! (Though he also said he is not a designer, or something like that!)

The other concern he raised was that IE 6 in particular was holding back the advancement of JavaScript; that changes were hard to introduce because of the prevalence of this poor quality browser.

Discussion Panel

Moderated by Jeremy Keith (the guy who coined the term — and authored a popular book by the same name — “DOM Scripting”)

Brenden Eich, Stuart Langridge, Alex Russell, and Douglas Crockford were on the panel answering questions raised by the audience. Most were around JavaScript’s future, what frameworks people were using, and concerns about Microsoft’s domination of the web (its negative impact on the web developer community and whether it mattered any more or not), etc. Some good topics and debates!

Conclusion

A really good day; lots of ideas and details. Some of the powerful aspects of JavaScript were shown in simple terms.

The last @media conference got me excited enough to finally start this blog. This one gives me a sense of urgency to replace some of my JavaScript code with jQuery

This event was one of the premier JavaScript/ajax events including speakers such as Brendan Eich (Mozilla, and inventor of JavaScript), Douglas Crockford (Yahoo, and creator of JSON), Derek Featherstone (Further Ahead), John Resig (jQuery), Jeremy Keith (author of Bulletproof Ajax), and Dion Almaer & Ben Galbraith (Ajaxian).

Every session was of interest. By no means are these a complete set of notes of everything said, just an overview and my impressions of it:

Overall

Great. Good to hear from some of the key people in this field. Though the conference felt more about JavaScript than just AJAX (but that was a good thing IMO).

A number of sessions talked of how JavaScript was hated and considered too basic for serious programmers until just recently and yet, without having really changed that much over the 10 years, is now well-respected, incredibly powerful, and very misunderstood!

The State of AJAX

By the guys who run Ajaxian.

Interesting talk noting various improvements in just a few short years, and some of the innovative things that are coming, from Mozilla (Tamarin, Screaming Monkey etc), Google (Gears, GWT), various frameworks (JQuery, YUI, dojo, etc), and of trends such as AJAX on desktop apps (Adobe AIR, Slingshot, Silverlight, Prism etc).

They presented a pie chart showing almost 50% of web developer’s time was typically wasted on sorting out problems with IE/Microsoft! Made people laugh, because how true it unfortunately is. (It was interesting — though not unexpected — that in almost every session there was some note, minor or major, of how much Microsoft/IE had stagnated/held back the web.)

Google Gears’ use of worker pools and other features to improve both security and performance was mentioned, which was quite interesting. (Gears has many things being considered for HTML 5 — including the much-talked about off-line storage — but because Gears requires a separate install on the user’s browser, I hadn’t really given it much attention. I am certainly interested to learn more now.)

The other point they made was that AJAX-based apps were now raising the bar on web apps; from form to function to the “wow” factor. They mentioned an interesting usability study looking at two apps with the same functionality, except one just looked better. They asked people around the world (not just US and/or Europe) which one they thought they were more productive with. They all said the better looking one. Whether it was true or not wasn’t the point; the wow factor was.

But I’m a bloody designer!

Interface designer Mike Stenhouse provided the perspective of a designer who, being comfortable on the design/HTML/CSS end of things in the past, perhaps with simple JavaScript stuff (image rollovers etc) would leave the construction and server-side programming to others. However, with web applications much has changed. For example, more programmers are coming to JavaScript and even “taking JavaScript away from the designer.”

He talked about how he found himself being more involved in day to day discussions and decisions and that agile development was a good fit for this changing, even for a designer. He found himself being involved both as a customer representative as well as part of the team, even involved in pairing with developers (not to write code necessarily but to appreciate the coding issues and to allow developers to appreciate the design issues).

It was interesting (and good) to hear a designer talking about the merits of Test Driven Development and even Behaviour Driven Development!

Real World Accessibility for Ajax-enhanced Web Apps

By accessibility expert, Derek Featherstone.

While he covered techniques that should be reasonably well known now for people who have been following web standards etc for the last few years, he presented it really well so hopefully those not as interested or aware of the issues should be better armed now.

Fundamentally he reiterated that markup still matters; that the structure of the HTML was still fundamental and should come first.

How To Destroy The Web

By Stuart Langridge, author and one of the founders of the Web Standards Project’s DOM Scripting Task Force.

This was a funny, tongue-in-cheek, look at how not to do web development or further the web.

Planning JavaScript and Ajax for Larger Teams

By Christian Heilmann, JavaScript expert, now Yahoo! UK lead web developer, standards evangelist and trainer.

Good discussion on the importance of team development. Also made a point that front end stuff like CSS and JavaScript should be treated as application code; with a build process.

Mentioned tools like JSLint for quality, minification and consolidation for performance, all things I have been interested in looking into further.

Another decent idea around team motivation and knowledge sharing was the “lightning talks” — 5 minutes to present a problem, 5 minutes demo the solution, 5 minutes to discuss (and then share with the world, through blogs, wikis etc). We have tried hour long sessions with our teams which are really good, but when our development is fully underway, these are sometimes sacrificed, unfortunately. These shorter “lightning talks” are an interesting idea, which I hope we try out.

He also talked about architecting JavaScript (thinking of modules instead of pages, providing configuration capabilities, custom events, etc). All good stuff which I have been trying to do more of lately (not always perfectly though), so nice to see that being mentioned.

Afternoon Coffee Break

No, not a session, but a break! The reason this was useful for me was that as a work colleague and I were talking near the cookies and coffee area, Stuart Langridge came over, so I quickly told him I liked his session and we started talking about various things.

He had very briefly mentioned something called Comet which I asked if he could explain further. All he said was, “why not ask the guy who invented the term” pointing to another guy just standing right next to us, Alex Russell (one of the speakers for the second day)!

It was a great discussion on the idea behind Comet (rather than the client polling the server continuously for something, being able to push data and events from the server to the client, all while using the existing HTTP infrastructure, which is not built for this type of communication. In short it involves having a script element request a resource from the server, but the server never returning, just blocking until different messages/events/data needs pushing. Simple in idea but involves some complexities to overcome. I will be trying to look into this further.)

Ajax at Work: A Case Study

By Peter-Paul Koch (ppk), known for his useful quirksmode web site of tips and tricks and understanding browser incompatibilities.

Ironically for an ajax conference, the only session that actually looked at the technical aspects of ajax. He compared using XML, JSON, CSV, and HTML as the data being returned from an AJAX request, looking at pros and cons of each. (As expected, ultimately XML or JSON are better than CSV or HTML in most cases, but it all depends on the situation.)

Conclusion

So, all in all, a decent day, getting to hear from some well known people. Can’t say I technically learned much, but I don’t think that was the goal of the day as such; more to share ideas and connect.

Day 2 was for the more technical stuff, and had even more well known people talking.

Why?

Why is Microsoft doing this? They say that it is because “Microsoft takes its commitment to help protect the entire Windows ecosystem seriously.”

My opinion on this is that they are finding that those with cracked/non-genuine Windows are stuck on IE 6 and even though that is not Microsoft’s fault, the security holes in that browser gives a bad image for Microsoft.

I also wonder if they are doing this to challenge the rising popularity of other browsers such as Firefox and Safari.

Anyway, those are just my initial quick thoughts.

Its a good move

From a web development perspective alone, I think this is a good thing:

For web developers IE6 has long replaced Netscape 4 as the annoying browser to cater for given all its CSS rendering bugs and DOM deficiencies.

IE 7 is a vast improvement over IE 6.

The less people using IE 6 the better for them and for us web developers!

That being said, IE 7 is still not up to speed with CSS and DOM support as the other modern browsers but in my opinion requires far less alternative CSS rules for example.

Or is it?…

Or, is it a good move?

If Microsoft regains its dominant market share of a few years ago (approx 95%) will it just sit on its browser and not do much with it again, thus slowing down overall progress as before?

(I’ll expand on this last point in another post!)

To be fair, there are enough signs that Microsoft’s IE team is far more committed to standards support etc than before, with people like Chris Wilson and Molly Holzschlag and various others there who “get it.”

Its near impossible to predict the future, but another way to put the above concern is as follows:

What would I prefer:

1. The current situation with IE 6 so prevelant
2. Microsoft regaining its dominant near monopoly browser market share with IE 7
3. IE 7 replacing many instances of IE 6, but being a browser amongst a diverse ecosystem of web browsers all competing by using standards as a basis for innovation, not proprietary stuff as the basis (as was the case in the Netscape 4 vs IE 4+ browser wars)

I think I would prefer the 3rd option…

A while back I posted on whether developers should avoid WYSIWYG editors or not, and what the general problems are.

However, while WYSIWYG HTML editors can be a hindrance to good quality markup for web developers, WYSIWYG HTML editors can be extremely important for effective Content Management Systems (CMSs) where end users (typically with no HTML knowledge) are often expected to contribute content.

Poor quality HTML from WYSIWYG editors

As alluded to in that previous post, various WYSIWYG editors create very poor quality HTML, which can affect things like accessibility, maintainability, and manageability.

Some of the problems include

• The continued use of bold, italics and underline buttons because word processors have them! (The intentions of those buttons are to produce presentational markup, rather than structural markup.)
• Not providing ability to set headings (or encouraging users to just increase the font size and make the text bold)
• Indenting text using HTML elements that were meant for other uses
• Being difficult to provide alternative text for images

And so on.

Why is all this problematic? In short, tools that process the document cannot offer any additional value to the user.

For example, if a WYSIWYG HTML editor doesn’t have simple headings support, users will typically increase some text size a few times. While it looks like a heading, it is technically not a heading; this can mean a screen reader cannot offer a useful list of headings to a blind user of the information, and that a site-wide visual design/brand may become harder to maintain if there are various elements used inappropriately to achieve the same effect.

Some of the challenges are due to the WYSIWYG editor providers, while other challenges include the education of the content creators to know about these issues.

But various projects are addressing these concerns

Fortunately, there are people trying to address this, so here are a few links (not exhaustive):

Alastair Campbell, a web usability and accessibility expert, provides some useful resources:

• WYSIWYG Editor Checklist is intended as a tool to assess and help improve editors. It follows the idea of the Web Content Accessibility Guidelines 1.0 Checklist from the W3C, which is quite useful.
• A collection of articles about WYSIWYG editors looks at various issues in depth.

XStandard is one of the better WYSIWYG editors that gets most of the issues and tries to provide a better interface for producing good quality markup, efficiently.

WYMEditor takes a good approach by using the term WYSIWYM (What you see is what you mean). The idea behind WYMEditor is to concentrate on a web document’s structure and meaning, while trying to give the user as useful an interface as possible, close to a WYSIWYG editor. This project is in early phases, but looks quite promising.

TinyMCE produces decent markup and offers semantic as well as visual styling. It is used by WordPress as the WYSIWYG HTML editor, too.

FCKEditor seems to produce decent markup too, offering semantic as well as visual styling.

Are there any others projects you know of that follow modern web standards principles for such editors?