WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 83380
Don't expose the intrinsic padding concept to the code outside rendering
https://bugs.webkit.org/show_bug.cgi?id=83380
Summary
Don't expose the intrinsic padding concept to the code outside rendering
Julien Chaffraix
Reported
2012-04-06 10:54:57 PDT
Currently intrinsic padding is available through a boolean on the padding* functions. This however exposes it to the outside world (and actually CSSComputedStyleDeclaration already relies on / works around it) when only the table rendering code should know about this concept. There has been some back and forth discussion going on about that. See for example,
bug 33593
and
bug 83092
.
Attachments
Proposed clean-up.
(18.99 KB, patch)
2012-04-06 12:41 PDT
,
Julien Chaffraix
no flags
Details
Formatted Diff
Diff
Updated patch against ToT, also took Dave's comment into account.
(26.89 KB, patch)
2012-04-10 16:00 PDT
,
Julien Chaffraix
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Julien Chaffraix
Comment 1
2012-04-06 12:41:44 PDT
Created
attachment 136054
[details]
Proposed clean-up.
Dave Barton
Comment 2
2012-04-06 19:43:58 PDT
I vote to rename the computedPadding* functions to cssOnlyPadding*. In all the padding functions something is "computed". I know you mean this in the sense of "computed CSS", but I don't know if a casual reader would get it.
> // The content area of the box (excludes padding - and intrinsic padding for table cells - and border).
// The content area of the box (excludes padding - and intrinsic padding for table cells, etc. - and border).
> // This returns the CSS computed padding values.
// These return the CSS computed padding values.
> // Those functions are used during layout. Table cells override > // them to include an alignment padding (called intrinsic padding).
These functions are used during layout. Table cells and some MathML renderers override them to include extra "intrinsic padding" for alignment and other uses. I need paddingStart and paddingEnd to be virtual also, for MathML. === With the above changes, I really like this patch! For the record, here's my point of view. I'd like to use intrinsic padding for MathML also, as in my recent patch for
bug 82353
, where intrinsic padding leaves room for a square root sign. I like to think of intrinsic padding as maybe "decorated padding" that's similar to a fancy kind of border, but contained in the "padding". This would be very helpful for MathML. That is, when RenderBlock::layout() uses the equation border-box = content-box + padding + border (+ maybe scroll bars), I want it to allow this padding to be more than just padding from CSS styles. Then this "rendering padding" needs to be treated as padding by availableLogicalWidth() for example when computing space for laying out or centering children. So RenderBoxModelObject is a base class with two kinds of padding functions. The rendering one that includes intrinsic padding is virtual, so derived classes like TableCell and some MathML classes can override it. Other classes don't know the specifics of intrinsic padding in these derived classes, but they do know there are two kinds of padding functions. Actually the one without intrinsic padding is mostly just used by computed styles, and doesn't need to be virtual, as you point out.
Alexis Menard (darktears)
Comment 3
2012-04-09 04:35:24 PDT
Comment on
attachment 136054
[details]
Proposed clean-up. Yes seems like a better solution and less intrusive.
Julien Chaffraix
Comment 4
2012-04-10 14:35:57 PDT
(In reply to
comment #2
)
> I vote to rename the computedPadding* functions to cssOnlyPadding*. In all the padding functions something is "computed". I know you mean this in the sense of "computed CSS", but I don't know if a casual reader would get it.
For the record, I thought about a similar name (cssPadding*) but I thought this would be confusing as it's not the raw CSS information (ie a Length) but a computed CSS information (percent / calculated length have been resolved). computedCSSPadding* could be a good compromise here.
Dave Barton
Comment 5
2012-04-10 14:42:50 PDT
computedCSSPadding* sounds great to me.
Julien Chaffraix
Comment 6
2012-04-10 16:00:56 PDT
Created
attachment 136562
[details]
Updated patch against ToT, also took Dave's comment into account.
Dave Barton
Comment 7
2012-04-10 16:27:49 PDT
Comment on
attachment 136562
[details]
Updated patch against ToT, also took Dave's comment into account. LGTM, FWIW.
Eric Seidel (no email)
Comment 8
2012-04-10 16:40:37 PDT
Comment on
attachment 136562
[details]
Updated patch against ToT, also took Dave's comment into account. Seems reasonable to me.
WebKit Review Bot
Comment 9
2012-04-10 21:15:56 PDT
Comment on
attachment 136562
[details]
Updated patch against ToT, also took Dave's comment into account. Clearing flags on attachment: 136562 Committed
r113823
: <
http://trac.webkit.org/changeset/113823
>
WebKit Review Bot
Comment 10
2012-04-10 21:16:01 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug