Re: [Spam] Re: standard out of the box

On Dec 24, 2007, at 7:27 AM, Barry Rader wrote:

> Brad Kemper wrote:
>> On Dec 21, 2007, at 11:53 AM, Barry Rader wrote:
>>>
>>> "Maybe sniffing out * html and *+html or similar in the CSS could  
>>> also result in the document displaying in legacy mode."
>>>
>>> I personally do not believe that IE8 should not do any css sniffing.
>>>
>>> The trigger should remain the same in all cases, "the doctype".  
>>> When the doctype is used quirks mode should be off period.
>> Too late. IE6 and IE7 are still in common usage; they do sniff the  
>> doctype, and they do exhibit quirky behavior (to put it politely).  
>> Authors who are not as cavalier as you are about destroying  
>> compatibility for 70 or 80 percent of their market have to  
>> accommodate those horrible bugs in IE. For corporate intranet  
>> applications it is probably more like 95%+ of their market.
> So are you saying you would rather have IE8 render improperly?

Of course not.

> or have web authors forced to tell IE8 to function properly in some  
> other way?

More or less. Since legacy authors are less likely to make any  
change, and people with legacy Web apps in their company will not  
want to upgrade IE if it breaks their apps.

>>> If the website is then broken it is the websites maintainer  
>>> responsibility in that case. This is not something new standards  
>>> mode has been around for a while a responsible web developer  
>>> should have accounted for such.
>> Easy for you to say. I account for it in my pages, where possible,  
>> but from what I can see I am in the minority, and well over half  
>> the Internet would be rendered badly if you just suddenly stopped  
>> expanding boxes that used to grow with their content, and had  
>> floats appearing in different places than before. Such an arrogant  
>> point of view, of "fix the pages or be left behind", is why so  
>> many have refused to upgrade from IE6 to IE7, and why MS wants a  
>> better fix this time. The CEOs find it easier to not upgrade, if  
>> upgrading means that all their Intranet apps go to sh!t.
>
> If they choose not to upgrade that is their decision. If the Author  
> has written a doctype and are using CSS for layout they "should"  
> know every new browser could essentially break their layout.

As an author I know that. But it is not a matter of wether or not the  
author upgrade's his browser. The decision to upgrade browsers or not  
will come from company executives who will decide if it is worth  
their trouble or not. If it means upgrading all of their existing Web  
apps for their intranet, and if it means waiting for their vendors to  
upgrade their apps and services, and only switching to the upgraded  
browsers once they are sure that all their apps are compatible...  
well, it might be a long wait.

But if MS were to include some way for the author to indicate with a  
single line that the app will work fine under standards, and if  
everything else continued to be compatible without changes, then MS  
could get much higher adoption rates than they did with IE7 (the  
online banking site I author has less than half of its IE customers  
using IE7, and most of their home banking is done at work). The  
sooner that happens, the sooner we can stop needing to use so many  
CSS hacks for IE6 and IE7.

> This is no difference from the way it has been for the last few  
> years. If this wasn't the case you would see a lot more websites  
> using css positioning instead of tables for layouts.

Its a little different when the browser in question still has such  
huge market share that if it breaks many Web sites it is, in essence,  
breaking the Web.  It is also different in that it is the browser  
people use when they don't even know what a browser is, or that Web  
software is something that can be downloaded. It is different when  
many, many large companies refuse (and even block) the downloads  
because they don't want to spend large amounts of time and money  
dealing with the problems it would cause.

These are all problems that mostly do not effect FireFox, Safari, or  
Opera, and did not make much difference in the move from IE5.5 to IE6.

You should watch the Channel 9 interview with Dean Hachamovitch,  
Chris Wilson, Alex Mogilevsky, and Markus Mielke [1].

>>> This is the same problem facing HTML5 as well supporting unclosed  
>>> tag elements for legacy reasons.
>>>
>>> I think the onus here is on the website creators. It should not  
>>> be on the browser vendors to fix the workings of peoples non- 
>>> standard HTML practises.
>> Microsoft made the bed in which they now lie. They are motivated  
>> to get better results than what would result from what you  
>> suggest. This list is to help bring together the needs of authors  
>> and implementors, is it not?
>
> I agree of the purpose of this list. However, how is leaving quirks  
> mode as is a problem here? The expected results are the same as  
> they were before.

The primary point is not about how leaving quirks mode alone would be  
a problem. It is the problem caused by having 2 or 3 different  
"standards" modes represented by IE6 through IE7. If there was some  
additional way to specify "full standards" instead of "IE6 standards"  
or "IE7 standards", then it would be also useful to have that switch  
available to Quirks mode, so that IE8 quirks were more similar to  
quirks modes in other browsers, which are fairly well defined, I  
believe.

>>> I think the solution here should be pretty simple. If there is a  
>>> doctype the website author is responsible> If there is no doctype  
>>> then let the current quirks mode render it accordingly.
>> That Web site author is also responsible for making their 4.01  
>> doctypes render reasonably in IE6 and IE7, with all of the unfixed  
>> bugs of those browsers. And there are undoubtedly many authors who  
>> blithely add the 4.01 doctype via some software that hides it from  
>> them, but only test in IE. You may not like it (I don't), but it  
>> is the real world we live in, not some idealized utopia.
>
> And if a tool you use writes bad code that is your fault.

What is the use of assigning fault? Does that help keep the Web from  
breaking? When it is a widespread problem that will occur by moving  
forward, it should be addressed when moving forward, in order to  
minimize its negative impact. Saying that its somebody's fault, or  
that it their tough luck for not listening to your advice just  
doesn't cut it.

> It seems to me your looking for some kind of "panacea" for  
> rendering. This isn't going to happen. For progress sometimes  
> things need to break. The best way to deal with this is to attempt  
> to minimize the amount that breaks.

I am looking for a way to minimize the amount that breaks, more so  
that you, it would seem. I have suggested a method to do so that you  
don't wish to even consider, because you would rather see larger  
portions break than I would. This seems to be satisfactory to you  
because it allows you to criticize and point blaming fingers at  
authors whose apps would break.

> Think of a city that has a river in it. You have two bridge people  
> use to get across this river. You need to upgrade these bridges and  
> repair them. You have a few choices but the four basic ideas would be:
>

<snipped esoteric bridge analogy>

I don't want to start arguing in metaphor. We are talking browsers,  
not bridges.

> I am suggesting the route of B. There are more pages running in  
> quirks mode either with an invalid doctype or none at all. This  
> seems to make the most sense from a usage point of view.

There are still a significant number running in with a valid 40.1  
doctype that have to deal with two different standards modes in IE  
already, plus a new one in IE8. It would be nice to be able to tell  
the browser which one of the three you are shooting for, and to be  
able to do so within the CSS file.

>
>>> No need to give added functionality to quirks mode leave it  
>>> alone. Those people currently developing for quirks mode will  
>>> have the functionality they currently know and understand.
>> There are still many valid reasons why people continue to work in  
>> quirks mode that have nothing to do with all the extra bugs that  
>> IE adds to the mix. It there was a way to address those extra bugs  
>> without forcing people to use 4.01 or higher doctypes, and without  
>> breaking old or unchanged sites, it certainly would be a boon to  
>> Web design.
>
> Could you give me one of those valid reasons?

Well, its getting a bit off-topic, and I don't really want to get  
into a separate conversation about these, but here are a few:

-- You want a more useful meaning to height:100%
-- You want to use an IFRAME that doesn't have the width continue  
underneath the scroll bar in IE6.
-- The numerous other bugs in IE6 and IE7 make it significantly more  
difficult to get a complex design to work in standards mode than in  
quirks mode (much more so than in other browsers)
-- You to easily match the design of the hundreds or thousands of  
legacy pages that you have, without a lot of extra effort or a second  
CSS file to maintain.
-- You might have your own reasons and don't feel the need to justify  
them to Barry Rader.

> I honestly only have seen three reasons to write for quirks mode.  
> Your lazy. Your trying to get around a rendering bug. Your using  
> some AJAX library that depends on quirks mode.
>
> The first reason can't be dealt with you can lead the horse to  
> water but you cannot make them drink. However, we can at least show  
> them how to get to the water.

Again with the metaphors. Maybe the horse doesn't need a drink. Maybe  
its not thirsty. Maybe your water is tainted. Anyway, the whole world  
is lazy; get used to it. People will almost always take the path of  
least resistance.

> The second would be fixed with proper rendering.

Not as long as there are a significant number of older browsers out  
there that remain unfixed.

> The third. well this is a tough one but I am pretty sure someone  
> would be able to come up with a library that fits in with proper  
> rendering once all major browser vendors render similarly.
>
>
>>> Those working in standards mode should be professional about it  
>>> and take responsibility for their work.
>> You should just eliminate the word "should" from your vocabulary  
>> and start dealing with the way things actually take place. Saying  
>> people "should' do something will not cause it to happen. People's  
>> actual likely behavior should be taking into account during the  
>> decision making process, as I am sure MS will.
>
> You are absolutely correct. Most people will bitch about it. And  
> when someone point out to them that by doing fixing their work it  
> will work better in all browsers then they might be able to swallow  
> that pill a little easier. No?

No.

>>> Those working in quirks mode wanting the added functionality of  
>>> CSS advancements, will need to learn proper HTML/XHTML and to  
>>> develop within standards.
>> How about those working in proper HTML 3.2 standards, who don't  
>> want to always code around bugs? From your point of view, it seems  
>> like you would also support the idea of all browsers no longer  
>> supporting any deprecated HTML elements. Maybe we should try that  
>> and see how many people upgrade their browsers to that, huh?
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
>
> and for those who want 2.0
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">

Those trigger quirks mode.

> Who is talking about taking functionality away here? The way I am  
> proposing is not taking any functionality away from anyone. It is  
> just adding functionality to those who do things properly.

By "properly" you mean according to the latest standard. Well, by  
your same philosophy of "screw anyone who is not using a 4.01 or  
higher doctype, and even many who are", people "shouldn't" be using  
any deprecated HTML elements because the latest standard says they  
should be avoided.


>>> Barry Rader
>>>
>>> Alan Gresley wrote:
>>>> Barry Rader wrote:
>>>>
>>>>> Brad,
>>>>>
>>>>> This is a Problem I deal with every day.
>>>>>
>>>>> However I do have a very simple solution that I use. The  
>>>>> following is pretty standard for all websites I work on.
>>>>>
>>>>>
>>>>> <style type="text/css" id="MasterStyle" media="all" >
>>>>> <!--
>>>>>     @import url("/include/presentation/css/style.css");
>>>>> -->
>>>>> </style>
>>>>>
>>>>> <!--[if IE 7]>
>>>>> <style type="text/css" id="IE7Style" media="screen" >
>>>>>     @import url("/include/presentation/css/ie7.css");
>>>>> </style>
>>>>> <![endif]-->
>>>>>
>>>>> <!--[if lt IE 7]>
>>>>>     <link rel="stylesheet" type="text/css" href="/include/ 
>>>>> presentation/css/ie.css" media="screen" />
>>>>> <![endif]-->
>>>> Well the above gives a clue for one way IE8 can to display  
>>>> legacy "standards mode" or "quirks mode." If it can sniffs out  
>>>> conditional comments a document should display in legacy mode  
>>>> (IE7 engine). Maybe sniffing out * html and *+html or similar in  
>>>> the CSS could also result in the document displaying in legacy  
>>>> mode.
>>>>> Not to say this is the greatest way of dealing with things but  
>>>>> it does do the trick.
>>>>>
>>>>> When IE8 is released every website I have done in the past 2  
>>>>> years should not have a problem. Unless there is some IE8  
>>>>> specific bugs that I need to worry about. Then I would be  
>>>>> adding the next conditional comment in my header.
>>>>>
>>>>> <!--[if IE 8]>
>>>>> <style type="text/css" id="IE8Style" media="screen" >
>>>>>     @import url("/include/presentation/css/ie8.css");
>>>>> </style>
>>>>> <![endif]-->
>>>>>
>>>>> Maybe someone else has a better way of doing this but to me it  
>>>>> is simple enough to setup and work with.
>>>>>
>>>>> Barry Rader
>>>> This is where I differ. Since IE8 (new layout engine "standards  
>>>> mode") is going to be much more of a standard complaint UA, then  
>>>> conditional comments in the html must go. I see no place in a  
>>>> html document including a doctype where such a trigger could  
>>>> appear. Presumably since a standard complaint IE8 is inferring  
>>>> to standard compliant CSS, then the rightful place for such a  
>>>> trigger is inside a CSS comment. This is something for the IE  
>>>> team to consider since what appears inside a comment doesn't  
>>>> really concern the CSS WG since what appears outside these  
>>>> comment should be of more importance.
>>>> Alan
>>>> http://css-class.com/
>>>
>
> Barry Rader
>

[1] http://mschnlnine.vo.llnwd.net/d1/ch9/0/IE8ACID2Final.wmv

Received on Monday, 24 December 2007 18:48:30 UTC