Intent to unship: XUL grid implementation

[Tim Nguyen]

Hi folks,

Thanks to Mats Palmgren & Rares Doghi, XUL grid got removed from tab prompts

(`alert`/`confirm`/`prompt`) last week, this was the last usage in
mozilla-central. If you notice any regressions, please file a bug and mark
it as a regression of bug 1583696
.

All other XUL grid removals have baked for a year now.

With that being said, I'm planning to unship the XUL grid implementation in
Firefox 85 in bug 1525737
, which includes:

   - the whole layout/xul/grid directory
   
   - the -moz-grid/-moz-grid-group/-moz-grid-line CSS display values
   - the // XUL elements

If you need grid-like functionality, alternatives are CSS grid or HTML
tables.
Please let me know if you have any concerns or questions.

Cheers,
Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: CSS conic-gradient

[Tim Nguyen]

Summary: CSS conic-gradients allow developers to specify gradients that
start from a certain angle where color stops are placed around the
circumference of a circle centered around a specified point.

Thanks to my friend Mohamed's work on Direct2D
, full Windows
support is now available, so this can now be enabled by default everywhere.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=conic-gradients

Standard: https://drafts.csswg.org/css-images-4/#conic-gradients

Target Release: 83

Platform coverage: All, but printing support will arrive after Cairo support
.

Preference for feature: On by default (layout.css.conic-gradient.enabled)

DevTools bug:

   - Output parser support (angle/color swatches) was done in bug 1621794
   
   - CSS autocomplete works
   - Prototype for a linear-gradient visualizer was done in bug 1364380
    as pointed out by
   Patrick in the last email thread

Other browsers: shipped since Chrome 69, Safari 12.1, Edge 79 and Opera 64

web-platform-tests:
https://searchfox.org/mozilla-central/search?q=conic-gradient=false=false=testing%2Fweb-platform
Many parsing tests along with few rendering tests were already there,
although many were added at the beginning of the year in bug 1616986
.

Restricted to secure contexts: No, CSS features are usually not restricted
to secure contexts

Is this feature enabled by default in sandboxed iframes? Yes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Removing the XUL grid implementation

[Tim Nguyen]

Hello folks,

After a year of work, all XUL grid usages have been removed from Firefox!
The Thunderbird team also has been doing a lot of hard work on their side.

This means the XUL grid implementation can now be removed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1525737

I'm planning to remove the XUL grid implementation at the beginning of the
Firefox 78 cycle to leave time to address potential regressions from the last
removal  and for the
Thunderbird team to remove their last usage
.

Thanks to everyone who reviewed my grid removal patches and to Daniel
Holbert and Emilio Cobos Àlvarez for the platform work that made this
possible!

Please let me know if you have any questions or concerns.

Cheers,
Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: CSS conic-gradient

[Tim Nguyen]

Summary: CSS conic-gradients allow developers to specify gradients that
start from a certain angle where color stops are placed around the
circumference of a circle centered around a specified point.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=conic-gradients

Standard: https://drafts.csswg.org/css-images-4/#conic-gradients

Target Release: 75-76

Platform coverage: All, initially WebRender only (though it shouldn't be
long until it's implemented for other backends)

Preference behind which this will be implemented:
layout.css.conic-gradient.enabled,
turned off by default until it's implemented outside of WebRender

DevTools bug: n/a, devtools could potentially add a gradient editor, but
that's also applicable to linear/radial gradients

Other browsers: shipped since Chrome 69, Safari 12.1, Edge 79 and Opera 64

web-platform-tests:
https://searchfox.org/mozilla-central/search?q=conic-gradient=false=false=testing%2Fweb-platform

Restricted to secure contexts: No, CSS features are usually not restricted
to secure contexts

Is this feature enabled by default in sandboxed iframes?  Yes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: nsStackFrame aka. `display: -moz-stack` and related features

[Tim Nguyen]

Hi folks,

I’m planning to remove nsStackFrame in bug 1576946 [0]. This is part of a
larger effort to make the browser stop using XUL layouts and align on more
standard CSS layouts such as CSS grid or flexbox instead. The removal is
targeted for Firefox 72.

The removal includes these two non web-exposed features:
- `display: -moz-stack` and the `-moz-stack-sizing` property
- support for XUL absolute positioning attributes
(left/top/bottom/right/start/end XUL attributes), that only worked in
display: -moz-stack contexts

Note that the  element is not going away. It will instead be
implemented using a single-area CSS grid, so those usages won’t need to be
rewritten. However, if you were planning to use XUL absolute positioning
attributes, you’ll need to look into alternatives:
- `align-self: start` or `align-self: end` can be used to position the
element on the vertical axis if you were using `top="0"` or `bottom="0"`
- `justify-self: start` or `justify-self: end` can be used to position the
element on the horizontal axis if you were using `start="0"` or `end="0"`
- If you were using non-zero values in the attributes and the element is
using `display: block;` or a non-XUL block-level display value, you can use
CSS absolute positioning instead.
- If you were using non-zero values in the attributes with a XUL display
value, you can use a combination of `margin` and
`justify-self`/`align-self`, see this code change [1] as a reference.

Regarding `-moz-stack-sizing`, this property was used to determine whether
a certain element would influence the size of its parent. The current
usages in mozilla-central were only used for children of  [2] and
those usages didn’t seem to change visually with the new CSS grid-based
implementation of  which ignores the `-moz-stack-sizing` property,
so it made sense to remove it.

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1576946
[1]: https://i.imgur.com/8hUDUDS.png
[2]:
https://searchfox.org/mozilla-central/search?q=-moz-stack-sizing=false=false=

Cheers,
Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Intent to change] display: -moz-box elements will no longer be forced to display: block (browser chrome only)

[Tim Nguyen]

Hi everyone,

We plan to soon land a change behind a pref [0] where we’ll stop
“blockifiying” elements with `display: -moz-box`. Before this change,
elements with `display: -moz-box` are forced to `display: block` when the
element:

  1. Is a child of a CSS grid or CSS flex container
  2. Has position absolute or fixed
  3. Is floated

This change will land behind a preference initially
(layout.css.xul-box-display-values.survive-blockification.enabled). There
are still some visual issues in the browser chrome with elements that rely
on the blockification behavior, and we plan to fix those by explicitly
setting `display: block`. Once we resolve these issues, we expect to remove
the pref and change the default behavior.

If you’re writing CSS that relies on the element being forced to `display:
block`, you’ll now need to explicitly set the display value in your CSS.
One thing to be careful with is the CSS specificity of the new display rule
that you’re adding, which might override an existing display rule.

The reason we’re making this change is to allow us to convert remaining XUL
grids to CSS grid layout [1], where the blockification of the grid items
breaks their appearance. We believe it will also make migration of other
XUL layouts to CSS easier. In particular, we think we can replace XUL deck
layout [2] and XUL stack layout [3] with a single area CSS grid layout. And
we think this will allow us to more incrementally replace XUL flexbox with
CSS flexbox (since migrating an element to the latter won’t break its
children).

Please reach out if you have questions or concerns about this change.

Cheers,
Tim

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1580012
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1520625
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1559192
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1576946
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

[Tim Nguyen]

Non-modal dialogs should just work fine in a chrome window (the dialog
would just be like a centered absolute positioned div). As for modal
dialogs (eg. dialogs that makes everything else inert), it would depend on
whether the current top-layer implementation works within a chrome window
and I don't think it is the case currently. So, I don't expect modal
dialogs to work within the chrome window (at least not without some extra
platform work). Xidorn might know better though.

As for how modal dialogs *should* behave in a chrome window, I would expect
it to be the same as for web content, i.e. it modal dialogs should make all
UI elements except the current dialog inert.

Tim


On Fri, Dec 23, 2016 at 12:33 AM, Justin Dolske <dol...@mozilla.com> wrote:

> What's the expected experience if chrome code uses this feature? (In a
> chrome window, interaction with a content window isn't the thing I'm
> wondering about.)
>
> Justin
>
> On Tue, Dec 20, 2016 at 3:56 PM, Tim Nguyen <ntim...@gmail.com> wrote:
>
>> *Summary*:
>> The *HTML  element* represents a dialog box or other interactive
>> component, such as an inspector or window.
>> It will initially be implemented behind a pref.
>>
>> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
>>
>> *Link to standard*: https://html.spec.whatwg.org/m
>> ultipage/forms.html#the-
>> dialog-element
>> <https://html.spec.whatwg.org/multipage/forms.html#the-dialog-element>
>>
>> *Platform coverage*: All
>>
>> *Estimated or target release*: Firefox 54
>>
>> *Preference behind which this will be implemented*:
>> dom.dialog_element.enabled
>>
>> *DevTools bug*: None yet, although I'm not sure how we can make DevTools
>> more useful here ?
>>
>> *Do other browser engines implement this?*
>> Shipped: Chrome (since version 37)
>> Considering: Edge ( http://status.modern.ie/dialogelementformodals )
>>
>> *Tests*:
>> https://github.com/w3c/web-platform-tests/blob/master/
>> html/dom/interfaces.html#L1835
>> https://github.com/w3c/web-platform-tests/tree/master/
>> html/semantics/interactive-elements/the-dialog-element
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: HTML5 element

[Tim Nguyen]

*Summary*:
The *HTML  element* represents a dialog box or other interactive
component, such as an inspector or window.
It will initially be implemented behind a pref.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640

*Link to standard*: https://html.spec.whatwg.org/multipage/forms.html#the-
dialog-element

*Platform coverage*: All

*Estimated or target release*: Firefox 54

*Preference behind which this will be implemented*:
dom.dialog_element.enabled

*DevTools bug*: None yet, although I'm not sure how we can make DevTools
more useful here ?

*Do other browser engines implement this?*
Shipped: Chrome (since version 37)
Considering: Edge ( http://status.modern.ie/dialogelementformodals )

*Tests*:
https://github.com/w3c/web-platform-tests/blob/master/
html/dom/interfaces.html#L1835
https://github.com/w3c/web-platform-tests/tree/master/
html/semantics/interactive-elements/the-dialog-element
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

SVG in our source code

[Tim Nguyen]

The number of SVGs in our source code has been growing quite fast during the 
last months and unfortunately a lot of SVGs entered our code without being 
cleaned up.

Making sure new SVGs are clean should be part of the review process, because 
SVG is code, and code should be clean.

So, I propose making guidelines for SVGs in our source code that need to be 
respected in order to get the SVG shipped. Here's a draft for possible 
guidelines [0] based on stuff seen in [1], where all our SVGs were cleaned up. 
These guidelines should be added on MDN so developers can have a reference.

Thoughts ?

[0] : https://etherpad.mozilla.org/svg-guidelines
[1] : https://bugzilla.mozilla.org/show_bug.cgi?id=1160771

Tim Nguyen [:ntim]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform