Intent to implement: -webkit-line-clamp

2019-02-14 Thread Cameron McCormack
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

2019-02-14 Thread Mike Hommey
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

2019-02-14 Thread L. David Baron
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

2019-02-14 Thread Sebastian Hengst

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