tree 989c44a9c1f44be0bed1cdb91cbbd8f753157673
parent 307bed6ce47421af59bd4d66fa720be1ac4b4745
author Daniel Holbert <dholbert@cs.stanford.edu> 1558673867 +0000
committer moz-wptsync-bot <wptsync@mozilla.com> 1558703895 -0400

part 1: [css-contain] Fix some CSS layout-containment web-platform-tests to make their assumptions more valid.

In particular:

- In contain-layout-suppress-baseline-002.html, the test currently indirectly
  relies on the 50px-tall-canvas being the tallest thing in each flex
  container. This isn't robustly true (and in fact on windows, the textarea is
  taller at 50.8px tall). So I'm adjusting this test so that it no longer has a
  hardcoded flex container size and no longer depends on this.

- In contain-layout-baseline-005.html and its reference case, we need to
  explicitly specify 'vertical-align:baseline' to test baseline-alignment,
  because some of its tested form controls have other UA-stylesheet-provided
  default values of 'vertical-align'.
  (e.g. <select multiple> defaults to 'vertical-align:text-bottom")

- Also: in that same test, we need to reduce the width of the an <input>
  textfield -- otherwise, it and the other elements on its line may not fit and
  may linewrap, which prevents us from effectively testing baseline-alignment
  on the linewrapped element.

- In contain-layout-button-001.html, the expectation was not correct. Before
  this patch, the test expects that a layout-contained button will have the
  same baseline as an empty button, and that's an invalid expectation. An empty
  button uses a point inside of its content-box as its baseline, whereas a
  layout-contained element *has no baseline*, which means that it does
  'vertical-align:baseline' alignment by aligning its own margin-bottom edge
  with the parent's baseline, per
  https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
  So, I'm amending the test to have this expectation and updating its meta tags
  to reference the updated expectation and with a reference to that spec text.

Firefox fails the amended contain-layout-button-001.html test, so this patch
adds a .ini file to reflect that failure.  The next patch in this series will
fix our implementation to make us pass the test, and will remove the .ini file.

Chrome also fails the amended contain-layout-button-001.html tests, and I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=965740 on them with an
explanation.

Differential Revision: https://phabricator.services.mozilla.com/D32182

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1552287
gecko-commit: 9360fef47426b836880d8a0cdf99b9357d1273c9
gecko-integration-branch: autoland
gecko-reviewers: TYLin