[Feature] [RFC] border-box or content-box or half-border-box

[100pah]

What problem does this feature solve?

At present, if a component can be set width/height and border and/or pending and left/right/top/bottom, the behavior is not consistent and not straight forward.

Basically, there three box models:

The name of the third one half-border-box is what I made just now. this box model seems to be not straight forward but it is the default behavior of HTML canvas, and widely used in echarts. Consider various graphic (e.g., polygon), content box or border box need complicated calculation but half-border-box is simple and work well in the most cases.

But when we set width/height and border and/or pending and left/right/top/bottom to a "container" or "component", the half-border-box seems to be not easy to understand. Since CSS box model only use border-box and content-box, the half-border-box probably makes users feel it is a bug.

Consider the case below:

Padding follows content-box/border-box rule (in echarts). But border follows half-border-box rule.

BTW, at present in echarts, there are inconsistent:

• if user set left: 0, top: 0
  • grid and title show half of left-top border
  • visualMap and treemap.breadcrumb show full border

BTW, at present in echarts, there are facts (just for the record):

• title legend visualMap timeline can set pending
• title legend grid visualMap toolbox (and the future thumbnail) can set border
• grid visualMap (and the future thumbnail) can set width/height of the container, while the others calculate content according to their content.

What does the proposed API look like?

• For component / container that can set width/height and border and/or pending and left/right/top/bottom, use border-box rules rather than half-border-box. Component like thumbnail is always placed on the corner and has border, which makes this issue obvious.
• Border should not overlay the content.

2022-07-08-1457.excalidraw.zip

[100pah]

Additionally, the requirements of subpixel optimization, which introduce complexity in some edge cases, partially results from the current border strategy - which often produces a .5 coord.

[100pah]

However, change the box-sizing strategy would likely to introduce major breaking changes, while offering limited benefits. A partially change will lead to a long-term inconsistency, potentially causing even greater harm. Therefore, I prefer to stick with the current setup.