Open Bug 369301 Opened 19 years ago Updated 3 years ago

UserContent.css rules for "pre" elements affects text-based files

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows XP
Type:
defect

Tracking

()

People

(Reporter: The.Pickle.Thief, Unassigned)

References

Details

Attachments

(1 file)

A test text file that can be used to see the problem.
1.72 KB, text/plain
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 ImageShackToolbar/3.0.4 Firefox/2.0.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 I noticed via a Firefox extension I have, Firefox parses text files as if the content was written in a "pre" HTML tag. This also occurs with site-specific rules. Reproducible: Always Steps to Reproduce: 1. Edit UserContent.css to include something tweaking "pre" HTML tags and save. Example: pre{color:red;} 2. Restart Firefox and view a text file. Actual Results: Firefox applies whatever is stated in a global UserContent.css rule to all text files. Expected Results: Firefox should ignore any CSS rules given to possibly affected "pre" tags. I have not checked XML files using a "pre" tag.
Assignee: nobody → dbaron
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
Summary: If there is a UnserContent.css entry for "pre" tags, it affects text files. → UserContent.css rules for "pre" elements affect text files
I just discovered this bug applies to JavaScript and CSS files as well. I'm thinking that all files that display like text files are affected.
Summary: UserContent.css rules for "pre" elements affect text files → UserContent.css rules for "pre" elements affects text-based files
Images too. Wouldn't "fixing" this bug prevent all these things from being styled?
Assignee: dbaron → nobody
QA Contact: ian → style-system
We convert text files into HTML internally and render the resulting HTML. So there really is a <pre> tag here. I suspect this should be wontfix, per comment 3. I'm also pretty sure it's a duplicate...
Whiteboard: DUPEME
Would it make sense to set a class on the <html> or <body> or <pre>, so user stylesheets can distinguish them easily? pre:not(.moztextdocument) { } pre.moztextdocument { }
Yeah, we could do that pretty easily for plaintext, images, etc.
ccing content peers, since that's where that change would live.
Would it be feasible to add an at-rule for matching on content-type? @-moz-content-type("text/plain") { ... } (HTML5 prescribes the DOM for text/plain, and currently, it's defined to be attributeless. If the attribute route is preferred, I think the attributes should be documented in HTML5.)
Yeah, we could add such a rule. That might also be interesting as a way of telling apart HTML from XML-based documents containing HTML nodes. David, what do you think?
Couldn't find a dupe, confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: DUPEME
Would fixing this break the following bookmarklet that makes text/plain files wrap? javascript:void(document.body.firstChild.style.whiteSpace='pre-wrap') If so, is there an alternate bookmarklet solution?
It probably would break that bookmarklet, although not certainly.
HTML doesn't allow us to break it, actually. This bug, as filed, is invalid. An @-rule could be useful, though.
For adding the @-rule, see also bug 626776. Once we have an @-rule, we could change the synthetic document to not contain a <pre> element, if we wanted to.
Not without violating the current HTML5 spec text (and possibly breaking some websites).
Depends on: 626776
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: