DAVOUD TOHIDY wrote:
> on Date: Sun, 27 Jan 2008 20:22:38  Philippe Wittenbergh wrote:
>  
>   
>> 'The standards' (and the doctypes) were not written with differences
>> in 'rendering' in mind.
>>     
>  
> is this what you know or you believe? is there anything documented
> about this statement?
>   
    In regards to the DOCTYPE, no rendering behavior is defined. As 
Philippe mentions (in the segment you omitted) the DOCTYPE links to a 
DTD (Document Type Definition) which simply defines the elements to use, 
their attributes and hierarchy. If you're curious check these two DTDs 
(HTML 4.01):
  http://www.w3.org/TR/html401/strict.dtd
  http://www.w3.org/TR/html401/loose.dtd

> and how a standard can be written without conducting any research
> on how browsers render an x(html) file?
>   
    I don't know the history for sure (that would be your homework), but 
as far as I know and at least on recent standards definitions, the 
'authority' (W3C) making them works in conjunction with the (biggest) 
browser vendors as well as experts in various fields (how it turns out, 
however, it's a different story).

> The following is from Eric's article at:
>  
> http://www.oreillynet.com/pub/a/network/2000/04/14/doctype/index.html?page=2
>  
> ///// Besides the simple difference that strict documents will be treated 
> differently,
> strict documents will have two big differences from quirky ones.
>  
> First is that all elements will inherit styles, including table elements,
> which have a hard time inheriting text colors and styles in quirky mode.
>  
> Second is that font-size: medium text will be the same size as unstyled text.
> In quirky mode, unstyled text is the same size as small. //////
>  
> So what i get from what erics states (which is actually the second and third
> significant examples BTW :) ) in the above statement, is that dtds prescribe
> a particular behaviour.
>  
> The above is an example of what a dtd sets as a rule and how a browser acts
> based on the set of rules defined by dtds. This has nothing to do with if a 
> browser
> wants to provide web-compatibility or not.
>   
    Haven't read the article, but only what you mention here... he's 
talking about Standard-mode vs Quirks-mode. I think that, by making 
reference to a "Standard mode" and something else, i.e. "Quirks mode", 
we can assume the latter as "not in standard mode".

    So, what was this about? Well, just that: Quirks-mode document don't 
adhere to the W3C standards, from their sole definition (i.e. they have 
even more of a browser-specific and/or undefined behavior). Now, whether 
a Standard-mode document is rendered as the Standard says or not, that's 
a different story.

    You should shook off the idea of different DTDs being the same as 
Standard and Quirks modes and make a clear distinction between them. If 
you haven't by now, then investigate a little further. The people here 
can help you understand it, but you should help them by reading about it 
yourself.

> If a browser wants to provide web-compatibility or does not want, it will not
> change the set of rules defined by say a strict dtd. A browser does not have
> a choice to decide what to do within a certain dtd once it is in and must obey
> what dtd rules out.
>   
    The point here, I believe, is to notice that the Standards don't 
define *every* situation's behavior, and that's where the browser vendor 
have to be a little creative about it. So even in Standard mode you may 
find different behaviors in browsers, and you can't actually comply 
about it (to them, at least).

    Now, the more old the browser the more "legacy behavior" it has, and 
this is a behavior should be preserved for backward compatibility. 
Stupid as it is, there are a lot of corporations (and big ones) that had 
set IE 6 (put attention to "6", please) as the /only allowed/ browser, 
and some of their people are so used to doing things simply so wrong, 
that their entire Intranet could break down if MS ever stops supporting 
that legacy behavior (assuming they'll ever update from IE 6, that is) 
---Anyway, this was a little off-topic.

> However it can decide which mode (standard or quirks) to use only if you do 
> not
> specify the URI or do not specify doctype at all, or you declare xml encoding 
> before
> doctype which is the doctype switching for backward compatibility reasons.
>   
    If you define a *valid* DOCTYPE, the browser should be in Standard 
mode, if it isn't, then you've found a bug, congratulations! (such as 
the XML declaration ---/required/ in XML documents--- dropping IE back 
to Quirks mode despite a DOCTYPE). It's when you don't define a DOCTYPE 
or is invalid (i.e. wrong) that the browser is set to Quirks mode, and 
in this case... well... good luck with your work.

>> Browsers, on the other hand, have, for web-compatibility reasons,
>> assigned a particular behaviour for some elements -for a very limited
>> number of elements-. The case of the alignment of images in table-
>> cells is the most (and only ?) significant example.
>>     
>  
> Are you suggesting that it is the browser which defines the standards?
>   
    They, as far as I know, participate in creating the Standards. Now, 
what good is for a Standard to exist if browser vendors refuse to adhere 
to them? At the end, the power is in the browser vendors, we can only 
pressure them by changing to a browser that does follow the Standards.

> Are you suggesting that it is the browser which decides to assign the
> gap for the image not the strict dtd?
>  
> if yes I believe that is a wrong statement. If not, then that is what I  mean.
>   
    Yes, it is... Why? Because it's a behavior they came up before the 
creation of the CSS Standard, when the presentation was defined by the 
structure alone. They cannot simply take it away now, and that is called 
/backward compatibility/.

    Rafael.
______________________________________________________________________
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Reply via email to