W3C home > Mailing lists > Public > www-style@w3.org > December 2007

Re: standard out of the box

From: Brad Kemper <brkemper@comcast.net>
Date: Fri, 21 Dec 2007 20:19:37 -0800
Message-Id: <AB1A2063-D640-4F8D-9C52-F18FF8B2F666@comcast.net>
Cc: "www-style@w3.org" <www-style@w3.org>
To: Barry Rader <brader@boldinternet.com>


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.

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

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

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

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

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

>
> 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/
>
Received on Saturday, 22 December 2007 04:19:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:57 GMT