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 not
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
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://telem
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 reaso
On 10/18/19 12:31 AM, ikilpatr...@chromium.org wrote:
Again "multiple dipslay values" are probably in the "trivial" feature
bucket (if that exists).
FYI, those weren't just syntax changes - we also added layout support
for 'inline list-item' and 'block ruby' for example, which I wouldn't
call t
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,
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
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
I intend to enable CSS subgrid by default for v71.
*Summary: *
The CSS Grid 2 subgrid feature allows nested grids to participate in the
sizing of their parent's tracks, on a per-axis basis.
*Bug to turn on by default: *
https://bugzilla.mozilla.org/show_bug.cgi?id=1580894
*Meta bug where this
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 "tabl
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.
/M
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 layo
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.mozi
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
Preferenc
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:/
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 t
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
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
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 hav
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 supp
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 151
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:
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 mat
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-prop
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 side
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.cs
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
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...
Fil
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
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 c
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-ap
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
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 replac
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/#a
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 h
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
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 addin
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 rem
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
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 form
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:/
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
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 p
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
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 cas
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 b
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 doe
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)
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/5e17f9181c6cb0968966280d1c1d96e
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 an
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-platfor
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
Hi Tim, can you describe how the modality of dialog.showModal() works?
Does a web page have the power to block the user from interacting
with the entire browser (all windows)? Or is it just one window?
or just one tab? or something else?
Thanks,
Mats
_
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.
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 i
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
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 (includi
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
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.enable
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:
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
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-characte
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.or
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 expressio
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, provid
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 (
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 di
On 03/27/2015 09:28 PM, Robert O'Callahan wrote:
As a followup it's probably worth replacing all of nsIntSize with
gfx::IntSize.
I think we should stop using these unit-less types in layout and
convert the few remaining uses to the unit-bearing types in
layout/base/Units.h instead.
I'm taking
On 03/27/2015 04:42 PM, Jan De Mooij wrote:
On the other hand, going from 99 columns to 80 will also be
annoying in a bunch of places.
I don't think that's necessary. Let's relax our 80-column rule
in Gecko instead. We can keep it as a recommendation, but allow
longer lines when it improves r
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,
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
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 thi
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_bu
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
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'
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-displa
Summary:
Styling an element with display:contents will inhibit generating
a box for the element, but its children and pseudo-elements still
generate boxes as normal.
Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=907396
Link to standard:
CSS Display Module Level 3
http://dev.w3.org/csswg/css-
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
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 p
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
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 is not allowed in
some build configurations of xpcom. See bug 786533 for deta
On 10/29/2012 07:47 PM, Jan Honza Odvarko wrote:
Is there any depth limit for HTML elements in a document?
Yes, around 200 or so.
http://dxr.mozilla.org/search.cgi?tree=mozilla-central&string=MAX_REFLOW_DEPTH
___
dev-platform mailing list
dev-platf
82 matches
Mail list logo
