Last Comment Bug 141397 - Ensure Mozilla extensions begin with -moz-
: Ensure Mozilla extensions begin with -moz-
: fixed1.7
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: mozilla1.7final
Assigned To: David Baron :dbaron: ⌚️UTC-10
: Jet Villegas (:jet)
Depends on:
  Show dependency treegraph
Reported: 2002-04-30 21:18 PDT by David Baron :dbaron: ⌚️UTC-10
Modified: 2011-11-17 13:57 PST (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch for :first-node and :last-node (checked in to trunk, 2004-04-07 16:25 -0700) (13.65 KB, patch)
2004-04-05 15:10 PDT, David Baron :dbaron: ⌚️UTC-10
bzbarsky: review+
bzbarsky: superreview+
chofmann: approval1.7+
Details | Diff | Splinter Review

Description David Baron :dbaron: ⌚️UTC-10 2002-04-30 21:18:59 PDT
This is intended to be a semipermanent bug that gets dealt with every few
milestones but never gets marked fixed.  It is, in a sense, a continuation of
bug 3935.

We should continue to audit the CSS properties, values, units, pseudo-classes,
and pseudo-elements that Mozilla supports to make sure that all extensions begin
with -moz-, and to ensure that properties that we don't support correctly are
disabled or changed to -moz-.

Given more testing or the stabilization of CSS3 drafts (to CR, or perhaps
late-stage WD if they're known to be stable), we can also start adding support
for non -moz-ed keywords back in (e.g., 'inline-table' and 'inline-block', if
they're tested and bugs are fixed).  We can add this easily for keywords while
keeping the -moz- support by duplicating keywords in nsCSSProps.cpp (with care
as to the order).  I'd need to look at how to do it for properties, but I think
it can be done without too much difficulty.

The current issues I can think of off the top of my head, from bug 3935, are
that we support a bunch of CSS3 selectors and 'text-align: start', and also
support one unit without -moz- (I think 'ch').
Comment 1 Madhur Bhatia 2002-05-17 14:30:20 PDT
cc'ing myself
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2003-11-08 14:05:21 PST
Are there any cases still in need of fixing that we know of?
Comment 3 David Baron :dbaron: ⌚️UTC-10 2004-04-05 15:08:00 PDT
I just noticed :first-node and :last-node.
Comment 4 David Baron :dbaron: ⌚️UTC-10 2004-04-05 15:10:52 PDT
Created attachment 145508 [details] [diff] [review]
patch for :first-node and :last-node (checked in to trunk, 2004-04-07 16:25 -0700)
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2004-04-05 15:20:26 PDT
Comment on attachment 145508 [details] [diff] [review]
patch for :first-node and :last-node (checked in to trunk, 2004-04-07 16:25 -0700)

Comment 6 David Baron :dbaron: ⌚️UTC-10 2004-04-05 18:13:48 PDT
Comment on attachment 145508 [details] [diff] [review]
patch for :first-node and :last-node (checked in to trunk, 2004-04-07 16:25 -0700)

This should have been fixed as part of a Mozilla1.0 blocker (bug 3935).
Comment 7 chris hofmann 2004-04-05 18:29:52 PDT
Comment on attachment 145508 [details] [diff] [review]
patch for :first-node and :last-node (checked in to trunk, 2004-04-07 16:25 -0700)

a=chofmann for 1.7
Comment 8 Kai de Leeuw 2004-04-07 23:38:50 PDT
shouldn't this bug be marked as RESOLVED FIXED?
Comment 9 David Baron :dbaron: ⌚️UTC-10 2004-04-08 01:08:08 PDT
No.  Read comment 0.  And in general, read comment 0 on any bug before
commenting on it.
Comment 10 David Baron :dbaron: ⌚️UTC-10 2011-11-17 13:57:22 PST
I think having a bug open on this is no longer useful.  I think we've been pretty good about ensuring this as part of the review process.

Note You need to log in before you can comment on or make changes to this bug.