HomePhabricator

Remove CSS resets that don't have any effect

Authored by thiemowmde on Oct 30 2018, 9:11 AM.

Description

Remove CSS resets that don't have any effect

Note this patch does not resolve T206526, but touches only a few less
controversial CSS properties.

In detail:

  • display: block – The targeted element is a <div>. It's a block anyway.
  • text-align: start – This might even be destructive. We want the alignment to respect the content language. A reset on an individual element can't be good.
  • text-indent: 0 – There is no indention on a <div> we need to remove.
  • text-shadow: none – As above.
  • text-transform: none – As above.
  • letter-spacing: normal – As above.
  • word-spacing: normal – As above.
  • text-rendering: auto – This puzzles me the most. I can see this might be needed when applying this set of CSS properties on a <textarea>, because browsers apply all kinds of crazy defaults on these. But the targeted element is not a <textarea> here, it's a plain <div>.

I think the later is the main source of the confusion here: When this set of
CSS properties was copied from two (I believe) Stackoverflow posts, what was
found there was probably made to work on *any* element including form elements.
But we are targetting a <div> here. All we care about is the font and
line-height (which does *not* accurately match the <textarea>s line-height, by
the way).

Also note that most of these properties don't cascade down to child elements,
especially not when the child element is a <textarea>. Margins, for example,
never cascade. Colors cascade, but not on a <textarea>. The <textarea>s own
color always wins, except the <textarea> itself is targeted, which it is not
in this case.

Bug: T206526
Change-Id: I73362fd9a23010b4dcfc66adff0e599fec4ef0cc

Details