Closed
Bug 730780
Opened 13 years ago
Closed 13 years ago
-moz-border-radius not good enough no more, need border-radius, too
Categories
(Webtools Graveyard :: Elmo, defect, P1)
Webtools Graveyard
Elmo
Tracking
(Not tracked)
RESOLVED
FIXED
2.1
People
(Reporter: Pike, Assigned: peterbe)
Details
Attachments
(1 file, 1 obsolete file)
5.07 KB,
patch
|
Pike
:
review+
|
Details | Diff | Splinter Review |
Nightlies stopped supporting moz-border-radius, it seems, we should add border-radius everywhere.
I think we should fix this on master, too. Not sure if a hotfix merges well, but might be worth a try.
Assignee | ||
Comment 1•13 years ago
|
||
Attachment #601005 -
Flags: review?(l10n)
Reporter | ||
Comment 2•13 years ago
|
||
Comment on attachment 601005 [details] [diff] [review]
done
Review of attachment 601005 [details] [diff] [review]:
-----------------------------------------------------------------
Can you attach a diff -w for snippet.css? That's hard to review as it is right now.
::: apps/l10nstats/templates/l10nstats/grid.html
@@ +1,2 @@
> +<!-- IS THIS TEMPLATE OBSOLETE?? -->
> +
Remove this comment, and just file a bug on it? Yes, it should be obsolete.
::: static/css/style.css
@@ -393,5 @@
> }
> -/* moved gradient from roe to cell level */
> -#policy_versions td {
> - background-image: -moz-linear-gradient(center top , white, #EEEEEE);
> -}
This was just duplicated?
Assignee | ||
Comment 3•13 years ago
|
||
Attachment #601005 -
Attachment is obsolete: true
Attachment #603034 -
Flags: review?(l10n)
Attachment #601005 -
Flags: review?(l10n)
Assignee | ||
Comment 4•13 years ago
|
||
(In reply to Axel Hecht [:Pike] from comment #2)
> Comment on attachment 601005 [details] [diff] [review]
> done
>
> Review of attachment 601005 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> Can you attach a diff -w for snippet.css? That's hard to review as it is
> right now.
>
Done.
Note: A lot of the whitespace changes were deliberate. Some of it is trailing whitespace cleanup but I also corrected some general identation.
> ::: apps/l10nstats/templates/l10nstats/grid.html
> @@ +1,2 @@
> > +<!-- IS THIS TEMPLATE OBSOLETE?? -->
> > +
>
> Remove this comment, and just file a bug on it? Yes, it should be obsolete.
>
https://bugzilla.mozilla.org/show_bug.cgi?id=733118
> ::: static/css/style.css
> @@ -393,5 @@
> > }
> > -/* moved gradient from roe to cell level */
> > -#policy_versions td {
> > - background-image: -moz-linear-gradient(center top , white, #EEEEEE);
> > -}
>
> This was just duplicated?
Yeah. A little remnant from the days of trying to get Schalk productive with our code.
Reporter | ||
Updated•13 years ago
|
Attachment #603034 -
Flags: review?(l10n) → review+
Comment 5•13 years ago
|
||
> background-image: linear-gradient(center top , white, #EEEEEE);
linear-gradient syntax was been changed again. It should be:
background-image: linear-gradient(to bottom, white, #EEEEEE);
Or simply:
background-image: linear-gradient(white, #EEEEEE);
It's more prefereable not to write the unprefixed version at all. In general, you should not introduce potential incompatibilities like this.
https://developer.mozilla.org/en/Web_development/Writing_forward-compatible_websites#Don%27t_use_unprefixed_versions_of_CSS_properties_or_APIs_until_at_least_one_browser_supports_them
> Don't use unprefixed versions of CSS properties or APIs until at least
> one browser supports them
> Until there's decently widespread support of the unprefixed version of
> something, its behavior can still change in unexpected ways. Most
> especially, don't use the unprefixed version if no browser actually
> supports it. You can't assume that the syntax of the final version will
> be the same as the syntax of any of the prefixed versions.
At present no browsers support unprefixed gradients.
Reporter | ||
Comment 6•13 years ago
|
||
Sounds like I should turn my r+ into an r+ with :emk's nits :-)
Assignee | ||
Comment 7•13 years ago
|
||
:emk
I'm sorry but I'm struggling to understand what your point is.
So we currently have this: http://hastebin.com/docemifilo.css
Are you suggesting we drop the non-vendor-prefixed selector?
Comment 8•13 years ago
|
||
(In reply to Peter Bengtsson [:peterbe] from comment #7)
> :emk
> I'm sorry but I'm struggling to understand what your point is.
> So we currently have this: http://hastebin.com/docemifilo.css
> Are you suggesting we drop the non-vendor-prefixed selector?
I recommend dropping the unprefixed declaration, but if you leave it, update to the latest spec, at least.
Reporter | ||
Comment 9•13 years ago
|
||
Just realizing that it'd be great to get this tweaked and landed, too.
Assignee | ||
Comment 10•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•13 years ago
|
Assignee: nobody → peterbe
Target Milestone: --- → 2.1
Updated•5 years ago
|
Product: Webtools → Webtools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•