On 1/3/17 4:48 PM, ktecrami...@gmail.com wrote:
>> e.g. It seems like introductory notes example could just use a
>> separate SVG element that had fixed positioning instead of needing to build
>> fixed-position into SVG.
>
> By "introductory notes example" do you mean the example in following link
It seems that generally, we don't need a clobber when adding new IDL
files -- but this was a special case where we do (and I've just pushed a
CLOBBER-tweak followup to inbound).
See https://bugzilla.mozilla.org/show_bug.cgi?id=1351461#c4 for a theory
about why.
~Daniel
On 3/28/17 1:43 PM, Andre
The very basics (at least) are semi-documented here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities#Checkin_comment
I frequently point people at that ^^ when they get it wrong (and e.g.
use the bug title as the commit message).
~Daniel
On
Agreed that this is footgunny & unexpected!
I'd lean slightly towards allowing the syntax and making it actually skip
the include expression. This construct seems valuable to have in our
toolbox (to be used only sparingly, e.g. for cases of platform-specific
features).
(Based on a quick grep[1],
The people.mozilla.org site was a general-purpose webserver for Mozilla
folks, and it was decommissioned entirely over the past few years. So,
that's why the study link there is broken.
You'd have to ask Josh (CC'd) if he has reposted (or could repost) the
study docs somewhere else.
~Daniel
On
Ah, I missed that Mike had replied -- it sounds like archive.org's
Wayback Machine is the easier way to get at the study, as compared to
bothering Josh. :)
On 2/26/18 9:26 AM, Daniel Holbert wrote:
> The people.mozilla.org site was a general-purpose webserver for Mozilla
> folks,
On Thu, Mar 29, 2018 at 8:19 AM, Mats Palmgren wrote:
> Hi,
>
> In bug 1398482 I'm unprefixing the grid-gap, grid-row-gap, and
> grid-column-gap properties
>
[...]
>
> These properties also applies to Flexbox:
> https://drafts.csswg.org/css-align-3/#gap-flex
> We haven't implemented layout for t
On Wednesday, February 17, 2016 at 9:11:43 PM UTC-8, Mike Taylor wrote:
> Howdy dev-platform (cross-posting fx-team for maximum synergy),
>
> A quick update on our progress of implementing the WebKit related deps
> of Bug 1170774.
>
> In Bug 1213126 we set layout.css.prefixes.webkit to true by d
On 09/01/2015 09:56 AM, Richard Barnes wrote:
> # Compatibility impact
>
> Disabling RC4 will mean that Firefox will no longer connect to servers that
> require RC4. The data we have indicate that while there are still a small
> number of such servers, Firefox users encounter them at very low rat
Summary:
A good chunk of the web today (and particularly the mobile web)
effectively relies on -webkit prefixed CSS properties & features. We
wish we lived in a world where web content always included
standards-based fallback (or at least multiple-vendor-prefixed
fallback), but alas, we do not li
On 12/31/2015 11:37 AM, Martin Thomson wrote:
> If we intend to continue to support these,
(We do.)
> and particularly if we
> anticipate more prefixed rules in future
(Happily, I don't anticipate too many more of these -- at least, the
space of -webkit-prefixed features is bounded, because impl
On 12/31/2015 01:15 PM, Daniel Holbert wrote:
> (1) Dubious effectiveness:
[...]
> (2) Dubious usefulness: Given that these prefixed features will now
> Just Work in Firefox, and given that we're saying they're de-facto part
> of the web & committing to supporting
Heads-up, from a user-complaint/ support / "keep an eye out for this"
perspective:
* Starting January 1st 2016 (a few days ago), Firefox rejects
recently-issued SSL certs that use the (obsolete) SHA1 hash algorithm.[1]
* For users who unknowingly have a local SSL proxy on their machine
from spyw
On 01/04/2016 09:47 AM, Eric Rescorla wrote:
> I believe that Chrome will be making a similar change at a similar time
>
> -Ekr
In contrast, it looks like IE & Edge will continue accepting SHA1 certs
on the web for another full year, until 2017. [1][2]
~Daniel
[1] https://blogs.windows.com/msed
On 01/04/2016 10:21 AM, Adam Roach wrote:
> I propose that we minimally should collect telemetry around this
> condition. It should be pretty easy to detect: look for cases where we
> reject very young SHA-1 certs that chain back to a CA we don't ship.
> Once we know the scope of the problem, we ca
On 01/04/2016 10:18 AM, Eric Rescorla wrote:
> I believe you are confusing two different things.
>
> 1. Whether the browser supports SHA-1 certificates at all.
> 2. Whether the browser supports SHA-1 certificates signed after Jan 1 2016
> (The CA/BF Baseline Requirements forbid this, so no publicl
On 01/04/2016 10:33 AM, Josh Matthews wrote:
> Wouldn't the SSL cert failures also prevent submitting the telemetry
> payload to Mozilla's servers?
Hmm... actually, I'll bet the cert errors will prevent Firefox updates,
for that matter! (I'm assuming the update-check is performed over HTTPS.)
So
On 01/04/2016 10:43 AM, Richard Barnes wrote:
> I was being a bit glib because I think in a lot of cases, it won't be
> just Firefox that's affected -- all of the user's HTTPS will quit
> working, across all browsers.
As noted else-thread, IE seems to be working just fine, and I'm not sure
it'll s
On 01/04/2016 12:19 AM, Daniel Holbert wrote:
> I wasn't able to
> remotely figure out what the piece of spyware was or how to remove it --
> but the rejected certs reported their issuer as being "Digital Marketing
> Research App" (instead of e.g. Digicert or Verisign).
On 01/04/2016 12:07 PM, Daniel Holbert wrote:
> UPDATE: in my family friend's case, the shoddy MITM spyware in question
> was "Simmons Connect Research Application", a consumer profiling tool
> that's tied to Experian which users can voluntarily install in exchange
>
For reference, I've now filed a bug to cover outreach for the specific
tool that this user was using:
https://bugzilla.mozilla.org/show_bug.cgi?id=1236664
I'm also trying to get my hands on the software, but it's "invitation
only", so that may prove difficult.
~Daniel
__
I believe this is a version of
https://bugzilla.mozilla.org/show_bug.cgi?id=1030952
The underlying issue is described here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1030952#c2
I believe the tentative patch there works, but it's not sufficient to
entirely fix the bug, as discussed in
https:
We still have documentation on MDN with the old rules:
"The uuid must be changed anytime any part of the
interface or its ancestors are changed"
https://developer.mozilla.org/en-US/docs/Mozilla/XPIDL#Interfaces
Ehsan, could you update that section of the page to reflect the new
state of the
Just to clarify, you're *only* talking about browser-chrome mochitests
here, correct? (not other mochitest suites like mochitest-plain)
(It looks like this is the case, based on the bug, but your dev.platform
post here made it sound like this change affected all mochitests.)
Thanks,
~Daniel
On
On 02/12/2016 11:02 AM, Armen Zambrano G. wrote:
> On 16-02-09 01:32 PM, Daniel Holbert wrote:
>> Just to clarify, you're *only* talking about browser-chrome mochitests
>> here, correct? (not other mochitest suites like mochitest-plain)
>>
>> (It looks like this is
On 03/21/2016 10:38 PM, Jet Villegas wrote:
> I'd like to see this guarded by its own pref && layout.css.prefixes.webkit
Pushing back on this slightly:
- At this point, I don't think it's conceivable that we'd want to ship
our webkit compatibility work until we're ready to also ship support for
"
On 03/22/2016 02:16 PM, Mike Taylor wrote:
> +1. It has been nice to have a single pref to flip to test for potential
> regressions (and for instructing people to do the same thing).
That's probably not a big concern here -- even if we ship this with its
own dedicated feature-pref, we could still
On 03/22/2016 04:53 PM, Jet Villegas wrote:
> I'm thinking we need two prefs so we cover the prefixed and unprefixed
> API as per:
> https://lists.w3.org/Archives/Public/www-style/2016Mar/0283.html
>
> It's a bit odd to have the -webkit parser pref also control the
> rendering pref in this case.
On 04/08/2016 10:38 AM, Jip de Beer wrote:
> I didn't manage to dump the Frame Tree using lldb... I followed these guides:
[...]
> I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran lldb
> from Terminal as well as Xcode).
> I was able to attach lldb to the browser, but not
On 04/08/2016 02:55 PM, Daniel Holbert wrote:
> On 04/08/2016 10:38 AM, Jip de Beer wrote:
>> I didn't manage to dump the Frame Tree using lldb... I followed these guides:
> [...]
>> I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran
>> lldb f
On 04/14/2016 02:40 AM, Ms2ger wrote:
>> Preference behind which this will be implemented:
>> layout.css.prefixes.webkit
>
> Should this have a more specific pref?
Absent a compelling reason, no -- it should not.
We're using layout.css.prefixes.webkit here because, without this
-webkit-text-stro
On 12/30/2015 10:40 PM, Daniel Holbert wrote:
> Estimated or target release:
> Firefox 46 (current Nightly), or 47 if we need to hold it back a
> release to fix things.
>
> Preference behind which this will be implemented:
> layout.css.prefixes.webkit
Following up on th
On 05/13/2016 10:49 AM, Jet Villegas wrote:
> If I'm reading the dependency list correctly, we still plan to uplift to
> 48 if we can get bug 1264905 fixed in time. Is that correct?
bug 1264905's fix (a pref-unguarding) was just landed, as well.
We could uplift both, if we *also* uplift bug 12699
On 07/25/2016 07:11 AM, Ms2ger wrote:
> Hey Jonathan,
[...]
> Do we know how other vendors feel about this?
Sentiment seems to be positive.
Browser vendors are collaborating on developing the Houdini specs, and I
haven't heard any serious reservations on this spec. (This is among the
more simple/
Firefox's behavior on that testcase matches an older version of the spec
(and then the spec changed).
This bug...
https://bugzilla.mozilla.org/show_bug.cgi?id=1000957
...is filed on bringing us up-to-date on that point.
~Daniel
On 08/07/2016 05:16 AM, Amit Zur wrote:
> Hey,
>
> Take a look a
ollable inner
> containers?
>
> Also, is it planned to ship in a near nightly?
>
> On Sunday, August 7, 2016 at 10:23:01 PM UTC+3, Daniel Holbert wrote:
>> Firefox's behavior on that testcase matches an older version of the spec
>> (and then the spec change
On 08/08/2016 10:12 AM, Daniel Holbert wrote:
> The fix in Firefox should be a pretty simple change, I think, but
> unfortunately we haven't gotten to it yet. I can prioritize it to fix
> in the next week or so, though that still means it wouldn't reach
> Firefox release
Just a heads-up, for anyone working on layout / style-system-related code:
In bug 1293739 [1], Jonathan Chan has some patches that will rename the
enumerated type "nsCSSProperty" to now be named "nsCSSPropertyID"
(adding the "ID" suffix). I plan on landing his patches on inbound later
today.
It's
On 08/12/2014 07:59 AM, Benjamin Smedberg wrote:
> But now that nsCOMPtr/nsRefPtr support proper move constructors, [...]
> Could we replace every already_AddRefed return value with a nsCOMPtr?
I have a variant of bsmedberg's original question here. He asked about
return values, but I'm wondering:
On 09/12/2016 11:00 AM, Boris Zbarsky wrote:
> On 9/12/16 1:53 PM, Daniel Holbert wrote:
>> (I believe we have the "already_AddRefed as a parameter" pattern in our
>> code in order to avoid an extra addref/release when ownership is being
>> transferred into a funct
On 09/12/2016 12:22 PM, Boris Zbarsky wrote:
> It's worse than that. For a wide range of callers (anyone handing the
> ref across threads), the caller must check immediately whether the
> callee actually took the value and if not make sure things are released
> on the proper thread...
Ah, ok; I c
On 09/21/2016 12:48 PM, ISHIKAWA,chiaki wrote:
> In the following URL about coding style,
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
> --- begin quote ---
> if (NS_WARN_IF(somethingthatshouldbetrue)) {
> return NS_ERROR_INVALID_ARG;
> }
>
> if (NS_WARN_IF(NS_
On 09/21/2016 08:41 PM, Samael Wang wrote:
> The NS_ASSERTION document [1] says "Don't use NS_ASSERTION", which could be a
> bit confusing that now some of the similar named macros may be deprecated but
> some are new and encouraged.
I think that document's advice is too severe.
roc made a comp
On 10/07/2016 12:49 AM, Gian-Carlo Pascutto wrote:
> This behavior can be controlled via a pref:
> pref("security.sandbox.content.level", 2);
>
> Reverting this to 1 goes back to the previous behavior
Warning: don't actually try to revert this to 1, just yet -- at the
moment, that triggers startu
On 12/21/2016 10:57 AM, mtana...@yandex.ru wrote:
> Fwiw, there is also a feature request for Edge:
>
> https://wpdev.uservoice.com/forums/257854/suggestions/17420707
[...]
> https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10152756/
>
> For some reason cannot add any of those
On 02/25/2013 01:57 PM, Bobby Holley wrote:
> We clone static copies of documents for print preview. We could
potentially
> do the same for normal printing, I'd think.
I'm almost certain that we already do. (smaug would know for sure)
___
dev-platform ma
As of this morning, our Margin C++ classes now take args in the order...
top, right, bottom, left
...to be consistent with CSS margins and other public APIs. They
formerly took args in the order "left, top, right, bottom". I made this
switchover in https://bugzilla.mozilla.org/show_bug.cgi?id=8
Stepping back: [
This issue is really a special case of "This patch compiles fine in my
local configuration, but it busts the build for $OTHER_PLATFORM".
The general solution to this class of problems is a try push, with
builds on at least one platform other than your local config (if not all
plat
how_bug.cgi?id=858224
~Daniel
On 04/03/2013 04:56 PM, Daniel Holbert wrote:
> Stepping back: [
> This issue is really a special case of "This patch compiles fine in my
> local configuration, but it busts the build for $OTHER_PLATFORM".
>
> The general solution to this cla
Would this mean that Beta-channel users would see some features appear
on release-day, and then disappear a couple weeks later, and then those
same features (plus maybe some new ones) would suddenly reappear on the
next release day, and then potentially disappear again? (etc)
This seems like it co
See also https://bugzilla.mozilla.org/show_bug.cgi?id=879275 , which bz
filed on (possibly, at some point) turning off support for -moz-box on
the web.
~Daniel
On 06/13/2013 08:56 PM, Robert O'Callahan wrote:
> Bug 875060 made me wonder whether we should disable XUL 'display' values on
> the Web,
> This wiki page: https://wiki.mozilla.org/Features/Release_Tracking
> now picks up on the keyword 'feature' in your meta/tracking bugs.
FWIW, our bugzilla instance currently has a definition for this keyword
that is Fennec-specific:
feature
Keyword to enable tracking new features for Fennec N
On 11/15/2013 03:16 PM, ops...@gmail.com wrote:
> adding either
> export CXXFLAGS="-std=gnu++0x"
> or
> export CXXFLAGS="-std=gnu++11"
> both seem to work. From Mozilla's perspective -- is one preferable?
FWIW, it looks like Mozilla uses the former (gnu++0x) in the build system:
http://mxr.m
On 11/22/2013 12:18 PM, Benjamin Smedberg wrote:
> If you are writing code that wants to issue
> warnings when methods fail, please either use NS_WARNING directly or use
> the new NS_WARN_IF macro.
>
> if (NS_WARN_IF(somethingthatshouldbetrue))
> return NS_ERROR_INVALID_ARG;
>
> if (NS_WARN_IF(
On 01/06/2014 03:10 PM, Karl Tomlinson wrote:
> Martin Thomson writes:
>
>> I would like to think that adding (or removing) braces from block statements
>> should be acceptable.
>
> I would argue that braces should not be added with automation.
>
> When debugging code, it is important to underst
On 01/09/2014 03:33 AM, Neil wrote:
> This does not apply to AssignLiteral on an nsString, since that used to
> take a char (&)[] parameter. Instead, consider assigning an
> NS_LITERAL_STRING, or you can also use the new char16_t overload of
> AssignLiteral by wrapping your string constant in MOZ_U
On 02/22/2014 12:26 PM, Hubert Figuière wrote:
> Now we talk about enabling more warning, yet Mozilla codebase is far
> from building warning free
>
> Maybe we should start with that first?
FWIW, I (and others) have been working on that, as a side project, for a
while now, and I think we're a
On 02/24/2014 08:25 AM, Sylvestre Ledru wrote:
> By the way, do you have any plan to do the same with these libraries and
> forward
> the patches upstream?
I don't have concrete plans to do this, but others are welcome to!
It's often more difficult (with less immediate benefit) to fix warnings
in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2014 10:26 AM, Zack Weinberg wrote:
> Does that mean a patch to squelch the uninitialized variable
> warnings in layout will now be accepted? Those are the only
> warnings in layout on my (Linux, debug) builds.
>
>> layout/base/FrameLayerBui
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2014 12:57 PM, L. David Baron wrote:
>> I also defy anyone to demonstrate a measurable performance impact
>> from the tiny amount of additional machine code that might be
>> emitted if we added initializations to squelch all those
>> warnings.
On 02/28/2014 05:32 PM, L. David Baron wrote:
> Why not change the try repo reset procedure so that instead of just
> cloning mozilla-central, you also pull from the old try repo into
> the new one all of the heads of try pushes made within the last one
> or two weeks. (Presumably there's a list o
On 04/01/2014 08:56 AM, Zack Weinberg wrote:
> The downside of turning this on would be that any switch
> statements that *deliberately* include only a subset of the
> enumerators, plus a default case, would now have to be expanded to
> cover all the enumerators. I would try it and report on how
>
On 03/07/2014 02:41 PM, Hal Wine wrote:
> On 2014-02-28 17:24 , Hal Wine wrote:
>> tl;dr: what is the balance point between pushes to try taking too long
>> and loosing repository history of recent try pushes?
> Based on the responses to this specific question, we'll go back to
> waiting for develo
On 05/18/2014 08:16 PM, Dave Hylands wrote:
> My interpretation of this is that the only time braces go on the end of the
> line is when you're starting a "control structure"
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Control_Structures
>
...and when you're
On 05/20/2014 03:13 PM, Rik Cabanier wrote:
> On Tue, May 20, 2014 at 9:16 AM, Gavin Sharp wrote:
>> Arguing that the incremental fingerprinting risk
>> is negligible is reasonable, but you lose credibility if you suggest
>> it doesn't exist.
>
>
> I don't follow. Where did I say that the finger
On 05/20/2014 03:50 PM, Rik Cabanier wrote:
> I agree that there's a risk since this will make it super easy to get to
> the core count.
> I don't have the exact number but I suspect that very few machines will
> have more than 8 cores which makes them valuable for targeted marketing.
(To be clear
On 05/20/2014 04:06 PM, Daniel Holbert wrote:
> On 05/20/2014 03:50 PM, Rik Cabanier wrote:
>> I agree that there's a risk since this will make it super easy to get to
>> the core count.
>> I don't have the exact number but I suspect that very few machines will
Hi dev-platform,
PSA: if you are adding a concrete class with AddRef/Release
implementations (e.g. via NS_INLINE_DECL_REFCOUNTING), please be aware
of the following best-practices:
(a) Your class should have an explicitly-declared non-public
destructor. (should be 'private' or 'protected')
(b)
ctorPrivateOrDeleted::value);
> }
>
>
> Output:
>
>
> std::is_destructible::value = 0
> std::is_destructible::value = 0
> std::is_destructible::value = 1
>
> IsDestructorPrivateOrDeleted::value = 1
> IsDestructorPrivateOrDeleted::value = 1
> IsDestructorPrivateOrDeleted::value
On 06/03/2014 07:32 AM, Gabor Krizsanits wrote:
> Currently m-c does not build with gcc 4.6 on ubuntu because something
> similar. After
> updating to 4.8 I got some warning in webrtc code, so I had to turn off
> warning-as-errors.
FWIW, you can work around that with "ac_add_options --disable-we
On 06/03/2014 04:25 PM, Mike Hommey wrote:
> As for warning-as-errors, it's not meant to be used for local builds,
> because different compilers don't come with the same set of warnings.
I think that might be putting it a bit too strongly. Warnings-as-errors
absolutely *is* meant to be used with
On 07/09/2014 08:16 AM, Gijs Kruitbosch wrote:
> On 09/07/2014 16:00, Tobias B. Besemer wrote:
>> My next run would be "Status = Assigned" & "Assigned To =
>> nob...@mozilla.org" ...
>>
>> Tobias.
>
> Please don't mass change the target milestone flag on bugs (definitely
> not manually). Same goes
On 07/09/2014 08:33 AM, Gijs Kruitbosch wrote:
> Either change should be done through a mass change that doesn't cause
> bugmail, so not by a casual contributor without the right bmo
> privileges. Otherwise we're just wasting (a) a lot of their and our
> (collective) time, and (b) don't gain very m
On 07/10/2014 02:48 AM, Neil wrote:
> Except for refcounted base classes (which as you note need to have a
> protected virtual destructor), is there a correct style as to whether
> the destructor should be private or protected and virtual or nonvirtual?
IMO, the destructor should be nonvirtual, si
On 07/10/2014 08:03 AM, Benjamin Smedberg wrote:
> On 7/10/2014 10:46 AM, Daniel Holbert wrote:
>> Shouldn't the refcounting still be on the concrete classes?
> Why?
>
> This happens for example with nsRunnable: nsRunnable does the
> refcounting, and all the derivations
Summary: The 'object-fit' and 'object-position' properties allow web
developers to customize how a replaced element's content gets scaled and
positioned to fit the element's content-box. (i.e. how an image or a
video gets scaled/positioned inside of an / tag) The
'object-fit' property lets authors
On 09/10/2014 05:26 PM, Jonas Sicking wrote:
> Yes!
>
> Do we have a sense for how supportive other browser vendors are of
> these properties?
Supportive! I haven't tested other browsers' implementations yet, but I
do know that it's been implemented in Blink, and it was apparently
undergoing code
Summary: The CSS declaration "image-rendering: pixelated" allows authors
to request that we scale up images by effectively making the pixels
larger (using a "nearest-neighbor" algorithm). This is in contrast to
the default (non-pixelated) scaling behavior, which tends to blur the
edges between an
On 09/23/2014 02:16 PM, Ehsan Akhgari wrote:
> Why are upscaling and downscaling treated differently for pixelated?
I'm not entirely sure what the origin of that distinction is, but my
understanding (mostly from reading Tab's comments/responses on the Blink
intent-to-implement thread) is that Near
On 09/23/2014 02:39 PM, Daniel Holbert wrote:
> On 09/23/2014 02:16 PM, Ehsan Akhgari wrote:
>> Why are upscaling and downscaling treated differently for pixelated?
>
> I'm not entirely sure what the origin of that distinction is, but my
> understanding (mostly from
On 09/23/2014 02:56 PM, Daniel Holbert wrote:
> FWIW, I also emailed www-style to sanity-check my understanding & to see
> if there are any other reasons for this behavior-difference:
> http://lists.w3.org/Archives/Public/www-style/2014Sep/0340.html
Turns out there wasn't a str
On 09/23/2014 04:24 PM, Jonas Sicking wrote:
> Would it make sense to have separate properties for "scale up" and
> "scale down"? With image-rendering being a shorthand for setting both?
Firstly: per my replies on the subthread started by ehsan, the
distinction in "scale up" vs. "scale down" behav
On 09/23/2014 04:38 PM, Daniel Holbert wrote:
> On 09/23/2014 04:24 PM, Jonas Sicking wrote:
>> Would it make sense to have separate properties for "scale up" and
>> "scale down"? With image-rendering being a shorthand for setting both?
>
> Firstly: p
On 09/23/2014 10:08 PM, Martin Thomson wrote:
> On 2014-09-23, at 13:53, Daniel Holbert wrote:
>
>> Link to standard:
>> http://dev.w3.org/csswg/css-images/#valuedef-pixelated
>
> Reading the spec it doesn’t say anything about what to do when the image is
> scaled
On 09/23/2014 01:53 PM, Daniel Holbert wrote:
> Link to standard:
> http://dev.w3.org/csswg/css-images/#valuedef-pixelated
As noted elsethread (in my response to Martin), it looks like the
canonical definition of this property-value is actually in a different
ED -- the "level 3"
On 09/23/2014 10:30 PM, Daniel Holbert wrote:
> As noted elsethread (in my response to Martin), it looks like the
> canonical definition of this property-value is actually in a different
> ED -- the "level 3" ED. (whereas the link above is currently the "level
> 4"
On 09/24/2014 09:32 AM, L. David Baron wrote:
> Or, alternatively, it seems like the use case here would be
> addressed by doing what the spec said before. Is it really that
> much harder to do?
No, it's not much harder.
> Is it just that we'd need to add another value to pass through
> variou
On 09/24/2014 07:38 AM, Ehsan Akhgari wrote:
>> This makes the implementation considerably simpler, which is great. It
>> also means that "pixelated" will essentially just be a
>> more-interoperable version of "-moz-crisp-edges", for the time being.
>
> So, what are we planning to do with -moz-cr
On 09/24/2014 09:32 AM, L. David Baron wrote:
> Or, alternatively, it seems like the use case here would be
> addressed by doing what the spec said before.
Following up more on this: the CSSWG has now resolved to *allow* (but
not require) the formerly-required-by-spec prettier downscaling
behavio
On 09/24/2014 06:26 PM, Ehsan Akhgari wrote:
> Hmm, doesn't that basically allow non-interoperable implementations? :(
> I think Jonas' idea on having separate properties for the upscale vs.
> downscale cases is much better.
I'm unconvinced about the usefulness of exposing that much control. This
On 09/24/2014 09:23 PM, Daniel Holbert wrote:
> So, it's not required to behave exactly the same everywhere; it simply
> codifies an author's intent. (OK, I suppose it *is* required to behave
> exactly the same everywhere in the case of "pixelated" & upscaling,
&
On 09/25/2014 09:16 AM, Ehsan Akhgari wrote:
> No, sorry for not being clear, I didn't mean pixel for pixel identical
> results. My question was: are we going to have the same behavior for
> pixelated in the downscaling case, since now the spec allows two
> different behaviors for that case.
Gotc
On 09/25/2014 08:24 AM, James Graham wrote:
> So, are we sure that this is what the spec *should* say? can we imagine
> a scenario in which authors either use hacks to specify different
> properties for different browsers
Bad news: we are already in that world. Right now, if authors want
pixelated
On 09/25/2014 09:10 AM, Jet Villegas wrote:
> Would it be wise to allow for "image-rendering: pixelated"
> that applies to any scale operation, and give us an option
> to add other operations (eg. "image-rendering: smooth" or
> "image-rendering: bilinear") later?
Down the line, we can definitely a
On 10/09/2014 02:39 AM, yio...@gmail.com wrote:
> Which version of the official opening?
It's looking like "object-fit" & "object-position" will be released in
Firefox 36, if that's what you're asking.
You can follow along on the bug page:
https://bugzilla.mozilla.org/show_bug.cgi?id=624647
Thi
On 09/25/2014 10:29 AM, Ehsan Akhgari wrote:
>> I don't see this temporary difference as particularly problematic,
>> particularly given that "pixelated" is primarily an upscaling feature,
>> and given that we'll match them before too long. But if others
>> disagree, I'm open to holding off on shi
This is known/expected fallout from a spec change. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1043520 for other trouble
that it's caused. :-/
tl;dr: you need to set "min-height:0" on the 'section' to get the
behavior you want. Here's the fixed version:
http://jsfiddle.net/vyhf2rzL/2/
Basic
On 11/10/2014 01:44 AM, Josip Maras wrote:
> How can I build a normal, standard Firefox installer for Windows,
> like the one distributed to standard Firefox users?
I don't know the answer to your specific question (I've never personally
had to build the installer), but just as a heads-up: you can
As of sometime early next week (say, Nov 17th 2014), I intend to turn on
support for the "object-fit" & "object-position" CSS properties by default.
They have been developed behind the
"layout.css.object-fit-and-position.enabled" preference. (The layout
patches for these properties are actually ju
Here's the intent to ship thread, for reference:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/DK_AyuGfFhg
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
1 - 100 of 138 matches
Mail list logo
