Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Ed Mullen]

Ken F wrote:

On Thursday, August 29, 2013 12:50:07 AM UTC-5, Ken F wrote:

Composer inserts characters & symbols display OK when preparing html webpages. When 
viewed on the web, Firefox will display a  for many (all?) of 
the inserted symbols & characters.



Example links:



Test page -

http://spontoon.rootoon.com/SPwTest1.html

Looks OK in View/ Preview. In View/ html, the actual symbol seems to be 
inserted rather than an html code for the symbol.



(The following may be a separate problem?)

A page originally prepared in Mozilla Composer in 2001, with copyright symbols added in 
reloads every year. This last year it was not possible to directly insert a copyright 
symbol for 2013 - I had to cut-&-paste. Now, it appears in my Firefox browser that 
all the copyright symbols (and an accent-'e') have reverted to '' (Unknown 
character?).

http://spontoon.rootoon.com/SPwHome1.html



My apologies in advance if I am overlooking any obvious html-development 
knowledge.



Thank you for your patience,

Ken


Thanks for favors granted to the kami of Saint Seamonkey of Composer.

I finally discovered the low-tech-knowledge fix, which was suggested by Trane 
Francks twice on this support group. I had not really understood what he was 
suggesting. (For over 10 years, most of my uploads had been a basic pattern of 
using the Composer symbols toolbar, rather than the top text toolbar on the 
screen.)

I am a hobbyist website tinkerer. I don't really know all the capabilities of 
the Composer software.

Recently, I went back to the Composer page, intending to check all the tool 
links to see if I had missed anything.

Because you all shared the proper vocabulary for the changes I needed, I was able to recognize what the top-line 
"Files" drop-down buttons offered. Besides "Save", there was (of course) "Save & 
change character encoding"... with the drop-downs offered of many encoding systems... including Unicode 
(UTF-8). This may not be as elegant as using a form of global change software, I can go in and make the changes 
webpage by webpage, for the 100 or so webpages that have the encoding problem. I've been doing this.

Thank you all for your comments so I could recognize the basic fix built into 
the Composer software.

I do not know the reasons for why there was a change in the older webpage 
displays from 8 years ago or more (with changes starting about 2 years ago). 
Maybe I don't need to know, if I can do the fix.

Several of you mentioned that the 'problem' character encoding in my webpage headers was for 
"windows-1252". Is it a co-incidence that the drop-down list for "Save & change 
character encoding" lists the codes alphabetically, and that Windows-1252 is at the bottom of the 
list (and the at-rest location of the cursor)?

Thank you all, and thanks again to the kami of Seamonkey,
Ken Fletcher



Ken, you should be aware that development of the Web Composer part of 
SeaMonkey/Mozilla/Netscape stopped dead in it tracks MANY years ago. 
And it's an outdated model of Web development.  Anyone serious about 
page dev learns CSS and HTML and writes in a plain-text editor which 
actually requires knowlege about HTML and CSS standards.


The offshoots of Composer aren't much better nor much more well 
developed and I won't even mention them here.


WYSIWG (What You See Is What You Get) editors like Composer are fairly 
disdained in serious Web design circles.  They rarely produce good code 
and frequently produce horrible code that causes casual designers more 
grief than good.


Learn HTML and CSS by using online resources and good books.

Use the validator services to check your pages:

http://validator.w3.org/

http://jigsaw.w3.org/css-validator/


--
Ed Mullen
http://edmullen.net/
"The problem with internet quotes is you never know if they're actually 
authentic." - Abraham Lincoln

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Ken F]

On Thursday, August 29, 2013 12:50:07 AM UTC-5, Ken F wrote:
> Composer inserts characters & symbols display OK when preparing html 
> webpages. When viewed on the web, Firefox will display a  w/white ?> for many (all?) of the inserted symbols & characters.
> 
> 
> 
> Example links:
> 
> 
> 
> Test page -
> 
> http://spontoon.rootoon.com/SPwTest1.html
> 
> Looks OK in View/ Preview. In View/ html, the actual symbol seems to be 
> inserted rather than an html code for the symbol.
> 
> 
> 
> (The following may be a separate problem?)
> 
> A page originally prepared in Mozilla Composer in 2001, with copyright 
> symbols added in reloads every year. This last year it was not possible to 
> directly insert a copyright symbol for 2013 - I had to cut-&-paste. Now, it 
> appears in my Firefox browser that all the copyright symbols (and an 
> accent-'e') have reverted to '' (Unknown character?).  
> 
> http://spontoon.rootoon.com/SPwHome1.html
> 
> 
> 
> My apologies in advance if I am overlooking any obvious html-development 
> knowledge.
> 
> 
> 
> Thank you for your patience,
> 
> Ken

Thanks for favors granted to the kami of Saint Seamonkey of Composer.

I finally discovered the low-tech-knowledge fix, which was suggested by Trane 
Francks twice on this support group. I had not really understood what he was 
suggesting. (For over 10 years, most of my uploads had been a basic pattern of 
using the Composer symbols toolbar, rather than the top text toolbar on the 
screen.) 

I am a hobbyist website tinkerer. I don't really know all the capabilities of 
the Composer software.

Recently, I went back to the Composer page, intending to check all the tool 
links to see if I had missed anything. 

Because you all shared the proper vocabulary for the changes I needed, I was 
able to recognize what the top-line "Files" drop-down buttons offered. Besides 
"Save", there was (of course) "Save & change character encoding"... with the 
drop-downs offered of many encoding systems... including Unicode (UTF-8). This 
may not be as elegant as using a form of global change software, I can go in 
and make the changes webpage by webpage, for the 100 or so webpages that have 
the encoding problem. I've been doing this.

Thank you all for your comments so I could recognize the basic fix built into 
the Composer software.

I do not know the reasons for why there was a change in the older webpage 
displays from 8 years ago or more (with changes starting about 2 years ago). 
Maybe I don't need to know, if I can do the fix.

Several of you mentioned that the 'problem' character encoding in my webpage 
headers was for "windows-1252". Is it a co-incidence that the drop-down list 
for "Save & change character encoding" lists the codes alphabetically, and that 
Windows-1252 is at the bottom of the list (and the at-rest location of the 
cursor)?

Thank you all, and thanks again to the kami of Seamonkey,
Ken Fletcher
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Trane Francks]

On 8/31/13 12:58 PM +0900, MCBastos wrote:

Interviewed by CNN on 30/08/2013 02:34, Ken F told the world:



I will experiment with that. Doing the actual html codes could be a good basic quick 
fix for me to do for restoring  copyright symbols, and other isolated symbols on 
webpages. It may be more difficult for the much older story webpages from 10 years 
ago, where the left-quotes and right-quotes and apostrophes are also now displaying 
as .


There is software that will do the conversion for you. HTMLtidy, for
instance, is able to take all your Win-1252 and convert it into
US-ASCII, changing all those curly quotes into appropriate HTML entities
such as ‘, ’ and such.

Note: there three major "generations" of HTMLtidy around the web:

- The original one by Dave Raggett, which is very old (there are still
some sites offering that one)
- The "official" updated version at Sourceforge, which is improved but
has no support for HTML5 stuff:
http://tidy.sourceforge.net/
(This page also has a lot of documentation)

- And Tidy-HTML5, a new (unstable) fork which is adding support for
HTML5, but for which it's a bit hard to find standalone binaries -- the
most recent one I found was here: http://tidybatchfiles.info/

Since you are mostly dealing with oldish pages, with no HTML5, your best
bet is probably the Sourceforge page.

The good points about Tidy: it's a command-line tool, therefore it's not
that hard to find some way to run it on all your HTML files in a batch.
Also, it will find (and attempt to fix) a lot of HTML syntax errors.

The bad points about Tidy: it's a command-line tool, so there is some
effort involved on learning to use it. Also, you don't see what it does
as it is doing it -- Its syntax-fixing algorithm is prone to do stupid
things. I mostly use it as an error FINDER, not an error FIXER; I run it
(taking care to keep a backup of the original file), check the error
log, revert to the backup file and fix the errors by hand.

But if your code is reasonably clean and free of stupid errors like
forgetting to close  tags, the auto-fixing might work for you. You
should check the pages afterwards just in case, to see if Tidy didn't
make a mess of them, as it sometimes happens.



SeaMonkey will also very nicely change the encoding in Composer.

--
/
// Trane Franckstr...@gol.comTokyo, Japan
// Practice random kindness and senseless acts of beauty.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[MCBastos]

Interviewed by CNN on 30/08/2013 02:34, Ken F told the world:

> 
> I will experiment with that. Doing the actual html codes could be a good 
> basic quick fix for me to do for restoring  copyright symbols, and other 
> isolated symbols on webpages. It may be more difficult for the much older 
> story webpages from 10 years ago, where the left-quotes and right-quotes and 
> apostrophes are also now displaying as .

There is software that will do the conversion for you. HTMLtidy, for
instance, is able to take all your Win-1252 and convert it into
US-ASCII, changing all those curly quotes into appropriate HTML entities
such as ‘, ’ and such.

Note: there three major "generations" of HTMLtidy around the web:

- The original one by Dave Raggett, which is very old (there are still
some sites offering that one)
- The "official" updated version at Sourceforge, which is improved but
has no support for HTML5 stuff:
http://tidy.sourceforge.net/
(This page also has a lot of documentation)

- And Tidy-HTML5, a new (unstable) fork which is adding support for
HTML5, but for which it's a bit hard to find standalone binaries -- the
most recent one I found was here: http://tidybatchfiles.info/

Since you are mostly dealing with oldish pages, with no HTML5, your best
bet is probably the Sourceforge page.

The good points about Tidy: it's a command-line tool, therefore it's not
that hard to find some way to run it on all your HTML files in a batch.
Also, it will find (and attempt to fix) a lot of HTML syntax errors.

The bad points about Tidy: it's a command-line tool, so there is some
effort involved on learning to use it. Also, you don't see what it does
as it is doing it -- Its syntax-fixing algorithm is prone to do stupid
things. I mostly use it as an error FINDER, not an error FIXER; I run it
(taking care to keep a backup of the original file), check the error
log, revert to the backup file and fix the errors by hand.

But if your code is reasonably clean and free of stupid errors like
forgetting to close  tags, the auto-fixing might work for you. You
should check the pages afterwards just in case, to see if Tidy didn't
make a mess of them, as it sometimes happens.


-- 
MCBastos

This message has been protected with the 2ROT13 algorithm. Unauthorized
use will be prosecuted under the DMCA.

-=-=-
... Sent from my Buttocks.
* Added by TagZilla 0.7a1 running on Seamonkey 2.20 *
Get it at http://xsidebar.mozdev.org/modifiedmailnews.html#tagzilla
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Ken F]

Thank you all for the continuing discussion.

Have you shared enough that it is a good time for me to take this to the 
webhost/webserver for additional support?

Ken F 
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[»Q«]

In ,
Rob  wrote:

> Philip Taylor  wrote:
> 
> > Ralph Fox (<-rf-nz-@xn--kba.invalid>) wrote:
> >
> >> Nothing has changed.  The HTTP Content-Type header has aways taken
> >> precedence over the HTML meta declaration, and not only in SM.  
> >
> > This is the defined behaviour :
> > http://www.w3.org/International/questions/qa-html-encoding-declarations) :
> >
> >> The HTTP header information has the highest priority when it
> >> conflicts with in-document declarations. 
> 
> However, it appears to be not working for that page.
> What could be the reason for that?

It is working -- the HTTP header which has precedence is specifying
UTF-8.  To make the server stop doing this, you need to modify
the .htaccess file(s) for the site.  Assuming all your HTML files use
the .html extension and that they are all windows-1252, this line should
work to change the HTTP header the server is sending:

 AddCharset windows-1252 html

If you're not sure how to edit the .htaccess file(s), contact your
web host for support.

Another way to go would be to convert all the HTML files to UTF-8 and
leave the server settings alone.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Ralph Fox]

On Thu, 29 Aug 2013 11:31:59 -0500, Rob wrote:

> Philip Taylor  wrote:
> >
> >
> > Ralph Fox (<-rf-nz-@xn--kba.invalid>) wrote:
> >
> >> Nothing has changed.  The HTTP Content-Type header has aways taken 
> >> precedence 
> >> over the HTML meta declaration, and not only in SM.  
> >
> > This is the defined behaviour :
> > http://www.w3.org/International/questions/qa-html-encoding-declarations) :
> >
> >> The HTTP header information has the highest priority when it conflicts 
> >> with in-document declarations. 
> >
> > Philip Taylor
> 
> However, it appears to be not working for that page.
> What could be the reason for that?


Although the server is setting the HTTP Content-Type header to say UTF-8, 
which trumps the meta declaration, the server is not transcoding the 
HTML data into UTF-8.


-- 
Kind regards
Ralph
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Trane Francks]

On 8/30/13 11:34 AM +0900, Geoff Welsh wrote:

Geoff Welsh wrote:

Philip Taylor wrote:



Rob () wrote:


Content-Type: text/html; charset=UTF-8







Nothing has changed. The HTTP Content-Type header has aways taken
precedence
over the HTML meta declaration, and not only in SM.


Then why is the page shown in UTF-8 while it should be windows-1252?


It should /not/ be Windows-1252. The W3C state that the http
content-type trumps the meta content-type [1], so the document should
be rendered in UTF-8.

Philip Taylor

[1]
http://www.w3.org/International/questions/qa-html-encoding-declarations)
:


The HTTP header information has the highest priority when it conflicts

with in-document declarations.


if I'm understanding this all correctly, the HTTP Header comes from the
server. And it overrides whatever the typical home (ISP based) author
puts in the page.

I've never run into this stuff before.
GW


I think I might try using " © " in the HTML source, rather than the
symbol

GW

Or just change the encoding on the site's pages and upload them to the 
server. Since the server wants UTF-8, give it UTF-8. Problem solved.


--
/
// Trane Franckstr...@gol.comTokyo, Japan
// Practice random kindness and senseless acts of beauty.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Rob]

Philip Taylor  wrote:
>
>
> Rob wrote:
>> Philip Taylor  wrote:
>>>
>>>
>>> Rob () wrote:
>>>
>> Content-Type: text/html; charset=UTF-8
>>>
>>   
>>>
> Nothing has changed.  The HTTP Content-Type header has aways taken 
> precedence 
> over the HTML meta declaration, and not only in SM.  

 Then why is the page shown in UTF-8 while it should be windows-1252?
>>>
>>> It should /not/ be Windows-1252.  The W3C state that the http
>>> content-type trumps the meta content-type [1], so the document should
>>> be rendered in UTF-8.
>> 
>> That is wrong, isn't it?
>> This meta http-equiv has the specific purpose of setting the content
>> type in cases where the http headers from the server are wrong and
>> cannot be easily corrected.
>
> Logically, I would say you are correct.  But the W3C is the sole arbiter
> of what is right and what is wrong w.r.t. the web, so if the W3C state
> that the http content-type trumps the meta content-type, that behaviour
> is correct.  However, this has nothing to do with Seamonkey per se, so
> it might be better to pursue it on an official W3C list such as
>
>   http://lists.w3.org/Archives/Public/www-html/
>
> where you have real experts such as Juuka Korpela who will be able to
> advise.
>
> Philip Taylor

I think it is a ridiculous standard, and I was surprised because we
have large sites that are still in iso-8859-1 and work correctly.

So I investigated a bit, and found that the real problem is that the
webserver that Ken uses now sends the character set in the Content-Type
header.  Probably it did not do that before, and everything worked Ok.

It has long been customary for webservers to send:
Content-Type: text/html
for .html files, and when the document itself has a meta http-equiv
with Content-Type and the desired character set, everything works
fine even with the broken standard.

But now, the server sends:
Content-Type: text/html; charset=UTF8
and suddenly the html document cannot set the correct charset anymore!

When the server has no way of determining the charset of the .html
document, it should not act like this.  But probably this was a change
with different motives than compatability.

It looks like Ken is forced to change al his documents to UTF8 because
of this change by his hoster, unless he can do something like creating
a .htaccess file in the root of his webpage with:

AddType text/html html

or:

AddType 'text/html; charset=windows-1252' html

When that is allowed by the hoster, it would fix it for now.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Philip Taylor]

Rob wrote:
> Philip Taylor  wrote:
>>
>>
>> Rob () wrote:
>>
> Content-Type: text/html; charset=UTF-8
>>
>   
>>
 Nothing has changed.  The HTTP Content-Type header has aways taken 
 precedence 
 over the HTML meta declaration, and not only in SM.  
>>>
>>> Then why is the page shown in UTF-8 while it should be windows-1252?
>>
>> It should /not/ be Windows-1252.  The W3C state that the http
>> content-type trumps the meta content-type [1], so the document should
>> be rendered in UTF-8.
> 
> That is wrong, isn't it?
> This meta http-equiv has the specific purpose of setting the content
> type in cases where the http headers from the server are wrong and
> cannot be easily corrected.

Logically, I would say you are correct.  But the W3C is the sole arbiter
of what is right and what is wrong w.r.t. the web, so if the W3C state
that the http content-type trumps the meta content-type, that behaviour
is correct.  However, this has nothing to do with Seamonkey per se, so
it might be better to pursue it on an official W3C list such as

http://lists.w3.org/Archives/Public/www-html/

where you have real experts such as Juuka Korpela who will be able to
advise.

Philip Taylor
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Rob]

Philip Taylor  wrote:
>
>
> Rob () wrote:
>
 Content-Type: text/html; charset=UTF-8
>
   
>
>>> Nothing has changed.  The HTTP Content-Type header has aways taken 
>>> precedence 
>>> over the HTML meta declaration, and not only in SM.  
>> 
>> Then why is the page shown in UTF-8 while it should be windows-1252?
>
> It should /not/ be Windows-1252.  The W3C state that the http
> content-type trumps the meta content-type [1], so the document should
> be rendered in UTF-8.

That is wrong, isn't it?
This meta http-equiv has the specific purpose of setting the content
type in cases where the http headers from the server are wrong and
cannot be easily corrected.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Ken F]

On Thursday, August 29, 2013 9:34:26 PM UTC-5, Geoff Welsh wrote:
> Geoff Welsh wrote:
> 
> > Philip Taylor wrote:
> 
> >>
> 
> >>
> 
> >> Rob (<.com>) wrote:
> 
> >>
> 
> > Content-Type: text/html; charset=UTF-8
> 
> >>
> 
> > 
> 
> >>
> 
>  Nothing has changed. The HTTP Content-Type header has aways taken
> 
>  precedence
> 
>  over the HTML meta declaration, and not only in SM.
> 
> >>>
> 
> >>> Then why is the page shown in UTF-8 while it should be windows-1252?
> 
> >>
> 
> >> It should /not/ be Windows-1252. The W3C state that the http
> 
> >> content-type trumps the meta content-type [1], so the document should
> 
> >> be rendered in UTF-8.
> 
> >>
> 
> >> Philip Taylor
> 
> >> 
> 
> >> [1]
> 
> >> http://www.w3.org/International/questions/qa-html-encoding-declarations)
> 
> >> :
> 
> >>
> 
> >>> The HTTP header information has the highest priority when it conflicts
> 
> >> with in-document declarations.
> 
> >
> 
> > if I'm understanding this all correctly, the HTTP Header comes from the
> 
> > server. And it overrides whatever the typical home (ISP based) author
> 
> > puts in the page.
> 
> >
> 
> > I've never run into this stuff before.
> 
> > GW
> 
> 
> 
> I think I might try using " © " in the HTML source, rather than the 
> 
> symbol
> 
> 
> 
> GW

Geoff Welsh --

Thanks.

I will experiment with that. Doing the actual html codes could be a good basic 
quick fix for me to do for restoring  copyright symbols, and other isolated 
symbols on webpages. It may be more difficult for the much older story webpages 
from 10 years ago, where the left-quotes and right-quotes and apostrophes are 
also now displaying as .

Ken F
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Ken F]

On Thursday, August 29, 2013 2:37:27 AM UTC-5, Rob wrote:
 ((snipped))
> 
> 
> 
> The page appears to have a long history :-)

I suppose I could claim that the not-so-hidden layers of broken html code were 
left underneath the surface on purpose, so future web archeologists could 
accurately compute the strata for any edits in the webpages 8p ... but it 
would be Wrong.

History: Serial story archives sometimes have long serial stories. 8)

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Ken F]

Thank you all for your comments. 

Even with my lack of html-fu I am getting some clues on what the issues likely 
are. 

Because of my work schedule, I may not be able to see comments or ask questions 
until Friday evening after 9pm Central Daylight Time.

Ken F

On Thursday, August 29, 2013 12:50:07 AM UTC-5, Ken F wrote:

> Thank you for your patience,
> 
> Ken

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Geoff Welsh]

Geoff Welsh wrote:

Philip Taylor wrote:



Rob () wrote:


Content-Type: text/html; charset=UTF-8







Nothing has changed. The HTTP Content-Type header has aways taken
precedence
over the HTML meta declaration, and not only in SM.


Then why is the page shown in UTF-8 while it should be windows-1252?


It should /not/ be Windows-1252. The W3C state that the http
content-type trumps the meta content-type [1], so the document should
be rendered in UTF-8.

Philip Taylor

[1]
http://www.w3.org/International/questions/qa-html-encoding-declarations)
:


The HTTP header information has the highest priority when it conflicts

with in-document declarations.


if I'm understanding this all correctly, the HTTP Header comes from the
server. And it overrides whatever the typical home (ISP based) author
puts in the page.

I've never run into this stuff before.
GW


I think I might try using " © " in the HTML source, rather than the 
symbol


GW
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Geoff Welsh]

Philip Taylor wrote:



Rob () wrote:


Content-Type: text/html; charset=UTF-8



   



Nothing has changed.  The HTTP Content-Type header has aways taken precedence
over the HTML meta declaration, and not only in SM.


Then why is the page shown in UTF-8 while it should be windows-1252?


It should /not/ be Windows-1252.  The W3C state that the http
content-type trumps the meta content-type [1], so the document should
be rendered in UTF-8.

Philip Taylor

[1]
http://www.w3.org/International/questions/qa-html-encoding-declarations) :


The HTTP header information has the highest priority when it conflicts

with in-document declarations.


if I'm understanding this all correctly, the HTTP Header comes from the 
server.  And it overrides whatever the typical home (ISP based) author 
puts in the page.


I've never run into this stuff before.
GW
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Philip Taylor]

Rob () wrote:

>>> Content-Type: text/html; charset=UTF-8

>>>   

>> Nothing has changed.  The HTTP Content-Type header has aways taken 
>> precedence 
>> over the HTML meta declaration, and not only in SM.  
> 
> Then why is the page shown in UTF-8 while it should be windows-1252?

It should /not/ be Windows-1252.  The W3C state that the http
content-type trumps the meta content-type [1], so the document should
be rendered in UTF-8.

Philip Taylor

[1]
http://www.w3.org/International/questions/qa-html-encoding-declarations) :

> The HTTP header information has the highest priority when it conflicts
with in-document declarations.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Rob]

Philip Taylor  wrote:
>
>
> Ralph Fox (<-rf-nz-@xn--kba.invalid>) wrote:
>
>> Nothing has changed.  The HTTP Content-Type header has aways taken 
>> precedence 
>> over the HTML meta declaration, and not only in SM.  
>
> This is the defined behaviour :
> http://www.w3.org/International/questions/qa-html-encoding-declarations) :
>
>> The HTTP header information has the highest priority when it conflicts with 
>> in-document declarations. 
>
> Philip Taylor

However, it appears to be not working for that page.
What could be the reason for that?
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Rob]

Ralph Fox <-rf-nz-@xn--kba.invalid> wrote:
> On Thu, 29 Aug 2013 02:37:27 -0500, Rob wrote:
>
>> The HTTP headers say UTF-8:
>> 
>> HTTP/1.1 200 OK
>> Date: Thu, 29 Aug 2013 07:31:25 GMT
>> Server: Apache
>> Last-Modified: Thu, 29 Aug 2013 04:44:38 GMT
>> ETag: "e74073-a7a-c36f5980"
>> Accept-Ranges: bytes
>> Content-Length: 2682
>> Connection: close
>> Content-Type: text/html; charset=UTF-8
>> 
>> 
>> 
>>   
>>   
>>   
>>   Test Insert Symbols
>> 
>> 
>> 
>> The meta header should override it.  Maybe that has been broken somehow?
>
>
> Nothing has changed.  The HTTP Content-Type header has aways taken precedence 
> over the HTML meta declaration, and not only in SM.  

Then why is the page shown in UTF-8 while it should be windows-1252?

On my Linux system running Seamonkey 2.20 it fails as well.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Philip Taylor]

Ralph Fox (<-rf-nz-@xn--kba.invalid>) wrote:

> Nothing has changed.  The HTTP Content-Type header has aways taken precedence 
> over the HTML meta declaration, and not only in SM.  

This is the defined behaviour :
http://www.w3.org/International/questions/qa-html-encoding-declarations) :

> The HTTP header information has the highest priority when it conflicts with 
> in-document declarations. 

Philip Taylor
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Ralph Fox]

On Thu, 29 Aug 2013 02:37:27 -0500, Rob wrote:

> The HTTP headers say UTF-8:
> 
> HTTP/1.1 200 OK
> Date: Thu, 29 Aug 2013 07:31:25 GMT
> Server: Apache
> Last-Modified: Thu, 29 Aug 2013 04:44:38 GMT
> ETag: "e74073-a7a-c36f5980"
> Accept-Ranges: bytes
> Content-Length: 2682
> Connection: close
> Content-Type: text/html; charset=UTF-8
> 
> 
> 
>   
>   
>   
>   Test Insert Symbols
> 
> 
> 
> The meta header should override it.  Maybe that has been broken somehow?


Nothing has changed.  The HTTP Content-Type header has aways taken precedence 
over the HTML meta declaration, and not only in SM.  



FYI from December 1999, see the HTML 4.01 Specification, section 5.2.2
http://www.w3.org/TR/REC-html40/charset.html#h-5.2.2

|   (from highest priority to lowest):
|   
|1.  An HTTP "charset" parameter in a "Content-Type" field.
|2.  A META declaration with "http-equiv" set to "Content-Type" and a value 
set for "charset".
|3.  The charset attribute set on an element that designates an external 
resource.


This year, June 2013, from Mozilla's website
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta

|   *   This  element is only a part of the algorithm to determine
|   the character set of a page that browsers apply. Especially, the
|   HTTP Content-Type header and any BOM elements have precedence over
|   this element.


-- 
Kind regards
Ralph
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Rob]

Paul B. Gallagher  wrote:
> kenandgiova...@yahoo.com wrote:
>
>> Composer inserts characters & symbols display OK when preparing html
>> webpages. When viewed on the web, Firefox will display a > diamond w/white ?> for many (all?) of the inserted symbols &
>> characters.
>>
>> Example links:
>>
>> Test page -
>> 
>> Looks OK in View/ Preview. In View/ html, the actual symbol seems to
>> be inserted rather than an html code for the symbol.
>
> Your code specifies Windows-1252, but SeaMonkey tries to display it as 
> Unicode (UTF-8). If I manually select Windows-1251 or Windows-1252, the 
> page displays correctly. I wonder why SeaMonkey isn't obeying your spec. 
> The spec appears to be well-formed:
>
> 

The HTTP headers say UTF-8:

HTTP/1.1 200 OK
Date: Thu, 29 Aug 2013 07:31:25 GMT
Server: Apache
Last-Modified: Thu, 29 Aug 2013 04:44:38 GMT
ETag: "e74073-a7a-c36f5980"
Accept-Ranges: bytes
Content-Length: 2682
Connection: close
Content-Type: text/html; charset=UTF-8



  
  
  
  Test Insert Symbols



The meta header should override it.  Maybe that has been broken somehow?

The page appears to have a long history :-)
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Paul B. Gallagher]

kenandgiova...@yahoo.com wrote:


Composer inserts characters & symbols display OK when preparing html
webpages. When viewed on the web, Firefox will display a  for many (all?) of the inserted symbols &
characters.

Example links:

Test page -

Looks OK in View/ Preview. In View/ html, the actual symbol seems to
be inserted rather than an html code for the symbol.


Your code specifies Windows-1252, but SeaMonkey tries to display it as 
Unicode (UTF-8). If I manually select Windows-1251 or Windows-1252, the 
page displays correctly. I wonder why SeaMonkey isn't obeying your spec. 
The spec appears to be well-formed:





(The following may be a separate problem?)
A page originally prepared in Mozilla Composer in 2001, with
copyright symbols added in reloads every year. This last year it was
not possible to directly insert a copyright symbol for 2013 - I had
to cut-&-paste. Now, it appears in my Firefox browser that all the
copyright symbols (and an accent-'e') have reverted to '' (Unknown
character?).



Same thing here.

It doesn't seem to matter if I turn auto-detect on or off, it always 
chooses Unicode (UTF-8) for these pages. I have checked my prefs and I 
don't force it to do so.


--
War doesn't determine who's right, just who's left.
--
Paul B. Gallagher

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SM 2.20 Composer Insert does not display symbols in Firefox.

[Geoff Welsh]

kenandgiova...@yahoo.com wrote:

Composer inserts characters & symbols display OK when preparing html webpages. When 
viewed on the web, Firefox will display a  for many (all?) of 
the inserted symbols & characters.

Example links:

Test page -
http://spontoon.rootoon.com/SPwTest1.html
Looks OK in View/ Preview. In View/ html, the actual symbol seems to be 
inserted rather than an html code for the symbol.

(The following may be a separate problem?)
A page originally prepared in Mozilla Composer in 2001, with copyright symbols added in 
reloads every year. This last year it was not possible to directly insert a copyright 
symbol for 2013 - I had to cut-&-paste. Now, it appears in my Firefox browser that 
all the copyright symbols (and an accent-'e') have reverted to '' (Unknown 
character?).
http://spontoon.rootoon.com/SPwHome1.html

My apologies in advance if I am overlooking any obvious html-development 
knowledge.

Thank you for your patience,
Ken



i think the:

meta http-equiv="Content-Type" content="text/html; charset=windows-1252"

in the source is incorrect somehow.

If I select that Encoding from the View menu, the page shows the correct 
characters, otherwise it shows the unknown symbols.


GW
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

SM 2.20 Composer Insert does not display symbols in Firefox.

[kenandgiovanna]

Composer inserts characters & symbols display OK when preparing html webpages. 
When viewed on the web, Firefox will display a  for 
many (all?) of the inserted symbols & characters.

Example links:

Test page -
http://spontoon.rootoon.com/SPwTest1.html
Looks OK in View/ Preview. In View/ html, the actual symbol seems to be 
inserted rather than an html code for the symbol.

(The following may be a separate problem?)
A page originally prepared in Mozilla Composer in 2001, with copyright symbols 
added in reloads every year. This last year it was not possible to directly 
insert a copyright symbol for 2013 - I had to cut-&-paste. Now, it appears in 
my Firefox browser that all the copyright symbols (and an accent-'e') have 
reverted to '' (Unknown character?).  
http://spontoon.rootoon.com/SPwHome1.html

My apologies in advance if I am overlooking any obvious html-development 
knowledge.

Thank you for your patience,
Ken 
 
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey