dominant-baseline property should be inherited

dominant-baseline property should be inherited

Update dominant-baseline property as inheritable property
as per spec.
http://dev.w3.org/csswg/css-inline/#dominant-baseline

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

[Shanmuga Pandi, 2015-07-20 13:56:14]

shanmuga.m@samsung.com changed reviewers:
+ rob.buis@samsung.com

[Shanmuga Pandi, 2015-07-20 13:56:14]

Please review this.
Thanks

[rwlbuis, 2015-07-20 16:55:20]

On 2015/07/20 13:56:14, Shanmuga Pandi wrote:
> Please review this.
> Thanks

It seems the SVG spec does not follow that csswg one for the moment. I think it
may be best to send an email about this to www-svg for clarification.

[Shanmuga Pandi, 2015-07-22 10:29:12]

On 2015/07/20 16:55:20, rwlbuis wrote:
> On 2015/07/20 13:56:14, Shanmuga Pandi wrote:
> > Please review this.
> > Thanks
> 
> It seems the SVG spec does not follow that csswg one for the moment. I think
it
> may be best to send an email about this to www-svg for clarification.

I posted this question to www-svg and waiting for response.

[Shanmuga Pandi, 2015-07-23 05:10:18]

On 2015/07/22 10:29:12, Shanmuga Pandi wrote:
> On 2015/07/20 16:55:20, rwlbuis wrote:
> > On 2015/07/20 13:56:14, Shanmuga Pandi wrote:
> > > Please review this.
> > > Thanks
> > 
> > It seems the SVG spec does not follow that csswg one for the moment. I think
> it
> > may be best to send an email about this to www-svg for clarification.
> 
> I posted this question to www-svg and waiting for response.

@Rob,
  I got the reply. Please check the link below. As per the reply,
dominant-baseline should be inheritable.
http://lists.w3.org/Archives/Public/www-svg/2015Jul/0033.html

[rwlbuis, 2015-07-23 14:45:31]

On 2015/07/23 05:10:18, Shanmuga Pandi wrote:
> On 2015/07/22 10:29:12, Shanmuga Pandi wrote:
> > On 2015/07/20 16:55:20, rwlbuis wrote:
> > > On 2015/07/20 13:56:14, Shanmuga Pandi wrote:
> > > > Please review this.
> > > > Thanks
> > > 
> > > It seems the SVG spec does not follow that csswg one for the moment. I
think
> > it
> > > may be best to send an email about this to www-svg for clarification.
> > 
> > I posted this question to www-svg and waiting for response.
> 
> @Rob,
>   I got the reply. Please check the link below. As per the reply,
> dominant-baseline should be inheritable.
> http://lists.w3.org/Archives/Public/www-svg/2015Jul/0033.html

That's great!
Unfortunately I see one potential problem with the patch. The size of
svg_inherited_flags will become 35 bits, exceeding the 32-bit limit on 32-bit
platforms.
I think color-interpolation-filters can be moved to ComputedStyle but that still
leaves us with 1-bit.
I'll CC pdr to see if he has any ideas or if it is not a big deal to exceed
32-bit limit.

[rwlbuis, 2015-07-23 14:46:16]

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

[rwlbuis, 2015-07-23 14:46:16]

Philip, see my previous comment, any idea what we can do here?

[rwlbuis, 2015-07-23 15:42:30]

Also I think paint-order may be able to take less bits, but not 100% sure.

[pdr., 2015-07-23 17:54:08]

On 2015/07/23 at 15:42:30, rob.buis wrote:
> Also I think paint-order may be able to take less bits, but not 100% sure.

Paint order can be made to use 3 bits (e.g.,
http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/style/SVGRender...)
but I wouldn't want to make the code too tortured to avoid growing this to 64b.

Could you make a pass through all of the inhereted properties to see if any
other are missing, or if we have any extra ones? If _dominantBaseline is the
last one, can you try to switch the paint order to use 3b as a first patch?

[Shanmuga Pandi, 2015-07-24 08:44:17]

On 2015/07/23 17:54:08, pdr wrote:
> On 2015/07/23 at 15:42:30, rob.buis wrote:
> > Also I think paint-order may be able to take less bits, but not 100% sure.
> 
> Paint order can be made to use 3 bits (e.g.,
>
http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/style/SVGRender...)
> but I wouldn't want to make the code too tortured to avoid growing this to
64b.
> 
> Could you make a pass through all of the inhereted properties to see if any
> other are missing, or if we have any extra ones? If _dominantBaseline is the
> last one, can you try to switch the paint order to use 3b as a first patch?

@pdr,
 As I go through the specs, I could not able to find any other property to be
inherited.
 Still I feel, SVG2 is continuously evolving, there might be more chances of a
property which is inheritable, can be added in near future.

Should I change paintOrder to use 3b as a first patch? Please confirm.

[pdr., 2015-07-26 21:09:27]

On 2015/07/24 at 08:44:17, shanmuga.m wrote:
> On 2015/07/23 17:54:08, pdr wrote:
> > On 2015/07/23 at 15:42:30, rob.buis wrote:
> > > Also I think paint-order may be able to take less bits, but not 100% sure.
> > 
> > Paint order can be made to use 3 bits (e.g.,
> >
http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/style/SVGRender...)
> > but I wouldn't want to make the code too tortured to avoid growing this to
64b.
> > 
> > Could you make a pass through all of the inhereted properties to see if any
> > other are missing, or if we have any extra ones? If _dominantBaseline is the
> > last one, can you try to switch the paint order to use 3b as a first patch?
> 
> @pdr,
>  As I go through the specs, I could not able to find any other property to be
inherited.
>  Still I feel, SVG2 is continuously evolving, there might be more chances of a
property which is inheritable, can be added in near future.
> 
> Should I change paintOrder to use 3b as a first patch? Please confirm.

Just to double-check my math... we are currently using 31 bits so we have 1 free
bit, and dropping paint order to 3 gives us 3 more for a total of 4?

If so, lets go ahead and try to shrink paint order as a first patch.

I looked through the other inherited properties and it looks like glyph
orientation may have been moved to css3 as well, so another option might be to
remove those from SVGComputedStyle and put them on CSSComputedStyle. This might
require some spec work though.

[Shanmuga Pandi, 2015-07-27 05:46:41]

On 2015/07/26 21:09:27, pdr wrote:
> On 2015/07/24 at 08:44:17, shanmuga.m wrote:
> > On 2015/07/23 17:54:08, pdr wrote:
> > > On 2015/07/23 at 15:42:30, rob.buis wrote:
> > > > Also I think paint-order may be able to take less bits, but not 100%
sure.
> > > 
> > > Paint order can be made to use 3 bits (e.g.,
> > >
>
http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/style/SVGRender...)
> > > but I wouldn't want to make the code too tortured to avoid growing this to
> 64b.
> > > 
> > > Could you make a pass through all of the inhereted properties to see if
any
> > > other are missing, or if we have any extra ones? If _dominantBaseline is
the
> > > last one, can you try to switch the paint order to use 3b as a first
patch?
> > 
> > @pdr,
> >  As I go through the specs, I could not able to find any other property to
be
> inherited.
> >  Still I feel, SVG2 is continuously evolving, there might be more chances of
a
> property which is inheritable, can be added in near future.
> > 
> > Should I change paintOrder to use 3b as a first patch? Please confirm.
> 
> Just to double-check my math... we are currently using 31 bits so we have 1
free
> bit, and dropping paint order to 3 gives us 3 more for a total of 4?
> 
> If so, lets go ahead and try to shrink paint order as a first patch.
> 
> I looked through the other inherited properties and it looks like glyph
> orientation may have been moved to css3 as well, so another option might be to
> remove those from SVGComputedStyle and put them on CSSComputedStyle. This
might
> require some spec work though.

@pdr,
Thank you for the reply. I will check it further.

[Shanmuga Pandi, 2015-08-03 10:23:50]

On 2015/07/27 05:46:41, Shanmuga Pandi wrote:
> On 2015/07/26 21:09:27, pdr wrote:
> > On 2015/07/24 at 08:44:17, shanmuga.m wrote:
> > > On 2015/07/23 17:54:08, pdr wrote:
> > > > On 2015/07/23 at 15:42:30, rob.buis wrote:
> > > > > Also I think paint-order may be able to take less bits, but not 100%
> sure.
> > > > 
> > > > Paint order can be made to use 3 bits (e.g.,
> > > >
> >
>
http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/style/SVGRender...)
> > > > but I wouldn't want to make the code too tortured to avoid growing this
to
> > 64b.
> > > > 
> > > > Could you make a pass through all of the inhereted properties to see if
> any
> > > > other are missing, or if we have any extra ones? If _dominantBaseline is
> the
> > > > last one, can you try to switch the paint order to use 3b as a first
> patch?
> > > 
> > > @pdr,
> > >  As I go through the specs, I could not able to find any other property to
> be
> > inherited.
> > >  Still I feel, SVG2 is continuously evolving, there might be more chances
of
> a
> > property which is inheritable, can be added in near future.
> > > 
> > > Should I change paintOrder to use 3b as a first patch? Please confirm.
> > 
> > Just to double-check my math... we are currently using 31 bits so we have 1
> free
> > bit, and dropping paint order to 3 gives us 3 more for a total of 4?
> > 
> > If so, lets go ahead and try to shrink paint order as a first patch.
> > 
> > I looked through the other inherited properties and it looks like glyph
> > orientation may have been moved to css3 as well, so another option might be
to
> > remove those from SVGComputedStyle and put them on CSSComputedStyle. This
> might
> > require some spec work though.
> 
> @pdr,
> Thank you for the reply. I will check it further.

With below patch, paintOrder will use 3b
https://codereview.chromium.org/1252933003/

Please review this patch.

[Shanmuga Pandi, 2015-08-04 04:04:54]

shanmuga.m@samsung.com changed reviewers:
+ ed@chromium.org, fs@opera.com

[Shanmuga Pandi, 2015-08-04 04:04:54]

Adding @fs and @ed...

[pdr., 2015-08-04 04:38:36]

On 2015/08/03 at 10:23:50, shanmuga.m wrote:
> Please review this patch.

I think this patch still needs to be rebased.

[Shanmuga Pandi, 2015-08-04 05:42:06]

On 2015/08/04 04:38:36, pdr wrote:
> On 2015/08/03 at 10:23:50, shanmuga.m wrote:
> > Please review this patch.
> 
> I think this patch still needs to be rebased.

@pdr,
I have rebased it again. Thanks

[pdr., 2015-08-04 06:07:40]

On 2015/08/04 at 04:04:54, shanmuga.m wrote:
> Adding @fs and @ed...

LGTM from me, but please give the other reviewers a day or so to comment.

[Erik Dahlström, 2015-08-04 08:34:33]

LGTM here.

[fs, 2015-08-04 08:47:26]

lgtm

[Shanmuga Pandi, 2015-08-04 08:50:08]

The CQ bit was checked by shanmuga.m@samsung.com

[commit-bot: I haz the power, 2015-08-04 08:50:15]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1241163002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1241163002/40001

[commit-bot: I haz the power, 2015-08-04 11:09:17]

Committed patchset #3 (id:40001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=199970