[TYPO3] Image Wrap

[Loek Hilgersom]

Hi Christopher & Mads,

Some strange things going on... Mads, did you change anything on that site? I 
renders correctly now but I can't see what has changed.

The weird thing was that this afternoon capitals in the CSS _did_ make the 
difference. First thing I noticed was that Firefox Webdeveloper didn't show any 
style information for one of the text-pic div's, although the stylesheet was 
clearly loaded... when I saw the doctype I remembered something about 
case-sensitivity which had never been an issue, but there it was. I can't 
reproduce it now.

Maybe we just experienced a very rare simultaneous interstellar Firefox hickup? ;-)

Anyway, more important stuff to do now (but still curious....)

Cheers,
Loek


Christopher Torgalson wrote:
> Hi,
> 
> On 8/14/07, Loek Hilgersom <hilgersom at xs4all.nl> wrote:
>> Hi Mads,
>>
>> The 'problem' is XHTML strict:
>>
>> 4.2. Element and attribute names must be in lower case
>> XHTML documents must use lower case for all HTML element and attribute
>> names.
>> This difference is necessary because XML is case-sensitive e.g. <li> and
>> <LI>
>> are different tags. [1]
>>
>> ....and Typo3 which isn't exactly XHTML strict yet.
>> css_styled_content uses capitals for all tags in the stylesheet -
>> unfortunately
>> - and lowercase characters for in the (X)HTML output. Not really
>> consequent.
>>
>> You can either change that stylesheet and include your own modified
>> version, or
>> change your doctype. Getting it all to work perfectly in XHTML strict
>> requires a
>> bit more handwork, unfortunately.
>>
> 
> 
> Loek, I was skeptical that that was the source of Mads' problem--the w3c
> validator doesn't even throw a warning for uppercase tag names in selectors
> [1]. A quick test in Firefox seemed to confirm that you were right, but then
> I found two things:
> 
> 1. Safari--arguably the most standards-compliant browser anywhere at this
> time--has no such rendering problem
> 2. I have an xhtml 1.0 strict site that uses "Text with image" content
> elements extensively (sorry, they're non-public), with no similar problems
> 
> Without deconstructing the entire CSS for the site, I'd have to guess that
> Mads' problem is related somehow to the other CSS in the stylesheet (though
> aside from one small error, the entire stylesheet is valid)...
> 
>