This would fix this bug as well as webcompat/web-bugs#17900.
The argument for this to be a reasonable change is that, table cells can
never shrink below the min intrinsic size, so overflow-wrap: break-word
doesn't make any sense in table when it didn't affect intrinsic size.
So this change basically revert the behavior of bug 1472386 for tables
which seems to be the biggest problem so far.
Differential Revision: https://phabricator.services.mozilla.com/D2638
--HG--
extra : moz-landing-system : lando
<applet> is not a thing anymore, and that selector in our UA sheet will never
match anyway, since an <applet> element will never have the BROKEN state.
MozReview-Commit-ID: 7UOMKOv55uJ
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
Bug 1259889 Part 2 [1] cannot be reverted cleanly, so I manually undo those
changes in this patch. That is, remove the ability for html.css to
invalidate dynamically since it was added specifically for details element.
Although reftest-stylo.list explicit mentions "DO NOT EDIT!", but I still
remove details pref from the file, since it doesn't harm to edit it anyway.
[1] https://hg.mozilla.org/mozilla-central/rev/30aaf3805b56
MozReview-Commit-ID: FsyTGQTxujh
--HG--
extra : rebase_source : 25e5a05a8a5a47642772da69f427631fa07e232d
CLOSED TREE
Backed out changeset 235ea1c681db (bug 1271765)
Backed out changeset 02d34b18d76b (bug 1271765)
Backed out changeset 088113647629 (bug 1271765)
This patch was generated by the command:
find . -name "*.css" -exec sed -i -f mozpropsub {} \;
in the root of a mozilla-central tree, with the file mozpropsub
containing the contents:
s/-moz-padding-end\>/padding-inline-end/g
s/-moz-padding-start\>/padding-inline-start/g
s/-moz-margin-end\>/margin-inline-end/g
s/-moz-margin-start\>/margin-inline-start/g
s/-moz-border-end\>/border-inline-end/g
s/-moz-border-end-color\>/border-inline-end-color/g
s/-moz-border-end-style\>/border-inline-end-style/g
s/-moz-border-end-width\>/border-inline-end-width/g
s/-moz-border-start\>/border-inline-start/g
s/-moz-border-start-color\>/border-inline-start-color/g
s/-moz-border-start-style\>/border-inline-start-style/g
s/-moz-border-start-width\>/border-inline-start-width/g
While I didn't manually review all the changes, I did review the list of
files, and manually reviewed the changes in the files that I thought
were more interesting.
Note that there are a few tests that should be fixed up as well, but
I'll do that in a later patch.
MozReview-Commit-ID: EiQTuuV0MNQ
Per html spec, the disclosure triangle can be generated via "display:
list-item", I removed the code to generate the triangle in
SummaryFrame::SetInitialChildList(). That is, when a web page set
"display: block" to the summary, the triangle will disappear, too.
Now SummaryFrame does nothing and is going to be removed in Part 2.
Also summary element should not increment the counter as hinted as
"counter-increment: list-item 0" in the spec. Hence the change in
nsBlockFrame::RenumberListsFor().
The rendering hint in html spec:
https://html.spec.whatwg.org/multipage/rendering.html#the-details-and-summary-elements
MozReview-Commit-ID: DELGYFe3zGX
--HG--
rename : layout/reftests/details-summary/open-summary-block-style.html => layout/reftests/details-summary/open-summary-block-style-ref.html
extra : rebase_source : 4bd5493fb6a1108eea31aef1d89f563f781b753f
We need to re-evaluate html.css whenever "dom.details_element.enabled"
is changed to make the disclosure triangle for summary elements show up.
Reftests for details and summary will need the a live pref to work.
MozReview-Commit-ID: 9SN1fQBuwA7
--HG--
extra : rebase_source : c8eafde9d3a97908c44099219603f76087d484b9
Xidorn Quan
Emilio Cobos Álvarez
Jonathan Watt
Boris Zbarsky
Wes Kocher
bechen
Iris Hsiao
Phil Ringnalda
Ray Lin
Tim Nguyen
Jessica Jong
Ting-Yu Lin
L. David Baron
Astley Chen
malayaleecoder