Closed Bug 266465 Opened 20 years ago Closed 18 years ago

ISO-8859-1 stylesheet loaded by local UTF-16 HTML page doesn't work

Categories

(Core :: CSS Parsing and Computation, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED INVALID

People

(Reporter: brownb2, Unassigned)

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1

I've been designing stylesheets held in a an external file on my Win XP desktop.
The html that references the css works with IE6 and the components are styled,
they are not under FF unless inlined.

Reproducible: Always
Steps to Reproduce:
1. Create a html file on Win XP desktop and a directory "css"
2. Put a css stylesheet in the css directory, the css should contain:
.tab-selected{	background-color:Black; }
3. Create a html file and put this on the desktop, in the head put the text:
<link rel="stylesheet" type="text/css" href="./css/default.css" />
Include in the body (within a form):
<input type="submit" value="Page 1" name="fred" class="tab-selected" />
4. Open html page in firefox

Actual Results:  
Page1 button input is a standard button input

Expected Results:  
Page1 button input should have been completely colored black
Works for me, doing exactly what you said with the same version on the same OS.
I think the bug may be to do with the file encoding. I saved the text into
another notepad file and saved it - hey presto it works. I've attached the files
with the dodgy encoding.
Attachment #163808 - Attachment description: I've attached the file I found the bug in in binary. If you need a diff content type please say. → I've attached the file I found the bug in as a binary (its html) to keep the encoding. If you need a diff content type please say.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050901
Firefox/1.0+ ID:2005090106

I can verify that this behavior exists in the latest head.  The issue seems tied
to the encoding the CSS is given in.  For example, if I convert to ANSI it does
not work; however, it works when I convert to unicode.

I'm confirming this bug, with the caveat that an engineer might look at this as
a non-bug.
Assignee: firefox → nobody
Status: UNCONFIRMED → NEW
Component: General → File Handling
Ever confirmed: true
QA Contact: general → file.handling
I've observed the same behaviour.  I wrote valid xhtml and xml that is displayed correctly in IE6 but not so in Firefox (v 1.5.0.1).  The xml is converted to xhtml via XSL or displayed directly.  Here is an example xsl file that I created.

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" 
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	
	<xsl:output method="xml" encoding="ISO-8859-1" indent="yes" doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"/>
	
	<xsl:template match="/">
	
	<html xmlns="http://www.w3.org/1999/xhtml" lang="ISO-8859-1">
		
		<head>
			<title><xsl:value-of select="poema/titulo"/></title>
			<link rel="stylesheet" type="text/css" href="F:Data/My Web Sites/AccessIble/StyleSheets/poema.css"/>
		</head>
		
		<body>
		<xsl:for-each select="poema">
			<h1>			
				<xsl:value-of select="titulo"/>
			</h1>
			<p class="autor"><xsl:value-of select="autor"/></p>
			<p class="cr">Copyright <xsl:value-of select="copyright"/></p>
			</xsl:for-each>
			<hr/>
			<xsl:for-each select="poema/estrofa" xml:space="preserve">
			<p/>
				<xsl:for-each select="verso">
					<p class="verso">
						<xsl:apply-templates/>
					</p>
				</xsl:for-each>
			</xsl:for-each>
		</body>	
	</html>
	</xsl:template>
</xsl:stylesheet>

------------------------------------------------------------------------

Here is the XML file

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="F:\Data\My Web Sites\AccessIble\StyleSheets\poema.xsl"?>
<poema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="F:\Data\My Web Sites\AccessIble\Schemas\poema.xsd">
	<autor>Jesse Avilés</autor>
	<titulo>Gracias</titulo>
	<copyright>1996</copyright>
	<estrofa>
		<verso>El estar junto a tí me produce una inmensa y descansa mi cuerpo, tu alma se junta a la mía para tener un solo pensar y sentir.</verso>
	</estrofa>
	<estrofa>
		<verso>Quiero jugar y eres la mujer que vuelve a su niñez para cumplir mis caprichos y antojos.  Jugamos y jugamos, per somos niños así que no nos cansamos.  Solos, gozamos de la realidad formada por el mundo de nuestros juegos.  Mas cuando me siento preocupado o muy alegre en tí confío esos momentos por que eres tú mi más intima amiga.  Compartes mis alegrías y me ayudas en mis problemas arrojando una luz que solo no encontraría.  Entonce, dejas tu mundo de niña soñadora, cruzas el umbral de la amistad para convertirte en mujer para amarme, para que te ame, para amarnos.  Aquí nadie puede distinguir el uno del otro, somos uno solo en perfecta armonía con el universo, dejando como único testigo al tiempo.</verso>
	</estrofa>
	<estrofa>
		<verso>Por eso y más, gracias por ser para mí, niña, amiga y mujer.</verso>
	</estrofa>
</poema>

----------------------------------------------------------------------

Here is the css file

html	{
	font-family: Tahoma, sans-serif;
	font-size: 12pt;
	display: block;
	white-space: pre;
	text-align: center;
	background-color: #FFFFFF;	
	}
h1	{
	font-weight: bold;
	font-size: 14.4pt;
	font-variant: small-caps;
	margin-top: 8pt;
	margin-bottom: 8pt;
	}
p.autor	{
	font-weight: bold;
	}
p.cr	{
	font-style: italic;
	}
p	{
	margin-top: 8pt;
	margin-bottom: 8pt;
	}
p.verso	{
	line-height: 100%;
	margin-top:0;
	margin-bottom:0;
	}
Does this bug still occur in the latest trunk build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
I must not have looked again, post-attachments, or I wouldn't have left this hanging out here: the bug is that the HTML is UTF-16, and so the CSS parser never finds the first "{" in the ISO-8859-1 stylesheet ("Warning: Unexpected end of file while searching for ',' or '{'."), and yes, trunk still assumes it will be in the HTML's encoding.
Component: File Handling → Style System (CSS)
Product: Firefox → Core
QA Contact: file.handling → style-system
Summary: Relative local (./) css stylesheets do not get loaded/parsed → ISO-8859-1 stylesheet loaded by local UTF-16 HTML page doesn't work
Version: unspecified → Trunk
http://www.w3.org/TR/CSS21/syndata.html#q23
<quote>
When a style sheet resides in a separate file, user agents must observe the following priorities when determining a style sheet's character encoding (from highest priority to lowest):

   1. An HTTP "charset" parameter in a "Content-Type" field (or similar
      parameters in other protocols)
   2. BOM and/or @charset (see below)
   3. <link charset=""> or other metadata from the linking mechanism (if any)
   4. charset of referring style sheet or document (if any)
   5. Assume UTF-8
</quote>


The first attachment is a XHTML file that starts:
<?xml version="1.0" encoding="UTF-16"?>
and later:
<link rel="stylesheet" type="text/css" href="./css/default.css" />

The CSS file (2nd attachment) does not have a BOM or @charset.

So we should interpret the CSS as UTF-16 according to rule 4, no?
Yes. There are times, like treating foo.xhtml as if it was served as application/xhtml+xml, where local file exceptions make sense, but with both <link charset=""> and @charset available to make it work, and with the high probability that a local file exception would make local files work and HTTP-served files fail, this isn't one of them.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: