Forum Moderators: open
we’re looking forward to the feedback when we release the first beta of IE7 this summer. Stay tuned for more details as we get closer to beta.
[blogs.msdn.com...]
- generally the imperative to upgrade hardware (and thus get a new browser from MS typically) is attenuated as software/hardware upgrades have lost their lock-steop relationship.
- the imperative to upgrade browsers is attenuated because most people just don't care about the peekaboo bug and they can surf everywhere with IE5 right now.
Otherwise, pardon me while I stifle a yawn, hearing somebody talk about how excited they are to be supporting a few standards that have been supported by all the other browsers for years does nothing for me except prove once again that MS will never care about the web unless competition forces them to upgrade their products, if left to themselves, well, we saw what happens when they're left to themselves, all systems stop.
Will be irrelevant to me soon, I'm dumping all things MS except for testing this year.
except for testing
Well, that's the main reason it's big news for most of us here.
However, for reasons stated above, I share your yawning sensation - it will be years and years before you can count IE6 dead. Browsers have become a mature product like word processors and most people only update mature products when they get a new computer (and then generally only when it's bundled in) or get forced to for their jobs.
That being the case, this really doesn't make much difference. If I design to standards, and then have tweaks for various existing bugs or deficiencies in existing browsers, the appearance of a truly standards-compatible browser means that there is no change to the way I work.
The appearance of another very popular but standards-incompatible browser would be a real problem though, so let's hope they've really got it right!
Although this may be wishful thinking on my part, I've seen a lot of people upgrade their browsers because of this simple pressure from Microsoft. If IE 7 truly is a more secure browser, then we may see MS push for a quicker transition.
Oh, they care, trust me. There's already rumours that MS is putting in some stuff to make Office not run on Wine/Crossover. Of course, as soon as those rumours surfaced, the main wine/crossover guy said: oh, we're waiting for them to do that, so are our lawyers. It's all about being the only option out there, sealing the market, perfecting the monopoly. Don't want to leave loose ends hanging. Remember, Dos x.0 is not done until Lotus won't run, the inside MS company slogan back then.
Will be irrelevant to me soon, I'm dumping all things MS except for testing this year.
ignore me if i am just missing the boat.
woo hoo for them sorting out floats and the peekaboo bug. about time and all!
_height:50px;min-heightmin-heightCSS layouts are supposed to offer a graceful degradation in older browsers, but there is a significant risk that many CSS layouts are going to suffer from an uncertain life-span. Now is the time to go back to those hack-laden designs and move as much as possible towards using IE conditional comments, despite all the associated downsides of effectively returning to browser-sniffing. Back to tables, anyone?
move as much as possible towards using IE conditional comments
These are, of course, the solution, as they can target each version of IE directly. Just split your stylesheets into different files, and link to them from within conditional comments.
Linux, I already have two out of 3 computers running only Linux, it's just a matter of getting some of the tools I need running, although I think I'll probably end up just making a new linux only box for my main one, and keep my old windows one for windows testing, since it has the major windows versions installed on it already. A lot of the new debian based distros are really nice, each has strengths and weaknesses, so it's a matter of trying them for yourself. I'll probably go with a 64 bit system, want to wait 6 months for some of the 64 bit Linux stuff to settle down a bit.
OS X is a nice option if you can stomach:
a: the price, double by specs what it costs to make the same system from parts.
b: the interface, makes me queasy to look at it. Not a flame, matter of personal preference. I hate the mac interface. I'll take KDE any time.
c: Finder. Enough said on that one. Even mac people hate it.
d: moving from one proprietary system to another one.
Re ie css hacks. The only one I use commercially is * html, plus ie conditionals sometimes in a very limited way. To me the point of using css is to stop using hacks, not to continue using hacks. Hasn't worked out the way we'd all hoped of course, sad to say.
Back to tables, anyone?
We went back a year ago and I am very happy we did. I really like focusing on things like content and marketing, instead of hacks and standard code that breaks.
Nothing they say or do can make up for the damage they've already done to the web, it's unforgiveable for a company with MS's resources to have done this.
Re site layout, either conservative divs, or a hybrid of divs and tables, that works very well if it's a columned layout. Doesn't really matter though, don't do any more static HTML so changing the site's layout tags doesn't take much time any more.
(IE conditional comments) are, of course, the solution, as they can target each version of IE directly. Just split your stylesheets into different files, and link to them from within conditional comments.
Trouble is, this approach completely defeats the point of using web standards: write once, run cross-browser, and above all be forward-compatible. Conditional comments will patch up the far-out advanced CSS layouts (I've got a few) which are dependent on hacks to run in IE. What is the difference in real terms between the conditional comment approach and good old-fashioned browser-sniffing, serving different versions to specific browsers, including a fonts-and-tables one for NN4, four IE ones (IE5, 5.5, 6 and now 7), a Gecko one, a KHTML one and a plain text version for Lynx? Will you have to change your site again every time a new browser comes on to the market?
Which brings us on to...
I think MS will only fix the bugs when Standards Mode is applied, so the majority of sites that run in Quirks Mode will be unaffected.
I agree: backwards compatibility is far more important to Microsoft (and to Mozilla for that matter). But that brings us to the crux of the matter: that we may well have been kidding ourselves over the last few years. Standards mode and CSS were supposed to be the forwards-compatible ones, but they are the ones we may well have to patch and hack to work in a new, currently unknown browser. Quirks mode has gotten the stability prize: because the playing field for quirks-mode sites is guaranteed, it is the quirks-mode sites which stand the best chance of being forward-compatible. It's a tough pill to swallow for standards advocates like myself who have been doing CSS layouts and hacking them like crazy for years because it was the "way forward" and "the right thing to do".
Back to tables? It has been seven months now [webmasterworld.com], and frankly it has been liberating. As tedster said, it has brought my focus back to the essentials of what a website is all about: not fancy layout and markup, but content, color, presentation, ...
Trouble is, this approach completely defeats the point of using web standards.
Well I envisaged using conditional comments to supply different styles, rather than hacks. So a PNG image could be styled for IE7, but not for IE6 or earlier. That way, you are still using web standards in a correct manner.
Hacks are to be avoided unless they are critical to your layout. Try to use as few as possible, because when an updated browser comes out, the hacks might not work as before.
Standards mode and CSS were supposed to be the forwards-compatible ones, but they are the ones we may well have to patch and hack to work in a new, currently unknown browser. Quirks mode has gotten the stability prize.
The forthcoming HTML5 takes up the Quirks Mode story where it was abandoned for XHTML. You make a very good point here. There are two modes of HTML:
1. Invalid, where end tags are missed, etc. Modern browsers like Firefox and Opera have written special routines to parse such documents and display them as they see fit. The obvious problem there is that each browser's approach will differ - there is no pure and exact way for browsers to go about this. (Though I could be wrong.)
2. Valid, where tags are precisely used, so a proper page structure can be created by the browser, which will work across many platforms and browser types. In essence, it's the same as XHTML.
It seems now that XHTML was a bridge too far. Too strict for everyone to follow, it has led (partly down to IE6's refusal to operate in the correct application mode 'xhtml/xml') to a mess of sites that claim to be XHTML, but aren't. Either they contain simple errors, like unencoded ampersands, or are sent as text/html.
Perhaps we only needed one language - HTML. It just had to be done properly.
But there is a major difference between HTML and XHTML (sent as XML). With HTML, a single mistake doesn't matter. The document will still be displayed. Even dozens of mistakes don't stop this. But with XHTML sent as XML, a single error stops the document dead. It cannot be displayed.
Also the problem here is that XML stops the browser from displaying it until the whole document is loaded. Though I believe browsers and parsers may be able to fix an XML document on the fly as it loads, to get round this. (I'm not sure.) Compare this to HTML which can be displayed as soon as a single paragraph comes down the line.
Back to tables? It has been seven months now, and frankly it has been liberating. As tedster said, it has brought my focus back to the essentials of what a website is all about: not fancy layout and markup, but content, color, presentation, ...
I really can't believe this. What a disasterous step backwards. How are you going to maintain your site when a non-table way is so easy using CSS? (Columns can be moved around at will. Table cells are always fixed to their neighbours.) And think of all the extra markup!
To truly concentrate on "content, color, presentation" as you say, requires separating the markup from the style - which means doing away with tables!
It's like the past few years of learning has just been thrown away. Tables are the easy way out, the way that works in all those old browsers hardly anyone uses. Oh well, so much for CSS.
How are you going to maintain your site when a non-table way is so easy using CSS? (Columns can be moved around at will. Table cells are always fixed to their neighbours.) And think of all the extra markup!
I think I'd better clarify my return to tables: I'm not using them nested 18-deep, but just for the basic layout, then using CSS margin and padding to control them. The markup is only marginally more verbose than with CSS, and sometimes it is less, with table cells replacing multiple divs with class names. Separation of content and presentation? Firstly, I use templates, so am only managing one "page" for the whole site, and secondly a dozen divs which serve as the structural basis for a CSS-P site are merely replaced by a dozen table declarations which do much the same job.
My tables-based designs are all valid HTML, all meet pretty stringent accessibility criteria, and they are both more forwards and backwards compatible than many of my CSS sites.
On the XHTML served as
application/xhtml+xml*- I can testify to this: I used it for over a year!
I made a pure 100% css site and got sick and tired of imputting a new hack on a daily basis and running to anybrowser.com to see what the result would be in any of 8 different major browsers at 3 different resolutions.
so I did as encyclo did...had ONE basic table holding all elements and did the other 98% of formatting using css.
and, as he said....what a relief, what a weight off my shoulders.
My basic template using divs was something like 4200 bytes and was actually 4050 bytes using the one table with each division given a class name....so I actually saved a bit! Not to mention the 1-2k of hacks that weren't necessary for my style sheeet.
I can see that css-only for layout has a lot going for it and I would love to go that way if only the browsers all saw it the same way. I have put it on hold at least for another year or so.
I just put up a site live using the hybrid techniques encyclo is referring to, it's pure CSS, simple 3 cell content table, everything else is divs and ul lists for navs, perfect rendering, I spent about 1 hour looking at it before I decided not to use divs for the 3 primary columns, and I'm happy, site is stable, works correctly on all browsers >=5, straight html delivered to legacy and non css browsers, excellent performance, stability, and zero onpage styles or formatting.
It's a CSS site that uses a simple layout table, divs top and bottom for header and footer, the HTML and CSS could not be any cleaner as far as I can tell, and I could never get that column performance with any CSS column hack, and I've tried almost all of them.
Site is live, out the door, fully controllable. So what if I can't move the columns around, that's a non issue, the columns will never be moved anyway, it's the design, if the design changes to something that works with divs changing the site is trivial since it's almost all templated anyway.
Encyclo: My tables-based designs are all valid HTML, all meet pretty stringent accessibility criteria...
On the XHTML served as application/xhtml+xml thing: it's dead. XHTML has been out for over six years (that is an eternity in "web time") and the number of sites or even pages using it amounts to a big round zero. No-one in their right mind would use it unless they are particularly masochistic anyway**- I can testify to this: I used it for over a year!
You just contradicted yourself. Also the number of sites using it is bigger than you think. I know of a few myself.
The fact that IE doesn't support it is a good thing for the web, and I hope that IE7 won't support it either: it goes against the fundamental principles of how the web works.
Which is backwards compatible. But surely IE should support as many standards as possible - especially when Opera and Firefox do. As for backwards compatibility, you can serve XHTML as 'text/html' for those browsers that don't support 'xhtml/xml'. It's just that you lose any benefits (which are few) of the page being XML.
There's a great interview with Tommy Olsson about the pros and cons of all this:
2by4 - an interesting post. OK then, if you say you won't need to change the columns around, what about when it comes to removing columns altogether, as when you create a print stylesheet? With CSS, it's very easy to knock off the menu column and size the main content so it prints beautifully. With a table-based site, it's not likely to print well.
And what about handhelds? Again, CSS can be used to show them only enough layout to fit their narrow screen widths.
One answer (which does favour tables) is the new Opera 8 browser's "Fit To Width" feature. This scales a layout down to fit narrow screens. I'm delighted to discover that it works dynamically (on the fly) so you can reduce the browser window to any size, and it tries to maintain some sense of order. The most important thing is that the text remains readable.
Another thing I personally like about tables (even though I currently use divs for my layouts) is that when you turn styles off, you don't lose the order of the content. An unstyled table appears almost the same. Sometimes I think it's important to retain the content order.
I guess it depends on your needs.
It's a surprise to find that the web is moving backwards though! Back to HTML from XHTML, back to tables, away from divs. Next people will be using font tags again and doing away with their stylesheets! :)
MS is putting in some stuff to make Office not run on Wine/Crossover.
Well of course - Office (and esp. Excel going back before it was all integrated) is MS's killer app. It's how they keep people tied to their other products. IE just doesn't serve that function.
Going back to my example, it took me three solid days to get my template looking good using css in all 5+ browsers. When I finally decided to switch to one table containing everything, it was a half hour job.
When the major browsers catch up even with css2, I will be waiting with open arms. Needs must.
application/xhtml+xmltext/htmlapplication/xhtml+xmlapplication/xhtml+xmlapplication/xhtml+xmlAs for backwards compatibility, you can serve XHTML as 'text/html' for those browsers that don't support 'xhtml/xml'. It's just that you lose any benefits (which are few) of the page being XML.
If the page can be sent as
text/htmlapplication/xhtml+xmlIt's a surprise to find that the web is moving backwards though! Back to HTML from XHTML, back to tables, away from divs.
I see it as the return swing of the pendulum: we simply pushed things to far, too fast, and forgot the most important parts of the equation: the content and the end-user.
Silly statement, I do one, many other people do one, check your facts before making statements that are totally incorrect. The percent of sites doing this is miniscule, definitely, but there are some.
Hester, re tables/css print, all elements that are structural have ids, like any other css layout, the print stylesheet would do exactly what you do with divs, display none for the ids you don't want to display, change width of containers for print, there's no difference, as I said, there is no onpage styling, no onpage widths, it's pure css, but it's not pure divs. I did this to provide the most stable layout to the most people, very easy choice to make.
All cell widths are set in css, there is, again, no onpage styling of any type, the table tag was chosen because it offered superior performance for the specific layout requirement, other layouts and other requirements I'll use divs for, I prefer divs, but I'm not sacrificing large blocks of time to develop a product that will end up being inferior.
Just for the heck of it, I made the site xhtml transitional just to bug the guy who originally made it, makes no difference at all, html 4 strict and xhtml 1 transitional are almost exactly the same, except for />
Handhelds treat table cells the same as divs, they line them up one after another, that's a non-issue as well, they have to, otherwise handheld users couldn't view the web.
XHTML is a problem not because there's something wrong with it intrinsically, it's a problem because IE doesn't support xhtml at all in terms of mime types, that's IE's fault, put the blame where it belongs, Gecko and newer operas support it fine, Safari still doesn't last I checked.
Just for the heck of it, I made the site xhtml transitional just to bug the guy who originally made it, makes no difference at all, html 4 strict and xhtml 1 transitional are almost exactly the same, except for />
Exactly. Where's the advantage? If you prefer the XHTML 1.0 syntax and are serving it as
text/htmlXHTML is a problem not because there's something wrong with it intrinsically
Actually I think there is an intrinsic, fundamental problem with XHTML/
application/xhtml+xmlapplication/xhtml+xmlapplication/xhtml+xmlUsing XHTML/
application/xhtml+xml
html 4 strict and xhtml 1 transitional are almost exactly the same
Hmmm - I'd say htrml 4 strict is more demanding. No deprecated attributes or elements allowed.
On moving columns around via CSS
I have to say, the issue of moving columns around via CSS during a redesign is something to which I give 0% consideration - it's been so long since I've put up a static page let alone a whole site of them, that I think mostly in terms of templates, not pages, when it comes to presentation. My moving around all happens server side with server-side templates.
I do like the pure CSS sites and have a couple, but in retrospect I would say that it was pure geekiness, then simple habit, rather than practicality that drove those decisions (and still does to a large degree).
What is the difference in real terms between the conditional comment approach and good old-fashioned browser-sniffing,
One is a documented method that works pretty much as documented. The other is a hack whose results are unpredictable with respect to future browsers.
