Intent to ship: CSS overflow:clip

[Mats Palmgren]

Summary:
We intend to ship CSS overflow:clip in v81, which is the standardized
version of a prefixed value (-moz-hidden-unscrollable) that we already
ship.  The prefixed value becomes an alias for the new value.
The standardized value is mostly compatible, but there are some
differences.  Most notably, we now support clipping in one axis
and overflowing in the other (i.e. 'clip' can be combined with
'visible' in the overflow-x/y properties).

Bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1531609
https://bugzilla.mozilla.org/show_bug.cgi?id=1635473

Standard:
https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip
https://github.com/w3c/csswg-drafts/issues/1971

Platform coverage:
All

Preference:
None. We've shipped the prefixed version of this value since forever
and any web-compat issues are unlikely.

DevTools bug:
N/A

Other browsers:
It's not implemented in Blink/WebKit yet:
https://bugs.chromium.org/p/chromium/issues/detail?id=966283
https://bugs.webkit.org/show_bug.cgi?id=198230
Blink appears to show positive signals in:
https://github.com/w3c/csswg-drafts/issues/1971

Web-platform-tests:
Yes, some already exist and I've added more.

Secure contexts:
This will not be restricted to secure contexts, like many other CSS features.

Is this feature enabled by default in sandboxed iframes?
Yes, like many other CSS features.


Credit also goes to Jeremy Ir who implemented the initial version of
the style system changes for this feature.


/Mats

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

Intent to Prototype: CSS Masonry layout

[Mats Palmgren]

Summary: Masonry layout is a popular idea of how to lay out content on
the web, e.g. a Pinterest wall of images. I've made a detailed proposal
on how to support this natively as feature of CSS Grid here:
https://github.com/w3c/csswg-drafts/issues/4650
The feedback has been overwhelmingly positive so far and the CSSWG has
resolved to adopt the proposal.  So I intend to implement a prototype of
this and enable it in Nightly for testing/feedback as we develop this
feature.

Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1607954
Standard: TBD
Platform coverage: all
Preference: layout.css.grid-template-masonry-value.enabled
DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1607971


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: MathML mfenced element

[Mats Palmgren]

On 12/18/19 10:11 AM, Frédéric Wang wrote:

Thanks for doing it. Out of curiosity, what do our counters say about
the % of pages containing mfenced relative to the number of pages
containing MathML?


FYI, most of our telemetry data is public.
You should be able to find it from here:
https://telemetry.mozilla.org/

In this case, the use counter is MathML_DeprecatedMfencedElement and it
doesn't show up in the relevant page:
https://georgf.github.io/usecounters/#kind=page=DEPRECATED=beta=72
which I'm reading as "never occurred even once".
I'm not very familiar with our telemetry though so I could be wrong...


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: MathML mfenced element

[Mats Palmgren]

In bug 1603773 I intend to ship 'mathml.mfenced_element.disabled' set to
true in all builds.  This pref is already set to true in Nightly builds
for ~2 months (added in bug 1587577), so my change just makes it ride
the trains.  The intention is to remove the preffed-off code eventually.

The reason we're removing support for this MathML element is that it was
removed from the spec.  See bug 1587577 for details.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Mats Palmgren]

On 10/18/19 12:31 AM, ikilpatr...@chromium.org wrote:

I think one interesting part here is that (from my knowledge) this
policy actually hasn't been applied yet, due to the "other browsers
shipping insecurely" exception.


Do other vendors apply the same policy for new CSS features?

For example, Safari recently shipped a bunch of color scheme features:
https://webkit.org/blog/8840/dark-mode-support-in-webkit/
Are those restricted to secure contexts?

I'd argue that if other vendors don't apply the same policy then our
policy is pointless since it comes down to chance whether another
vendor shipped it for non-secure contexts first.  And even if we
did follow our own policy when we're first, if another vendor then
ships it insecurely we'd have to enable it for non-secure contexts
too for web-compat reasons.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Mats Palmgren]

On 10/17/19 8:12 PM, ikilpatr...@chromium.org wrote:

On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren
wrote:

As far as I know, we never constrain new CSS features to secure
contexts. At least not on the property/value level.


According to
https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/
you should be?

"Effective immediately, all new features that are web-exposed are to be
restricted to secure contexts. Web-exposed means that the feature is
observable from a web page or server, whether through JavaScript, CSS,
HTTP, media formats, etc."


True, but we have never applied that policy for CSS features
as far as I know.  Just recently we've added 'column-span',
the ::marker pseudo, new 'display' syntax with values like
'inline list-item', 'block ruby' etc, 'clip-path: path()',
and a long list of other CSS features since 2018.

As far as I know we don't even have a mechanism that I could
have used to restrict subgrid to secure contexts.  And to be
clear: I have no intention of blocking subgrid on waiting for
such a mechanism.



Or does the policy wrong and needs to be updated?


Maybe, but that's not for me to decide.

The issue you raise is a good one, but it's not really related
to subgrid specifically.  Perhaps it would be better if you
start a new thread regarding how that policy applies (or not)
to CSS features in general?


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Mats Palmgren]

On 10/17/19 5:35 PM, ikilpatr...@chromium.org wrote:

On Wednesday, October 16, 2019 at 11:14:02 AM UTC-7, Mats Palmgren
wrote:

*Secure contexts:* N/A


Replying as requested from:
https://twitter.com/ecbos_/status/1184690249324290048


Well, I just copy-pasted the email-template TYLin used in his
intent-to-ship for 'column-span' earlier, so I assumed "N/A" is
the correct term... :-)

Anyway, I don't think we constrain new CSS properties/values to secure
contexts in general. As far as I know, we don't even have a mechanism
for doing so.  So "N/A" seems appropriate.



Subgrid is a new feature to CSS behind a new display value [...]


No, 'subgrid' is not a new 'display' value.  It's a new value for
the 'grid-template-rows/columns' properties:
https://drafts.csswg.org/css-grid-2/#subgrid-per-axis



Does
https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/
apply here?


As far as I know, we never constrain new CSS features to secure contexts.
At least not on the property/value level.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: multi-keyword values on the CSS 'display' property

[Mats Palmgren]

On 8/26/19 4:42 PM, Boris Zbarsky wrote:

On 8/19/19 3:42 PM, Mats Palmgren wrote:
Sure.  I'm just saying that I suspect some of the combinations may be hard 
to implement using anon boxes, depending on what combinations are allowed.


For example, can one have a thing which is "table-cell" on the outside and 
"flex" on the inside, per spec?


No, 'table-cell' is currently a  keyword and those
can't be combined with other keywords at all. [1]

However, I'm proposing in [2] that 'table-cell'/'table-caption'
should instead be  keywords [3], which would allow
'display:table-cell flex' etc.

I've written proof-of-concept code to implement that and it was
fairly straight-forward now that we support multi-keyword values
in general.  I didn't see any signs of additional complications
regarding anon boxes from this. (To be concrete, removing the inner
anon box we currently have for table cells wouldn't become harder,
nor easier, by any of these changes.)

(I'll add a disclaimer for 'run-in' though.  It's not implemented
by anyone yet so it's hard to speculate about.  I'll also add that
I (and others) have doubts about it...)


It's worth trying to find out, and in particular to find out whether what 
we plan to ship is compatible with what they plan to ship.


Well, the CSS spec is public and being actively discussed in various
github issues / www-style.  I would expect them to file a spec issue
if they have objections or intend to implement something different.

/Mats

[1]
https://drafts.csswg.org/css-display-3/#the-display-properties

[2]
https://github.com/w3c/csswg-drafts/issues/3940

[3]
https://drafts.csswg.org/css-display-3/#typedef-display-outside
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Removing display:-moz-inline-grid and -moz-inline-stack

[Mats Palmgren]

In bug 1574994, I'm removing the display:-moz-inline-grid/stack values.
(They are inline-level versions of display:-moz-grid/stack XUL boxes
which we continue to support, for now).

These values are not exposed to web-content and there are no internal
uses in mozilla-central nor comm-central.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: multi-keyword values on the CSS 'display' property

[Mats Palmgren]

On 8/14/19 6:52 PM, Boris Zbarsky wrote:

On 8/14/19 12:37 PM, Mats Palmgren wrote:

This first patch set adds support for the new syntax
only, but no new box types (I'll add those separately in a bit).


In general, it seems like we should think about how to integrate this 
stuff into layout in a better way than anonymous boxes everywhere.  In 
particular, we may want to consider changing nsIFrame such that we have it 
point to a "how I look to my parent" class and a "how I manage my kids or 
paint myself" class and be able to mix and match those.



I agree, but splitting up the 'display' property into three separate
keywords doesn't imply we'll implement them using anonymous boxes in
more cases than if it's just one keyword.  Your point is well taken but
it's an independent issue.

I'm guessing you're thinking of the implementation of 'block ruby',
which indeed does introduce a new anonymous box (it's a block box with
anonymous ruby box inside it).
This is mandated by the Ruby spec though:
"If an element has an inner display type of ruby and an outer display type 
other than inline, then it generates two boxes: a principal box of the 
required outer display type type, and an inline-level ruby container. All 
properties specified on the element apply to the principal box (and if 
inheritable, inherit to the ruby container box)."

https://drafts.csswg.org/css-ruby-1/#block-ruby

(It makes sense to me to use two boxes in this case.  I'm happy to
continue discuss that off-list I you want.)

(There are no anonymous boxes associated with any of the list-item values.)



Other browsers: Other UAs don't support this yet, AFAIK.


Do they plan to?



I don't know what their plans are.  I haven't seen any public
announcements one way or another.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS 'display:block ruby'

[Mats Palmgren]

On 8/14/19 9:51 PM, David Burns wrote:

Are there any web platform tests for this ...

Yes, it seems I missed to include this item in my original email:

Tests: WPT and other tests were added.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: CSS 'display:block ruby'

[Mats Palmgren]

Summary:
Add support for 'display:block ruby' which creates a block box
with a ruby box inside it.

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

Standard: https://drafts.csswg.org/css-display/#the-display-properties

Platform coverage: All

Estimated or target release: v70

Preference: None

DevTools: The new value has been added to the auto-completion menu
for the 'display' property

Other browsers: Other UAs don't support this yet, AFAIK.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: CSS 'display:inline list-item' and 'display:inline flow-root list-item'

[Mats Palmgren]

Summary:
Add support for 'display:inline list-item', which creates an inline box
with a ::marker box inside it, and 'display:inline flow-root list-item',
which creates an inline-block with a ::marker (inside or outside).

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

Standard: https://drafts.csswg.org/css-display/#list-items

Platform coverage: All

Estimated or target release: v70

Preference: None

DevTools: The new values have been added to the auto-completion menu
for the 'display' property.

Tests: WPT and other tests were added.

Other browsers: Other UAs don't support this yet, AFAIK.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: multi-keyword values on the CSS 'display' property

[Mats Palmgren]

Summary:
Add support for multi-keyword values on the CSS 'display' property.
The spec splits this property into three parts: an outside part,
an inside part, and a list-item part so the author can specify them
separately.  This first patch set adds support for the new syntax
only, but no new box types (I'll add those separately in a bit).
So, this bug just adds a bunch of synonyms for exist values we
already support, so we can now write "block flow list-item" or
"block list-item" etc instead of just "list-item".  Keywords can
be given in arbitrary order, so there are now a lot of valid
permutations for the same computed value.  The values are
serialized to their shortest form as usual though.

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

Standard: https://drafts.csswg.org/css-display/#the-display-properties

Platform coverage: All

Estimated or target release: v70

Preference: None

DevTools: No change

Tests: WPT and other tests were added.

Other browsers: Other UAs don't support this yet, AFAIK.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

[Mats Palmgren]

On 7/4/19 1:11 PM, Henri Sivonen wrote:

I don't _know_, but most like they want to benefit from optimizations
based on overflow being UB.


It's worth noting that such optimizations can be exploitable if an
overflow do occur.  See bug 1292443 for an example.

Compiling with -fwrapv would fix that, but then you'd lose those
optimizations of course.

/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Mats Palmgren]

On 3/27/19 12:30 AM, Domenic Denicola wrote:

(On-list this time)


However, the actual semantics for how list items work are exclusively
defined by CSS ([css-lists], [css-pseudo]). The above mentioned HTML
elements/attributes simply maps to the relevant CSS properties, using
a built-in 'list-item' counter.



Where does [css-lists] and [css-pseudo] define this?



From CSS Lists, Introduction:
https://drafts.csswg.org/css-lists-3/#intro
"It also defines _counters_, which are special numerical objects
often used to generate the default contents of markers."
where _counters_ links to:
https://drafts.csswg.org/css-lists-3/#counter

Pretty much all of CSS Lists is about how these generic
counters work.  The built-in 'list-item' is such a counter.
The only thing special about it is that it's automatically
incremented for any element that has 'display:list-item'.
https://drafts.csswg.org/css-lists-3/#declaring-a-list-item
Other than that, it works exactly like a counter an author
can introduce themselves.

FYI, the CSS Lists spec isn't very well maintained, sadly,
so it's not up-to-date with recent resolutions.  So, some
of the finer details in there might be wrong, but I think
most of it regarding counters is correct.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Mats Palmgren]

On 3/25/19 6:21 AM, Domenic Denicola wrote:
> The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item
> seems to contradict that hard-fought consensus. It seems like a
> regression to implement list item numbering according to that spec,
> instead of according to HTML.

As others have clarified, there are zero regressions from these changes
(that we know of) and **a lot** of bugs fixed.  The compatibility with
other UAs and web content is now greatly improved.

You seem to think that HTML is the authoritative specification for
how list items work.  That's only partly true.
HTML specifies the part where certain elements opens a list item
scope (ol/ul/menu), have a default 'display:list-item' value (li)
and that  sets the value of the counter, etc.

However, the actual semantics for how list items work are
exclusively defined by CSS ([css-lists], [css-pseudo]).
The above mentioned HTML elements/attributes simply maps to
the relevant CSS properties, using a built-in 'list-item' counter.
Most importantly: this counter behaves **exactly** the same as any
other CSS counter would for a given set of style values.
We're simply not going to add a parallel "HTML counter" implementation
that is incompatible with CSS counters just to implement these HTML
elements (in fact, we've just removed the special counting we had).

Mapping HTML lists to CSS has **major** benefits for authors and
implementors alike.  I'd be happy to elaborate on that if you wish.


> This omits all the details at [...], e.g. reversed="", the collection
> of owned list items, value="" attribute parsing, etc.

 is mapped to the 'counter-set' property.

 is the one thing that isn't yet defined fully in a CSS spec.
We have implemented it using an internal (not exposed to web content)
inherited CSS property, and then map the attribute to that.

So, what our new implementation proves is that all of HTML's funky list
items can be fully and exclusively implemented using CSS concepts.
Well, we hope so anyway.  We'll know after it hits the release channel :-)


> An important thing to test here is the result of getComputedStyle on
> list items as a result of this change. HTML specifies that ordinal
> values are displayed on list items without any counter CSS properties
> involved

Emilio filed https://github.com/w3c/csswg-drafts/issues/3769 about this.
I disagree that getComputedStyle should lie about the actual value
of any of the counter-* properties.  I see no benefit to anyone
in doing that and I also don't think it's needed for web-compatibility.


Regards,
Mats

[css-lists]
https://drafts.csswg.org/css-lists/

[css-pseudo]
https://drafts.csswg.org/css-pseudo/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: CSS ::marker pseudo-element

[Mats Palmgren]

Summary:
The ::marker pseudo-element represents the automatically generated
marker box of a list item.  It allows authors to style the marker
and generate content for it through its 'content' property (like
::before/::after).

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=205202
Animation support is pending:
https://bugzilla.mozilla.org/show_bug.cgi?id=1538618

Link to standard:
https://drafts.csswg.org/css-pseudo-4/#marker-pseudo
https://drafts.csswg.org/css-lists/#markers
https://github.com/w3c/csswg-drafts/issues/3499

Platform coverage: All platforms

Estimated or target release: Firefox 68

Preference behind which this will be implemented: none

DevTools bug: none (I've checked that a ::marker shows up as
a pseudo in the panel with ::before/::after and it appears
to work fine)

Do other browser engines implement this?
Safari implements limited support for ::marker (it doesn't support
the 'content' property, and it has no support for the built-in
'list-item' counter, both which are major pieces of this general
feature).  Chrome supports none of it AFAICT.
https://wpt.fyi/results/css/css-pseudo

web-platform-tests:
There are some tests in css/css-pseudo/ and I've added
a bunch more.

Is this feature restricted to secure contexts? No

Many thanks to Emilio who patiently reviewed all of these list
item related changes.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: built-in CSS counter 'list-item'

[Mats Palmgren]

Summary:
The built-in 'list-item' counter is used to implement HTML /
(and other elements with display:list-item) using CSS.

I'm also removing our old (frame-based) code for list item counters,
which had a number of decades-old bugs (bug 4522 et al), was rather
slow (bug 3246) and crashy (bug 1515124).

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

Link to standard:
https://drafts.csswg.org/css-lists/#declaring-a-list-item

Platform coverage: All platforms

Estimated or target release: Firefox 68

Preference behind which this will be implemented: none

DevTools bug: none

Do other browser engines implement this?
No, as far as I can tell.

web-platform-tests:
I added a couple of WPTs in css/css-lists/ and there are some
in css/CSS2/lists which we now pass.  Also, given that we now
use this built-in counter for all display:list-item elements
we should have basic coverage from existing tests for those.

Is this feature restricted to secure contexts? No


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: CSS counter-set property

[Mats Palmgren]

Summary:
The counter-set CSS property assigns an absolute value to a CSS counter.
(It behaves the same as counter-increment but assigns instead of
increments.)

It will be used internally to map  to set the value of
the built-in 'list-item' counter (see separate announcement following
this).

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

Link to standard:
https://drafts.csswg.org/css-lists/#propdef-counter-set

Platform coverage: All platforms

Estimated or target release: Firefox 68

Preference behind which this will be implemented: none

DevTools bug: none

Do other browser engines implement this?
No, as far as I know.

web-platform-tests:
I added some under css/css-lists/.  (It will also be tested
indirectly through .)

Is this feature restricted to secure contexts? No


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: CSS 'prefers-color-scheme' media feature

[Mats Palmgren]

Summary:
The 'prefers-color-scheme' media feature is way for pages to detect
if the user prefers a light or dark color theme.  The values are
'light', 'dark', and 'no-preference'.  If the "resist fingerprinting"
feature is active we always match 'light'.  If the media type is
'print' we always match 'light'.  Otherwise, we try to determine
a value from the user's current "desktop theme".  This should work
well on recent versions of OSX and Windows.  On Linux, we don't
know how to determine a value from the system so we match
'no-preference' there - help wanted:
https://bugzilla.mozilla.org/show_bug.cgi?id=1525775

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

Link to standard:
https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme

Platform coverage: All platforms

Estimated or target release: Firefox 67

Preference behind which this will be implemented:
The feature is always enabled, but there is an existing hidden
preference to set a value (integer), ui.systemUsesDarkTheme:
0 = light
1 = dark
2 = no-preference

Is this feature enabled by default in sandboxed iframes?
Yes, but if widget look-and-feel features are disabled in
sandboxed iframes then we'll match 'no-preference'.

DevTools bug: none

Do other browser engines implement this?
Safari has implemented this feature and it's available in their
Nightly build, but it's not yet shipped AFAICT.
https://paulmillr.com/posts/using-dark-mode-in-css/ is a post about
implementation of this feature in Safari;
https://webkit.org/blog/8475/release-notes-for-safari-technology-preview-68/ 
documents its addition.


It appears Chrome is actively working on it:
https://bugs.chromium.org/p/chromium/issues/detail?id=889087

web-platform-tests:
https://w3c-test.org/css/mediaqueries/prefers-color-scheme.html

Is this feature restricted to secure contexts? No

Credit also goes to Jonathan Kingston who wrote the initial
implementation of this feature.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: The border-{start,end}-{start,end}-radius CSS properties

[Mats Palmgren]

Summary:
The border-{start,end}-{start,end}-radius CSS properties are flow-relative
versions of their corresponding physical property, border-top-left-radius etc

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

Link to standard:
https://drafts.csswg.org/css-logical-1/#border-radius-properties

Platform coverage: All platforms

Estimated or target release: Firefox 66

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A, devtools support is included in these patches

Do other browser engines implement this?
I don't know, there was no WPT for these.

web-platform-tests:
I added one: css/css-logical/logical-box-border-radius.html

Is this feature restricted to secure contexts? No


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: CSS border-{block,inline}-{color,style,width} and border-{block,inline} shorthands

[Mats Palmgren]

Summary:
The border-{block,inline}-{color,style,width} CSS properties are shorthand 
for their respective -start/-end properties.
The border-{block,inline} are shorthand for their respective -start/-end 
shorthands, though you can only specify one value (which is used on both 
the -start/-end sides).


Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1520236
https://bugzilla.mozilla.org/show_bug.cgi?id=1520396

Link to standard:
https://drafts.csswg.org/css-logical/#propdef-border-inline-color (etc)
https://drafts.csswg.org/css-logical/#propdef-border-inline

Platform coverage: All platforms

Estimated or target release: Firefox 66

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A, devtools support is included in these patches

Do other browser engines implement this?
https://wpt.fyi/results/css/css-logical/logical-box-border-shorthands.html

web-platform-tests:
http://w3c-test.org/css/css-logical/logical-box-border-shorthands.html

Is this feature restricted to secure contexts? No


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: CSS inset/inset-block/inset-inline shorthands

[Mats Palmgren]

Summary:
The inset-block CSS property is a shorthand for the inset-block-start/end 
properties (ditto -inline).
The 'inset' CSS property is a shorthand for the top, right, bottom, and 
left properties.


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

Link to standard:
https://drafts.csswg.org/css-logical/#propdef-inset-inline
https://drafts.csswg.org/css-logical/#propdef-inset

Platform coverage: All platforms

Estimated or target release: Firefox 66

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A, devtools support is included in the patch

Do other browser engines implement this?
https://wpt.fyi/results/css/css-logical/logical-box-inset.html

web-platform-tests:
http://w3c-test.org/css/css-logical/logical-box-inset.html

Is this feature restricted to secure contexts? No


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: CSS margin-block and margin-inline shorthands

[Mats Palmgren]

Summary: The margin-block CSS property is a shorthand for the 
margin-block-start/end properties (ditto -inline)


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

Link to standard: https://drafts.csswg.org/css-logical/#propdef-margin-inline

Platform coverage: All platforms

Estimated or target release: Firefox 66

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A, devtools support is included in the patch

Do other browser engines implement this?
https://wpt.fyi/results/css/css-logical/logical-box-margin.html
Blink appears to have implemented them behind a flag:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/css_properties.json5?rcl=b166577f0820ba3f3aefe3c0fbe330c8e2f86dc9=4820-4831

web-platform-tests: 
http://w3c-test.org/css/css-logical/logical-box-margin.html


Is this feature restricted to secure contexts? No


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

[Mats Palmgren]

On 1/14/19 7:23 PM, Boris Zbarsky wrote:

Do you know whether this is purposeful or just a typo?


Dunno.  It seems like a typo to me.

2) We are just implementing the padding shorthands for now, not the margin 
ones?


Yes, but I should probably just add margin-block/inline while I'm at it...
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1519944


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

[Mats Palmgren]

Summary: The padding-block CSS property is a shorthand for the 
padding-block-start/end properties (ditto -inline)


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

Link to standard: https://drafts.csswg.org/css-logical/#propdef-padding-inline

Platform coverage: All platforms

Estimated or target release: Firefox 66

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A, devtools support is included in the patch

Do other browser engines implement this? No, 
https://wpt.fyi/results/css/css-logical/logical-box-padding.html


web-platform-tests: 
http://w3c-test.org/css/css-logical/logical-box-padding.html


Is this feature restricted to secure contexts? No


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Reporting API

[Mats Palmgren]

On 11/13/18 10:33 AM, Andrea Marchesini wrote:

*Summary*: Reporting API allows the page to receive notifications such as
the usage of deprecated APIs and FeaturePolicy violations.
I decided to implement this API, because it is required in the
web-platform-tests for FeaturePolicy.

Reporting API covers 2 different features:
a. reporting to the current page, via ReportingObserver
b. reporting to a remote server, known via 'report-to' HTTP header.
My implementation covers only the first aspect. However I also have patches
for the second part, not in review yet.


It is blatantly clear to me that the second part would be
a violation of the GDPR.  I raised this issue in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1492036#c9
No one has yet responded.

It may very well be that the first part also violates the GDPR
if it gives the page access to data that it would not otherwise
have access to.  Isn't the whole purpose of the ReportingObserver
to facilitate sending data back to an external server through
some other mechanism like XHR?


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: most -moz-appearance values not supported by other UAs / spec

[Mats Palmgren]

Hi,

In bug 1496720 I intend to unship most -moz-appearance values that
aren't supported by other UAs / spec.  These are mostly XUL-related
values that we use internally in our UI (and they will continue to be
available for that purpose).  Also, since -webkit-appearance is now
an alias for -moz-appearance we currently expose these values on that
property too unfortunately.  Which is why I think we should do this
sooner rather than later.

These are the values I intend to unship:
https://hg.mozilla.org/try/diff/05e54dac9610/layout/style/test/test_non_content_accessible_values.html

The spec for -webkit-appearance is:
https://compat.spec.whatwg.org/#css-non-aliased

There is some analysis of web-compat impact in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1496720#c14
My conclusion is that unshipping these values will likely make our
rendering more compatible with Chrome's.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Mats Palmgren]

On 9/20/18 5:59 PM, Andrew McCreight wrote:

On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione  wrote:


On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote:

So, I don't think we need to do anything fancy with forking - we'd just
need to capture stacks and send them via telemetry rather than as a crash
report. This was the idea behind bug 1209131, which got pretty far along
but never made it to the finish line.


This would actually potentially even give us better information
than fork-and-crash, since we should be able to include JS
stacks in that setup too. We've never been able to do that in
ordinary crash reports, since breakpad doesn't know how to
unwind JS stacks, and we can't safely ask the JS runtime to do
it while we're crashing.



Though keep in mind that any stack that includes content JS is going to
likely count as PII, so it would have to be hidden by default on Soccorro.



Please note that it would be illegal to collect such data
without asking for explicit user consent first.
The GDPR requires a "positive opt-in" mechanism:
https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/consent/
Our current Telemetry permission is an opt-out mechanism.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Mats Palmgren]

On 8/14/18 12:52 AM, Jonathan Watt wrote:

On 08/08/2018 21:08, Boris Zbarsky wrote:

Are we writing down something that could get turned into a spec?


I've got a bunch of messy notes that I hope will be of some use for that, but
no, so far I have not attempted to create draft spec text to replace the text in
CSS UI 4.


It'd be awesome if you could write this down somewhere while you
have the details somewhat fresh in your mind.  I'd be happy to
contribute what I know about this too.

Those notes would be an excellent starting point for a discussion
with other vendors about speccing this property, which I believe
is necessary if we're going to converge UAs to something that
is "compatible".


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Mats Palmgren]

The plan to ship -webkit-appearance looks good to me, fwiw.

On 8/14/18 12:46 AM, Jonathan Watt wrote:
> On 08/08/2018 16:31, Mike Taylor wrote:
>> On 8/7/18 5:16 PM, Jonathan Watt wrote:
>>> Spec: None. We're reverse engineering Chrome and ignoring
>>> https://drafts.csswg.org/css-ui-4/#appearance-switching
>>> since the 'appearance' property defined there is not
>>> web compatible.
>>
>>   From the "Possible ways forward" from that link, I think option 5
>> makes the most sense. We can always spec this in the Compat Standard,
>> if the issue is never resolved.
>
> That's the option that I think makes most sense too, ...

I fully agree that speccing -webkit-appearance is the way forward.
I doubt it's possible to spec the rendering in detail, but it should
be possible to spec at least the list of valid values and what each
value does on various HTML elements in loose terms to the degree that
any differences between UAs is unlikely to cause any major web-compat
issues.

Having a spec for it, even if it's vague, is good since it prevents
UAs from introducing new values without going through the normal
CSSWG process.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: URL.createObjectURL(MediaStream)

[Mats Palmgren]

On 4/23/18 10:01 AM, Anne van Kesteren wrote:

On Mon, Apr 23, 2018 at 9:50 AM, Andrea Marchesini
 wrote:

. I haven't checked edge (I don't run windows locally)


Ask for a BrowserStack account (not entirely sure who arranges these
though, I got mine via jst).


Or you can get a gratis Win10 VM here:
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: CSS subgrid

[Mats Palmgren]

Hello Grid lovers,

I've started implementing a prototype for CSS subgrid layout.
I say "prototype" since the spec [1] is far from settled and will need
to be updated based on feedback from implementors.  I've summarized
the features of this prototype and my views on the spec at [2].
(I'll use bug 1240834 as the meta bug.  None of the code has landed yet.)

/Mats


[1]
https://drafts.csswg.org/css-grid-2/#subgrids

[2]
https://github.com/w3c/csswg-drafts/issues/2280#issuecomment-380546425
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unprefix grid-gap, grid-row-gap, and grid-column-gap and updating them to spec

[Mats Palmgren]

Hi,

In bug 1398482 I'm unprefixing the grid-gap, grid-row-gap, and
grid-column-gap properties.  The old names becomes aliases for
the respective unprefixed property.
I'm also adding support for the 'normal' keyword to these properties
and making it the initial value, per spec [1].

I'm also adding support for percentages to the existing unprefixed
column-gap property (which is only supported in multi-column layout
until now) in bug 1398537.  It already supports 'normal', so with
these changes it has the same syntax as the updated grid-column-gap
property so we can now "merge" them.

These properties also applies to Flexbox:
https://drafts.csswg.org/css-align-3/#gap-flex
We haven't implemented layout for that yet[2], so one could argue
that we shouldn't unprefix the grid-* properties until we do.
I think we should anyway, for two reasons:
1. Chrome decided to ship them[3] without Flexbox layout support,
   so it will likely lead to Grid web-compat issues soon unless we
   do the same
2. column-gap is already in the wild, so the problem already exists
   for this property with the spec generalizing it to Grid/Flexbox


/Mats

[1]
https://drafts.csswg.org/css-align-3/#column-row-gap

[2]
https://bugzilla.mozilla.org/show_bug.cgi?id=1398483

[3]
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/UViBfJuuIq8/w7_2W7lLAgAJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Shapes Module Level 1 (partial)

[Mats Palmgren]

On 11/29/17 12:03 PM, Ting-Yu Lin wrote:

We can ship all the properties in this module at once, or we could probably
divide it into two stages, and ship it to the user incrementally.

For example, stage 1 is to ship shape-outside" (except  value) and
"shape-margin", and stage 2 is to ship the remaining "shape-outside:
" and "shape-image-threshold". If everything goes well, stage 1 is
targeting at Firefox 59.



I think supporting only a subset of the valid values for a property
is problematic.

CSS conformance rules says:
"[...] the user agent must parse the value according to the property
definition. This means that the user agent must accept all valid values
and must ignore declarations with invalid values."
https://www.w3.org/TR/CSS21/conform.html

Shipping support for a subset of the properties in a spec might make sense
in some cases, but since you say:


The downside of the two-stage roll-out could raise web-compat issues
because Blink and Webkit already support the entire module.


it's not probably not a good idea in this case, for web-compat reasons.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Microsoft VMs for testing

[Mats Palmgren]

FYI, Microsoft distributes free VMs for browser testing purposes:
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Mats Palmgren]

On 9/19/17 5:09 PM, Ehsan Akhgari wrote:

Do you find the arguments that people have against this convincing?


No.


If not, would you mind elaborating why please?


Sure, to recap, the arguments against aligned params in this thread are:
1. more work

Not an issue if we use a tool to do the formatting.
Even manually, I think it's minor work that I'm willing to do for
the benefit of the readers of our code.

2. touching more lines than necessary when adding/removing params,
   making it harder to follow blame links

Judging from my personal use of blame links, it's very rare that
I want to find when a specific param was added to a signature.
This is also something that tooling could solve (skip blame on
lines that differ only by whitespace).

3. more likely to lead to overly long lines that require wrapping

When that happens (even without aligning param names) the most common
solution I've seen is to simply move the whole param block to the next
line.  Like so:
VeryLongFunctionNameOrWhatever...(
  int   aSomething,
  void* aSomethingElse)
{

But, do we still believe that a 80-column hard limit makes sense in this 
century?

I tend to think that we should relax it.
(BTW, it seems some modules already have -- I got a review comment today
to vertically align ".function()" on the dot in JS even if it overflows
80 columns).

I think improved readability trumps all of the minor issues above.

/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Mats Palmgren]

On 8/31/17 6:50 PM, Ehsan Akhgari wrote:

On 08/30/2017 09:03 PM, Eric Rahm wrote:

Okay sounds like there's agreement on a).


Indeed.  I have edited the Style Guide to reflect this.


Fwiw, I disagree with this decision.

Here's a more realistic example of *actual use* from our code base:
http://searchfox.org/mozilla-central/rev/d29c832536839b60a9ee5b512eeb934274b879b0/layout/forms/nsFormControlFrame.h#57-64

This example shows that it's easier to read arguments at a glance
when they are aligned, IMO.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Placement of binary operators when breaking a long line

[Mats Palmgren]

On 9/7/17 4:45 PM, Ehsan Akhgari wrote:

$ git grep '\s(>|>=|<|<=|==|!=)\s*$' -- '*.c*' | wc -l
2794


Don't you get plenty of false positives for '>' with that regexp though?
For example:
dom/bindings/BindingUtils.h:template
js/public/HashTable.h:struct IsPod >
etc

/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Mats Palmgren]

On 02/17/2017 03:22 AM, Boris Zbarsky wrote:
I thought about this a fair bit the last few days, and I think it would be 
a mistake to tie shipping appearance/-webkit-appearance to the removal of 
-moz-appearance.  We should ship the no-prefix version and the -webkit 
version.  Then we should get people to switch to them.  Then we can remove 
-moz-appearance.


Fair enough, I've updated the patches so that both prefs are now enabled
by default.  IOW, we'll ship both appearance/-webkit-appearance:none, and
-moz-appearance with no change in semantics except that it is now trumped
by an appearance/-webkit-appearance:none.

Does that sound reasonable?


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Mats Palmgren]

On 02/16/2017 07:20 PM, Benjamin Smedberg wrote:
It has happened repeatedly over the past two years that we discovered 
critical issues that affect websites only after we ship to release.


I don't think removing -moz-appearance even has the potential of being
"critical".  All that happens is that you get native styling instead
(at worst).  There shouldn't be any loss of function.  I don't think
an average web user will even notice it.

In the unlikely event that we do want to roll this back, all we need
to do is toggle the preference values, which I believe we can do even
in release builds nowadays by pushing a restart-less system add-on.



It is not hard nowadays to add metrics (telemetry) to measure web
feature usage.


Getting the data we would need in this case is actually a lot harder
than you may think.  It's probably easy to measure "does this web page
have a style rule that declares a valid -moz-appearance value?", but
that's useless in this case, since we really need to know if there's an
'appearance/-webkit-appearance' declaration that "wins" in this style
rule, or in some other rule.  Or if there's a 'border' declaration etc
that also turns off native styling in some cases, or if the element
is a  or something that has no support for native styling to begin
with, etc.

Adding that telemetry machinery to the style system seems rather tricky
to me.  And given the low risk with removing -moz-appearance - doesn't
seem worth implementing to me.  (I think our goal is to remove all
-moz-prefixed CSS properties eventually anyway, at which point this
machinery would have little value.)



In this case, I understand the advantage of shipping CSS 'appearance'.
I'm less sure about what it would cost us to keep supporting
-moz-appearance: none, perhaps indefinitely.


It seems you haven't considered that *removing* a -moz-prefixed property
could actually *improve* web compatibility.  We actually have some
evidence of that for -moz-appearance:none in bug 1328474.

I suspect this is the case for -moz-appearance.  If the web author also
wrote -webkit-appearance/appearance:none (as they should) then there is
no change, and if they didn't they might not have intended to have 'none'
styling in the first place.  It's just that they never tested it in
Firefox.  I get that impression after studying the usage of these
properties in some github projects.

AFAICT, IE11 (on a Win7 desktop) has no support for 'appearance' at all
(or any prefixed variant thereof), and Edge specifically added support
only for '-webkit-appearance:none'.  And I assume the web still works
in those browsers.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Mats Palmgren]

On 02/16/2017 04:27 PM, Boris Zbarsky wrote:

On 2/16/17 10:23 AM, Mats Palmgren wrote:

That's a valid concern, but I think ignoring -moz-appearance has fairly
benign effects in most cases.


Well, as in things just look wrong, is all, right?


Right.  But as I said, at least in some cases it actually looks better
(to me).


And as Jet pointed out to me, just landing
it and see what breaks is standard procedure for unprefixing properties:
https://bugzilla.mozilla.org/show_bug.cgi?id=775235


For addons we can do better: we can just contact them about it.  Please 
talk to :jorgev.


Will do.

FYI, Kohei-san has posted a heads-up here:
https://www.fxsitecompat.com/en-CA/docs/2017/moz-appearance-property-has-been-removed/


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Mats Palmgren]

On 02/11/2017 04:59 AM, Boris Zbarsky wrote:
The biggest worry for me is that inline style is never a "chrome sheet" in 
this sense.


That's a valid concern, but I think ignoring -moz-appearance has fairly
benign effects in most cases.  And as Jet pointed out to me, just landing
it and see what breaks is standard procedure for unprefixing properties:
https://bugzilla.mozilla.org/show_bug.cgi?id=775235

Anyway, I took a quick look at some add-on usage in XUL files:
https://dxr.mozilla.org/addons/search?q=moz-appearance+file%3A*.xul

Most uses appears to be "-moz-appearance:none" which is reasonably safe
to ignore, and can be easily amended with a "appearance:none" if needed.

For other values, I installed the first four add-ons that use
non-none values and analyzed what effect ignoring -moz-appearance
would have.

"dnsqueries":
https://dxr.mozilla.org/addons/source/addons/11806/chrome/content/dnsqueries.xul#42
The "-moz-appearance:textfield" has the effect of creating an extra
border+padding around the input field.  This causes the control to
have extra height making the whole toolbar have more height than
needed.  Ignoring this -moz-appearance makes those "problems" go
away and the toolbar and text control actually looks better (IMO).
Also, the text control still works with no loss in function.

"RDS Bar":
https://dxr.mozilla.org/addons/source/addons/14581/chrome/content/dialogs/preferences/parameters/weather/window.xul#20
https://dxr.mozilla.org/addons/source/addons/14581/chrome/content/rdstb.xul#3492,3525
It appears this "weather" button is dead code, I couldn't find a way
to enable it.

"Print Edit":
https://dxr.mozilla.org/addons/source/addons/193270/chrome/content/printedit-options.xul#123
 has the effect of adding
a chevron to the button.  Ignoring it makes it look like a standard
color picker button (which is an improvement, IMO).
There is no loss in function.

"Smart Text"
https://dxr.mozilla.org/addons/source/addons/161982/content/options.xul#16
The "-moz-appearance:textfield" has the effect of creating an extra
border+padding around the input field.  However, in this case it appears
that the  (XHTML) element does count as a chrome sheet so there
is no change in behavior for this add-on since the -moz-appearance is
still honored.  (IMO, it would actually have looked better without it).

While this is a small sample, there were no problems detected.
To the contrary, it actually looks like an improvement IMO.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Mats Palmgren]

On 02/11/2017 12:28 AM, Justin Dolske wrote:

Do we have any data on existing content usage of -moz-appearance? Or
is this a "ship it and see what breaks" kind of thing?


I'm not aware of any data that would be useful here.  Data on how often
-moz-appearance is used isn't very useful since it doesn't say if that
rule also contains -webkit-appearance / appearance (which is what is
recommended).

So what we did was to look at CSS rules in projects in github, e.g.
https://github.com/search?l=CSS=%E2%9C%93=-webkit-appearance+none=Code=searchresults
which makes it quite clear that dropping -moz-appearance in favor of
-webkit-appearance will improve web compat (if we assume these projects
are somewhat representative of the web).

Also note that any failure probably isn't catastrophic.  Say there is
a rule with only -moz-appearance:none, that form control will now
render using the native theme styling instead of the author's style.
(In some cases -moz-appearance:none isn't even needed, since just
setting a border/background turns off the theme anyway.)
So the control should still be visible and usable.

I'm guessing Firefox add-ons might not bother with anything but
-moz-appearance though,  but I assume those counts as chrome sheets,
so the property will continue to work there as before. (Please correct me
if I'm wrong about that.)

So I'm not too worried about dropping -moz-appearance.
I think the risk comes mostly from starting to honor rules that only have
-webkit-appearance:none in case that would make the control invisible
or ugly because of incompatibilities in other properties.  I think that
risk is fairly low though.  And Edge did this before us so there's some
evidence it works fine.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Mats Palmgren]

Summary: add support for the CSS UI property 'appearance:none | auto' with 
'-webkit-appearance' as an alias.  Unship '-moz-appearance'.


'appearance:none' works exactly as '-moz-appearance:none' -- it turns off 
the native theme for elements that have one.  'appearance:auto' (the 
initial value) makes an element have its default appearance.  We are 
currently shipping '-moz-appearance' with a large number of other values, 
such as 'button', 'range', 'radio' etc.  '-moz-appearance' will continue 
to work exactly as is, but will now be restricted to UA and chrome style 
sheets, i.e. it will *not* be available to web content.


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

Spec: https://drafts.csswg.org/css-ui-4/#appearance-switching

Platfrom coverage: All

Estimated release: 54 (tentatively)

Preferences: layout.css.appearance.enabled for 
'appearance'/'-webkit-appearance' (enabled by default), 
layout.css.moz-appearance.enabled for '-moz-appearance' (disabled by 
default).  All these properties are available to UA and chrome style 
sheets though, regardless of the preference settings.


Devtools bug: None needed, I think.

Status in other implementations: No other UA implements the unprefixed 
'appearance' as far as I know.  Edge implements '-webkit-appearance:none' 
but no other values, nor do they implement it unprefixed.  WebKit/Blink 
implements '-webkit-appearance' with a plethora of values, much like we 
currently do for '-moz-appearance'.  I don't know what their plans are for 
'appearance' and/or restricting the number of supported values.


I think the fact that Edge currently only ships '-webkit-appearance:none' 
proves that's all that is needed for web compat.  I tend to think we 
should also implement the unprefixed property though, because that's what 
the CSS spec says and I don't think it'll have any negative impact in 
terms of web compat (I admit I'm not 100% certain of that though, but we 
can adjust as needed).


Tests: Reftests and mochitests included.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing the representation of rectangles in platform code

[Mats Palmgren]

On 02/09/2017 03:26 AM, Botond Ballo wrote:

As far as I can tell, ISize and BSize are methods on
mozilla::LogicalRect, which does not derive from BaseRect, and as such
would not be affected.


Here's LogicalRect::ISize():
https://dxr.mozilla.org/mozilla-central/rev/5e17f9181c6cb0968966280d1c1d96e725702af1/layout/generic/WritingModes.h#1552-1556

'mRect' there is an nsRect, which you propose to change, right?
So every call will now need to calculate "x2 - x1" there, IIUC.
(same for BSize(), Width(), Height(), Size(), and the ctor taking
a LogicalSize (need to calculate x2/y2))

It's hard to speculate about performance of something like this
where some operations becomes faster and some slower.  But given
the scope of the change I would like to see measurements that
shows this is a performance win overall.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing the representation of rectangles in platform code

[Mats Palmgren]

On 02/09/2017 01:56 AM, Botond Ballo wrote:

- Replace direct accesses to the 'width' and 'height' fields
throughout the codebase with calls to getter and setter methods. (There
aren't that many - on the order of a few dozen, last I checked.)


I think you must have made a mistake, width/height and *Size things
are used in a gazillion places in layout code.  Most of those are
probably accessing the logical versions though (ISize/BSize) so that
might explain why it doesn't look like it's used much.  I suspect that
this usage is much more common than the operations you mentioned.

Is your proposal that all access to width/height/isize/bsize now becomes
something like "std:max(0, x2 - x1)" ?


The Graphics team, which owns this code


Sounds odd to me.  This code was written by and is mostly maintained by
the Layout team and is used mostly in Layout code.  The only reason
it's in gfx/ is so that it may be used also in Graphics code.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSS display:flow-root

[Mats Palmgren]

FYI, Chrome is following our lead and now intend to ship too:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/k9WOAVA5Ewc

/Mats

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

Intent to implement and ship: CSS display:flow-root

[Mats Palmgren]

Summary:
A display:flow-root element generates a block container box, and lays out
its contents using flow layout. It always establishes a new block
formatting context for its contents (per CSS2).
This is intended to make "clearfix" hacks unnecessary.

The implementation is fairly trivial: it adds a new keyword to
the 'display' property and ties that to existing code for
"NS_NewBlockFormattingContext".

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

Link to standard:
https://drafts.csswg.org/css-display-3/#valdef-display-flow-root

Platform coverage: all platforms

Estimated or target release: Fx53

Preference behind which this will be implemented:
layout.css.display-flow-root.enabled

DevTools bug: no need

Do other browser engines implement this?
Not that I am aware of, bugs have been filed for WebKit/Blink:
https://bugs.webkit.org/show_bug.cgi?id=165603
https://bugs.chromium.org/p/chromium/issues/detail?id=672508

Tests: added as part of the implementation

Security & Privacy Concerns: none


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Who loves multiple selection feature in editor?

[Mats Palmgren]

On 12/20/2016 03:25 AM, Masayuki Nakano wrote:

I'm talking about only nsISelectionController::SELECTION_NORMAL. Other
selections need multiple selection.


I suspect that treating SELECTION_NORMAL differently from other kinds of
Selections will actually make the code more complicated, not less.



At this time, we need to create loop for deleting all selection ranges,
but the ranges may be changed/removed during handling other selection
ranges.


Is that due to notifying selection listeners?  If so, there is a RAII
class for blocking those until you're done: SelectionBatcher.
Anyway, I believe that we can add a few convenience methods/classes
to make this stuff easy to work with...

But let's take that code discussion off-list.  :-)


We don't have any spec how do we behave in such case.


The current spec editor seems open to discussing multi-range Selection,
which is encouraging.

Perhaps we could add something like this:

selection.forEachRange(function (range) {
  // do awesome stuff
})

Since web developers are essentially doing this today:
doAwesomeStuff(selection.getRangeAt(0));

it seems it should be an easy upgrade to do this instead:
selection.forEachRange(doAwesomeStuff);

Look, it's even shorter! :-)


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Who loves multiple selection feature in editor?

[Mats Palmgren]

On 12/16/2016 06:32 PM, Ehsan Akhgari wrote:

* The developer facing APIs.  As you have noted above, our selection API
allows you to construct and examine multi-range selections.  This is
something that we should fix at some point, since other browser vendors
have been very clear that they won't implement this functionality


Quoting Ryosuke Niwa, the current spec author:
"As a vendor (Apple), we have quite a bit of interest in improving
selection for bidirectional text and new CSS layout modes such as flex
box and grid layout which can change the order of context. One way to
achieve that would be supporting multi-range selection.
As a spec author, there has been some discussion about bringing back 
multi-range selection, there is no wide support nor consensus about it."

https://bugzilla.mozilla.org/show_bug.cgi?id=1323681#c5

Quoting Tab Atkins Jr. from the same bug:
"Yeah, Selection is just *silly* in common Grid cases under the old
'single start and end DOM locations' model. Need multi-range selection to
make it work."
https://bugzilla.mozilla.org/show_bug.cgi?id=1323681#c7

I've made an example Grid to illustrate that last point, try selecting
the first column then the second (first some A's then some B's)
(you need Nightly or DevEdition for the example to work):
https://people-mozilla.org/~mpalmgren/tests/grid/grid-selection.html
I agree with Tab that this is going to happen *a lot*.

I think we should work with Ryosuke to develop a better Selection API
so that handling multi-range Selection comes naturally.  That part
doesn't seem that hard to me; the problem is mostly about getting web
developers to use the new API, but if we can make it just a little bit
nicer than getRangeAt() then I believe we can win them over.



* The user facing functionality.  Currently we expose multi-range
selections to the user in the following ways (perhaps among others that
I'm missing?):

  * Table cell selection (by Ctrl/Cmd-clicking on several table cells
allows you to select them all)
  * Mouse based selection (by holding Ctrl/Cmd when selecting something
on a page with another selection present)
  * (and perhaps touch based selection also similarly, but I don't have
a device I can test that on)


* user selection over CSS '-moz-user-select:none' regions
* user selection in CSS Grid layout (eventually :-) )


/Mats

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

Re: Who loves multiple selection feature in editor?

[Mats Palmgren]

On 12/15/2016 10:46 AM, Masayuki Nakano wrote:
> Supporting multiple selection in editor makes our editor code
> complicated.

Why is that so exactly?  By necessity, the code already operates
on one Range, right?  so why can't we implement something like:
Selection.ApplyToAllRanges(aFunction) that applies the existing
code to all the ranges?  And for functions that doesn't make sense
to apply to all ranges, it's usually the first or last range
you want, so let's make convenience functions for those too.

Would that help solve the problem?

/Mats

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

Re: Intent to ship: CSS Grid

[Mats Palmgren]

On 12/05/2016 09:53 PM, Benjamin Smedberg wrote:

Have the various grid properties be added to our fuzzers and we've been
fuzzing the implementation fairly comprehensively?


Yes, I believe Grid is included in our normal fuzz testing.
Grid has been enabled by default in Nightly and Aurora (including our
testing profile) for about a year now.  I've seen a few bug reports
from fuzz testing in that time.  There's also a fairly extensive reftest
suite for Grid which I think is fed into the fuzz testing and with
the usual DOM/CSS fuzzing on top of that I think fuzzing Grid layout
is well covered.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Grid

[Mats Palmgren]

On 12/05/2016 08:00 PM, Boris Zbarsky wrote:

What performance testing have we done on this implementation?  Have we
done edge-case stress-testing?  Stress-testing with large but "real-life"
layouts?  Something else?


Nope, I've done no /dedicated/ performance testing so far.
Both I and dholbert (who did the reviews) have been mindful of
potential performance issues throughout development though, fwiw.

Now that the implementation of features for release is complete,
I intend to do the kind of dedicated testing you're asking about.
And I invite everyone else with an interest in Grid to do the same.

There are two O(n^2) bugs that I'm aware of, but those only occur
in edge cases (fragmentation) so we decided they weren't release
blockers, since they won't affect viewing typical Grid layouts.
They will certainly be addressed in v53 though.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: CSS Grid

[Mats Palmgren]

As of Gecko 52, I intend to let CSS Grid ride the trains on all platforms.
https://drafts.csswg.org/css-grid/
This also includes all parts of the CSS Box Alignment spec that are
relevant to Grid layout:
https://drafts.csswg.org/css-align-3/

It has been developed behind the "layout.css.grid.enabled" preference,
and has been enabled by default in Nightly and Aurora for some time now.

Other UAs shipping this or intending to ship it are:
Chrome - intends to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/hBx1ffTS9CQ
Safari - is implementing it (independently):
https://bugs.webkit.org/show_bug.cgi?id=60731
Edge - status unknown to me

Note about the 'subgrid' feature:
We will *not* support the subgrid feature of CSS Grid in this first
release.  This feature is marked as "at-risk" in the spec and thus
not needed for spec compliance.  (Chrome is likewise not going to
support subgrid in their first release.)

This feature was previously discussed in this "intent to implement" thread:
https://groups.google.com/forum/#!msg/mozilla.dev.platform/jSmfRivZOrU/ZMPcwySUEW4J

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1217086

CSS Grid meta bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=css-grid

The Devtools team is implementing specific tools for Grid:
https://bugzilla.mozilla.org/show_bug.cgi?id=1181227
(some of which will ship in 52 I'm told)


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming hg.mozilla.org certificate change

[Mats Palmgren]

On 09/26/2016 07:20 PM, Gregory Szorc wrote:

# Mercurial 3.9+

[hostsecurity]
hg.mozilla.org:fingerprints =
sha256:8e:ad:f7:6a:eb:44:06:15:ed:f3:e4:69:a6:64:60:37:2d:ff:98:88:37:bf:d7:b8:40:84:01:48:9c:26:ce:d9

# Mercurial <= 3.8

[hostfingerprints]hg.mozilla.org =
73:7f:ef:ab:68:0f:49:3f:88:91:f0:b7:06:69:fd:8f:f2:55:c9:56



Note that the "name = value" should be on a single line or else
you will get "hg: parse error".  That is, there should be
no newline after the "=".

In case your mail reading application helpfully added a newline
there for you...

/Mats

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

Re: MXR permanently offline, please transition to DXR

[Mats Palmgren]

On 06/28/16 01:01, Tanvi Vyas wrote:

Is it possible to safely redirect mxr to dxr?


This would be most welcome.  There are lots of pasted MXR links
in Bugzilla comments which now requires tedious editing to
follow.

/Mats

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

Re: Coding style for C++ enums

[Mats Palmgren]

On 2016-04-11 19:47, Seth Fowler wrote:

Let me suggest again (especially since I'm not sure my previous email
reached this list yet) that rather than compromise on the "e" prefix, we
compromise on all caps for values, which is just as readable without
placing even more pressure on our 80-character line length restriction.


I'm opposed to that, for the following reasons:
1. dropping the 'e' only makes the line shorter for single word values,
   and makes it *longer* for THREE_WORD_VALUES
2. many people read all-caps as SCREAMING
3. the claim that a single 'e' makes it harder to keep lines under 80
   columns to any significant degree is extremely weak
4. the 'e' prefix is already the de-facto standard and widely used in
   our code base

I do agree with you though that our 80-column rule produces awkward
line-wrapping that makes it hard to read, write and review code.
The solution to /that/ problem is to relax that rule so that using
longer lines is allowed when code readability so demands.  The root
cause for this is usually our use of VeryLongAndDescriptiveNames
(which is a good thing).  We shouldn't sacrifice descriptive names,
nor code readability, for this archaic 80-column rule.

So, my counter-proposal is this:
Try to keep lines to 80 columns or less, as a rule of thumb.
Use up to 100 columns (hard limit) when code readability so demands.

Thanks,
Mats

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

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

[Mats Palmgren]

On 2016-04-11 23:32, Emma Humphries wrote:

Here's the open bugs they have touched http://mzl.la/1Q3w24o


He touched 283 bugs in the last 48 hours, most of which are FIXED.

Many comments are identical, for example:

https://bugzilla.mozilla.org/show_bug.cgi?id=1240762
https://bugzilla.mozilla.org/show_bug.cgi?id=1240778
https://bugzilla.mozilla.org/show_bug.cgi?id=1240670
https://bugzilla.mozilla.org/show_bug.cgi?id=1240682

All four have identical comments, added in a time span of 15 seconds.

/Mats

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

Re: Coding style for C++ enums

[Mats Palmgren]

On 2016-04-08 23:03, Jeff Gilbert wrote:

Strong preference against eFoo, here. :)


Strong preference *for* eFoo, here. :)

If I see Bar::Foo anywhere in code I'm not familiar with, my brain
is likely to first parse that as a type before realizing that, hmm
that doesn't make sense in an expression context, and then I will
likely have to lookup what that silly Bar thing is just to be sure.

eFoo is unambiguous and utterly clear.

/Mats

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

Re: Triage Plan for Firefox Components

[Mats Palmgren]

On 04/01/2016 10:35, Marco Bonardo wrote:

Fwiw, we (Awesome Search Team) also use Priority for the backlog, and we
consider P1, P2 and P5 the same as Media Playback team. So there is some
convergence about the meaning of those.
Though we also use P3 for "we care about this and will fix it, provided
there's no major priority bug to fix first".


This is roughly how we use P1-P5 in Layout as well:
http://dbaron.org/log/20090120-bug-priorities

/Mats

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

Re: Proposal: revisit and implement navigator.hardwareConcurrency

[Mats Palmgren]

On 9/8/15 3:21 PM, Luke Wagner wrote:

On a more technical detail: WebKit and Chromium have both shipped,
returning the number of logical processors where WebKit additionally
clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed
by WHATWG text [7].  I would argue for not clamping (like Chrome),


If that clamping is good enough for WebKit then why shouldn't it
work for our users too?

/Mats

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

Re: Intent to ship: Directory picking and directory drag-and-drop

[Mats Palmgren]

On 09/21/2015 05:37 PM, Jonathan Watt wrote:

Targeting Firefox 44 we intend to ship[1] Directory Upload[2],


It seems there are many security, privacy and UI issues discussed in
bug 907707 that are still unresolved.  I see that it's blocking the
ship-it tracking bug, but it seems premature to discuss shipping this
feature before we have consensus on those issues.

https://bugzilla.mozilla.org/show_bug.cgi?id=907707

/Mats

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

Re: Using rr with test infrastructure

[Mats Palmgren]

On 03/13/2015 12:26 PM, Ted Mielczarek wrote:

The other question I have is: what percentage of our intermittent
failures occur on Linux? If it's not that high then this is a lot of
investment for minimal gain.


FYI, there have been several intermittent crashes reported on Linux test
runs lately, e.g. bug 1142662.  If this setup can help us fix just one of
those crashes (and I expect it will) the investment has paid off, IMO.

/Mats

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

Re: Intent to ship: CSS display:contents

[Mats Palmgren]

On 02/04/2015 08:20 PM, cmzieba...@gmail.com wrote:

I am trying to set up a CodePen to test this feature:

http://codepen.io/WebDevCA/pen/vEeMjx

If I understand display:contents properly then if it is working the
green border around the DIV can't be seen but the contents of the H1
inside that DIV can be seen?


Right, the H1 will be displayed in DIV's parent and the DIV itself will
not be displayed.  However, H1 still inherit style from the DIV so you
can do h1 {border:inherit} to get a green border.  And the DOM and
CSS selectors works normally, so it still matches div h1 {} etc.

Developer documentation for this feature is forthcoming, but for now
I suggest you download Firefox Developer Edition and play with it:
https://www.mozilla.org/en-US/firefox/channel/#developer

Thanks for your interest!

/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: CSS Grid Layout Module Level 1

[Mats Palmgren]

On 02/03/2015 04:51 PM, Jonas Sicking wrote:

Can we also expose this to certified apps so that our Gaia developers can
start experimenting with using grids?


There isn't any useful layout code in the tree yet.  The ETA for
anything that's worth experimenting with is still 3-4 weeks or so.

I think we can enable the pref for Nightly/Aurora at that point.
I'll send an update when that happens.

/Mats

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

Re: Intent to ship: CSS display:contents

[Mats Palmgren]

On 02/02/2015 07:27 PM, paul.ir...@gmail.com wrote:

Hey Mats, the use cases are not obvious to me, but I didn't follow the
original www-style threads on this so I'm lacking context. (A the spec
doesn't help either)

Can you help explain why a developer would use `display:contents`?

I think it'd help to have it described a bit. Thanks!



I wasn't involved in the discussions either so I don't know what use
cases the CSSWG has, so I'll just describe how it works technically
and give some examples what you could use it for.

With display:contents you can have DOM elements for styling or scripting
reasons but in terms of layout behave as if they're not there.  In Grid
and Flexbox layout for example, if you wrap some children in an element
it will affect layout since the wrapper becomes a grid/flex item.
Styling it with display:contents undoes that so that the wrapped children
are again the grid/flex items, but they now inherit style from the
wrapper.  I imagine it might be useful also in Web Components (styling
the shadow host and/or the shadow DOM elements with display:contents).

Here's a rather academic example just to illustrate:
style
tr {display:contents}
/style
table
trtd1td2
trtd3td4
/table

The above table will have one row with four cells in layout. In terms
of CSS box construction it's identical to:
table
td1td2
td3td4
/table

If you replace the style rule with td {display:contents} you'd get two
rows with one cell each (12 and 34).  With tr,td {display:contents}
you'd get one row with one cell.

display:contents can be nested of course, so you can bubble up CSS
boxes from arbitrary DOM depths.  It allows you to break out of the
(mostly) one-to-one mapping between DOM nodes and CSS boxes.

It's a rather powerful feature and I think it remains to be seen how
web developers will make use of it.

The initial motivation for implementing display:contents in Gecko though
was to support implementing 'overflow:fragments' where we'd like to have
multiple (sibling) boxes for an element, where each can be styled
independently through a pseudo-element:
http://dev.w3.org/csswg/css-overflow-3/#fragment-overflow


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: CSS Grid Layout Module Level 1

[Mats Palmgren]

Summary:
CSS Grid defines a two-dimensional grid-based layout system, optimized for 
user interface design. In the grid layout model, the children of a grid 
container can be positioned into arbitrary slots in a flexible or fixed 
predefined layout grid.


Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=css-grid

Link to standard:
CSS Grid Layout Module Level 1
http://dev.w3.org/csswg/css-grid/

Platform coverage:
All Gecko platforms and products.

Estimated or target release:
TBD

Preference behind which this will be implemented:
layout.css.grid.enabled


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: CSS display:contents

[Mats Palmgren]

CSS display:contents has been enabled by default in v37 and my intent
is to ship this feature in v37 on all platforms.

It can be disabled by setting the hidden preference
layout.css.display-contents.enabled to false.

Link to standard:
CSS Display Module Level 3
http://dev.w3.org/csswg/css-display/#valdef-display-outside-contents

This feature was previously discussed in this intent to implement thread:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/display$3Acontents/mozilla.dev.platform/QEr_FYzdyCw/br1ovObRnhwJ

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1105369


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS display:contents

[Mats Palmgren]

On 02/02/2015 04:11 PM, Boris Zbarsky wrote:

On 2/1/15 4:36 PM, Mats Palmgren wrote:

CSS display:contents has been enabled by default in v37 and my intent
is to ship this feature in v37 on all platforms.


Do we have any indication on whether any other UAs are planning to ship this?


I'm not aware of other vendors' plans on display:contents, sorry.

FWIW, it's been in the spec for quite a long time though, first as
'box:contents' then as 'display-box:contents', and I haven't seen
any negative comments about it.


/Mats

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

Re: Intent to ship: the 'box-decoration-break' CSS property

[Mats Palmgren]

On 11/09/2014 06:28 PM, sime.vi...@gmail.com wrote:

On Friday, July 11, 2014 7:38:39 PM UTC+2, Mats Palmgren wrote:


IE10 has -ms-box-decoration-break



I've tested[1] this property in IE11 with the values slice and
clone. IE does not seem to support it. (I've also checked in older
versions via Document Mode in F12 tools.)


[1]: http://jsbin.com/zusuwo/1/edit?css,output



Right, it appears I was mistaken.  The rendering in IE when using a large
'border-radius' is quite broken and it looks a bit like 'clone' (as your
example shows) so I guess that's what lead me to believe it was supported.

I've corrected the MDN page, thanks!

/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: the 'box-decoration-break' CSS property

[Mats Palmgren]

As of 2014-07-08 support for the CSS property 'box-decoration-break'
has been turn on by default in Nightly (sorry for being late in
announcing that).  It's been developed behind the preference
layout.css.box-decoration-break.enabled.  The plan is to
enable it by default also on Aurora (32) to provide an upgrade
path for an old prefixed property (-moz-background-inline-policy)
which was removed.

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1006326

Link to standard:
http://dev.w3.org/csswg/css-break/#break-decoration

Chrome has shipped the prefixed property
-webkit-box-decoration-break

IE10 has -ms-box-decoration-break
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Keywords for flagging unreduced regression windows

[Mats Palmgren]

On 11/26/2013 08:10 PM, Josh Matthews wrote:

* regressionwindow-wanted, testcase-wanted: regression from earlier
versions is present, and some help crafting a testcase/clear steps to
consistently reproduce is desired


I think we should keep testcase and steps to reproduce as separate
notions.  There is a keyword to flag the absense of the latter:
steps-wanted.


* regressionwindow-wanted, testcase: regression from earlier versions is
present, and good STR have been identified


I don't think we should change testcase to also mean good STR have
been identified.  Again, we have a keyword for the latter: reproducible.
(testcase implies reproducible of course)

As I see it, a testcase is different from good STR.  It's usually
a small standalone file attached on the bug that reproduces the
problem.

So I think we already have keywords to represent the states you want.

* regressionwindow-wanted: regression from earlier versions is present,
but there are not clear, reproducible steps to follow (likely quite
complex/intermittent)

* regressionwindow-wanted, steps-wanted: regression from earlier versions
is present, and some help crafting a testcase/clear steps to consistently
reproduce is desired

* regressionwindow-wanted, reproducible: regression from earlier versions
is present, and good STR have been identified

* regressionwindow-wanted, reproducible, testcase-wanted: as above, but
we still want help producing a testcase from the STR

* regressionwindow-wanted, testcase: regression from earlier versions is
present, and we have a testcase that reproduces the problem

where the last three are variations of the state you labeled as
good STR have been identified.



so I propose being more explicit about this.


Yes, I fully agree. And that goes for any bug, not just regressions.


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

NS_MIN/NS_MAX replaced by std::min/std::max

[Mats Palmgren]

Our NS_MIN/NS_MAX C++ templates have been removed and we're now using 
std::min/std::max instead.


There's one exception: files under xpcom/ still use the old templates (now 
renamed as XPCOM_MIN/MAX) because #include algorithm is not allowed in 
some build configurations of xpcom.  See bug 786533 for details[1].


The change is in mozilla-inbound - it should be in mozilla-central soon.
comm-central has been fixed too.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=786533

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