Closed Bug 21552 Opened 25 years ago Closed 24 years ago

'-moz-border-outer' CSS properties

Categories

(Core :: CSS Parsing and Computation, enhancement, P3)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows 95
Type:
enhancement

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: bugs, Assigned: trudelle)

Details

(Keywords: css-moz) 

Rationale:

To be able to design reasonable looking UI, an extra level of border (an exact
clone of 'border', but drawing around the outside of any border an element may
have) is really necessary.

Currently, we have a single border layer, which is insufficient to create
desirable chrome widget "depth" - e.g. look at command buttons on windows. The
inner border of such buttons is 'buttonhighlight' on the top and left and
'buttonshadow' on the bottom an right. the outer border is 'buttonface' on the
topleft, and 'threeddarkshadow' on the bottomright. these colours are also used
in other windows widgets, like menupopups, text fields, etc. The system is
similar with Qt. Mac widgets offer even more detail, but much of that could be
difficult to implement - all that is necessary is an extra level of border to
give widgets and other frames, like content regions, more depth and make the UI
look more like a real app.

Proposed Solution:-

a moz-css extension called '-moz-border-outer' (or similar)
it is /exact/ clone of regular css 'border' except it is drawn around the
outside of the regular border. It supports the full set of border
sub-properties:

-moz-border-outer-style
-moz-border-outer-top

etc.

(I'm filing this just in case its really easy to do, and someone who knows this
part of the code has a burning desire to include such a feature ;)
Severity: normal → enhancement
Assignee: pierre → shuang
Component: Style System → UE/UI
Reassigning to the owner of UE/UI to get more opinions: do we need a new CSS

property to make the UI look more like a real app? If yes, reassign to myself

otherwise just close as WontFix. My opinion is that there is nothing that is

described here that we cannot do now.
note: the extra borders cannot be achieved simply by using CSS. You could use
'outline' I suppose, but its not really designed for that and may have other
uses.

one can achieve the extra level of detail by wrapping the appropriate elements
in another frame, but that introduces xul dependency into skins, which is Wrong.
Summary: [RFE][moz-css] '-moz-border-outer' CSS property → [RFE] {moz-css} '-moz-border-outer' CSS properties
I have actually proposed to the www-style newsgroup an extension to do just
this. It is the pseudo-element :outside. This is just an box which wraps the
element in question and which can be given background, color, size, and so on.

So you could do the -moz-border-outer stuff like this:

   button         { border: solid white; }
   button:outside { border: solid aqua; }

There are many technical problems to this. The discussion can be found here:
   http://lists.w3.org/Archives/Public/www-style/1999Feb/0021.html

If a -moz-border-outer set of properties is introduced, then interaction with
the box model should be VERY carefully examined.
Assignee: shuang → german
reassign it to german to make decision or point to proper spec.
Hmmm, I think Hyatt should own this bug since it has to do with the
implementation of widgets, frames, etc.  This has nothing to do with the design
or appearance of the current Netscape-specific or mozilla.org chrome.  It's all
about making it easier to do other skins.  Hyatt (or Trudelle :-) can decide
whether he has the time for this.
Assignee: german → trudelle
Actually I do not think we need this, or it is very low priority. I believe the
combination of both CSS borders (with variable width and styles) and CSS
outlines is sufficient to replicate most known look and feel variations. As for
the new default look and feel for Netscape, once outline works as spec'd in CSS,
we will not need an extra attribute. We should attempt to make CSS stuff work
properly first. Peter? David?
I would strongly suggest that if it is not really necessary then we forget
about it (WONTFIX) and wait for CSS to have a standard, well specified way of
doing this. Otherwise, once CSS does spec this, we will have to support both
this and the new, official way, and all sorts of evil problems will ensue.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
resolving as later
you're right, this is not urgent. Please do not mark this "WONTFIX" for
standardisation reasons. This is intended to be an extension to proprietary
moz-css, rather than an addition to plain-vanilla CSS, and for use internally to
Mozilla only for widget appearance.

It'd be cool to get this done some time in the future as even though the current
skin does not require it, we'd like to provide more flexibility to skin authors.
Status: RESOLVED → VERIFIED
Verified LATER
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
This is now being asked again in bug 29523...
Component: User Interface: Design Feedback → Style System
Keywords: css-moz
Summary: [RFE] {moz-css} '-moz-border-outer' CSS properties → '-moz-border-outer' CSS properties
reopening all latered bugs
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Moving all latered bugs to M20 as ordered by project manager.  Although these 
bugs are now open, assigned and targetted, XPToolkit has no plans to 
fix/implement them in the current release cycle, if ever.
Target Milestone: --- → M20
Status: REOPENED → ASSIGNED
peter, we probably don't need this now we have XBL (at least not in XUL - if 
HTML supported XBL then we'd not need it there either).

Since XBL offers a good interim solution, I propose gecko just implement 
'outline' properly, which is in the standard, and offers what is needed in both 
places ;) 
Mass move of all M20 bugs to M30.
Target Milestone: M20 → M30
Mass moving M20 bugs to M30
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
As per meeting with ChrisD yesterday, taking QA.

Noting the comments from Ben Goodger 2000-04-01 18:42, should we WONTFIX this?
It is a non-standard extension that we do not need, and we have much more 
important issues to look at.
QA Contact: chrisd → py8ieh=bugzilla
> Noting the comments from Ben Goodger 2000-04-01 18:42,
> should we WONTFIX this?
> It is a non-standard extension that we do not need,
> and we have much more important issues to look at.

Well, *if* it's implemented, it ordinary web pages shouldn't be able to use it, only themes should (this goes for all -moz extensions).
I agree this can be wontfixed.
I disagree that webpages should be disallowed from using -moz extensions. Being 
a standards compliant web browser does not remove our right to innovate. 
Furthermore, IIRC (well, someone told me this) that it was legal to extend with 
-vndname-propertyname, hence -moz-border-radius and so on.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WONTFIX
VERIFIED WONTFIX. Excellent. :-)

And yeah, CSS3 will (apparently) say something about the -vnd-extension syntax.
Status: RESOLVED → VERIFIED
> I disagree that webpages should be disallowed from
> using -moz extensions. Being
> a standards compliant web browser does not
> remove our right to innovate.

In the same way that Netscape "innovated" when it created the 'layer' element?

> Furthermore, IIRC (well, someone told me this) that it
> was legal to extend with -vndname-propertyname,
> hence -moz-border-radius and so on.

It's not. At least the W3C stylesheet validator thinks it isn't, and reports a 'parse error' (this is not the same thing as a 'unknown property error, which also exists). I've tried reading the formal CSS 2 grammar, but was only left confused ... :/

But I've heard it should be included as part of CSS 3 (though I don't know how reliable the source is).
Karl: Innovation is fine, so long as the standards work. Particularly in our
case, where we need some things for the UI which are not in any standard yet.
So long as they don't interfere with any standard, past or future, then there
is no problem. This is why the CSS WG have discussed the -vnd-* syntax for
extensions. 

The CSS Validator doesn't recognise those properties since they are invalid 
CSS2 -- but the whole point is that they will ALWAYS be invalid CSS, and there
will never be a case where -vnd-x clashes with a standard property.

This has been discussed in the CSS Working Group, which is as official as you
get without a published document.

Anyway. Let's move this discussion to a more appropriate forum like 
mozilla-general or #mozillazine.
You need to log in before you can comment on or make changes to this bug.