render mode for non-html pages should say "n/a" or similar

RESOLVED WONTFIX

Status

SeaMonkey
Page Info
--
minor
RESOLVED WONTFIX
16 years ago
3 years ago

People

(Reporter: Jeremy M. Dolan, Assigned: db48x)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: jmd-remind, URL)

(Reporter)

Description

16 years ago
render mode for non-html pages should say "n/a" or similar

currently text and image pages claim to be in "compatibility mode". not very ideal.
Well..... thing is, they are.  We construct an HTML document internally and it's
a quirks document....  I can think of scenarios where one would want to know
this (eg bookmarklets that work on image documents may need to be designed
differently because of this).
(Reporter)

Comment 2

16 years ago
> thing is, they are

I know. But users shouldn't.

> I can think of scenarios where one would want to know this (eg bookmarklets

I can't. Regardless, bmlets are automated. This bug is only for changing the
text "Page info" reports. Not the value of some object accessible w/ JS. I (and
users) don't care about the backend. There's no need to expose image/gif as
"compatible" rendering mode via page info.
(Assignee)

Comment 3

16 years ago
the images are decoded in a 'compatibility' mode, because some images that don't
exactly comply with the standard can still be displayed. Also, isn't text/plain
supposed to mean that the file is 8 bit clean? (I could be wrong) We certainly
don't display an error if the file happens to have high bit characters in it.
I'm not inclined to fix it. WONTFIX'ed
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 4

16 years ago
It's not a rendering mode though. Certainly a different definition of the term,
at least. Very poor UI.
Whiteboard: jmd-remind
Product: Browser → Seamonkey

Updated

3 years ago
Depends on: 1135252

Updated

3 years ago
No longer depends on: 1135252
You need to log in before you can comment on or make changes to this bug.