CARVIEW |
CSS Exclusions Module Level 1
W3C Working Draft, 15 January 2015
- This version:
- https://www.w3.org/TR/2015/WD-css3-exclusions-20150115/
- Latest version:
- https://www.w3.org/TR/css3-exclusions/
- Editors Draft:
- https://dev.w3.org/csswg/css-exclusions/
- Previous Versions:
- https://www.w3.org/TR/2013/WD-css3-exclusions-20130528/
- Feedback:
- www-style@w3.org with subject line “[css-exclusions] … message topic …” (archives)
- Test Suite:
- https://test.csswg.org/suites/css-exclusions-1_dev/nightly-unstable/
- https://test.csswg.org/suites/css3-exclusions/nightly-unstable/
- Editors:
- Rossen Atanassov (Microsoft)Vincent Hardy (Adobe)Alan Stearns (Adobe)
- Issues list:
- in Bugzilla
Copyright © 2014 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
Abstract
CSS Exclusions define arbitrary areas around which inline content ([CSS21]) can flow. CSS Exclusions can be defined on any CSS block-level elements. CSS Exclusions extend the notion of content wrapping previously limited to floats.
CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc.Status of this document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This document is a W3C Working Draft.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The (archived) public mailing list www-style@w3.org (see instructions) is preferred for discussion of this specification. When sending e-mail, please put the text “css-exclusions” in the subject, preferably like this: “[css-exclusions] …summary of comment…”
This document was produced by the CSS Working Group (part of the Style Activity).
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 August 2014 W3C Process Document.
Table of Contents
- 1 Introduction
- 2 Terminology
- 3
Exclusions
- 3.1 Declaring exclusions
- 3.2 Scope and effect of exclusions
- 3.3 Propagation of Exclusions
- 3.4 Exclusions order
- 3.5
Processing model
- 3.5.1 Description
- 3.5.2 Step 1: resolve exclusion boxes belonging to each wrapping context
- 3.5.3 Step 2: resolve wrapping contexts and lay out containing blocks
- 3.5.4 Step 2-A: resolve the position and size of exclusion boxes
- 3.5.5 Step 2-B: lay out containing block applying wrapping
- 3.5.6 Processing Model Example
- 3.6 Floats and exclusions
- Acknowledgments
- Conformance
- References
- Index
- Property Index
- Issues Index
1. Introduction
This section is not normative.
This specification defines features that allow inline flow content to wrap around outside the exclusion area of elements.
2. Terminology
- Exclusion box
- A box ([CSS3BOX]) that defines an exclusion area for other boxes. The wrap-flow property is used to make an element’s generated box an exclusion box. An exclusion box contributes its exclusion area to its containing block’s wrapping context. An element with a float computed value other than none does not become an exclusion.
- Exclusion area
-
The area used for excluding inline flow content around an exclusion box. The
exclusion area is equivalent to the
border box
for an exclusion box.
If a user agent implements both CSS Exclusions and CSS Shapes, the shape-outside property defines the exclusion area instead of the border box.
- Exclusion element
- An exclusion element is a block-level element which is not a float and generates an exclusion box. An element generates an exclusion box when its wrap-flow property’s computed value is not auto.
- Wrapping context
-
The wrapping context of a box is a collection of exclusion
areas contributed by its associated exclusion boxes.
During layout, a box wraps its inline flow content in the
wrapping area
that corresponds to the subtraction of its wrapping context from its own content area.A box inherits its containing block’s wrapping context unless it specifically resets it using the wrap-through property.
- Content area
- The content area is normally used for layout of the inline flow content of a box.
- Wrapping area
- The area used for layout of inline flow content of a box affected by a wrapping context, defined by subtracting the wrapping context from its content area.
- Outside and inside
- In this specification, outside refers to DOM content that is not a descendant of an element while inside refers to the element’s descendants.
3. Exclusions
Exclusion elements define exclusion areas that contribute to their containing block’s wrapping context. As a consequence, exclusions impact the layout of their containing block’s descendants.
Elements lay out their inline content in their content area and wrap around the exclusion areas in their associated wrapping context. If the element is itself an exclusion, it does not wrap around its own exclusion area and the impact of other exclusions on other exclusions is controlled by the z-index property as explained in the 'exclusions order' section.
3.1. Declaring exclusions
An element becomes an exclusion when its wrap-flow property has a computed value other than auto.
3.1.1. The wrap-flow property
Name: | wrap-flow |
---|---|
Value: | auto | both | start | end | minimum | maximum | clear |
Initial: | auto |
Applies to: | block-level elements. |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | as specified except for element’s whose float computed value is not none, in which case the computed value is auto. |
Animatable: | no |
The values of this property have the following meanings:
- auto
- No exclusion is created. Inline flow content interacts with the element as usual. In particular, if the element is a float (see [CSS21]), the behavior is unchanged.
- both
- Inline flow content can flow on all sides of the exclusion.
- start
- Inline flow content can flow around the start edge of the exclusion area but must leave the area next to the end edge of the exclusion empty.
- end
- Inline flow content can flow around the end edge of the exclusion area but must leave the area next to the start edge of the exclusion empty.
- minimum
- Inline flow content can flow around the edge of the exclusion with the smallest available space within the flow content’s containing block, and must leave the other edge of the exclusion empty.
- maximum
- Inline flow content can flow around the edge of the exclusion with the largest available space within the flow content’s containing block, and must leave the other edge of the exclusion empty.
- clear
- Inline flow content can only flow before and after the exclusion in the flow content’s block direction and must leave the areas next to the start and end edges of the exclusion empty.
If the property’s computed value is auto, the element does not become an exclusion.
Otherwise, a computed wrap-flow property value of both, start, end, minimum, maximum or clear on an element makes that element an exclusion element. It’s exclusion area is contributed to its containing block’s wrapping context, causing the containing block’s descendants to wrap around its exclusion area.

Exclusion with wrap-flow: start interacting with various writing modes.
Determining the relevant edges of the exclusion depends on the writing mode [CSS3-WRITING-MODES] of the content wrapping around the 'exclusion area'.
An exclusion element establishes a new block formatting context (see [CSS21]) for its content.

Combining exclusions
The above figure illustrates how exclusions are combined. The outermost box represents an element’s content box. The A, B, C and D darker gray boxes represent exclusions in the element’s wrapping context. A, B, C and D have their respective wrap-flow computed to both, start, end and clear respectively. The lighter gray areas show the additional areas that are excluded for inline layout as a result of the 'wrap-flow’value. For example, the area to the right of B cannot be used for inline layout of left-to-right writing mode content because the wrap-flow for B is start.
The background blue area shows what areas are available for a left-to-right writing mode element’s inline content layout. All areas represented with a light or dark shade of gray are not available for (left-to-right writing mode) inline content layout.
<div id="grid"> <div id="top-right" class="exclusion"></div> <div id="bottom-left" class="exclusion"></div> <div id="content">Lorem ipsum…</div> </div> <style type="text/css"> #grid { width: 30em; height: 30em; display: grid; grid-columns: 25% 25% 25% 25%; grid-rows: 25% 25% 25% 25%; #top-right { grid-column: 3; grid-row: 2; } #bottom-left { grid-column: 2; grid-row: 3; } .exclusion { wrap-flow: <see below> } #content { grid-row: 1; grid-row-span: 4; grid-column: 1; grid-column-span: 4; } </style>
The following figures illustrate the visual rendering for different values of the wrap-flow property. The gray grid lines are marking the grid cells and the blue area is the exclusion box (positioned by the grid).
.exclusion{ wrap-flow: auto; } |
.exclusion{ wrap-flow: both; } |
![]() |
![]() |
.exclusion{ wrap-flow: start; } |
.exclusion{ wrap-flow: end; } |
![]() |
![]() |
.exclusion{ wrap-flow: minimum; } |
.exclusion{ wrap-flow: maximum; } |
![]() |
![]() |
.exclusion{ wrap-flow: clear; } |
|
![]() |
3.2. Scope and effect of exclusions
An exclusion affects the inline flow content descended from the exclusion’s containing block (defined in CSS 2.1 10.1) and that of all descendant elements of the same containing block. All inline flow content inside the containing block of the exclusions is affected. To stop the effect of exclusions defined outside an element, the wrap-through property can be used (see the propagation of exclusions section below).
As a reminder, for exclusions with position:fixed, the containing block is established by the root element.
3.3. Propagation of Exclusions
By default, an element inherits its parent wrapping context. In other words it is subject to the exclusions defined outside the element.
Setting the wrap-through property to none prevents an element from inheriting its parent wrapping context. In other words, exclusions defined outside the element, have not effect on the element’s children layout.
Exclusions defined by an element’s descendants still contribute to their containing block’s wrapping context. If that containing block is a child of an element with wrap-through computes to none, or the element itself, then exclusion still have an effect on the children of that containing block element.
3.3.1. The wrap-through Property
Name: | wrap-through |
---|---|
Value: | wrap | none |
Initial: | wrap |
Applies to: | block-level elements |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | as specified |
Animatable: | no |
The values of this property have the following meanings:
- wrap
- The element inherits its parent node’s wrapping context. Its descendant inline content wraps around exclusions defined outside the element.
- none
- The element does not inherit its parent node’s wrapping context. Its descendants are only subject to exclusion areas defined inside the element.
<style type="text/css">
#grid {
display: grid;
grid-columns: 25% 50% 25%;
grid-rows: 25% 25% 25% 25%;
}
#exclusion {
grid-row: 2;
grid-row-span: 2;
grid-column: 2;
wrap-flow: <see below>
}
#rowA, #rowB {
grid-row-span: 2;
grid-column: 1;
grid-column-span: 3;
}
#rowA {
grid-row: 1;
}
#rowB {
grid-row: 3;
}
</style>
<style type="text/css">
.exclusion {
wrap-flow: both;
position: absolute;
left: 20%;
top: 20%;
width: 50%;
height: 50%;
background-color: rgba(220, 230, 242, 0.5);
}
</style>
<div id="grid">
<div class=”exclusion”></div>
<div id="rowA" style=”wrap-through: wrap;”> Lorem ipsum dolor sit amet...</div>
<div id="rowB" style=”wrap-through: none;”> Lorem ipsum dolor sit amet...</div>
</div>
3.4. Exclusions order
Exclusions follow the painting order (See [CSS21] Appendix E). Exclusions are applied in reverse to the document order in which they are defined. The last exclusion appears on top of all other exclusion, thus it affects the inline flow content of all other preceding exclusions or elements descendant of the same containing block. The z-index property can be used to change the ordering of positioned exclusion boxes (see [CSS21]). Statically positioned exclusions are not affected by the z-index property and thus follow the painting order.
Ordering of exclusions.
<style type="text/css">
.exclusion {
wrap-flow: both;
position: absolute;
width: 200px;
}
.topleft {
top: 10px;
left: 10px;
background-color: lightblue;
}
.middle {
top: 90px;
left: 90px;
background-color: lightgreen;
}
.bottomright {
top: 170px;
left: 170px;
background-color: pink;
}
</style>
<div class="exclusion topleft">
The top left div...
</div>
<div class="exclusion middle">
The middle div...
</div>
<div class="exclusion bottomright">
The bottom right div...
</div>
.middle { z-index: auto; } |
.middle { z-index: 1; } |
![]() |
![]() |
Is the CSS exclusions processing model incorrect?
The current draft provides a model for exclusions without a collision-avoidance model. The existing exclusion model in CSS uses floats, which have both exclusion and collision-avoidance behavior. Concerns have been raised that allowing exclusions without collision avoidance could be harmful, particularly with absolutely-positioned elements. Three options should be considered:
- Allow exclusions in positioning schemes with no collision avoidance.
- Disallow exclusions in positioning schemes with no collision avoidance.
- Define collision-avoidance behavior for positioning schemes without it, and use this behavior by default with exclusions.
3.5. Processing model
3.5.1. Description
Applying exclusions is a two-step process:
- Step 1: resolve exclusion boxes belonging to each wrapping context
- Step 2: resolve each wrapping context and lay out
each containing block in turn:
- Step 2-A: resolve the position and size of exclusion boxes
- Step 2-B: lay out containing block, wrapping around each exclusion area
3.5.2. Step 1: resolve exclusion boxes belonging to each wrapping context
In this step, the user agent determines which containing block each exclusion area
belongs to. This is a simple step, based on the definition of containing
blocks and elements with a computed value for wrap-flow that is not
auto
.
3.5.3. Step 2: resolve wrapping contexts and lay out containing blocks
In this step, starting from the top of the rendering tree (see [CSS21]), the the agent processes each containing block in two sub-steps.
3.5.4. Step 2-A: resolve the position and size of exclusion boxes
Resolving the position and size of exclusion boxes in the wrapping context may or may not require a layout. For example, if an exclusion box is absolutely positioned and sized, a layout may not be needed to resolve its position and size. In other situations, laying out the containing block’s content is required.
When a layout is required, it is carried out without applying any exclusion area. In other words, the containing block is laid out without a wrapping context.
Step 2-A yields a position and size for all exclusion boxes in the wrapping context. Each exclusion box is processed in turn, starting from the top-most, and each exclusion area is computed and contributed to the containing block’s wrapping context.
Scrolling is ignored in this step when resolving the position and size of position: fixed exclusion boxes.
Once the containing block’s wrapping context is computed, all exclusion boxes in that wrapping context are removed from the normal flow.
3.5.5. Step 2-B: lay out containing block applying wrapping
Finally, the content of the containing block is laid out, with the inline content wrapping around the wrapping context’s exclusion area.
When the containing block itself is an exclusion box, then rules on exclusions order define which exclusions affect the inline and descendant content of the box.
3.5.6. Processing Model Example
This section illustrates the exclusions processing model with an example. It is meant to be simple. Yet, it contains enough complexity to address the issues of layout dependencies and re-layout.
The code snippet in the following example has two exclusions affecting the document’s inline content.
<html> <style> #d1 { position:relative; height: auto; color: #46A4E9; border: 1px solid gray; } #e1 { wrap-flow: both; position: absolute; left: 50%; top: 50%; width: 40%; height: 40%; border: 1px solid red; margin-left: -20%; margin-top: -20%; } #d2 { position: static; width: 100%; height: auto; color: #808080; } #e2 { wrap-flow: both; position: absolute; right: 5ex; top: 1em; width: 12ex; height: 10em; border: 1px solid lime; } </style> <body> <div id="d1"> Lorem ipsusm ... <p id="e1"></p> </div> <div id="d2"> Lorem ipsusm ... <p id="e2" ></p> </div> </body> </html>
The following figures illustrate:
- the document’s DOM tree
- the layout tree of generated block boxes
DOM tree
Layout tree of generated block boxes
3.5.6.1. Step 1: resolve exclusion boxes belonging to each wrapping context
The figures illustrate how the boxes corresponding to the element sometimes
have a different containment hierarchy in the layout tree than in the DOM tree.
For example, the box generated by e1
is positioned in
its containing block’s box, which is the d1-box
, because
e1
is absolutely positioned and d1
is relatively positioned. However, while e2
is also absolutely
positioned, its containing block is the initial containing block (ICB). See the
section 10.1 of the CSS 2.1 specification ([CSS21]) for details.
As a result of the computation of containing blocks for the tree, the boxes belonging to the wrapping contexts of all the elements can be determined:
- The wrapping context for the html element contains the
e2
box: WC-1 (Wrapping Context 1) - The wrapping context for the body element inherits the html element’s wrapping context: WC-1
- The wrapping context for
d1
inherits the body element’s wrapping context and adds thee1-box
to it. So the wrapping context is made of both thee1-box
and thee2-box
: WC-2 - The wrapping context for
d2
inherits the body element’s wrapping context: WC-1
3.5.6.2. Step 2: resolve wrapping contexts and lay out containing blocks
In this step, each containing block is processed in turn. For each containing block, we (conceptually) go through two phases:
- resolve the wrapping context: resolve the position and size of its exclusions
- lay out the containing block
In our example, this breaks down to:
- resolve the position and size of the exclusions belonging to WC-1: RWC-1 (Resolved Wrapping Context 1).
- lay out the initial containing block (i.e., lay out its content):
- resolve the html element’s wrapping context: RWC-1
- lay out the html element:
- resolve the body element’s wrapping context: RWC-1
- lay out the body element:
- resolve the
d1
element’s wrapping context: RWC-2 - lay out the
d1
element - resolve the
d2
element’s wrapping context: RWC-1 - lay out the
d2
element
- resolve the
3.5.6.2.1. Resolving RWC-1
The top-most wrapping context in the layout tree contains the
e2
exclusion. Its position and size needs to be
resolved. In general, computing an exclusion’s position and size may or may
not require laying out other content. In this example, no content needs to be
laid out to resolve the e2
exclusion’s position
because it is absolutely positioned and its size can be resolved without
layout either. At this point, RWC-1 is resolved and can be used when laying
inline content out.
3.5.6.2.2. Resolving RWC-2
The process is similar: the position of the e1
exclusion needs to be resolved. Again, resolving the exclusion’s position and
size may require processing the containing block (d1 here). It is the case here
because the size and position of e1
depend on
resolving the percentage lengths. The percentages are relative to the size of
d1
’s box. As a result, in order to resolve a size for
d1
’s box, a first layout of d1
is done without any wrapping context (i.e., no exclusions applied).
The layout yields a position and size for e1
’s box.
At this point, RWC-2 is resolved because the position and size of both e1 and e2 are resolved.
The important aspect of the above processing example is that once an element’s wrapping context is resolved (by resolving its exclusions' position and size), the position and size of the exclusions are not re-processed if the element’s size changes between the layout that may be done without considering any wrapping context (as for RWC-2) and the layout done with the resolved wrapping context. This is what breaks the possible circular dependency between the resolution of wrapping contexts and the layout of containing blocks.
3.6. Floats and exclusions
3.6.1. Similarities
There are similarities between floats and exclusions in that inline content wraps around floats and also wraps around exclusion areas. However, there are very significant differences.
3.6.2. Differences
- scope. While floats apply to content that follows in the document, exclusions apply to content in their containing block.
- positioning. Floats are part of the inline flow and float on the line box. Authors can control how the floats move on the line box, to the right or to the left. By contrast, exclusions can be positioned using any positioning scheme such as grid layout ([CSS3-GRID-LAYOUT]), flexible box ([CSS3-FLEXBOX]) or any other CSS positioning scheme.
- separation of concerns. Making an element a float determines both its positioning scheme and its effect on inline content. Making an element an exclusion only determines its impact on inline content and does not impose constraints on its positioning method.
3.6.3. Interoperability
3.6.3.1. Effect of floats on exclusions
Floats have an effect on the positioning of exclusions and the layout of their inline content. For example, if an exclusion is an inline-box which happens to be on the same line as a float, its position, as computed in Step 2-A will be impacted by the float, as is any other inline content.
3.6.3.2. Effect of exclusions on floats
Exclusions have an effect on the positioning of floats as they have an effect on inline content. Therefore, in Step 2-B, floats will avoid exclusion areas.
Acknowledgments
This specification is made possible by input from Andrei Bucur, Alexandru Chiculita, Arron Eicholz, Daniel Glazman, Arno Gourdol, Chris Jones, Bem Jones-Bey, Marcus Mielke, Alex Mogilevsky, Hans Muller, Mihnea Ovidenie, Virgil Palanciuc, Florian Rivoal, Peter Sorotokin, Bear Travis, Eugene Veselov, Stephen Zilles and the CSS Working Group members.
Conformance
Document conventions
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words "for example"
or are set apart from the normative text with class="example"
,
like this:
This is an example of an informative example.
Informative notes begin with the word "Note" and are set apart from the
normative text with class="note"
, like this:
Note, this is an informative note.
Advisements are normative sections styled to evoke special attention and are
set apart from other normative text with <strong class="advisement">
, like
this:
UAs MUST provide an accessible alternative.
Conformance classes
Conformance to this specification is defined for three conformance classes:
- style sheet
- A CSS style sheet.
- renderer
- A UA that interprets the semantics of a style sheet and renders documents that use them.
- authoring tool
- A UA that writes a style sheet.
A style sheet is conformant to this specification if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.
A renderer is conformant to this specification if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by this specification by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)
An authoring tool is conformant to this specification if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.
Partial implementations
So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported component values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.
Experimental implementations
To avoid clashes with future CSS features, the CSS2.1 specification reserves a prefixed syntax for proprietary and experimental extensions to CSS.
Prior to a specification reaching the Candidate Recommendation stage in the W3C process, all implementations of a CSS feature are considered experimental. The CSS Working Group recommends that implementations use a vendor-prefixed syntax for such features, including those in W3C Working Drafts. This avoids incompatibilities with future changes in the draft.
Non-experimental implementations
Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.
To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group.
Further information on submitting testcases and implementation reports can be found from on the CSS Working Group’s website at https://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.
References
Normative References
- [CSS21]
- Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 7 June 2011. W3C Recommendation. URL: https://www.w3.org/TR/2011/REC-CSS2-20110607
- [CSS3-WRITING-MODES]
- Elika J. Etemad; Koji Ishii. CSS Writing Modes Module Level 3. 15 November 2012. W3C Working Draft. (Work in progress.) URL: https://www.w3.org/TR/2012/WD-css3-writing-modes-20121115/
- [CSS3BOX]
- Bert Bos. CSS basic box model. 9 August 2007. W3C Working Draft. (Work in progress.) URL: https://www.w3.org/TR/2007/WD-css3-box-20070809
- [rfc2119]
- S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://www.ietf.org/rfc/rfc2119.txt
Informative References
- [CSS3-FLEXBOX]
- Tab Atkins Jr.; Elika J. Etemad; Alex Mogilevsky. CSS Flexible Box Layout Module. 18 September 2012. W3C Candidate Recommendation. (Work in progress.) URL: https://www.w3.org/TR/2012/CR-css3-flexbox-20120918/
- [CSS3-GRID-LAYOUT]
- Tab Atkins Jr.; Elika J. Etemad; Rossen Atanassov. CSS Grid Layout. 2 April 2013. W3C Working Draft. (Work in progress.) URL: https://www.w3.org/TR/2013/WD-css3-grid-layout-20130402/
Index
- content area, 2
- exclusion area, 2
- exclusion box, 2
- exclusion element, 2
- outside-inside, 2
- wrap-flow, 3.1.1
- 'wrap-flow'!!'auto', 3.1.1
- 'wrap-flow'!!'both', 3.1.1
- 'wrap-flow'!!'clear', 3.1.1
- 'wrap-flow'!!'end', 3.1.1
- 'wrap-flow'!!'maximum', 3.1.1
- 'wrap-flow'!!'minimum', 3.1.1
- 'wrap-flow'!!'start', 3.1.1
- wrapping area, 2
- wrapping context, 2
- wrap-through, 3.3.1
- 'wrap-through'!!'none', 3.3.1
- 'wrap-through'!!'wrap', 3.3.1
Property Index
Name | Value | Initial | Applies to | Inh. | %ages | Media | Animatable | Computed value |
---|---|---|---|---|---|---|---|---|
wrap-flow | auto | both | start | end | minimum | maximum | clear | auto | block-level elements. | no | N/A | visual | no | as specified except for element’s whose float computed value is not none, in which case the computed value is auto. |
wrap-through | wrap | none | wrap | block-level elements | no | N/A | visual | no | as specified |
Issues Index
The current draft provides a model for exclusions without a collision-avoidance model. The existing exclusion model in CSS uses floats, which have both exclusion and collision-avoidance behavior. Concerns have been raised that allowing exclusions without collision avoidance could be harmful, particularly with absolutely-positioned elements. Three options should be considered:
- Allow exclusions in positioning schemes with no collision avoidance.
- Disallow exclusions in positioning schemes with no collision avoidance.
- Define collision-avoidance behavior for positioning schemes without it, and use this behavior by default with exclusions.