| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
| |
This existed in Firefox before this bug.
I don't know if it came from a previous bug or was removed post-fork.
|
| |
|
|
|
|
|
|
|
| |
https://bugzilla.mozilla.org/show_bug.cgi?id=1547792
Aspect Ratio handling simplified by using floating point integers:
- Multiplication of value (or inverse value) to a known side for Scaling
- No unequal equal values such as "4/3" vs "8/6" vs "20/15"
- Truly "Empty" aspect ratios, even if one dimension is not 0
|
| |
|
|
|
|
|
|
|
|
| |
columns
Before issue #146, border-radius on row groups, rows, column groups, or columns don't apply to the background of each cell, yet the border-radius on the cell itself does.
After issue #146, the behaviors changed. In this patch, I tried to revert the behaviors of border-radius on table row groups, rows, column groups, or columns back to what happened before issue #146.
Also: Don't override GetBorderRadii in nsBCTableCellFrame.
|
| |
|
|
| |
Dispense the shared hashtable and instead attach the frame property list directly to nsIFrame.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This causes transparent stops to behave like "true transparent" instead
of "transparent black", even in RGBA space.
i.e.: the gradient will transition to a transparent version of the color
adjacent to the transparent color stop (on either side if not on the edge).
|
| | |
|
| |
|
