Tony Yarusso wrote:

Am I correct in believing that other browsers choose the display mode based on the DOCTYPE?

I'm not a decision-maker in this group, but heartily against any IE-specific changes in Drupal personally.

IE 6 and 7 have the same display modes as the other browsers (quirks and standards compliance mode) that's triggered by the doctype, it's just that IE8 will introduce a new switch that goes a little further than the current doctype. http://www.alistapart.com/articles/beyonddoctype One potential problem I can see is that someone might create a great module that uses new features introduced into IE9 (a long way away). If Drupal core were to use this new module we would have to include <meta http-equiv="X-UA-Compatible" content="IE=9" /> to take advantage of the module's features. This would essentially lock the rest of Drupal and contrib modules into IE9. Would we simply ignore the module since it requires an IE specific feature (as in excluding 6, 7 and 8)? Or is there a fat chance of this scenario happening at all?

On Jan 24, 2008 9:14 AM, Victor Kane <victorkane@gmail.com> wrote:

We need to clarify the discussion a bit.

The meta tag is more flexible, invoking IE9 or "edge" (IE1000), for that matter, does not lock you into IE:

The referenced article points to something like this, which would be cross browser compliant:

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

Specifying the latest release of IE would get you out of quirks mode automatically.

After all, it might be an IE only meta tag / HTTP header, since other browser developers are not too happy with it, there are lots of possible problems: http://weblogs.mozillazine.org/roc/archives/2008/01/post_2.html So the FF=3, OtherUA=4 part there is simple speculation right now. The Mozilla arguments are: - the browser needs to ship with multiple rendering engines for all users (higher footprint) - an iframe in IE6 mode might need to communicate with a document in IE8 mode (different APIs, different DOMs) - you cannot freeze the IE6 engine, you need to maintain it "forever", because you ship with it, so you need to solve bugs / security issues (which might break APIs) - also more attack possibilities since you have more engines installed So it does not look like the other browsers are following suite. Gabor

Well, this is a great list of materials. Lots of food for thought. Just, concerning your point "...don't be suckered by Eric Meyer and Jeffrey Zeldman's support for the idea - get educated..."; I think that the need to debate what Eric Meyer, certainly someone on the forefront of CSS standards use, has to say on the subject is hardly getting suckered into something. It is a very significant move by Microsoft, which may amount to nothing, may amount to something, may be adopted by other browsers, may not (they all may find positive uses for it, at least it might be a switch to level the playing field) but the points being raised are central to the future of webdesign. While profit margins make the decisions in the context of the world war between Microsoft - HP - IBM - Sun (a proud Drupal sponsor), there is no hope for rational standards, really. Which would include your Jeremy Keith position, which I would agree with. The question, however, will be how to get around what the corporations actually put out. And, 75% still use IE, so... Again, whatever is adopted, all that Drupal needs to do is make the switch accessible via admin interface (I would be strongly against leaving this to a theme level, since it is a royal PITA to have to redo settings while changing themes). saludos, Victor Kane http://awebfactory.com.ar On Jan 24, 2008 10:07 AM, Adrian Simmons <adrinux@perlucida.com> wrote:

Rowan Wigginton wrote:

...

Do you think the changes announced [1] by Microsoft could have a significant impact on Drupal's (or any CMS's) progress?

[1] http://blogs.msdn.com/ie/archive/2008/01/21/compatibility-and-ie8.aspx

IE8 isn't even out yet and given the controversy[1,2,3,4,5,6,7,8,9] surrounding this suggested meta/version-targeting feature it may yet change, so lets not worry too much about this right now. It could be applied at the theme level or even the server level (outwith Drupal) when the time comes, *if* the time comes.

In the meantime, don't be suckered by Eric Meyer and Jeffrey Zeldman's support for the idea - get educated. Here are some links to read around this idea:

[1] Drew McLellan points out that - despite what's said on the IEBlog - the Web Standards project is not 100% behind the idea, several members were only aware of the proposal after the publication on ALA and seem quite miffed: http://www.webstandards.org/2008/01/22/microsofts-version-targeting-proposal...

[2] Andy Budd on why this would be a bad thing for microsoft in the long run: http://www.andybudd.com/archives/2008/01/has_internet_ex/

[3] John Ressig (of jQuery) on why it would be bad for javascript: http://ejohn.org/blog/meta-madness/

[4] Ian Hixie has a bit of a rant too: http://ln.hixie.ch/?start=1201080691&count=1

[5] Robert O'Callahan on why we'll never see this in Firefox: http://weblogs.mozillazine.org/roc/archives/2008/01/post_2.html http://weblogs.mozillazine.org/roc/archives/2008/01/slipping_the_ba.html

[6] Maciej Stachowiak on why we'll never see this in Webkit (Safari) http://webkit.org/blog/155/versioning-compatibility-and-standards/

[7] Anne van Kesteren (works for Opera) also thinks it's a bad idea: http://annevankesteren.nl/2008/01/ie-lock-in

[8] James Bennett has a good follow up to his "Fire and Motion" post of why Microsoft is having to do this: http://www.b-list.org/weblog/2008/jan/23/legacy/

[9] Jeremy Keith on why the execution is flawed, and how it can be fixed: "I think that the X-UA-Compatible header is a great idea. It's great for Microsoft. It's great for Microsoft's customers. But the default behaviour is wrong, wrong, wrong! This should be an innovative feature, not a mandatory part of the process of creating a document on the World Wide Web." http://adactio.com/journal/1402/

IMNSHO Jeremy Keith has the right answer, it's a good idea badly implemented.

-- Adrian Simmons (aka adrinux) <http://perlucida.com> e-mail <mailto:adrinux@perlucida.com>

Right, we are definitely on the same page :) On Jan 25, 2008 5:46 PM, Adrian Simmons <adrinux@perlucida.com> wrote:

Victor Kane wrote:

...

I think that the need to debate what Eric Meyer, certainly someone on the forefront of CSS standards use, has to say on the subject is hardly getting suckered into something. I was trying to say the opposite - just because Eric says it doesn't mean it's not up for debate - I think we actually agree :)

Besides I was being a bit harsh on Eric, he'd like the default to be 'latest' too, but seems to think Microsoft have no choice: http://meyerweb.com/eric/thoughts/2008/01/24/almost-target/

...

(I would be strongly against leaving this to a theme level, since it is a royal PITA to have to redo settings while changing themes). Good point. I guess a contrib module could inject the relevant meta though, and be configurable too. But it might need to default to 'off' because you can add an http header to the server instead of the meta.

I still hope Microsoft will change the default to standards mode, and this will all be moot. Time will tell.

--

Adrian Simmons (aka adrinux) <http://perlucida.com> e-mail <mailto:adrinux@perlucida.com>

I agree, this is totally up to individual designers to implement at the theme level. The core themes should probably all be updated to implement it, but as a theme developer myself, I prefer to keep anything design related as far away from the site admins as possible (don't wnat them changing a setting and messing everything up). Laura Scott wrote:

On Jan 25, 2008, at 5:19 AM, Victor Kane wrote:

...

Again, whatever is adopted, all that Drupal needs to do is make the switch accessible via admin interface (I would be strongly against leaving this to a theme level, since it is a royal PITA to have to redo settings while changing themes).

I feel just the opposite. This is totally a theming issue, and how it's addressed would depend upon the theme approach altogether.

Also, another dissenting view on this whol special-tag thing: http:// realtech.burningbird.net/standards/bobbing-heads-and-the-ie8-meta-tag/

Laura

-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com

The funny and sad thing here is that Microsoft does not want the standard compliant mode to be the default, and rather make it and opt-in. Granted the reason is backward compatibility and such, but still, the default is not standards, regardless. What we do in core now (at least in garland) is to detect if IE6 or earlier, and put out some specific CSS for it. No metas or other stuff. So, I say keep core out of this. No changes necessary. There are several browser detection libraries out there, e.g. http://techpatterns.com/downloads/php_browser_detection.php You can download it, include it in template.php, and spit out the appropriate meta if you so wish in page.tpl.php and friends.

I see both points. module developers need to know how to deal with the MS non-standard implementations, and so do themers, especially given we deliver CSS at both the module and theme layers. I like the helper function approach that drupal takes on JS. The architectural decision seems to me to parallel the accessibility standards compliance question. If core plays a role, I think that the key question to answer isn't whether the user wants standards, but what kind of browser we're dealing with and what mode its in so the developers can deliver the best CSS for the solution. I realize that browser detection scripts are hard, but I love using the Drupal JS detection scripts; they really make my life easier. perhaps a drupal_set_meta() function combined with themers could choose to include the print $meta or to override with drupal_set_meta () at the theme level? Anyway just brainstorming solutions, and I realize that it's a bit early for that given where we are with the IE 8 release and how little we know about what problems it is likely to cause with our standards based approach. On Jan 26, 2008, at 7:30 AM, Victor Kane wrote:

This is an interesting point.

One would think, that in the scheme of clean separation between presentation and business logic (code) layers, the choice of quirk mode would fit into the presentation layer.

But I feel this is more than a presentation question, the decision to go XHTML/CSS standards compliant crosses the gray line into an architectural decision for a given site or web application. That's why I don't see it as a purely presentation design issue.

And what about sites that have optional themes, or are multi-themes?

Of course, I think the theme should be able to override too.

On a practical level, the decision would be made in an early iteration of the development cycle, to go standards compliant, and then there might be a whole succession of themes or even parrallel theme development. I would want to avoid obligatory redundancy there.

That's what I was thinking.

Victor Kane http://

On Jan 25, 2008 8:31 PM, Laura Scott <laura@pingv.com> wrote:

...

On Jan 25, 2008, at 5:19 AM, Victor Kane wrote:

...

Again, whatever is adopted, all that Drupal needs to do is make the switch accessible via admin interface (I would be strongly against leaving this to a theme level, since it is a royal PITA to have to redo settings while changing themes).

I feel just the opposite. This is totally a theming issue, and how it's addressed would depend upon the theme approach altogether.

Also, another dissenting view on this whol special-tag thing: http:// realtech.burningbird.net/standards/bobbing-heads-and-the-ie8-meta- tag/

Laura

Chris Johnson wrote:

There's a wild rumor that MS won't support XHTML in IE8, which seems incredibly far-fetched to me. I think when people say that they're talking about IE accepting XHTML as application/xhtml+xml as opposed to text/html, it's more about the XML side of things than XHTML per se.

-- Adrian Simmons (aka adrinux) <http://perlucida.com> e-mail <mailto:adrinux@perlucida.com>