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

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? or have 
web authors forced to tell IE8 to function properly in some other way?

>> 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. 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.

>> 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.

>> 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. 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.

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:

A: Repair both bridges and while doing so upgrade.
	This will cause congestion and will take a very long time to complete 
it will also cost a lot of money and man hours to complete.

B: Repair and upgrade the less used bridge, then go back and fix the 
larger and more used bridge.
	This will still cause trouble and congestion but not as much as would 
be to go the the other way around.

C: Repair and Upgrade the more used bridge, then go back and fix the 
smaller less used bridge.
	This would be the most difficult and problematic. Although it would 
have the greatest effect once completed.

D: Create a new bridge a reasonable distance away, and once completed go 
back and attempt to repair the old bridges.
	This would cost less overall and once completed would give another 
avenue for the people to get across the river.

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.

>> 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? 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.

The second would be fixed with proper rendering.

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?

>> 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">

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.

>>
>> 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

Received on Monday, 24 December 2007 15:28:33 UTC