W3C home > Mailing lists > Public > www-amaya@w3.org > October to December 2006

Re: Bug report: Source display of non-breaking space

From: Robin Whittle <rw@firstpr.com.au>
Date: Thu, 26 Oct 2006 10:33:30 +1000
Message-ID: <4540025A.5040401@firstpr.com.au>
To: Amaya Discussion List <www-amaya@w3.org>
Cc: Irene.Vatton@inrialpes.fr

Irene Vatton wrote:

> On Friday 20 October 2006 09:07, Robin Whittle wrote:
> 
> > On Debian with the distributed binary of the latest version 9.52, 
> > I find that the view source frequently displays non-breaking
> > spaces as "&nbsp" rather than the light blue tilde '~' it normally
> > uses.
> 
> It displays &nbsp; when the encoding is set to ASCII.

OK - I understand this now, it is not a bug.  Here is my exploration
with the 9.52 CVS version I compiled yesterday on Debian.  I have
Preferences > General > Keep multiple spaces turned on.

I create a new XHTML Transitional document, with the default charset
(a drop-down list in the new file dialogue) encoding "iso-8859-1".
I write "xxxx    yyyy" into it, save it as New.html and open it again.

The file begins:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

In source view, non-breaking spaces are displayed as light blue tildes.

In the file itself, non-breaking spaces are stored as single bytes of
hex A0.

I hadn't realised that non-breaking spaces could be stored as this
single byte.  I had always seen the 6 byte "&nbsp;" form, but looking
at page 96 of the HTML 4.01 specification I see this is so.

Repeating the exercise, I select "us-ascii" for the charset.

The non-breaking spaces are displayed as "&nbsp;" and saved in the
file in this 6 byte form.

 - Robin
Received on Thursday, 26 October 2006 00:33:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:30:52 UTC