Do not expose auto as value of widows

Do not expose auto as value of widows

According to both:
http://www.w3.org/TR/CSS2/page.html#propdef-widows and
http://dev.w3.org/csswg/css-break/#widows
the only allowed values for the widows property are inherit or integer
and not 'auto'. We do need to support parsing 'auto' for backward
compatibility, but this patch implements not exposing the value though
computed style.

Behavior matches IE11.

BUG=363562
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=187543

[rwlbuis, 2014-12-16 22:01:29]

Patchset #3 (id:40001) has been deleted

[rwlbuis, 2014-12-17 15:53:05]

Patchset #4 (id:80001) has been deleted

[rwlbuis, 2014-12-17 21:49:01]

rob.buis@samsung.com changed reviewers:
+ timloh@chromium.org

[rwlbuis, 2014-12-17 21:49:01]

PTAL

[Timothy Loh, 2014-12-17 23:13:23]

On 2014/12/17 21:49:01, rwlbuis wrote:
> PTAL

This is.. weird. I'm pretty sure returning an empty string in getComputedStyle
is always wrong (even though firefox does it in this case). Is the improvement
here that authors using widows need less workarounds for the property?

[rwlbuis, 2014-12-17 23:29:36]

On 2014/12/17 23:13:23, Timothy Loh wrote:
> On 2014/12/17 21:49:01, rwlbuis wrote:
> > PTAL
> 
> This is.. weird. I'm pretty sure returning an empty string in getComputedStyle
> is always wrong (even though firefox does it in this case). Is the improvement
> here that authors using widows need less workarounds for the property?

Possible. To my surprise Firefox claims not to support it:

https://developer.mozilla.org/en-US/docs/Web/CSS/widows

So maybe its css handling is not to be trusted either... I guess IE is the
only reference left (I don't think I have an old Opera browser). I'll do some
tests later... I guess an option is to always return whatever is in widows,
since
for 'auto' it would be the default value (2).

[mstensho (USE GERRIT), 2014-12-18 08:56:53]

On 2014/12/17 23:29:36, rwlbuis wrote:
> On 2014/12/17 23:13:23, Timothy Loh wrote:
> > On 2014/12/17 21:49:01, rwlbuis wrote:
> > > PTAL
> > 
> > This is.. weird. I'm pretty sure returning an empty string in
getComputedStyle
> > is always wrong (even though firefox does it in this case). Is the
improvement
> > here that authors using widows need less workarounds for the property?
> 
> Possible. To my surprise Firefox claims not to support it:
> 
> https://developer.mozilla.org/en-US/docs/Web/CSS/widows
> 
> So maybe its css handling is not to be trusted either... I guess IE is the
> only reference left (I don't think I have an old Opera browser). I'll do some
> tests later... I guess an option is to always return whatever is in widows,
> since
> for 'auto' it would be the default value (2).

Presto (old Opera) follows the spec when it comes to orphans and widows, i.e.
initial value is 2. It's supported both in paged media and multicol.

This 'auto' thing in WebKit / Blink has always baffled me. It was announced and
discussed here: http://lists.w3.org/Archives/Public/www-style/2012Dec/0135.html

I read through the discussion again, and I still don't understand why 'auto' is
a good idea. 'auto' is a spec violation in any case, so I really don't
understand why it's better than 1. I read that 'auto' was added to let the UA
decide, and, as far as I know, it has always been translated to 1 in WebKit /
Blink, ever since this was introduced 2 years ago. So what was the point?

I suggest that we get rid of 'auto', by doing one of the following:

A: Break the spec in a less weird way: let initial value be 1
B: Follow the spec. If something breaks on the world wild web because of it,
evangelize.

[rwlbuis, 2014-12-18 18:13:15]

On 2014/12/18 08:56:53, mstensho wrote:
> On 2014/12/17 23:29:36, rwlbuis wrote:
> > On 2014/12/17 23:13:23, Timothy Loh wrote:
> > > On 2014/12/17 21:49:01, rwlbuis wrote:
> > > > PTAL
> > > 
> > > This is.. weird. I'm pretty sure returning an empty string in
> getComputedStyle
> > > is always wrong (even though firefox does it in this case). Is the
> improvement
> > > here that authors using widows need less workarounds for the property?
> > 
> > Possible. To my surprise Firefox claims not to support it:
> > 
> > https://developer.mozilla.org/en-US/docs/Web/CSS/widows
> > 
> > So maybe its css handling is not to be trusted either... I guess IE is the
> > only reference left (I don't think I have an old Opera browser). I'll do
some
> > tests later... I guess an option is to always return whatever is in widows,
> > since
> > for 'auto' it would be the default value (2).
> 
> Presto (old Opera) follows the spec when it comes to orphans and widows, i.e.
> initial value is 2. It's supported both in paged media and multicol.

IE11 seems to act like Presto, i.e. 2 is the initial value and 'auto' is not
supported.

[rwlbuis, 2014-12-18 22:04:44]

On 2014/12/18 08:56:53, mstensho wrote:
> I suggest that we get rid of 'auto', by doing one of the following:
> 
> A: Break the spec in a less weird way: let initial value be 1
> B: Follow the spec. If something breaks on the world wild web because of it,
> evangelize.

My latest patch set implements 1. I like it since it allows us to get rid of
some
code related to 'auto'.

[rwlbuis, 2014-12-18 22:07:11]

On 2014/12/18 22:04:44, rwlbuis wrote:
> On 2014/12/18 08:56:53, mstensho wrote:
> > I suggest that we get rid of 'auto', by doing one of the following:
> > 
> > A: Break the spec in a less weird way: let initial value be 1
> > B: Follow the spec. If something breaks on the world wild web because of it,
> > evangelize.
> 
> My latest patch set implements 1. I like it since it allows us to get rid of
> some
> code related to 'auto'.

Sorry, I meant A :)
I am not sure if orphans would need to be done in the same patch. And if
we should remove the 'auto' parsing handling as well for widows/orphans.

[Timothy Loh, 2014-12-18 23:00:39]

lgtm

I think we can probably get away with removing 'auto' support without a
UseCounter. Usage of widows and orphans are both high, but auto is the default
value so it's a bit of an edge-case for removing it to make a difference.

[rwlbuis, 2014-12-19 14:17:47]

The CQ bit was checked by rob.buis@samsung.com

[commit-bot: I haz the power, 2014-12-19 14:18:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/430333002/180001

[commit-bot: I haz the power, 2014-12-19 15:29:24]

Committed patchset #8 (id:180001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=187543