The default bug view has changed. See this FAQ.

should be able to disable CSS (Use Style > None or global pref)

RESOLVED FIXED in mozilla1.8alpha3

Status

()

Core
Layout
P2
normal
RESOLVED FIXED
17 years ago
3 years ago

People

(Reporter: Martin Horwath, Assigned: fantasai)

Tracking

(Blocks: 2 bugs, 4 keywords)

Trunk
mozilla1.8alpha3
css1, helpwanted, html4, relnote
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [WAI-P1][HTML4-14.3.1][CSS1-7] se-radar relnote-user [Hixie-P2][Hixie-P0], URL)

Attachments

(3 attachments, 6 obsolete attachments)

(Reporter)

Description

17 years ago
in Preferences/Advanced/enable style sheets has no effect.

i thought this option should disable any styles on any page, but
it simply does nothing.

something like this,

***
  <link href="/opensa.css" rel="stylesheet" type="text/css">

***
<style>
  body { font-size: 50px }
</style>

***
 if (document.getElementById) {
   document.write('<link rel=STYLESHEET type="text/css"
href="/layout/css/gecko.css">');

should be simply ignored.

testet on win98 build 2000031708

Comment 1

17 years ago
Turning off CSS in the Prefs menu actually does nothing.  I turned it off and 
went to the following page: http://www.lehigh.edu/~cjm3/links.html, where the 
following CSS code is used:

<style>
<!--
a{text-decoration:none}
//-->
</style>

After reloading the page (after turning of CSS), the links still were not 
underlined.  I even restarted Mozilla and had the same results.

Build ID: 2000050508
Operating System: Win98, Intel Pentium II
Confirming.

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

17 years ago
M17 ...
Assignee: matt → mcafee
Keywords: nsbeta2
Target Milestone: --- → M17

Comment 4

17 years ago
ekrock, is it impt to be able to turn off for beta2.
Whiteboard: [NEED INFO]
*** Bug 34825 has been marked as a duplicate of this bug. ***
David, Ian--does the CSS or HTML spec *require* that applications have a 
feature/pref enabling style sheets to be turned off?

Pierre, Mark--how much work is it in the code to just turn off CSS?

Possible reasons to mark nsbeta2+:
1) strong reason: if mandated by a W3C spec
2) another good reason: there may be some users with visual impairments such as 
colorblindness who find that a particular CSS-specified page color scheme makes 
it hard/impossible for them to read a particular page; for those users, the 
ability to turn off CSS would improve accessibility
3) weaker reason: backward compatibility of "degree of functionality control" 
with Nav4

I *suspect* we can enable this easily but need more info from our standards 
gurus about requirements and from engineering about LOE.
Keywords: 4xp
HTML 4.01, section 14.3.1, paragraph 7:
#  User agents SHOULD also allow users to disable the author's style 
#  sheets entirely, in which case the user agent MUST not apply any
#  persistent or alternate style sheets.
Blocks: 7954
Keywords: html4
OS: Windows 98 → All
Hardware: PC → All

Comment 8

17 years ago
From Ian's post opf the HTML spec it looks like it is optional (noting the 
SHOULD). We cannot just turn off CSS - nothing would work if we did that. We 
can, however, disable the author's stylesheet if we can identify it. The 
underlying support is there in the StyleSet and SyleSheet, however we need to 
hook up some plumbing to get the correct sheet(s) and disable them, and also to 
re-enable them. Probably not a huge amount of work (a few days?), but it doesn't 
look like it is essential. 

Note that for bug 38026 I need to implement something similar in the 
StyleSet (ability to enable/disable a QuirkMode style sheet) so I can generalize 
the implementation to support something like this (enable/disable *any* 
stylesheet, including author style sheets). Once that work is done, the 
preferences can make calls into the StyleSet to do the work.

Comment 9

17 years ago
[nsbeta2-] Make sure this has to do with link style sheets rather than default.
Whiteboard: [NEED INFO] → [nsbeta2-][NEED INFO]
<tough_decision>Sigh. All right. (1) It's a SHOULD, not a MUST, in the HTML 4.01 
spec. (2) IE5 Win doesn't seem to have this either. Marking FUTURE, helpwanted, 
and relnote as Mark clearly indicates this is a nontrivial enhancement, and 
we're out of time for enhancements. Unless I'm persuaded otherwise in the next 
few days, I'll file a bug to have the "disable style sheets" pref removed from 
the UI. </tough_decision>
Keywords: helpwanted, relnote
Whiteboard: [nsbeta2-][NEED INFO] → [nsbeta2-]
Target Milestone: M17 → Future

Comment 11

17 years ago
> We cannot just turn off CSS - nothing would work if we did that. We 
> can, however, disable the author's stylesheet if we can identify it.

Isn't that exactly what "...in which case the user agent MUST not apply any 
persistent or alternate style sheets" is addressing. It seems to me that this 
says, "if you have the option of turning off the author's style sheets, then you 
must not use another in its place".

Comment 12

17 years ago
jerrybaker, what I meant was that we must still apply the *user agent* style 
rules (in html.css and xul.css), so we cannot 'turn off style'. You are correct, 
however, in that we MUST not apply any author stylesheets, persistent or 
altermate, when we do implement thsi in the future.

Comment 13

17 years ago
over to ekrock to resummarize and/or this bug.
I can do pref UI stuff, not clear what's going on here.
Assignee: mcafee → ekrock
until we get help on this feature, should the Pref be pulled from the UI?
To clarify:
1) retitling this bug "should be able to enable/disable style sheets via a pref 
in UI", leaving as FUTURE, reassigning to attinasi
2) opening new, separate bug 39552 on mcafee to eliminate the enable/disable 
pref of the UI for nsbeta2 (and FCS)
Assignee: ekrock → attinasi
Summary: enable/disable style sheets in prefs has no effect → should be able to enable/disable style sheets via a pref in UI

Updated

17 years ago
Status: NEW → ASSIGNED

Comment 16

17 years ago
*** Bug 35322 has been marked as a duplicate of this bug. ***

Comment 17

17 years ago
Here's a quote from the W3C User Agent Accessibility Guidelines, checkpoint 4.12:

"Allow the user to select from available author and user style sheets or to
ignore them. *[Priority 1] *"

This is a priority 1 checkpoint:

"This checkpoint *must* be satisfied by user agents, otherwise one or more
groups of users with disabilities will find it impossible to access the Web.
Satisfying this checkpoint is a basic requirement for enabling some people
to access the Web."

There should be a way to disable (document) style sheets in Mozilla, preferably as a button or a menu-item. Perhaps a small button in the statusbar for disabling/enabling style sheets?
Whiteboard: [nsbeta2-] → [nsbeta2-][WAI-P1]

Comment 18

17 years ago
IMHO, it would be logical to include the disable option in the "Use Stylesheet" 
menu.  For details, see http://www.people.fas.harvard.edu/~dbaron/css/ssui/ and 
the discussion at bug 6782.
spam: adding mostfreq, not necessarily due to many dups, but because i run into 
this problem frequently (thus want to get it my queries easily).
Keywords: nsbeta2 → mostfreq
Whiteboard: [nsbeta2-][WAI-P1] → [WAI-P1]

Comment 20

17 years ago
Disable the author stylesheets? That's what XBL style bindings are for...
Geek humor aside, Marc, this should be fairly easy to do if you can find a way to 
tell whether the PresContext (or whatever owning object we're in) belongs to the 
chrome or to the content (because we want to do this in the content area only, 
right?). Looking for "isChrome" in nsDocumentViewer.cpp or for "isContent" in 
nsFrameFrame.cpp, or just asking hyatt, should put you on the right track. If you 
find the trick before me, please drop a note in bug 31816.

I think that this pref should be active only in HTML documents.
And XHTML documents. And MathML documents. And XUL documents. And documents that
only have elements from those namespaces.

I think it might be easier just to always have this pref available...

Comment 22

17 years ago
From Daivd Hyatt:

ben says you need to know how to tell if you're in chrome... 

This info is on the docshell... you can see an example of the check in 
nsDocumentViewer.cpp where I check to see whether or not I want to use chrome or 
content user stylesheets.... 

  nsCOMPtr<nsIDocShellTreeItem> docShell = (get it from whereever you are...) 
  PRInt32 shellType; 
  docShell->GetItemType(&shellType); 
  PRBool isChrome = (shellType == nsIDocShellTreeItem::typeChrome); 

Comment 23

17 years ago
I filled in bug 51690 (disable stylesheets (also style="" and <style>) via
View|Use stylesheet).
This brought me to the question:
Does disable means that "Use stylesheet" is disabled or that we default to
"None" if we load a page so the user can later use this menu to choose a style?
Removing mostfreq - this bug does not qualify for this keyword under the 
established criteria.

Gerv
Keywords: mostfreq
adding se-radar to status so that i can find this bug more easily. pls don't
remove it [yet], thx.
Whiteboard: [WAI-P1] → [WAI-P1] se-radar
*** Bug 55989 has been marked as a duplicate of this bug. ***
I think it would be better to make this a main part of the stylesheet UI and
remember the setting between windows and invocations.

Updated

17 years ago
Whiteboard: [WAI-P1] se-radar → [WAI-P1] se-radar relnote-user
Closer examination of the CSS1 specification indicates that this is a CSS1
full-support requirement too. (Section 7.)

RELEASE NOTE ITEM:
   In this release it is not possible to totally disable author stylesheets.
   It is possible to use user stylesheets (see XXX) to achieve more fine-grained
   control over the styling of web pages, however.
Keywords: css1

Comment 29

17 years ago
I'm not sure what you mean by full-support, Ian, but in section 7 I read:

This specification also recommends, but doesn't require, that a UA:
  - allows the reader to specify personal style sheets
  - allows individual style sheets to be turned on and off

as indicating that it is optional, but recommended. By full-support do you mean
that we implement all _recommendations_ as well as _requirements_?

I agree that the release note item is a good idea, thanks for writing it.
Marc: Yes, full support as distinct from conformant support.
Nominating for mozilla 0.9.  There have been a number of strongly negative
comments about Netscape 6 on c.i.w.a.s because of the lack of this feature.

Probably the safer way to implement this pref would be around the loading of
stylesheets and parsing of style elements/attributes.  However, this would still
allow HTML presentational hints.  Implementing this at the cascade level would
also block those, I think (if we've implemented them correctly, although I
suspect we may not in some cases).  Would there be any unexpected consequences
of doing that?  Would we want 2 separate prefs?
Keywords: mozilla0.9

Comment 32

17 years ago
CC'ed erik & momoi.

Comment 33

17 years ago
I'm thinking that we want to turn on or off individual stylesheets more than
having a global 'use stylesheets' preference. That is what CSS1 recommends.
Having a global pref could simply be a shortcut for always disabling all
stylesheets, of course, but we would still benefit from a UI to toggle each
stylesheet individually (similar to the Alternate Stylesheets UI?)
I don't see any reason for toggling stylesheets individually other than as
described by the author with TITLEs.  Allowing that discourages or encourages
authors from using linked stylesheets versus STYLE elements for reasons other
than the ones on which they should be basing that decision.  It also discourages
authors from writing modular stylesheets, since the author would have to worry
about the effects of disabling part of the stylesheets but not all.

Comment 35

17 years ago
One reason to support disabling of individual stylesheet is the CSS1
specification. Section 7 says:

This specification also recommends, but doesn't require, that a UA:
 - allows the reader to specify personal style sheets
 - allows individual style sheets to be turned on and off

I guess we could argue that the spec is wrong, and I cannot find the same
recommendation in the CSS2 specification. I don't personally care either way, so
hopefully Eric can tell us what he thinks the product should support -
enabling/disabling of all stylesheets, or per-stylesheet.

Also, do we really want to suppress HTML presentational hints along with the
stylesheets? I do not see why we would since from an author's perspective they
are NOT stylesheets (even though we may implement some of them as style rules
internally).
The argument for including nonpresentational hints in the "turn all stylesheets
off" option is that a user who chooses to turn off all stylesheets (including
persistent ones) probably can't use the page with the styles given, which may or
may not be specified using stylesheets.

Comment 37

17 years ago
Agreed. Then what we really want is an option to 'turn off all style'. I doubt
users want to be bothered with figuring out what parts of the page are
implemented with stylesheets vs. HTML attributes and elements. So what then
would be included in the presentational hints that we disable? Font sizes, font
faces, font weight, underline, bold, italics, color, and background? Hey, why
not just make a 'show as plain text' option! Seriously, that is pretty much what
it would be, except that you would have images too, and borders.
A *per-stylesheet* disabling UI would be incredibly confusing and utterly
useless for ordinary users. A classic "provide too much UI and complexity for
the user to understand, thus providing no benefit"-type mistake. (Yes, I'm sure
that a few developers might find such a beast handy for testing & QA during page
development, but Mozilla/N6 are a browser application, not a sophisticated style
sheet development tool. Let's leave authoring tool functionality to the
authoring tool vendors.) A single "turn off style sheets" option is clearly the
way to go.

As for turning off presentational hints at the same time: let's be careful about
reinterpreting what the standards say. First of all, by presentational hints,
are you referring to hardcoded FONT FACE tags and the like? If so, we'd be in
violation of the HTML spec if we ignored those tags as well when the user turned
of style sheets, yes? After all, we'd be ignoring markup that, though
deprecated, should be respected and is used by developers as a fallback for
non-stylesheet browsers (and thus arguably should be preserved if style sheets
are turned off in a style sheet-capable browser).

My take:
1) the ability to turn on/off all style sheets (binary, global) is something
that Netscape should invest its time in.
2) The ability to ignore presentational hints is a separate feature, an
enhancement request, and honestly not a good use of Netscape resources at this
time.

My proposal:
a) Let's have Marc limit himself to working on a binary "turn off style sheets"
checkbox (or View menu item, or whatever--the point is it should be an
all-or-nothing setting that turns off the application of CSS only)
b) A separate enhancement request bug on the "turn off presentational hints"
should be opened and reassigned to nobody@mozilla.org until someone not at
Netscape takes this work on.

Netscape developers should remain focused on stability, performance, and bug
fixes for some time to come, not work on enhancements that will only be use to a
tiny fraction of our user base if that.

Comment 39

17 years ago
From an accessibility standpoint, it might be useful to be able to switch off
all style sheets except for the user style sheet.
I disagree with Eric Krock's comments above.  Turning off all stylesheets is
only a useful feature in that it allows the user to control the browser when the
page author misbehaves.  If it only works for style specified in CSS, it won't
be very useful.  Turning off the FONT tag does *not* break compliance with HTML 4.0.

I also suspect that, from an implementation standpoint, turning off all author
style is easier than turning off all CSS, since it can be implemented easily at
the cascade level.  Turning off all CSS (including STYLE elements and
attributes) seems a bit more difficult.
What's the status here? :-) Marc, is this very much on your back burner, or are 
we going to get it for 0.9 or 1.0?

Gerv

Comment 42

16 years ago
Still a back-burner issue, but my manager has just informed me that I need to
start addressing the nominations... That should happen over the next few days.

Comment 43

16 years ago
Can't you filter external stylesheet out on HTTP level?
Add more keywords. We really _do_ need to do this for 1.0, and that means doing 
it for 0.9 if it's going to get any serious testing. 

Gerv
Keywords: mozilla0.9.1, mozilla1.0, nsbeta1

Comment 45

16 years ago
*** Bug 93241 has been marked as a duplicate of this bug. ***

Comment 46

16 years ago
Adding CSS to the summary, may help people searching for this bug if they're
looking for "CSS" rather than "style sheets"
Summary: should be able to enable/disable style sheets via a pref in UI → should be able to enable/disable style sheets (CSS) via a pref in UI

Updated

16 years ago
Blocks: 104166
(Assignee)

Updated

16 years ago
Blocks: 51690
*** Bug 107326 has been marked as a duplicate of this bug. ***

Comment 48

16 years ago
Taking this style bug off Marc's list.
Assignee: attinasi → pierre
Status: ASSIGNED → NEW

Comment 49

16 years ago
*** Bug 51688 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.0

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla0.9.9

Comment 50

16 years ago
*** Bug 51690 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Depends on: 51688

Comment 51

16 years ago
Rather then a pref, which would be quite inaccessible when you simply want to
disable style temporarily, this should be integrated into the current
view->stylesheets menu.

As far as prefs, the current ones that disable custom fonts/colors etc should
simply apply to CSS as well as the traditional HTML <font> method, as users
using those options are most likely doing so for permanent accessibility
reasons, and don't really care if the moron web designer used CSS or <font> to
set the page to be 6pt green text on a blue background.

How about this for the menu:

 None       # No stylesheets applied
 -------    # divider
 Default    # Only persistant styles applied. Equivilent to current 'none'
 funky      # Prefered sheet listed next, which would be selected at page load
 clean      # Alternate stylesheets listed next, in order of referance on the
 very red   #   page (unless the spec says they should be listed in some other
            #   order)

Currently, when only a persistant stylesheet is active, 'None' is checked in the
menu. As shown above, I suggest 'Default' be added, which is only the persistant
styles applied.

None actually meaning, 'no stylesheets', is alot more obvious than it meaning
'no alternate/prefered stylesheets', especially to people who haven't read the
CSS and HTML specs.
> Default    # Only persistant styles applied. Equivilent to current 'none'

It doesn't make sense to call that "Default", since it's not the default.  I
wrote a proposal in the main alternate stylesheets UI bug a year or two ago with
suggestions for how to do this.
(Assignee)

Comment 53

16 years ago
Some history: It was decided in bug 6782 to have a no-author-level-styles option
in the Use Style menu; this was filed as bug 51690, which was marked as a
duplicate of this bug. Bug 51688 was filed to deal with the current "none"
option--initially to change the wording until 51690 could be fixed.
Created attachment 64169 [details]
IRC discussion about how to implement this, and other issues
(Assignee)

Updated

15 years ago
Blocks: 107023
Moving to Mozilla1.1. Engineers are overloaded with higher priority bugs.
Target Milestone: mozilla0.9.9 → mozilla1.1
(Assignee)

Comment 56

15 years ago
Created attachment 68076 [details] [diff] [review]
patch v0.1

This unfinished fix enables/disables author level styles.
There are two outstanding issues:
  1.) The refresh function needs to be called on *every* page load.
      I don't know how to do this.
  2.) Switching around with CSS generated content images has weird results and
      sometimes crashes. Reproducible. Might have something to do with the
      DeviceContext calls made in SetPreferenceStyleRules that I'm not making,
      or something else I'm not yet aware of. I'm going to look into this;
      hopefully I'll find the problem.

Also, I haven't tested it with framesets yet.
Bulk moving from Moz1.1 to future-P1. I will pull from this list when scheduling
work post Mozilla1.0.
Priority: P3 → P1
Target Milestone: mozilla1.1 → Future
*** Bug 127464 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Blocks: 86194

Comment 59

15 years ago
Mass removing self from CC list.

Comment 60

15 years ago
Now I feel sumb because I have to add back. Sorry for the spam.
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: ASSIGNED → NEW
Priority: P1 → P2

Comment 62

15 years ago
I notice that style sheet toggling can be done per page via a bookmarklet:
http://www.ninjakitten.net/digiboy/2002_06.php#post000262
Seems to work fine.
The bookmarklet doesn't disable non-CSS style hints.
Whiteboard: [WAI-P1] se-radar relnote-user → [WAI-P1][HTML4-14.3.1][CSS1-7] se-radar relnote-user
Whiteboard: [WAI-P1][HTML4-14.3.1][CSS1-7] se-radar relnote-user → [WAI-P1][HTML4-14.3.1][CSS1-7] se-radar relnote-user [Hixie-P2][Hixie-P0]
*** Bug 180649 has been marked as a duplicate of this bug. ***
Component: Preferences → Layout
QA Contact: sairuh → ian
cc:ing Aaron 

Is this another accessibility win?  

-R

Comment 66

15 years ago
Sure, this would be nice for some visually impaired users if it was something
that could be easily toggled. I'd like to see something like this on the pref
toolbar from xul planet. Not a high priority compared to our other accessibility
work, at least at the moment.

Updated

14 years ago
Summary: should be able to enable/disable style sheets (CSS) via a pref in UI → should be able to disable CSS (Use Style > None or global pref)

Comment 67

14 years ago
There are really two separate issues here:

(a) being able to disable CSS (or for those of you who prefer to say it this
way, use only the UA stylesheet) as a global user preference
(b) being able to switch the style sheet off temporarily (View -> Use Style ->
None or something) for such purposes as testing or reading badly-written pages.

(a) could merely set the default, while still allowing the user to override it
either way from the Use Style submenu.
(Assignee)

Comment 68

14 years ago
I think having two switches, one global and one "local" will just confuse the
user. Are they two interfaces to the same switch? Are they two separate
settings--e.g. does one override the other? Which one? It's better, IMO,
to have just one switch in the Use Style menu and remember its last setting
between sessions. The disabling author style, btw, will be quite drastic, as it
will not only disable all CSS, but most HTML formatting as well. I doubt its use
as a global preference will be very common; forcing a color or font override is
usually more useful.

Comment 69

14 years ago
Please clarify:

1. If the global setting overrode the local setting, what would the local setting do at all?
2. How would disabling the author style sheet disable HTML formatting?
(Assignee)

Comment 70

14 years ago
> 1. If the global setting overrode the local setting, what would the local
> setting do at all?

"Obviously" the local setting overrides the global one, but you have to convey
this model to the users, which is easier said than done. They don't need a
separate global setting; why confuse them with one?

> 2. How would disabling the author style sheet disable HTML formatting?

Disabling author styles disables HTML formatting because HTML formatting is
part of the author style level[1]. It is style assigned by the author, so it
certainly belongs there.

From a UE perspective, we should not make a distinction between <font
color="#FF0000"> and <span style="color: #FF0000"> because the user doesn't
care. Lime text on a Green background is hard to read whether it's specified
with HTML attributes or CSS properties.

[1] http://www.w3.org/TR/REC-CSS2/cascade.html#cascade , specifically 6.4.1 and
    6.4.4

Comment 71

14 years ago
Your link gives this line:

"It is therefore important that the user agent give the user the ability to turn off the 
influence of a certain style sheet, e.g., through a pull-down menu."

But 6.4.4 seems rather odd.  Why should HTML presentation hints be at the beginning of 
the author style sheet, rather than treated as being in style="..." attributes?  And can't a 
makeshift "author style sheet" be used to handle HTML presentation hints if the real 
author style sheet is disabled?

As for your "UE perspective", I'm not totally sure what to say.  But what is for certain is that 
there is sometimes the need to disable an author style sheet in order to read a badly 
coded page.
(Assignee)

Comment 72

14 years ago
> Why should HTML presentation hints be at the beginning of 
> the author style sheet, rather than treated as being in style="..." 
> attributes? 

So that author CSS can override HTML presentation hints. If I make links silver
with <body link="silver">, I should be able to make some of them aqua with
  .navigationbar :link {color: aqua}

> And can't a makeshift "author style sheet" be used to handle HTML presentation
> hints if the real author style sheet is disabled?

Technically, yes. But we don't want to do that because, as you say, 

"there is sometimes the need to disable an author style sheet in order to read a
 badly coded page."

And there is no less a need to disable <font> and other presentation hints in
order to read a page badly coded with HTML presentational hints. You *do not
care* if a poor color combination was specified in HTML or CSS. You just want to
disable it.

Comment 73

14 years ago
You misunderstand.  I was actually thinking of bad CSS and JS rather than bad
HTML.  There are situations where a page is inaccessible, e.g. because it has
used some combination of CSS and JS to show/hide content, and the code is
somewhere broken or otherwise heavily reliant on having the right browser.

Witness http://www.sineadquinn.tv for example.  OK, so this one would need a bit
more than just switching off the author style sheet, but surely some sites would
work if only explicit CSS declarations were ignored even if HTML presentation
hints are allowed to shine through.

That's what happened on browsers that predated CSS, didn't it?
(Assignee)

Comment 74

14 years ago
> surely some sites would work if only explicit CSS declarations were ignored even
> if HTML presentation hints are allowed to shine through.

Certainly, but why give HTML presentation hints (which are deprecated, btw) such
a stronger precedence than CSS? I argue that if the same site used CSS instead of
HTML presentation hints, I should get the same result if I turn off author style.

And you still have this whole problem with color contrast, etc, which should be
handled the same in both HTML and CSS.

Comment 75

14 years ago
A side comment (to the last few): Should the DOM Style interfaces be disabled
when the style is "switched off"? Or may be made read-only to not be modifiable
by scripts.
DOM style is just inline style.  If inline style is off, so is DOM style (it can
be changed, but has no effect on rendering).

Comment 77

14 years ago
Re: fantasai

Yes, but if on a given page it's only the CSS that's broken and not the HTML, why should 
the luser be forced to disable both?

Comment 78

14 years ago
Re: famtasai

Yes, but if on a given page it's only the CSS that's broken and not the HTML, why should 
the luser be forced to disable both?

HTML presentation hints in a CSS-formatted page are, after all, supposed to be for 
graceful degradation.
What if it is the HTML that is broken and not the CSS? What if one stylesheet of
the two linked to a page is fine, but the second is not? In fact, what if one
third of the fifth stylesheet is the problem, but the rest is not?

And how should the user discover this?

As far as the overwhelming majority of users are concerned, there's no
difference between HTML hints and CSS hints.

Comment 80

14 years ago
> What if it is the HTML that is broken and not the CSS?

Good question.  But can you supply an example of such a page?

> What if one stylesheet of the two linked to a page is fine, but the
> second is not?  In fact, what if one third of the fifth stylesheet
> is the problem, but the rest is not?

That would be a tricky question.  But how likely is it that, should
that be the case, using no stylesheet at all and letting the HTML
hints shine through wouldn't GD?

> And how should the user discover this?

That depends.  But discovering the case I mentioned above would be
perfectly straightforward given the option.

> As far as the overwhelming majority of users are concerned, there's
> no difference between HTML hints and CSS hints.

I expect that the overwhelming majority of users also don't care
about the difference between alternative stylesheet 1 and alternative
stylesheet 2.  So why shouldn't we give the handful who either are
interested or need it the option of using no stylesheet at all?
>> What if it is the HTML that is broken and not the CSS?
>
> Good question.  But can you supply an example of such a page?

That's trivial. A page with <font size="1"> at the top.


>> What if one stylesheet of the two linked to a page is fine, but the
>> second is not?  In fact, what if one third of the fifth stylesheet
>> is the problem, but the rest is not?
>
> That would be a tricky question.  But how likely is it that, should
> that be the case, using no stylesheet at all and letting the HTML
> hints shine through wouldn't GD?

GD?


>> And how should the user discover this?
>
> That depends.  But discovering the case I mentioned above would be
> perfectly straightforward given the option.

So you want the user to try various options until they think the rendering is
ok? Come on.


>> As far as the overwhelming majority of users are concerned, there's
>> no difference between HTML hints and CSS hints.
>
> I expect that the overwhelming majority of users also don't care
> about the difference between alternative stylesheet 1 and alternative
> stylesheet 2. 

They don't know about the feature, maybe, and that is an argument for making it
more visible on pages with alternates. However, users like playing with themes
(just look at mobile phone users changing their login screens). I have yet to
see a user say "I'd like to turn off half the styles on this page".


> So why shouldn't we give the handful who either are
> interested or need it the option of using no stylesheet at all [but leaving
> the HTML hints in place]?

Because every option we add reduces overall usability.


I agree that we should have a feature to remove all the stylesheets, and
according to the CSS spec, HTML hints count as being in a stylesheet.

Comment 82

14 years ago
> I agree that we should have a feature to remove all the stylesheets,
> and according to the CSS spec, HTML hints count as being in a stylesheet.

do you mean to include user style (userContent.css) when removing all
stylesheets?

i think we need to be careful of reducing accessibility. imagine someone
challenged has gone to the trouble of making their web experience more
accessible, and this feature nukes their style.

as much as i don't like adding options either, i think we need one to keep
user style persistent -- unless we're going to keep it always (which could be
just as bad with a fubar user stylesheet).
Sorry, I meant author sheets. Yes, of course, user and UA stylesheets would stay
enabled at all times.

Comment 84

14 years ago
Re: comment 81

> GD?

Gracefully degrade.

> So you want the user to try various options until they think the
> rendering is ok?  Come on.

They would only need to try one various option in the case I was referring to,
and that is the Use Style -> None that is the subject of this whole bug.  Which
is worse: not being able to read a page at all, or having an option making the
page readable?

> Because every option we add reduces overall usability.

How can a little extra item on the Use Style submenu possibly reduce the
usability of the whole of Mozilla, regardless of whether the user actually uses
the option?
>> So you want the user to try various options until they think the
>> rendering is ok?  Come on.
>
> They would only need to try one various option in the case I was referring to,
> and that is the Use Style -> None that is the subject of this whole bug.  
> Which is worse: not being able to read a page at all, or having an option 
> making the page readable?

I completely agree with the request for the feature to disable all author
styling. What I was diagreeing with is having the option to disable author
styling done by CSS but _not_ disabling author styling done by HTML.


>> Because every option we add reduces overall usability.
>
> How can a little extra item on the Use Style submenu possibly reduce the
> usability of the whole of Mozilla, regardless of whether the user actually 
> uses the option?

It's a basic fact of user interface design that every additional menu item
increases the time required by the user to decide which menu item to pick.

Comment 86

14 years ago
I'd like to mention the two big reasons I see on why this is really a legitimate
feature.

1) It's useful to advanced or disabled users, who have personal stylesheets. Try
setting text or/and background color on the user side and see how many pages are
now unreadable because they only set one or the other.

2) It's useful to developers (at least as much as JS or Java console) to make
sure their page is logicially laid out (section headers should still be <h1>/etc
regardless of how the page looks with style, and things like that).

This is assuming 'None' also removes old HTML styling. <font> and the like.
Otherwise it's not much use, at least for point (1), the more important of the
two IMO.

Also keep in mind this isn't adding a menu item, it's adding a sub-menu item,
which is a big difference.

I for one will be very sad to see the Mozilla-suite featureness attack the
Firebird UI, but the style menu is one addition I look forward to. Heck, doesn't
the spec require it?

Comment 87

14 years ago
BTW Opera 7.x has this feature: View | Style | User mode
*** Bug 215803 has been marked as a duplicate of this bug. ***
bz: Will your stylesheet loader work give us an easy way to do this? (Including
disabling author styles in the markup, such as <font> or <hr color>.)
No, that's pretty orthogonal to this rfe...

Updated

13 years ago
Blocks: 68416
*** Bug 233471 has been marked as a duplicate of this bug. ***
*** Bug 241139 has been marked as a duplicate of this bug. ***
Am I mistaken, or does Firefox already have this feature?  When I visit sites
that have stylesheets, I get a little selector widget in the left end of the
status bar that lets you choose between "No Style", "Basic Style", and the
author's stylesheet.  Is that something that was implemented specifically in
Firefox that didn't get backported to Mozilla?  Or am I looking at something else?
> choose between "No Style", "Basic Style", and the author's stylesheet

A vanilla firefox build (just downloaded today's nightly) has a slightly
different widget without the "No Style" option, so sounds like you have some
sort of extension installed (which doesn't do quite what we want to do, since it
can't possibly disable presentational attributes....)
Created attachment 146651 [details]
Firefox Theme widget

OK, here's what I was seeing.  I mis-remembered it, it says "Theme", not
"Style".  But there is a "No Theme" item, which when chosen does indeed get rid
of any formatting on the page that wasn't defined directly in the HTML.  The
"Basic Theme" item appears to honor fonts, but ignore colors.
Yeah, "No Theme" is not there in a vanilla nightly (and again, doesn't do what
we feel it should).
this is the 0416 nightly, and the only extension I have installed is UserAgent
Switcher.
It depends on what page is being displayed (and whether it has any persistent
sheets).
(Assignee)

Comment 99

13 years ago
bz, if one were to implement this, what is the interface function the Use Style
> None menu would call?
Assignee: dbaron → fantasai.bugs
There isn't such a function yet.  It'd have to be written.

Comment 101

13 years ago
We now have a menu option "use style". All we need to do is switch to an empty
stylesheet, no?
Felix, please read David Baron's comments on this bug.
(Assignee)

Comment 103

13 years ago
write the interface definition, please?
We haven't even quite decided what the function should do.

Once we have an idea of that, we could try to write an interface definition....
(what interface to put it in?  What should happen with subframes?)
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.8alpha2
(Assignee)

Comment 105

13 years ago
I'm disabling Doc and PresHint. Should this option disable Override as well?
It probably should disable override in case we ever implement
http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-DocumentCSS .  I think
override is currently used only by editor, though.  If you were to add disable
CSS UI to editor that would be a problem, but otherwise I don't think it would.
it should be possible to disable any HTML page provided styles and show the page
without any single <STYLE > tag or style="" parameter.
(Assignee)

Comment 108

13 years ago
Created attachment 152786 [details] [diff] [review]
patch
Attachment #68076 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #152786 - Flags: review?(dbaron)
nsIDOMDocumentStyle.idl claims it's frozen, as visible in your patch... that
means you should probably not change it.
(Assignee)

Comment 110

13 years ago
I'd have gone through some other interface, but adding that property has been
planned in bug 200930, so I figured I might as well add it now.
Frozen means you can't change it.

You need to add another interface that inherits from it and add to that instead.
 (This is often done by adding nsIDOMNS... to inherit from nsIDOM...)
(This also disables things like bgcolor="", <font>, etc, right?)
(Assignee)

Comment 113

13 years ago
(See comment #105. Would I write a patch that didn't?)
(Assignee)

Comment 114

13 years ago
Created attachment 153604 [details] [diff] [review]
patch

Added nsIDOM3DocumentStyle from bz's work on stylesheet switching interfaces
Attachment #152786 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #153604 - Flags: review?(dbaron)
(Assignee)

Updated

13 years ago
Attachment #152786 - Flags: review?(dbaron) → review-
Comment on attachment 153604 [details] [diff] [review]
patch

>+  //Enable/Disable entire author style level (Doc & PresHint levels)
>+  PRBool GetAuthorStyleDisabled();
>+  nsresult SetAuthorStyleDisabled(PRBool aStyleDisabled);

This could just return void.

>   PRUint16 mBatching;
> 
>   unsigned mInShutdown : 1;
>-  unsigned mDirty : 7;  // one dirty bit is used per sheet type
>+  unsigned mAuthorStyleDisabled;
>+  unsigned mDirty : 6;  // one dirty bit is used per sheet type

The default is 32 bits, so putting that in the middle there doesn't do what you
intended, I don't think.  That said, please don't change this to 6, even though
it could be now, since I'm adding a 7th in bug 252578.

You'll also have to merge the GatherRuleProcessors changes with bug 252578 if I
land first -- and it would probably be simpler to use an early return i.e.,
after the Clear(), just return if mAuthorStyleDisabled and the type is one of
the relevant types.  (I'm saying that knowing what the changes in bug 252578
look like.)

More later...
(In reply to comment #115)
> (From update of attachment 153604 [details] [diff] [review])
> >+  //Enable/Disable entire author style level (Doc & PresHint levels)
> >+  PRBool GetAuthorStyleDisabled();
> >+  nsresult SetAuthorStyleDisabled(PRBool aStyleDisabled);
> 
> This could just return void.

Actually, never mind.
Comment on attachment 153604 [details] [diff] [review]
patch

>+nsStyleSet::SetAuthorStyleDisabled(PRBool aStyleDisabled)
>+{
>+  if (aStyleDisabled != (PRBool)mAuthorStyleDisabled) {

Don't cast to PRBool; it doesn't help anything.

>+/**
>+ * The nsIDOM3DocumentStyle interface is an extension to the
>+ * nsIDOMDocumentStyle interface.  This interface exposes more ways to interact

If it's an extension, shouldn't it be nsIDOMNSDocumentStyle?

What happened to all the nsDocument changes in bz's patch in bug 200930?  The
preferredStyleSheet changes and the authorStyleDisabled stuff seem like two
different things that should be reviewed separately.  And the UI changes should
probably be reviewed as a third patch (or third and fourth, if separate for the
suite and Firefox).

Any chance you could attach a new patch addressing these (and previous)
comments to this bug, and a separate one to bug 200930 if that one needs
updating?  Other than that, the authorStyleDisabled part of this patch looks
fine.
(Assignee)

Comment 118

13 years ago
> If it's an extension, shouldn't it be nsIDOMNSDocumentStyle?

I haven't got a clue. I don't know anything about APIs, I'm just copying what bz
did in bug 200930. If there's something you want me to change about it, you need
to explain it.

> What happened to all the nsDocument changes in bz's patch in bug 200930?

Most of those changes are for adding document.selectedStylesheetSet support and
are therefore not relevant here.

> The preferredStyleSheet changes and the authorStyleDisabled stuff seem like
> two different things that should be reviewed separately.

Although it adds a new interface, the preferredStylesheet code changes are small
and they are necessary for a correct interface here. I don't see how separating
out the patch will help, it's just more work afaics.

As for not using bz's method of calling GetHeaderData to get the preferred style
set, I don't think it would work. The preferred style sheet is not always set
via HTTP headers.
See http://www.w3.org/TR/html40/present/styles.html#h-14.3.2

If you want to spend more time pondering the preferredStylesheetSet interface,
then I will file a new bug on it. But if you already know what the interface is
going to be, I don't see any point.

> And the UI changes should probably be reviewed as a third patch (or third and
> fourth, if separate for the suite and Firefox).

I will open a separate bug for the patch to Firefox trunk. The UI changes for
the Mozilla Suite are necessary in this patch because there's no other way to
test the changes! Besides, if the only way of doing that is for the user to make
an API call, then /this/ bug is definitely not fixed and will need a second
patch.
Target Milestone: mozilla1.8alpha2 → mozilla1.8alpha3
One other thing -- the JS changes make it look like you're removing the "Basic
Page Style" option whenever there are preferred sets.  This make sense, but if
so, perhaps the name should be "Page Style" instead?  Also, if you think the
code would be simpler if that option were created by the function that fills the
popup (and created only if there are no preferred/alternate sheets), then that
might be better (and more symmetric, since we're already doing that, and having
both that and display toggling might be confusing).
Comment on attachment 153604 [details] [diff] [review]
patch

>-          <menupopup onpopupshowing="stylesheetFillPopup(this);"
>-                     oncommand="stylesheetSwitchAll(window.content, event.target.getAttribute('data'));">
>-            <menuitem label="&useStyleSheetPersistentOnly.label;" accesskey="&useStyleSheetPersistentOnly.accesskey;" type="radio"/>
>+            <menuitem label="&useStyleSheetNone.label;" accesskey="&useStyleSheetNone.accesskey;" oncommand="setStyleDisabled(true);" type="radio"/>
I don't like you putting oncommand attribute on your dynamic menuitems. Please
add event.preventBubble(); here instead.
>+            <menuitem label="&useStyleSheetPersistentOnly.label;" accesskey="&useStyleSheetPersistentOnly.accesskey;"
>+                      oncommand="stylesheetSwitchAll(window.content, event.target.getAttribute('data'));" type="radio"/>

>-  itemNoOptStyles.setAttribute("checked", noOptionalStyles);
>+  menuPopup.firstChild.setAttribute("checked", styleDisabled);
>+  itemPersistentOnly.setAttribute("checked", !altStyleSelected && !styleDisabled);
Why can't you keep using the noOptionalStyles variable? Also you didn't remove
all references to it.

>+  if (window.content.document.preferredStylesheetSet) {
>+    itemPersistentOnly.style.display = "none";
>+  }
>+  else {
>+    itemPersistentOnly.style.display = "";
>+  }
We have to use .hidden = <boolean> here to play nicely with the Mac whose
menubar doesn't use CSS, although in general we like to use attributes and
stylesheets (.hidden = true; invokes a style rule in xul.css) rather than
inline style.

> function stylesheetSwitchAll(frameset, title) {
>+  setStyleDisabled(false);
This is a recursive function so this isn't a good place to add code. As you'll
be moving the oncommand handler back to the menupopup you could add it there.
Additionally I would have thought that enabling style after instead of before
selecting the stylesheet would reduce the amount of style resolving.
>   if (!title || stylesheetInFrame(frameset, title)) {
>     stylesheetSwitchFrame(frameset, title);
>   }
>   for (var i = 0; i < frameset.frames.length; i++) {
>     stylesheetSwitchAll(frameset.frames[i], title);
>   }
> }
(In reply to comment #120)
> >-  itemNoOptStyles.setAttribute("checked", noOptionalStyles);
> >+  menuPopup.firstChild.setAttribute("checked", styleDisabled);
> >+  itemPersistentOnly.setAttribute("checked", !altStyleSelected &&
!styleDisabled);
> Why can't you keep using the noOptionalStyles variable? Also you didn't remove
> all references to it.

It's just a rename of the same thing to be more consistent with other parts of
the code.
(Assignee)

Comment 122

13 years ago
Created attachment 154923 [details] [diff] [review]
patch
Attachment #153604 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #154923 - Flags: superreview?(dbaron)
Attachment #154923 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 154923 [details] [diff] [review]
patch

>Index: mozilla/content/base/src/nsStyleSet.h
>   unsigned mInShutdown : 1;
>-  unsigned mDirty : 7;  // one dirty bit is used per sheet type
>+  unsigned mAuthorStyleDisabled: 1;
>+  unsigned mDirty : 6;  // one dirty bit is used per sheet type

We need 7 bits here, so you can't use 6.

>Index: mozilla/content/base/src/nsStyleSet.cpp
> nsresult
> nsStyleSet::GatherRuleProcessors(sheetType aType)
> {
>   mRuleProcessors[aType] = nsnull;
>+  if (mAuthorStyleDisabled && (aType == eDocSheet || aType == ePresHintSheet)) {
>+    //don't regather if this level is disabled
>+    return NS_OK;
>+  }

You need to check eHTMLPresHintSheet and eStyleAttrSheet as well.

>+nsresult
>+nsStyleSet::SetAuthorStyleDisabled(PRBool aStyleDisabled)
>+{
>+  if (aStyleDisabled != mAuthorStyleDisabled) {
>+    mAuthorStyleDisabled = aStyleDisabled;
>+    if (!mBatching) {
>+      nsresult rv;
>+      rv = GatherRuleProcessors(eDocSheet);
>+      if (NS_FAILED(rv)) return rv;
>+      rv = GatherRuleProcessors(ePresHintSheet);
>+      if (NS_FAILED(rv)) return rv;
>+    }
>+    else {
>+      mDirty |= 1 << eDocSheet;
>+      mDirty |= 1 << ePresHintSheet;
>+    }
>+  }
>+  return NS_OK;
>+}

Likewise here.	Perhaps it's worth having an array:

static const nsStyleSet::sheetType authorTypes = {
  ePresHintSheet,
  eHTMLPresHintSheet,
  eDocSheet,
  eStyleAttrSheet
};

and iterating through that array in both these places, e.g. (for the first):

// don't regather if author style is disabled
if (mAuthorStyleDisabled)
  for (const nsStyleSet::sheetType *type = authorTypes,
			       *type_end = authorTypes +
NS_ARRAY_LENGTH(authorTypes);
       type < type_end; ++type)
    if (*type == aType)
      return NS_OK;

although perhaps it's not worth it for just 4 entries.	(I wonder which one
generates less code.)

>Index: mozilla/dom/public/idl/stylesheets/nsIDOMNSDocumentStyle.idl
>+ * The nsIDOM3DocumentStyle interface is an extension to the

The comment should match the name.

With those changes, sr=dbaron.
(Assignee)

Comment 124

13 years ago
Created attachment 154939 [details] [diff] [review]
patch
(Assignee)

Updated

13 years ago
Attachment #154923 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #154939 - Flags: superreview?(dbaron)
Attachment #154939 - Flags: review?(neil.parkwaycc.co.uk)
(Assignee)

Updated

13 years ago
Attachment #154923 - Flags: superreview?(dbaron)
Attachment #154923 - Flags: superreview-
Attachment #154923 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #154923 - Flags: review-
(Assignee)

Updated

13 years ago
Attachment #153604 - Flags: review?(dbaron)
(Assignee)

Updated

13 years ago
Attachment #154939 - Flags: superreview?(dbaron)
Attachment #154939 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #154939 - Flags: review-
(Assignee)

Comment 125

13 years ago
Created attachment 154942 [details] [diff] [review]
patch
Attachment #154939 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #154942 - Flags: superreview?(dbaron)
Attachment #154942 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 154942 [details] [diff] [review]
patch

I was surprised that turning all style off also affected mapped attributes.
Anyway, I was originally unsure how this was supposed to work, but now I see
that "None" means no CSS at all while "Default Style" means that there were no
named regular stylesheets.
Attachment #154942 - Flags: review?(neil.parkwaycc.co.uk) → review+
Comment on attachment 154942 [details] [diff] [review]
patch

>Index: mozilla/content/base/src/nsStyleSet.h
>-  unsigned mDirty : 7;  // one dirty bit is used per sheet type
>+  unsigned mAuthorStyleDisabled: 1;
>+  unsigned mDirty : 14;  // one dirty bit is used per sheet type

Just leave it at 7, since that shows what we need.


>Index: mozilla/content/base/src/nsStyleSet.cpp
>+nsresult
>+nsStyleSet::SetAuthorStyleDisabled(PRBool aStyleDisabled)
>+{
>+  if (aStyleDisabled != mAuthorStyleDisabled) {
>+    mAuthorStyleDisabled = aStyleDisabled;
>+    if (!mBatching) {
>+      nsresult rv;
>+      rv = GatherRuleProcessors(eDocSheet);
>+      if (NS_FAILED(rv)) return rv;
>+      rv = GatherRuleProcessors(ePresHintSheet);
>+      if (NS_FAILED(rv)) return rv;
>+      rv = GatherRuleProcessors(eHTMLPresHintSheet);
>+      if (NS_FAILED(rv)) return rv;
>+      rv = GatherRuleProcessors(eHTMLPresHintSheet);
>+      if (NS_FAILED(rv)) return rv;
>+    }
>+    else {
>+      mDirty |= 1 << eDocSheet;
>+      mDirty |= 1 << ePresHintSheet;
>+      mDirty |= 1 << eHTMLPresHintSheet;
>+      mDirty |= 1 << eStyleAttrSheet;
>+    }
>+  }
>+  return NS_OK;

I just realized a way to simplify this a good bit:

  if (aStyleDisabled != mAuthorStyleDisabled) {
    mAuthorStyleDisabled = aStyleDisabled;
    BeginUpdate();
    mDirty |= 1 << eDocSheet |
	      1 << ePresHintSheet |
	      1 << eHTMLPresHintSheet |
	      1 << eStyleAttrSheet;
    EndUpdate();
  }
  return NS_OK;

With that, sr=dbaron.
Attachment #154942 - Flags: superreview?(dbaron) → superreview+
... except that the return value from EndUpdate should be propagated, i.e.,
|nsresult rv = NS_OK;| at the start of the function, |rv = EndUpdate();| instead
of just |EndUpdate();|, and |return rv;| instead of |return NS_OK;|.
(Assignee)

Comment 129

13 years ago
Created attachment 155203 [details] [diff] [review]
final patch
Attachment #154942 - Attachment is obsolete: true
(In reply to comment #118)
> As for not using bz's method of calling GetHeaderData to get the preferred style
> set, I don't think it would work. The preferred style sheet is not always set
> via HTTP headers.

But the headerDefaultStyle header data is always set to the preferred style
sheet. If it didn't work, you need to file a bug. There was no need for
GetPreferredSheet on the CSS loader IMHO.

The license on nsIDOMNSDocumentStyle.idl references the NPL, please use the
MPL/GPL/LGPL boilerplate
(http://www.mozilla.org/MPL/boilerplate-1.1/mpl-tri-license-c) when adding new
files.

Comment 131

13 years ago
The error came out by build of Camino.
Mac OS X 10.3.4

make[7]: Entering directory
`/Users/sek/Documents/mozilla-current/camino/mozilla/dom/public/idl/stylesheets'
/Users/sek/Documents/mozilla-current/camino/mozilla/config/nsinstall -L
/Users/sek/Documents/mozilla-current/camino/mozilla/dom/public/idl/stylesheets
-m 644 nsIDOMLinkStyle.idl ../../../../dist/idl
/Users/sek/Documents/mozilla-current/camino/mozilla/config/nsinstall -L
/Users/sek/Documents/mozilla-current/camino/mozilla/dom/public/idl/stylesheets
-m 644 _xpidlgen/nsIDOMLinkStyle.h ../../../../dist/include/dom
/usr/bin/perl -I../../../../config ../../../../config/build-list.pl
../../../../dist/include/dom/.headerlist nsIDOMLinkStyle.h
make[7]: *** No rule to make target `nsIDOMNSDocumentStyle.idl', needed by
`export'.  Stop.
make[7]: Leaving directory
`/Users/sek/Documents/mozilla-current/camino/mozilla/dom/public/idl/stylesheets'
make[6]: *** [export] Error 2
(Assignee)

Comment 132

13 years ago
If the defaultStyle header *is* set by the configuration of <link> elements,
/then/ I'd probably have to file a bug. <link> elements shouldn't set HTTP
headers. And if they are, then we're probably violating HTML 4.

http://www.w3.org/TR/html40/present/styles.html#h-14.3.2
  # If two or more META declarations or HTTP headers specify the preferred
  # style sheet, the last one takes precedence. HTTP headers are considered
  # to occur earlier than the document HEAD for this purpose.
  #
  # If two or more LINK elements specify a preferred style sheet, the first
  # one takes precedence.
  #
  # Preferred style sheets specified with META or HTTP headers have precedence
  # over those specified with the LINK element."

How would we implement that if a default style set with a LINK element gets
treated the same as a meta tag with an HTTP header?
They are not treated the same, but they all set the headerDefaultStyle header
data. There could very well be bugs there, that still doesn't justify
GetPreferredSheet on the CSS loader. If our existing API really is broken you
did nothing to fix it, you just added another API to get the same bad value.
(Assignee)

Comment 134

13 years ago
-> bug 254445
marking this fixed. Tinderbox is in flames because cvs-mirror is out of sync 
with cvs.

Updated

13 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Assignee)

Updated

13 years ago
Blocks: 253332

Comment 135

13 years ago
It looks like nsIMarkupDocumentViewer was changed without modifying the UUID of
the interface.  Sure, it's a private interface, but you never know if some wacky
extension or embedder may be using this interface for some random reason. 
Better to always modify interface UUIDs when modifying interfaces.  Otherwise,
you give those who need to use this interface no hope of doing so across browser
versions.
(In reply to comment #135)
> It looks like nsIMarkupDocumentViewer was changed without modifying the UUID of
> the interface.

I just checked in a patch to change the uuid. unfortunately alpha3 was released
with the old UUID, but ah well, it's only an alpha.

Comment 137

13 years ago
*** Bug 264859 has been marked as a duplicate of this bug. ***
while netscape4.8 is able to show html pages when offline (lacking the css which
points to a net adress) if you disable the css use, Mozilla 2005013106 is not,
regardless if you choose View-Use Style-None or not.

Updated

12 years ago
Blocks: 318175
So why was this _experimental_ interface added to SDK_XPIDLSRCS?  And given that I need to change it if I'm going to reasonably implement the WHATWG proposal for this stuff, where do we go from here?

I'm tempted to move it out of SDK_XPIDLSRCS, frankly.  Except I suspect that's not kosher.  :(
Yikes.  I suppose if you have to, you can just leave it and not implement it anymore.  Although not being able to use the name anymore is annoying.
So the current WHATWG proposal would just extend this interface.  I suppose I could create nsIDOMNSDocumentStyle2 and inherit from nsIDOMNSDocumentStyle...
(Assignee)

Comment 142

11 years ago
I'd call it nsIDOMNSDocumentStyleSets over nsIDOMNSDocumentStyle2
(In reply to comment #142)
> I'd call it nsIDOMNSDocumentStyleSets over nsIDOMNSDocumentStyle2

Agreed ! Please, please don't run into the MS way of numbering new interfaces...
> I'd call it nsIDOMNSDocumentStyleSets over nsIDOMNSDocumentStyle2

How would someone looking at the WHATWG spec (where the interface is DocumentStyle) find that?  I don't like the numbering that much, but it's the only sane choice when the DOM or WHATWG folks add stuff to interfaces that are already frozen.

Note the discussion in mozilla.dev.platform, btw.  I'm still tempted to just move this interface back out of SDK_XPIDLSRCS.

Comment 145

11 years ago
The interface name only affects C++ consumers at least.  We've been using numbering for other DOM interfaces (e.g., nsIDOM3Node anyone?).

Comment 146

11 years ago
nsIDOMWindow2 is probably a better example of my point than nsIDOM3Node fwiw.
You need to log in before you can comment on or make changes to this bug.