Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 63 additions & 2 deletions css-backgrounds-4/Overview.bs
Original file line number Diff line number Diff line change
Expand Up @@ -242,8 +242,69 @@ Painting Area: the 'background-clip' property</h3>
<h2 id="corners">
Corners</h2>

<h3 id=corner-sizing>
Corner Sizing: the 'border-radius' property</h3>
<h3 id="corner-sizing">
Corner Sizing: the 'border-radius' and 'border-*-radius' shorthand properties</h3>

<h4 id="page-relative-corner-sizing">
Page-Relative (Physical) Corner Sizing:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect "page-relative" to mean inside (binding) versus outside edges of a printed page (i.e., inside would be the left side for a recto page in an ltr book, etc. We have had proposals for such logical properties, but I think they've been removed from current drafts.

I think its probably best to just use "Physical" and not "Page-Relative".

Also, in both this h4 title and the next, I think you should mention these are specifically side shorthands... since there are longhand properties for these things elsewhere in the specification.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect "page-relative" to mean inside (binding) versus outside edges of a printed page (i.e., inside would be the left side for a recto page in an ltr book, etc. We have had proposals for such logical properties, but I think they've been removed from current drafts.

I think its probably best to just use "Physical" and not "Page-Relative".

Note that I took "Page-Relative" from CSS Box 3/4, where it refers to the physical properties to distinguish them from their logical counterparts. Though you're right, "physical" is less ambiguous and also much more common throughout the specs. So I replaced "Page-Relative" by "Physical".

We may change that terminology in CSS Box as well to bring them in line with the rest of the specs.

Also, in both this h4 title and the next, I think you should mention these are specifically side shorthands... since there are longhand properties for these things elsewhere in the specification.

Good point. I've added it.

I also realized that the second h4 actually included the wrong property names. 😊 So I've also fixed that now.

The 'border-top-radius', 'border-right-radius', 'border-bottom-radius', 'border-left-radius' shorthands</h4>

<pre class=propdef>
Name: border-top-radius, border-right-radius, border-bottom-radius, border-left-radius
Value: <<length-percentage [0,&infin;]>>{1,2} [ / <<length-percentage [0,&infin;]>>{1,2} ]?
Initial: 0
Applies to: all elements (but see prose)
Inherited: no
Percentages: Refer to corresponding dimension of the <a>border box</a>.
Computed value: see individual properties
Animatable: see individual properties
</pre>

<p>The 'border-*-radius' shorthands set the two 'border-*-*-radius'
longhand properties of the related side. If values are given before
and after the slash, then the values before the slash set the
horizontal radius and the values after the slash set the vertical radius.
If there is no slash, then the values set both radii equally.
The two values for the radii are given in the order
top-left, top-right for 'border-top-radius',
top-right, bottom-right for 'border-right-radius'
bottom-left, bottom-right for 'border-bottom-radius',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this, would it be better to follow the same order as in border-radius?

So border-radius: 1px 2px 3px 4px would be equivalent to

border-top-radius: 1px 2px;
border-bottom-radius: 3px 4px;

instead of

border-top-radius: 1px 2px;
border-bottom-radius: 4px 3px;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it makes more sense to keep them from top to bottom and left to right, especially in regard of their logical counterparts. E.g. in horizontal writing modes you probably would not want the values switch their order depending on whether they are left-to-right or right-to-left.

Though I created an issue in the spec. so we can discuss this separately.

and top-left, bottom-left for 'border-left-radius'.
If the second value is omitted it is copied from the first.

<h4 id="flow-relative-corner-sizing">
Flow-Relative Corner Sizing:
the 'border-start-start-radius', 'border-start-end-radius',
'border-end-start-radius', 'border-end-end-radius' properties</h4>

<pre class=propdef>
Name: border-block-start-radius, border-block-end-radius, border-inline-start-radius, border-inline-end-radius
Value: <<length-percentage [0,&infin;]>>{1,2} [ / <<length-percentage [0,&infin;]>>{1,2} ]?
Initial: 0
Applies to: all elements (but see prose)
Inherited: no
Percentages: Refer to corresponding dimension of the <a>border box</a>.
Computed value: see individual properties
Animatable: see individual properties
</pre>

<p>These properties correspond to the 'border-top-radius',
'border-right-radius', 'border-bottom-radius', and 'border-left-radius'
shorthand properties.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This implies that with writing-mode: horizontal-tb; direction: rtl,

border-block-start-radius: 1px 2px;

should become

border-top-radius: 1px 2px;

i.e.

border-top-left-radius: 1px;
border-top-right-radius: 2px;

Instead, I think that

border-block-start-radius: 1px 2px;

should expand to

border-start-start-radius: 1px;
border-start-end-radius: 2px;

which then will map to

border-top-right-radius: 1px;
border-top-left-radius: 2px;

This is because shorthands must be expanded into longhands at parse time, while logical-to-physical mapping happens at computed-value time. So we can't have logical shorthands mapping into physical shorthands. Shorthands just expand, it's the longhands that can have logical/physical pairings.

The mapping depends on the element’s 'writing-mode', 'direction',
and 'text-orientation',
with start/end referring to the axis orthogonal to the one given
by the first part of the name
(i.e. patterned as 'border-block-<i>inline</i>-radius' and
'border-inline-<i>block</i>-radius')
If values are given before and after the slash,
then the values before the slash set the
horizontal radius and the values after the slash set the vertical radius
like for the page-relative properties.

<h4 id="corner-sizing-shorthand">
Sizing All Corners At Once:
The 'border-radius' shorthand</h4>

<pre class="propdef">
Name: border-radius
Expand Down