Re: [css-grid] some editorial nits, up through section 6

On 02/25/2015 04:53 PM, Daniel Holbert wrote:
> Hi www-style,
>
> I'm re-reading the CSS Grid spec (after not looking at it for a while), and noticed some editorial nits (mostly typos & mis-targeted/missing hyperlinks).  I figured I'd write to report them so they can be fixed.
>
> Editor's draft URL, which I'm going off of:
>   http://dev.w3.org/csswg/css-grid/
>
> (For convenience / tracking purposes, I've grouped the issues by section, and I labeled each spec-quote with a letter -- (A), (B), etc.)
>
> Section 1.3:
> ------------
> (A) # [...] when viewed either in landscape or portrait
>      # orientation (Figures 4 and 5)
>
> s/"landscape and portrait"/"portrait and landscape"/, to match the ordering of the figures it's referring to. (Figure 4 is *portrait*, Figure 5 is *landscape*).  (Also, the sample CSS below in "Example 2" right below this section has the "portrait" CSS first).

Fixed.

> Example 3:
> ----------
> (B) #  * and track parts  in this example. */
>
> Typo: there's a (visible) extra space character after "parts" here.

Fixed.

> Section 2.3:
> ------------
> (C) # [...] a column or row that uses a contents-based
>      # relative size
>
> I think this wants s/contents/content/ -- i.e. it wants to say "content-based". This is the only usage of the term "contents-based" in https://hg.csswg.org/drafts/ , whereas there are many usages of the term "content-based".  (Alternately, if "contents-based" actually means something different from "content-based", it probably needs a definition.)

Fixed.

> Section 3.1data
> -----------
> (D) # Grid containers form a containing block for their
>      # contents exactly like block containers do.
>
> I think this is wrong -- at least, it conflicts with this earlier text from section 2.3 (which I'm assuming is correct): "A grid item’s grid area forms the containing block into which it is laid out."  It also conflicts with this text from section 4: "A grid item is sized within the containing block defined by its grid area".

Okay, replaced this sentence with
   # The contents of a grid container are laid out into a grid,
   # with grid lines forming the boundaries of each grid items’
   # containing block.

> (E) # all of the column-* properties in the Multicol module
>      # have no effect on a grid container.
> Nothing in this text is linkified right now. Something here should
> link to http://dev.w3.org/csswg/css-multicol/ (or the equivalent working draft).

Fixed. (Also fixed in Flexbox.)

> (F) # the ::first-line and ::first-letter pseudo-elements
>      # do not apply to grid containers
>
> "first-line" is linkified here, but "first-letter" is not. It should be.
> (This might actually be a bug in css-pseudo-4 spec, which defines these selectors -- it looks like this same inconsistency happens all throughout that spec: http://dev.w3.org/csswg/css-pseudo-4/ )

Fixed. (css-pseudo was missing <dfn> tags.)

> (G) # The table in CSS 2.1 Chapter 9.7 is thus amended to
>      # contain an additional row, with 'inline-grid' in the
>      # "Specified Value" column and grid in the
>      # "Computed Value" column.
>
> Two nits about the word "grid" here:
>   - The word "grid" here is currently linked to #grid, but it should actually be linked to #valdef-display-grid (since it's talking about the "display" value, not the general concept of a grid).
>   - Need to add single-quotes around 'grid', for consistency with 'inline-grid' earlier in this sentence. (This might happen automagically when it gets linked to #valdef-display-grid -- not sure.)

Fixed.

> Section 4
> ---------
> (H) # However, an anonymous grid item that contains
>      # only white space is not rendered, as if it were
>      # display:none.
>
> Right now, the term "white space" here is linked to the "white-space" property definition:
>    http://www.w3.org/TR/CSS21/text.html#white-space-prop
> This doesn't make sense, because this prose isn't talking about the white-space *property*. If this is linked to anything, it should be to a definition of what "white space" is. (what characters are considered to be white space) Later on, the spec mentions "whitespace" (as a single word) and links to http://dev.w3.org/csswg/css-syntax-3/#whitespace -- maybe that's what we should be doing here as well?

This is actually the correct link: css-syntax defined CSS syntactic white space,
but here we're talking about document white space (which is not the same thing).
I updated the link to point to CSS3 Text, which might be a bit clearer.

> Section 5.1
> -----------
> (G)  # Name:          grid-template-columns, grid-template-rows
>       # [...]
>       # Computed value:  As specified, except for auto (see prose)
>
> I'm confused about the "except for auto" exclusion here. Does that need to be there? The prose for "auto" doesn't actually say anything about it *computing* to some other value -- rather, it says what "auto" is "identical to" or "represents" (and there's similar language for the other values). If "auto" actually needs to *compute* to some other value (and I'm not sure it should), then its prose needs to say that. Otherwise, the "except for auto" exclusion seems arbitrary & vague.

It used to compute to minmax(min-content, max-content), but that's changed now.
Fixed. :)

> Section 5.1.3
> -------------
> (H)  # Each column or row’s share of the free space      # can be computed as the column or row’s
>       # <flex> * <free space> / <sum of all flex factors.
>
> This is missing a ">" after "factors".

Fixed.

> Section 5.1.4
> -------------
> (I) # If a grid container that is not a grid item uses the subgrid
>      # keyword, it grid-template-rows/grid-template-columns value
>      # is treated identically to none
>
> Typo here -- "it" is out of place, in the phrase "it grid-template-rows". Maybe replace with "this" or "the"?

Fixed with s/it/its/.

> (J) #  The subgrid’s own grid items participate in the
>      #  sizing of its parent grid and are aligned to it.
>      #  In this process, the sum of the item’s margin,
>      #  padding, and borders are applied as an extra
>      #  layer of margin to the items at those edges.
>
> Clarification nit:
> "the item's margin[...]" here is ambiguous, because there are two layers of items we're discussing. The subgrid is itself an item, and it has items (which are the items primarily being discussed here).
>
> I think the spec is talking about the subgrid's margin/padding/border here, so perhaps s/item's/subgrid's/.

Fixed.

> (K) # The subgrid is always stretched; the align-self/justify-self
>      # properties on it are ignored. Any specified width/height
>      # constraints are also ignored.
>      # [...] the align-content/justify-content properties on it
>      # are ignored.
>
> This seems like an odd restriction, for subgrids that are only subgrids in one dimension. (e.g. "subgrid" only specified in  grid-template-columns.)  Shouldn't such a subgrid be able to use the alignment properties in the other (non-subgrid) dimension?
>
> e.g. if a nested grid uses "subgrid" to defer to its parent on column sizing, then it makes sense that its horizontal alignment properties would be ignored -- but it's not clear why we'd *also* ignore the alignment properties (and force it to stretch) in the *other* dimension, where it's not deferring to the parent for track definitions.

Good point. Fixed. :]

> Section 6
> ---------
> (L) # Once the explicit grid is filled (or if there is no
>      # explicit grid) auto-placement
>
> This sentence just trails off without ending (as quoted above).

Fixed.

Thanks!

~fantasai

Received on Thursday, 7 May 2015 23:03:14 UTC