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

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).

Example 3:
----------
(B) #  * and track parts  in this example. */

Typo: there's a (visible) extra space character after "parts" here.

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.)

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".

(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).

(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/ )

(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.)

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?

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.

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".

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"?

(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/.

(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.


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).

Thanks,
~Daniel

Received on Thursday, 26 February 2015 00:53:37 UTC