Intent to implement: -webkit-line-clamp
Summary: -webkit-line-clamp is a feature implemented in WebKit, Blink, and Edge that allows authors to control the height of a block so that it contains at most the specified number of lines, and if there are excess lines, an ellipsis is inserted in the last non-excess line. http://dropshado.ws/post/1015351370/webkit-line-clamp Lack of support for -webkit-line-clamp is a common cause of Web compatibility problems in Gecko, particularly on mobile sites. Unfortunately, this feature is an odd duck in the existing implementations, since: 1. It only has an effect in `display: -webkit-box` and `display: -webkit-inline-box` elements. 2. Any excess lines are still displayed, and overflow the box. Authors must (and do) use `overflow: hidden` to hide them. 3. -webkit-line-clamp is implemented as an additional constraint on the intrinsic size of the element (like a max-block-size property), and so usually only has an effect if `-webkit-box-orient: vertical` is also specified. The CSS Working Group is attempting to define a standards-based solution that is sufficiently compatible with existing content. As currently written, I think the standard line-clamp property (if we also support it with the -webkit prefix) should be compatible with the content we know we are currently broken on, although there is some risk of breakage due to the property applying to more elements. This solution would need a more complex solution than WebKit/Blink currently have, however. (Rather than just adjusting an input to the intrinsic sizing of the element, it would require fragmenting the excess lines away and suppressing them, something we don't have the concept for internally at the moment.) The current spec does capture the use case of just limiting the number of lines in an element more sensibly than the existing implementations, though. My current plan is to implement something closer to the existing implementations since (a) it is simpler, and (b) there is less risk of compatibility problems introduced by -webkit-line-clamp applying to more elements than in WebKit/Blink. I will then provide feedback on the spec to support this behavior, or if that's not possible, get something added to the Compat spec. Implementing the full fragmentation based line-clamp solution can be a followup task at some point. Note that there seems to be some desire in Blink to replace -webkit-line-clamp's behavior with something that lives in a spec (https://bugs.chromium.org/p/chromium/issues/detail?id=305376) but I am doubtful that support for it can be removed entirely. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=866102 Link to standard: https://drafts.csswg.org/css-overflow-3/#line-clamp Platform coverage: everywhere Estimated or target release: Firefox 68 Preference behind which this will be implemented: layout.css.webkit-line-clamp.enabled Is this feature enabled by default in sandboxed iframes? yes DevTools bug: as this is being implemented only for compatibility I don't think it's appropriate to build a DevTools feature for it Do other browser engines implement this? yes (WebKit, Blink, and Edge) web-platform-tests: none exist (and I don't plan to write WPTs until I manage to get the spec changes made) Is this feature restricted to secure contexts? no (other engines don't restrict it) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for compiling with MSVC in the near future
Hi, Bug 1512504 has now landed on autoland, meaning that compiling Firefox with MSVC is now not supported anymore. MSVC is however still necessary as a build requirement for its headers and libraries (as well as its assembler on aarch64 and the preprocessor for midl ; and maybe a few other things) Mike On Thu, Dec 06, 2018 at 03:00:12PM -0500, Ted Mielczarek wrote: > Hello, > > In light of the fact that we've switched to clang-cl for our Windows > builds[1], we are planning to drop support for compiling Firefox with MSVC in > the near future[2]. Our estimate is that this will happen sometime in Q1. > Supporting more than one compiler is a maintenance burden and we've already > seen developers spend considerable time getting their patches that work with > clang-cl to build with MSVC. We are currently blocked by the fact that our > aarch64-windows builds are still using MSVC and we are waiting on upstream > clang-cl work to switch those builds to clang-cl. Once that takes place we no > longer have a compelling reason to continue supporting MSVC. > > To preempt the question--when this happens we intend to make MSVC error in > configure, and not just move MSVC to Tier 3 "patches welcome" status. Our > reasoning is that Tier 3 configurations still create work: developers spend > time building in those configurations, and lack of CI coverage means that > when they inevitably break they waste time trying to fix things. Bugs get > filed, and other developers waste time trying to help or reviewing patches to > fix things. Explicitly unsupporting MSVC is the best way for us to convey the > fact that developers should not be using it and we will not accept patches to > fix issues that only affect MSVC. > > If you have specific reasons for continuing to use MSVC please let us know. > If there are deficiencies in clang-cl compared to MSVC we should get them > filed and fixed. > > Thanks, > -Ted > > 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1443590 > 2. https://bugzilla.mozilla.org/show_bug.cgi?id=1512504 > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
WIP new W3C Charter: Media Working Group
The W3C has announced work in progress (WIP) on the development of a new working group charter: Media Working Group https://lists.w3.org/Archives/Public/public-new-work/2019Feb/0009.html The description of the working group is: The Media Working Group would develop and improve client-side media processing and playback features on the Web by standardizing media related specifications and features that have matured in the Web Platform Incubator Community Group [0]. The group would also maintain and further develop the existing Media Source Extensions (MSE) Recommendation [1]. and there's also discussion as to whether or not to include maintenance of EME as well (see link above). This is prior to the formal review, and it's useful (and probably easier) to get feedback in at this early stage. Depending on the feedback, it may make sense to discuss it here or to file issues directly, whichever seems appropriate. (Feel free to contact me directly if you're not sure.) -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
bzpost hg extension to post try pushes to bugs: update required
Hi, some of you use the Mercurial bzpost extension to get Treeherder links generated and posted to the mentioned bug after you pushed to the Try server. A Treeherder change requires that those links use the last revision from the push to work. The fix is available, you can install it by running the following command from a gecko/mozilla-* source code directory. ./mach vcs-setup --update-only To find your pushes for which a broken link got posted, create a link like https://treeherder.mozilla.org/#/jobs?repo=try=LOCALPARTOFYOUREMAIL%40DOMAIN.TLD - e.g. https://treeherder.mozilla.org/#/jobs?repo=try=dev%40example.org or click your email address in Treeherder for a newer Try push to also see the previous ones. -- Sebastian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform