IEBlog

This looks better, plus it's CSS...
http://www.bath.ac.uk/~cs1spw/demos/moz-border-radius.html

moz-border-radius >>>>>>>> fake borders

Rounding corners

Only works with Mozilla/Firefox and a non-standard syntax so far, hopefully CSS3 gains more support soon. There are many very useful ways to get rounded corners in the specs (such as the one below, just without the -moz- prefix), but progress is slow.

/* make a few corners round, only supported by moz/firefox/other gecko browsers for now */
#p-cactions ul li, #p-cactions ul li a { -moz-border-radius-topleft: 0.4em; -moz-border-radius-topright: 0.4em; }
#content { -moz-border-radius-topleft: 0.6em; -moz-border-radius-bottomleft: 0.6em; }
div.pBody { -moz-border-radius-topright: 0.4em; -moz-border-radius-bottomright: 0.4em; }

There are more techniques to get rounded corners, unfortunately very few work in old browsers such as IE. The working ones involve ugly and big html markup, tables and images..

The MSDN solution is overkill.

Try
http://openrico.org/demos.page?demo=ricoEffectRound.html

"Perhaps you're tired of waiting for the W3C to release the CSS3 Recommendations, which will include specifications for rounded corners, and—even better—several border properties."

Is that article *implying* that if the W3C were to finalize CSS3, then IE would move to support it?

Well, CSS 2/2.1 *is* finalized. If IE7 doesn't support it, I'm going to cry "hypocrite."

Remember this moment. This may give us the proof we need when IE7 comes.

Or maybe you'll get it right, and I'll rejoice and sing your praises and be much more productive in developing web sites.

(Well, IE6 will still be a problem for the forseeable future...)

Wow, I did not know that there are CSS tutorials on MSDN. This is really a nice article, they even mention the semantic disadvantages of the last solution.

What I do not understand is why the headline says "in Internet Explorer" - of course this method is not an IE-only feature.

I think they could have left out the possibilites using tables, these are not necessary any more.

By the way, both links on the bottom of the page do not work (the value of the type-attribute is missing).

Thanks for telling us that you won't implement CSS3 working drafts (which is right) - I'll keep wating for the posts that say what parts of the CSS-specifications you _are_ going to implement :)

The Nifty Corner's is another good way to implement rounded corners. http://pro.html.it/articoli/id_599/idcat_31/pro.html

MUUUUCH cleaner than nested divs or god forbid using a table to create the look.

How about this idea? Instead of me having to manually draw and colour the damn corners, give me SVG and let me do this:

border.svg:
<pre>
&lt;?xml version="1.0"?&gt;
&lt;svg viewBox="0 0 100 100"&gt;
&lt;rect x="0" y="0" width="100" height="100" rx="25" ry="25 fill="blue"/&gt;
&lt;/svg&gt;
</pre>

<pre>
my.css:
div { background-image: border.svg }
</pre>

Done.

border.svg:
<?xml version="1.0"?>
<svg viewBox="0 0 100 100">
<rect x="0" y="0" width="100" height="100" rx="25" ry="25 fill="blue"/>
</svg>

er, something like that

"Well, CSS 2/2.1 *is* finalized. If IE7 doesn't support it, I'm going to cry 'hypocrite.'"

Actually, CSS 2.1 went back to Last Call Working Draft on June 13 (ie. it's -not- finalised), and it's well-known that CSS2 is too full of errors to use reliably. So, please, no cries of hypocracy just yet.

Yet another slap in the face.

Why can't you put some serious effort into improving Trident?

This is bad joke...

No designer worth his salt would consider doing this (much less supporting it all around a large site). To me, this looks like what a programmer who wants to get the boss off his back would do.

As for the "easily" and "efficiently" parts, I had better not comment.

Using -moz-border-radius is a bad idea. Not because it's nonstandard (gecko's CSS extensions are named correctly after all, unlike IE's "filter" junk), but because you forgot about -khtml-border-radius!

This is nothing new. I was hoping you'd show off some sexy, IE-only way of achieving this effect.

J. King:
Touché. CSS 2.1 is in last call.

But as I understand it unless some huge mistakes are found by July 15, 2005, it will pretty much be finalized.

And I do not expect a final version of IE7, much less a release candidate, by July 15.

I'm starting to doubt we'll see a beta by then, either. Even so, nobody says a few minor details cannot change between a beta and final release, otherwise we'd be skipping the beta.

So yes, I'll give IE the July 15 date, and if any beta versions after that date don't support CSS 2.1, I'll surely have the right to cry foul on this article.

Can I assume that IE7 will include some way to update its rendering engine via service packs or some other modular system? It makes sense not to waste time supporting as-yet unfinished drafts of CSS3, but a lot of it SHOULD be worked on before it's finished, so that once it is a recommendation we don't have to wait another five years for IE to support it.

Well I'm all for standards, but no matter which browser, you can't currently do rounded corners without resorting to hacks. A little noise in the signal, but a also happier bosses and continued paychecks, so I guess for now I'll slut out and make rounded corners with hacks. When CSS 3 comes out, though, and we have border backgrounds, that will be a whole nother smoke. (If I'm still in this business by then)

One-Element-With-Four-Corners implementation:

http://vitaly.harisov.name/example/corners.html

> Well I'm all for standards, but no matter which browser, you can't currently do rounded corners without resorting to hacks.

You may do round corners using one element and CSS2.
See my previous comment.

um, whats wrong with an image in each corner? Seems by far the easiest, and fastest, and least maintenance. Least always has worked for me - but I guess I just am one that sticks with what has always worked and dont look to reinvent the wheel.

> um, whats wrong with an image in each corner?

<img> element is content, round corners is appearance.

> You may do round corners using one element and CSS2.

Sorry, CSS 2.1.

MSDN has a new article on doing rounded corners in IE (via IEBlog). None of the solutions they suggest really separates content and presentation well - they all involve extra markup of one sort or another. It's amusing that they criticise the four-divs-and-CSS solution as being &quot;difficult to read&quot;, having just suggested a table-based solution which is a lot more markup-heavy. My current favourite method is the Nifty Corners JavaScript library. (Note that the version I link to is free software; later versions are not.) After all, if JS is turned off, you just get square corners. No big deal. I also note with interest the following quote from the article: So, you're staring at your Web site. It all looks very boxy, and you're thinking that it would be nice if you could add some rounded corners. Perhaps you're tired of waiting for the W3C to release the CSS3 Recommendations, which will include specifications for rounded corners, and—even better—several border properties. The good news is that you don't have to wait any longer... I am glad that Microsoft is committed to supporting CSS3 as soon as it is released, as it's clear from this quote that the unfinished nature of the spec is the only thing holding them back....

This is news! People have been doing this for a while, but of course they're always the extra markup that get's really messy to manage for large projects. This kind of thing as been around for years. (in fact MSDN nicely outlined all the _wrong_ way's to do this). You support a lot of things that aren't in standards, like vbscript and activeX, why not support something that is at least planned and will be in the standards very soon?

Great job at innovation guys!

With IE7 I'll be able to use PNG+A to get anti-aliasing properly...

but tables? nested divs? Nooo...

Make IE support generated content! All other browser vendors managed to implement it. Even Dean Edwards managed to hack IE6 to support it, so why is it so hard for Microsoft developers?

Moz's rounded corner implementation still has some issues - namely lack of antialising and background image bleding. However it's definitely the right way to go. I recently had a design that was pretty much impossible to accomplish in IE; it needed a moving container with a rounded top left corner on top of a static background. Without using alpha PNGs or CSS rounding we had to give up on it (and unfortunately in Fx too due to the lack of AA and a sense of consistency).

The final nested DIV solution is downright malicious. It will break as soon as any other unrelated div is inserted into the rounded corner box. The right way to code what the example wants would be with > (child) selector , e.g. div.roundcorner2>div>div { ... }. (Surprise: Not supported by IE!). Therefore, the next rightest way here is using a class on EVERY level of wrappers.

Furthermore, this example got another nasty bug. div. roundcorner2 div div div is WRONG. There must be no space between dot and roundcorner2 - otherwise roundcorner2 will be treated as element name!

Wow, still using tables in 2005 to create a visual layout. MS devs sure are lagging behind. I hope no one takes their advice on web user interfaces.

I can't believe you've linked to this terrible article. In the days of semantic markup and CSS you are suggesting that web devs alter their data to get a visual effect. Astonishing. I hope that Mr Mielke won't be allowed to blog again here.

Uh oh! Dean Edwards has been stirred from slumber...

MSFT better respond before another prominent dev pops in.

BTW, this story article needs a good Slashdotting!

LOL!

"Moz's rounded corner implementation still has some issues - namely lack of antialising and background image bleding. However it's definitely the right way to go."

This is being worked on by someone... Can't remember his name now, but he's got a webpage showing his progress on this. I'll post it when I find it.

Personally, I think the DIV solution is best, but JavaScript building it, keeping the source clean.

Here's a design I've been throwing around which uses divs & javascript http://www.larndan.e7even.com/

I followed the link. And I just laughed.
You must be kidding.

I reckon that this post is deliberately planted to to spread 'viral hatred' around the blogosphere.

This will drive traffic in the short term to IEBlog, where, according to Scoble, there will be a big announcement later today from Hachamovitch (probably just a public demo of IE7).

Any publicity is good publicity...

Why did I bother looking at that link. Why are you wasting people's time?

Image hack - oooh that's amazing that IE6 supports that! Incredible. About as impressive and Netscape 4!

Just get your rendering engine to support rounded corners and stop wasting people's time.

@David - I've been following the guy who's been doing the AA work although he only seems to have an implementation in JS at the moment. Still good work. I didn't realise anything was being done on the bleeding issue though? That'll be good. Still, we'll have to wait for Backgrounds&Borders module to get back up to CR before we can remove the -moz- prefix.

Yeah, don't bother using hundreds of nested <div>. Use the JavaScript way...

Why oh why must you link to that kind of articles when guys like Roger Johansson have worked out and released ways to do it with cleaner markup, and more flexibility? (http://www.456bereastreet.com/archive/200506/customising_custom_corners_and_borders/)

I use the <fieldset><legend>Rounded</legend>Content Here</fieldset> for my rounded needs.

It's not quite a lame as the solution you posted. I mean we are talking circa 1998?

You guys got nothing better to work on than bringing up ridiculous posts like the former?

Jeff, I'd agree with you there. Markus should rather sink effort into breaking up the svg against vml muddle.

I wrote a little more about the true way rounded corners should be accomplished: <a href="http://blog.codedread.com/archives/2005/06/23/rounded-corners-the-last-word/">http://blog.codedread.com/archives/2005/06/23/rounded-corners-the-last-word/</a>

http://blog.codedread.com/archives/2005/06/23/rounded-corners-the-last-word/">http://blog.codedread.com/archives/2005/06/23/rounded-corners-the-last-word/

Damn, call me stupid for having done this twice now, but it's hard to keep track of which blogs support markup and which don't. A Preview button would help here!

I wouldn't be surprised to see this sort of article published in 1999. But March 2005! Where have you been the last 5 years? Didn't you see that the web has evolved and this sort of ugly hacks that bloat the markup and degrade user experience for a small visual effect is no longer accepted? I really hope there are people on the IE development team with better understanding of web developers' needs...

Here's the page detailing the work on improving Mozilla's & KHTML's border and background handling:

http://verens.com/borders/borders.html

Yeah, that's the project I was thinking of. Maybe the IE team can get some tips :)

How did the IE team think we were going to respond... There has not been a single positive comment.

I don't expect the IE team to defend themselves and post a rebuttal. It's 7AM in Redmond, the team should be first seeing this comment.

"Since we have no plans to do native rounded corner support in IE7 (CSS3 feature)"

Sincerely: May I ask WHY?!

For spite? Can't be IE finally 100% compliant?

:|||||||

Sorry, but this is one of the reasons IE is holding back real creative design on the web. We designers and developers have great ideas for designs and we can make them work in browsers that support common-sense methods but then the enormous IE user base rears its head and we have to downgrade our beautiful designs and techniques to make them work in IE. This is a prime example. There have been numerous articles on this subject to which others here have provided the links that are far better than the solution in the MSDN article.

It's 2005 and with all of the push for Web standards and accessibility, it half amazes me that an article like that would be written with with such blatent disregard for them. I say only half because the other half of me remembers that this is Microsoft and their view of standards is far from decent.

Sorry for coming down so hard but years of frustrated development and wanting to use sensible method for creating sites has left me rather bitter.

Honestly, did you think the reaction would be good to this?

Please, Please, Please tell your folks at Microsoft, to STOP POSTING SAMPLE CODE THAT DOESN'T MEET XHTML 1.0!!!!!!!

<http://www.w3.org/TR/xhtml1/#h-4.2>

In the referenced article, and all over MSDN, Microsoft constantly uses:

<UPPERCASETAG>sample text data</UPPERCASETAG>

Not only is it REALLY ANNOYING! it is so blatently wrong!

Pretend for a moment, that IE7 will actually be a good, standards based browser, and show some commitment to the future of the Web, and not resort to these "circa 1990" code snippets. That's right, if nothing else, by using <TABLE>, and <BR>, you are making it look like you haven't done web design in this Century!

Thank you

I just have a personal web site, and even I know that UPPERCASE tags and attributes are wrong.

The IE developers are partying like it's 1998. Someone go in their and tear a few sheets off their wall calendar. If they think security is the public's only concern, they have another think coming to them. If sites are prettier in Firefox than in IE, who wouldn't switch?

When I see an article on MSDN with UPPERCASE tags, I just stop reading right there. Whoever wrote it is dumber than even me.

I think this is part of an elaborate 'laugh at dumb webmasters' IE team game:

STEP 1: Post blatantly idiotic blog entry
STEP 2: Wait for angry hordes to rip you to shreds
STEP 3: Score a point for every post saying WTF or words to that effect. Extra credit for insults, slashdottings, other browser devs commenting on your stupidity, and so forth.

I just want to second or third the Nifty Corners solution. It is mostly CSS and works pretty well across browsers.

First, the good things:

I agree with the IE people when they say IE7 won't support a CSS3 draft spec. C'mon, curved borders? There are far bigger fish to fry than adding whizbang features that haven't even been finalized yet. Listen to any competent web developer who complains about IE rendering bugs and just *wait* for him to mention lack of support for CSS3's border-radius.

Still waiting?

Maybe in a few years he'll mention it, by which point it may have been standardized and implemented with sufficiently few bugs in other browser and he'll have a reason to complain. Right now, tho, assuming release schedules were not a priority, it would be incredibly low on the ladder.

(Besides, you know if IE7's implementation had bugs in it, we'd be working around them for the next five years. As long as IE has a longish development cycle where we'll be stuck supporting a browser simply because it's used by everyone still on Windows <insert old version here>, I'd prefer features implemented properly with very few bugs as opposed to features implemented halfway with lots of bugs.)

Also, I think I somewhat agree with the author when he says the last solution (with three <div/> elements) is difficult to read. Despite it being far less code than the table method, it's far less intuitive. <div/>s have no inherent styling whatsoever, so it's not obvious why they're there unless you want to dig into the CSS as well (which might even be maintained by another person). Tables, on the other hand, make perfect sense: tables have rows, rows contain cells, and cells can span rows and columns. Tables have inherent, well-known styling which makes their use here much more understandable, even if from a code standpoint it requires more markup and is less performant.

Now, the not-quite-as-good-but-not-bad things:

At least one commenter here has suggested a JavaScript solution, which seems to be ideal to me. Markup can be perfectly sensible - you won't have to deal with div-in-a-div-in-a-div hacks within the page. Also, if you were to code it to do the div hack method, it would be as accessible as the divs method is. (Remember that this is a semantically meaningless design issue, so if the user won't/can't load scripts he won't miss anything.) The only drawback I see is that you're mixing the design aspects with the content aspects, but the addition of one line to include a JavaScript file should not be that much of a burden. What were the reasons this wasn't suggested? I suspect space issues might be a problem, as the script would probably be too complicated to introduce. That, however, is just speculation.

Lastly, another commenter asked about your use of CAPS for the HTML elements in the source code examples. For regular HTML this is perfectly acceptable, but for XHTML it's not acceptable. Why not go a little further and add some future-proofing to this by lowercasing the elements? It's quick and painless, and because HTML's case-insensitive here you'd be risking nothing in terms of compatibility.

Thanks for all your feedback. I just shortly want to point out: There is no perfect solution until CSS3 is ready and most browsers have implemented it (us included). Until then each solution has their pro/cons. Please feel free to use the comments here to share what you think your best solution is.

Thanks
-- Markus

I agree with Jeff, it would be premature to implement CSS 3 rounded corners.

As for the uppercase tags, it's not an error in HTML, but it still "smells bad". I've not come across any competent developer that has used uppercase tags in *years*. I have, however, seen plenty of complete idiots using uppercase tags. It could be the best code in the world that is in that article, but I'm still going to read it with the preconception that whoever wrote it doesn't know what they are doing.

Are you kidding me?!

Addition to my previous comment: even if one were to implement rounded corners using this ugly GIF solution, one should at least put all the corners into the same image so that the browser doesn't have to do four requests instead of just one. It improves the performance significantly, especially in IE that always sends If-Modified-Since requests for cached files regardless expiration headers (btw will this be fixed in IE7?). Here are the details: http://wellstyled.com/css-nopreload-rollovers.html.

Nifty Corners:

http://pro.html.it/articoli/id_599/idcat_31/pag_1/pag.html

"I didn't realise anything was being done on the bleeding issue though?"

@Robin: If I correctly understand what you mean by the bleading issue (i.e. background-images visible outside rounded borders) then it sure looks like he is fixing this too.

All caps tags and attributes are very definitely an error in the current standards, XHTML 1.0 and 1.1. They do not validate. This has been true for about four years now.

All caps tags were permissible under HTML 4.01, which dates back before the turn of the century.

To those esposusing Microsofts failures and Firefox's greatness I would like to remind all of you that Firefox does not support standards either (What!? Heresy! He dares defile the almighty Firefox). Don't get me wrong I like Firefox, and I think IE has problems, but Microsoft is working on them. As far as rounded corners are concerned ... sure Firefox has rounded corners ... I wouldn't use them though cause they look like crap. Not to mention that they aren't standard. So, all those bashing Microsoft for proprietary code ... look in the mirror. BTW don't believ me that Firefox does not support standards check out the acid test. http://www.webstandards.org/act/acid2/test.html#top The only browser to support it so far is Safari. All browsers suck because they are all made by humans who interpret things differently. Stop ranting on Microsoft, get lives, and let them do their jobs.

True, Mr. Clown. Microsoft should not be measuring itself against Firefox. It should be measuring itself against standards.

I wrote some help files for a developer. They were in XHTML 1.1, encoded as UTF-8, and they validated. He decided to use them for another application so he edited them but needed help. The files were not UTF-8, some had over 100 errors according to the validator, and they were filled with uppercase tags, illegal tags, unclosed tags, and tags that had no business loitering in there.

I cleaned it all up. I couldn't believe the developer had produced that big of a mess, so I asked him how he edited the files.

In Visual Studio, he said. No wonder.

I understand that Visual Studio 2005 is going to use this century's standards and generate valid XHMTL 1.1. I suspect IE7 will match VS2005. I just hope Microsoft doesn't implement a subset of the standards, like now (no position:fixed, for example).

Microsoft got in trouble once before for implementing standards before they were standardized, so I think CSS3 is too much to expect.

"All browsers suck because they are all made by humans who interpret things differently."

More or less, yes. But IE wouldn't suck quite so hard if they hadn't shelved it for four years.

That article is garbage.

It uses unsemantic tables to present a stucture that is, well, not a table.

Get with it. A CROSS BROWSER, CSS solution has been in the community for over a year now.

Thanks for coming out though, and btw, don't you dare destroy RSS.

You missed a good opportunity to impress people. Instead of just a 'catch up to Firefox release' you could have went for CSS3 support and brought in a whole new era of web design. The blogs would all have something nice to say about IE 7....

Instead you demonstrate you don't get the web. At least you don't get the difference between proactive and reactive.

>>Instead you demonstrate you don't get the web. At least you don't get the difference between proactive and reactive.

No. That is what got them into the predicament that they are in now. Hello people!! CSS3 has not been cemented as a standard yet. It would be foolish to release a browser right now that fully suported CSS3 because you would just have to revoke it when the real CSS3 was cemented. Brains people ... use em.

Staying ahead of the curve?? OMGWTF, lousy round corners?
Once upon a time there was MS IE staying ahead of the curve proposing vml? The MSOffice guys bent their mind to that zombie?
Go and see http://www.antigrain.com/demo/index.html ? How about adding real scalable graphics (binary) behaviour to IE??

Markus, stop hiding behind your computer screen and at least put up a decent argument as to why we should use the solutions you suggested.

Somebody please pinch me. "Enjoy", enjoy what? This rounded corners article is mostly counterproductive (wrong approaches, nasty code snippets), so kids, look away.

And audience, please pass on recommending vendor specific properties. Or do you belong to the "I don't validate because my parents didn't told me to" fraction?

(Jens, just unsubscribe from this feed, just unsubscribe...)

Awwwwwwweeeeesssssoooooommmmmmmeeeeee.

Welcome to 4 years ago.

Those that pointed fingers at IE till now for avoiding "standards" are introducing "standards" of their own? What nonsense is this? Mozilla is a batch of hypocrisy!

And yes, these methods for rounding corners aren't IE-only and have been around for ages.

k. I'm done. Keep up the great work IE-Team :)

-moz-border-radius (and other -moz-??s) is perfectly standards compliant. Check out the section on vendor specific keywords in the spec.

Jim,
'standards' method for that crooked shapes to a great extent is svg? That antigrain stuff let's you add basic svg behavior to ie in a couple of days. Markus may start with the svg behaviour tonight? At least it would keep him far away from the 'corners with ie today' type of innovations:-))

Where to start.
1)Ugh, code you linked to, ugh.
2)On the release of ie7, Please wait until CSS3 is finalized, something tells me you will need the extra time anyway.
3)Id have more insults but I feel that they were taken care of by previous commenters.

There's nothing stopping IE7 from having "-msie-border-radius" that implements CSS3 rounded rectangles until the standard is finalized.

Or they could even use "-khtml-border-radius." I wouldn't recommend "-moz-border-radius" since it doesn't completely follow the CSS3 spec, but since I rarely use assymetric radii this isn't an issue for me.

I'd personally rather just edit my CSS files if the spec changed than go through EVERY HTML file/script, find the nasty nested <DIV> or <TABLE> elements required to hack rounded corners into IE, and change them to the CORRECT markup.

But the standards can't be finalized until a few different browsers implement it. You don't seriously want a standard that exists only on paper for years and years, only to find that it's impossible to implement.

Seriously, updating a stylesheet every now and then isn't that big of a deal if your markup is semmantic. Well, it wouldn't be if we had more selectors (like the + and > selectors) and pseudo-classes. There's all this talk about "templates" and "theming" websites, but with good CSS support, a site can be customized drastically without any changes to markup (look at CSS Zen Garden--which makes me jealous because of my minimal design skills).

Updating loads and loads of content, however, is a pain, unless you plan to go XML->XSLT->(X)HTML->CSS->screen. Personally, I'd rather go XML->CSS->screen, but that won't be viable for a while, and without CSS2 and eventually 3, it is not easy to do correctly.

So, I'll gladly put "-moz-border-radius," "-khtml-border-radius," "-msie-border-radius," in my CSS until the standard is finalized. At that point, I can just put "border-radius."

If you're really worried about forward-compatability, don't use the vendor extensions and draft specs. But it helps the specs to move forward if they're actually implemented in some manner.

MSFT is trying to push this article off the front page viewing area.

a TABLE?! You will never learn, right?

You do realize that capital letters in html documents went out of style with the xhtml standard, right?

Modern Web Developer said:
> Please, Please, Please tell your folks at Microsoft,
> to STOP POSTING SAMPLE CODE THAT DOESN'T MEET XHTML 1.0
Say why? HTML 4.01 would be more than enough...

Ken said
> All caps tags and attributes are very definitely
> an error in the current standards, XHTML 1.0 and 1.1.
> They do not validate. This has been true for about
> four years now.
Your point?

> All caps tags were permissible under HTML 4.01,
> which dates back before the turn of the century.
Uh, your point again? XHTML 1.0 is merely XML'd version of HTML 4.01, and even though it's acceptable to send it as text/html it's basically rendered as HTML 4.01 when you do so anyway.

Check Anne van Kesteren's blog, he went back to good ol' HTML to show how useless XHTML is right now.

HTML 4.01 IS a standard, the only thing XHTML 1.0 *could* bring over it is XML and modules, which need the XML mode and MSIE doesn't handle XHTML (try feeding it a page sent with application/xhtml+xml MIME type).

and HTML 5 will be a standard too, at the same time as XHTML 2.0, even though they cast aside al synchronization between the two branches for the occation.

Fred Clown said:
> Not to mention that they aren't standard.
They are proprietary and defined so according to the spec's guidelines, using the spec-defined prefix.
> The only browser to support it so far is Safari.
Wrong, Safari, Konquerror and iCab3 are all supposed to pass Acid2... as development versions

Jesse said:

> You missed a good opportunity to impress people.
> Instead of just a 'catch up to Firefox release'
> you could have went for CSS3 support and brought
> in a whole new era of web design. The blogs would
> all have something nice to say about IE 7....
Guess they could've gone for CSS2.1 for a start...

I can understand the IE team not gunning for CSS3, even as a development feature that'd be update with the draft, but not implementing CSS2.1? Not bothering getting fully CSS1 compliant (and i'm not talking about CSS1 Core, no one talks about CSS1 Core when he talks about CSS1 compliance) or implementing advanced CSS selectors (mmm, yummy first-child, next-sibling, first-letter... too bad ya can't use them)

Jim said:
>
Those that pointed fingers at IE till now for avoiding
> "standards" are introducing "standards" of their own?
> What nonsense is this? Mozilla is a batch of hypocrisy!
Uuuh, no? Your post doesn't even make sense man...

Mozilla implemented vendor-specific rounded corners. They don't follow CSS3 specs, but don't claim to be standard or soon to be standardized, and they use Mozilla's vendor-specific prefix defined by the CSS spec (-moz-).

The problem is not that there is no way to make rounded corners (even with divs) but that IE lacks correct implementation of CSS to make it happen.

Most of the times I must downgrade in features or compliance (xhtml -> html) because otherways I must jump between to much hoops or use many ugly hacks. It's like that when one thing seems to work something else breaks. I do not want to sound as a troll, but I can say that those situations are very frustrating and cost a hell lot of time to fix sometimes.

And this day of age when more and more devices are going online, I really preferer pages that are strict in markup.

Great tip!!!!!!
Here's anothr one u might like. If u want 2 hav txt in all diffent color make image in MS Paint with txt in it of right color. Save as .bmp file and load in 2 yor page! Wicked color!!

It's no using posting your comments here. If it would change anything it would be really great. But the MS Blogs are just here for MS developers to say: "Listen, this is how we'll do it. It sucks and is the same crap as always. But we have this really lame reason to do it (usually their 'customers' have indicated no need for so and so feature)". Pointing out in the comments why it sucks doesn't help. They don't read or they read and just laugh in their ignorance.

Exactly why MS is headed down the drain. They once were innovative. Now they are missing the boat big time, and this is illustrated by the blog. Seriously, if this was a Mozilla dev blog, we could point out there was a better solution, and it would be heard (and probably implemented). That's why Firefox is so much better than IE.

Rounded corners? Do me favour. When IE7 doesn't look as if it will even solve existing problems with basic layout features, eg. float model, I hardly think it's worth wasting hot air about rounded corners. Then again one has to ask what would happen to Microsoft's game of making standards-compliant browsers appear buggy if it started implementing standards properly.

ah, yes, the always popular IE using-stupid-ancient-techniques-in-order-to-overcome-obsolete-browser-technology technique...

it's a well known one and has been dealt with for years by web developers desiring to build open, portable, true web applications.

thanks for nothing...

Hi guys - I'm the one that's working (when my kid doesn't interrupt) on the corners for Mozilla.
My solution fits the css3 draft, and has a few improvements over the current implementation - ie; anti-aliasing, dashed curves, no more image bleeding, and proper two-axis curves (the css spec calls for ovals - not circles).

As I've mentioned at some point somewhere, when I'm happy with the code, I'll rewrite it in C, then offer it up for whoever wants it, free. I'll be directly promoting it to Mozilla and KHTML, but it will be free for anyone to pick up.

Why would I give it out free for even The Beast? Simple: because I'm tired of writing ugly hacks for simple problems - I want to write plain HTML and CSS and have it implemented as I want it to be implemented. To that end, when I am finished with the code, /please/ consider using it.

Kae

HTML 4.01 loose (pref strict.dtd) is fine.

Table with rounded corners is a low-tech solution, very easy to implement, and tends not to suffer from the cross browser CSS implementation "bugs" that occur with cleverer/better implementations. And they tend to size with content (height-wise anyway) btter than many of the javascript/css solutions.

And what if JavaScript is disabled in your clients browser? I've seen a few clients who do this for external sites.

Until we get proper CSS support across all browsers, a pragmatic use of tables for content will still work for many people.

But please, do investigate the alternatives.

This 'solution' is a laugh. Maybe IE7 'll support :after and :before (like all the other browsers), this requiers no extra markup.

Poor mans rounded corners

<fieldset><legend>round corners</legend>Sort of round</fieldset>

Have a look at this for a another solution to rounded corners:-

http://www.webreference.com/programming/css_borders/index.html

The truth is that there is not a 'proper' way to implement rounded corners on your webpages at the moment. As has always been the case with web development, the more advanced stuff needs some ingenuity from the developer until such a time that it makes it's way into the browsers.

Personally I prefer to use a background image on some arbitrary element rather than an img tag or a pixel based solution. But each to their own.

The nifty solution is nice, but what if I want a 100px radius?

I had a go myself at a hack using characters (i.e. the "o" character) and overflow:hidden. It failed miserably I'm afraid to say (largely due to inconsistencies between even Safari and Firefox), but I reckon a solution that is in some way vector based would be the optimum one.

Back a few years ago we were all desperate to begin using CSS, but it wasn't possible due to Netscape's large market share and pitiful support. That time Netscape were the villains and MS were the heroes. The Firefox crew have produced a very nice browser, but their track record over the last decade is not much better than Microsoft's. Sure, IE6 is buggy and dated but the Mozilla equivalent back then wasn't too good either. Let's wait and see what they can do with IE7 before we give up all hope. ;)

I think the Acid test is a superb idea and it worries me slightly that the W3C haven't provided anything similar to help achieve consistent behavior between browsers. That surely would have helped prevent the mess we're in now.

Ahhh, more lazyness of the IE people. Nice.

I've got to admit that yes MSIE has had it's shares of problems. However I'd like to keep an open mind, and here is what I mean.

Think about if you were working for MS. While they could pay you to improve the product the boss has decided at the time that they pretty much killed netscape. While you may go home and eventually end up using Firefox the boss has money on his mind.

So I would at least like to think the developers are in a hard spot. I do think they have some understanding of the frustration that we designers and developers are putting up with.

CSS 3 should *NOT* be supported officially though I think it would be wise to prep IE7 for css3 so that once it becomes standard at least some of the more popular and crucial aspects of it will be supported *IF* and only if the css3 spec has been developed enough for the MSIE team to work with; otherwise we'll be looking at some rather nasty IE7 hacks to get css3 to work and then people will be back b*t*hing and moaning as usual.

Yes I am frustrated at the fact that I have to still use tables and mix appearence with html here in the year 2005. I'm also disapointed that we don't have flying cars, oh well.

As designers, at least the professional portion of designers we should be charging extra for jobs that require hacks. When your boss tells you "do it" then you say "pay me". It's as simple as that. If you are told to do something that is no supported then you need to stop grinning and bearing it and stand up and take that extra cash for being both a designer and a hacker.

I expect IE7 to support most of css2 and maybe even 99% of css1. I would hope that it fully supports (including the quote on quote optional stuff which there should be no reason for optional standards in css, see spec 1 sheet and do some reseach, it's there with an ms root) css 1 and 2.1 in full without exception. If it does then I as a designer will be happy. CSS 3 isn't a spec yet so no one has the right to demand anything of MSIE team for CSS 3. If the MSIE team wants to gain some shred of favor with the designers however they would be wise to implement some system where (in the future) sites using CSS 3 (once it's official!) then MSIE will require some windows update to properly display the page as someone earlier suggested that MSIE could have it's rendering engined prepped as so.

MSIE and designers are like American politics, everyone is either too far left or too far right to understand the concept of something somewhere in the middle. I would lean left though modestly in the web sense and I won't make any political comments however as this obviously isn't the place for it.

Keep in mind that is it the open source community over at Mozilla that's forcing IE7 to come out before Longhorn. Eventually big companies like MS will see the usefulness of opensource. We my brothers will eventually hunt down all those spyware infested pcs and rename the iexplore executable. It's up to MS to decide if they will get in gear before MS passes it's current bitch stage and falls in to extinction like NS4. Here's hoping the MSIE team wins back at least our desposition with IE7 and like any good product that it will be released when it's done and not before hand.

I really hope that MS will use WindowsUpdate to it's full potential to get IE7 on users' PCs. We can't afford to wait 2 years or however long it takes to get 95% of IE users on v7.

And then, it would be good if they could patch up any standards compliance bugs as quickly as they deal with security problems. And distribute patches immediately to everyone via WindowsUpdate. If they can lead in this area you can guarantee that the Firefox and Safari teams will raise their game too with their release cycles.

Microsoft has shown recently that it can do a very good job of managing software updates - it could really get ahead of the competing browsers if it can stay ahead of the standards rather than playing catch up. Perhaps this is a perfect opportunity for them to demonstrate that they can compete on all fronts with open source software?

If WindowsUpdate is not used it will be a big opportunity missed.

Round corners have been in IE for over 7 years.

See http://www.w3.org/TR/1998/NOTE-VML-19980513

Example:
<html xmlns:v="urn:schemas-microsoft-com:vml">
<head>
<style>
v\:* { behavior: url(#default#VML); }
</style>
</head>
<body>
<v:roundrect style='width: 120pt; height: 80pt' strokecolor="red" strokeweight=5pt>
<v:stroke filltype="solid" />
</v:roundrect>
</body>
</html>

Here is what I dont get

Who the heck cares what the friggin code looks like?

Jesus, some of you people spend so much time on valid code, perfectly tabbed this, perfectly commented that, perfect capitalization, perfect just perfect code - oh how wonderful.

Who cares? Do you really think that the end users care? My god - the only thing that matters is what that markup does, not how it looks. And I hate to break it to you - but it really is not that big of a deal if your site is cross browser compatible or not. If you have a site that all it does is have firefox plugins and tutorials on it - who cares if it works in IE, and if you have a site that deals with a user group that includes no techy people - and your products are built for windows, then you are looking at about 98 percent IE usage rate - so who cares if it works in Moz? (IE last I checked still has 95 percent usage on the windows platform - throw out all the techy type - combine with my own logs - and that is a low educated guess)

The only thing that is important is that you meet the needs of your users. Not if you meet the needs of another webmaster, or standards group, microsoft, or anybody else - and about the last 5000 regular users I have talked to - if I needed to them to look at the source - they didnt know how to cause they never had before, and probably have not since.

Markus Mielke, that is a hack, which really isn't easy or efficient.

> Who the heck cares what the friggin code looks like?

The people who have to read and write it all day every day?

> the only thing that matters is what that markup does, not how it looks.

I can only imagine you haven't written anything but the most trivial "hello world" type programs.

Spagetti code simply costs more to maintain. Maybe if it were a hobby project that has one or two people working on it, it might not matter, but for serious work, how clean the code is matters. Matters enough to be able to measure the difference in cold hard cash.

> And I hate to break it to you - but it really is not that big of a deal if your site is cross browser compatible or not.

And I hate to break it to you, but if I dropped cross-browser compatibility, I'd be out of work.

> If you have a site that all it does is have firefox plugins and tutorials on it - who cares if it works in IE

That's a contrived example that is not representative of almost any real-world situation.

> if you have a site that deals with a user group that includes no techy people

Who cares how techy they are? Absolutely loads of people use schools, libraries and their workplace to surf - these are situations where the knowledge to pick a browser is not a factor in the slightest. They use what they are given.

> and your products are built for windows

Again, not representative of most companies.

> then you are looking at about 98 percent IE usage rate - so who cares if it works in Moz?

Would you accept 98% of your salary because your boss said he couldn't be bothered going to the "extra effort" of paying you 100% of your salary?

What boss in his right mind would willingly throw away 2% of his customers for no good reason?

And you've made the assumption that 2% of visitors equals 2% of profits, haven't you? It could well be that the 2% of your user base you throw away is disproportionately higher spenders than the rest. Who's going to be checking out your website on a handheld, for instance - somebody who earns minimum wage, or somebody with lots of disposable income?

> IE last I checked still has 95 percent usage on the windows platform

So in other words, everywhere you said "2%", replace that with "5%, plus however many non-Windows users there are"? That's upwards of one in twenty people you are saying nobody cares about. You really think a company wouldn't care about a 5%+ drop in sales?

> combine with my own logs

Oh wow, access logs. They are *really* accurate. You might as well just make up the numbers, guesswork is just as accurate as observing HTTP traffic. And that's before you factor in the near certainty that your traffic is not everyone's target market. And that's before you factor in the problem of self-fulfilling prophecy - if you are building websites that don't work in Firefox, then you are undoubtedly going to see far less traffic from Firefox users than if you are building websites that work in Firefox.

> The only thing that is important is that you meet the needs of your users.

...says the person who is quite willing to show 5%+ of them the door. How are you meeting their needs?

I just use -moz-border-radius. Hip, cool FF users get hip, cool rounded corners. Square IE users get square corners. It's called matching form and function, and the site still works whatever shape the corners are.

Of course, I have the luxury of coding for myself. If I was doing it to a spec, there are plenty of neater ways of rounding corners - even if they need a couple of spurious divs/spans - with CSS than adding some manky table markup. Wake up guys, it's 2005!

If Microsoft are really this out of touch with web development, and the state of the web in general, I can't say I have much faith in IE7 being a reasonable browser.

Was this post a joke?

No, seriously. Was it a joke?

IE team,

Thus far I've read your blog without complaint, hopeful that IE7 would finally alleviate my web-design pains.

But this is too much to bear.

I came up with solutions very much like those listen in the MSDN article as a Semester 1 Internet Publishing student -- **in maybe ten minutes!**

It’s a very crude solution, and one that necessitates the intermingling of content and style -- something today’s web designers, including myself, are leary (and weary) of doing. (Site redesign should mean something here.)

The CSS3 solution is plainly the best, as it allows the content/style separation. -moz-border-radius is workable (Google Adwords uses it for its nav tabs). A true CSS3 border-radius property would be the best of all, as it would allow **browser-independent, CSS-only control of corners** without any silly GIFs or what-have-you.

If IE7 does not allow CSS-based rounded corners, guess which of my sites’ visitors will not be seeing any rounded corners?

***On behalf of webmasters everywhere, I implore you, IE team, to include a CSS-based solution for rounded corners!*** Thank you for you time, and *please* consider my request!

Alan Hogan

> Who the heck cares what the friggin code looks like?

The people who have to read and write it all day every day?


Then I would suppose they wrote it in a matter that they can read. If not - they are pretty dumb. I personally do not care if you can make heads or tails of what I write - not important to me. Only important if it does what I want it to do.




> the only thing that matters is what that markup does, not how it looks.

I can only imagine you haven't written anything but the most trivial "hello world" type programs.

Spagetti code simply costs more to maintain. Maybe if it were a hobby project that has one or two people working on it, it might not matter, but for serious work, how clean the code is matters. Matters enough to be able to measure the difference in cold hard cash.



Again - I would assume you write in ways that make sense to you. If I am the only person that is going to mess with a chunk of code - My variables are normally about one character long - and I know what the variable is for because I always use the same letter to represent the same type of thing. I reference functions that are about two characters long that you could spend a year trying to find because of when and how I included them - both in JS and PHP - works for me, I know what is going on - saves me a very measureable about of time because I do not have to write out 37 character function and var names that I see so many use - and then try to figure out what the almost makes sense name is refering to.

> And I hate to break it to you - but it really is not that big of a deal if your site is cross browser compatible or not.

And I hate to break it to you, but if I dropped cross-browser compatibility, I'd be out of work.




Again, as I said - it depends on the situation. I promise ya that over 50 percent of all web style of work is done to an IE only compatibiltiy. Before you start screaming - stop and think. Intranets exist in many places, and are most often only done IE only. Then add in all the software that uses webpages as part of its functionality or UI, that are hosted with in the IE Webbrowser control. Those two together I am going to say that are maybe 75 percent of the actual USE in the world. (actually probably higher since things like Organize your Favorites in IE are nothing more than a webpage)







> If you have a site that all it does is have firefox plugins and tutorials on it - who cares if it works in IE

That's a contrived example that is not representative of almost any real-world situation.



It doesnt make the example invalid.



> if you have a site that deals with a user group that includes no techy people

Who cares how techy they are? Absolutely loads of people use schools, libraries and their workplace to surf - these are situations where the knowledge to pick a browser is not a factor in the slightest. They use what they are given.




You would be wrong. The vast majority of my users do not even know that Firefox exists. I know this cause when I am talking to some of them one on one, and mention Firefox, Mozilla, MyIE - they have no clue what I am talking about.











> and your products are built for windows

Again, not representative of most companies.




You are telling me that most software companies do not design their software for only Windows? I think you would be wrong here.











> then you are looking at about 98 percent IE usage rate - so who cares if it works in Moz?

Would you accept 98% of your salary because your boss said he couldn't be bothered going to the "extra effort" of paying you 100% of your salary?






What does that have to do with anything? Browsers are the only place the notion that something should work on all systems exist. The most profitable sofware market is still video games, and they are rarely made to work on anything other than Windows and some con