Re: Changing the representation of rectangles in platform code
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: Changing the representation of rectangles in platform code
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
Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.
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: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.
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&utf8=%E2%9C%93&q=-webkit-appearance+none&type=Code&ref=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
Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.
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'.
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'.
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'.
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: Coding style: Placement of binary operators when breaking a long line
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: Coding style: Argument alignment
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: Argument alignment
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
PSA: Microsoft VMs for testing
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: Intent to ship: CSS Shapes Module Level 1 (partial)
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
Intent to unprefix grid-gap, grid-row-gap, and grid-column-gap and updating them to spec
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
Intent to implement: CSS subgrid
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
Re: Intent to unship: URL.createObjectURL(MediaStream)
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
Re: Intent to ship: Directory picking and directory drag-and-drop
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: Proposal: revisit and implement navigator.hardwareConcurrency
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: Triage Plan for Firefox Components
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: Coding style for C++ enums
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: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.
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
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: MXR permanently offline, please transition to DXR
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: Upcoming hg.mozilla.org certificate change
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
Intent to ship: CSS Grid
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: Intent to ship: CSS Grid
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
Re: Intent to ship: CSS Grid
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: Who loves multiple selection feature in editor?
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: Who loves multiple selection feature in editor?
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?
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: Intent to implement: HTML5 element
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 ___ 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
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: Intent to implement and ship: CSS display:flow-root
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
Re: Keywords for flagging unreduced regression windows
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
Intent to ship: the 'box-decoration-break' CSS property
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: Intent to ship: the 'box-decoration-break' CSS property
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 implement: CSS display:contents
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-display/#valdef-display-outside-contents Platform coverage: all Gecko based products Estimated or target release: Landed, disabled by default, in Firefox 36. Turning on the pref by default: TBD https://bugzilla.mozilla.org/show_bug.cgi?id=1102374 Preference behind which this will be implemented: layout.css.display-contents.enabled ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: CSS display:contents
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
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: CSS display:contents
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: tr {display:contents} 12 34 The above table will have one row with four cells in layout. In terms of CSS box construction it's identical to: 12 34 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
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
Re: Intent to implement: CSS Grid Layout Module Level 1
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
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: Using rr with test infrastructure
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: SpiderMonkey and XPConnect style changing from |T *p| to |T* p|
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 readability of the code. In Layout, where I spend most of my time, we tend to prefer ReallyLongAndDescriptiveNames which often leads to weird line- breaking and indentation to make the code fit in 80 columns. This makes the code hard to read and maintain, not to mention the *significant* waste of time for the writer to try to squeeze it down to fit. I have to admit that I have sometimes chosen shorter and less descriptive names just to avoid the problem and I've seen others do the same (most recently today actually when reviewing some code). So let's change the project-wide coding rules instead to allow 99 columns as the hard limit, but keep 80 columns as the recommended (soft) limit. /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: From nsIntSize to gfx::IntSize
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 a stab on a couple of those so I'd prefer if you leave nsIntSize as is for now in layout/ to avoid conflicts. /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
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 ship '-webkit-appearance' and changes to '-moz-appearance' values
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: Enabling (many) assertions in opt builds locally and eventually Nightly
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
Intent to unship: most -moz-appearance values not supported by other UAs / spec
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: Intent to implement: Reporting API
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 Implement and Ship: CSS padding-block and padding-inline shorthands
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 and Ship: CSS padding-block and padding-inline shorthands
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 margin-block and margin-inline shorthands
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&l=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
Intent to Implement and Ship: CSS inset/inset-block/inset-inline shorthands
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 border-{block,inline}-{color,style,width} and border-{block,inline} shorthands
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: The border-{start,end}-{start,end}-radius CSS properties
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 'prefers-color-scheme' media feature
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: CSS counter-set property
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: built-in CSS counter 'list-item'
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 ::marker pseudo-element
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
Re: Intent to implement and ship: built-in CSS counter '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 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
Re: Intent to implement and ship: built-in CSS counter 'list-item'
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: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_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, 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
Intent to ship: CSS 'display:inline list-item' and 'display:inline flow-root list-item'
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
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
Intent to ship: CSS 'display:block ruby'
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
Re: Intent to ship: CSS 'display:block ruby'
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
Re: Intent to ship: multi-keyword values on the CSS 'display' property
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
PSA: Removing display:-moz-inline-grid and -moz-inline-stack
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
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
Intent to ship: CSS subgrid
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 feature is developed:* https://bugzilla.mozilla.org/show_bug.cgi?id=1240834 *Standard:* https://drafts.csswg.org/css-grid-2/#subgrids *Platform coverage:* All platforms. *DevTools bug:* Subgrid is supported in devtools. Metabug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464440 *Other browsers: * Blink/WebKit doesn't support subgrid so far, but it is expected that they eventually will. Folks from Igalia and others have been participating in the spec discussions. *web-platform-tests: * https://github.com/web-platform-tests/wpt/tree/master/css/css-grid/subgrid *Secure contexts:* N/A *Note:* There is one unresolved spec issue under discussion: https://github.com/w3c/csswg-drafts/issues/4411 which might require updating our implementation. I don't feel like it's a major issue that needs to block us from shipping. There should be a resolution soon and hopefully we can uplift any potential changes as a bug fix before it's released. /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
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: CSS subgrid
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
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
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 trivial (not in the sense of "adding a new color value" anyway). /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: MathML mfenced element
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 unship: MathML mfenced element
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&group=DEPRECATED&channel=beta&version=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 Prototype: CSS Masonry layout
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
Intent to ship: CSS overflow:clip
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
Re: HTML depth limit?
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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
NS_MIN/NS_MAX replaced by std::min/std::max
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 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