Re: [css-values] Re: CR: CSS Values and Units Module Level 3

Note to self: two issues open:
   - 'width: 0' example
   - toggle example needs splitting

On 07/03/2015 11:20 AM, timeless wrote:
> On Thu, Jun 11, 2015 at 9:25 AM, Notifier <notifier@aries.w3.org> wrote:
>> CSS Values and Units Module Level 3
>>
>> http://www.w3.org/TR/2015/CR-css-values-3-20150611/\nnfeedback due by: 2015-09-09
>
>> Status of the Document
>> The specification will remain Candidate Recommendation at least until 09 September 2015. At the date of publication there is no explicit test suite (implicityl [sic], all CSS tests exercise this module in some way) and no implementation report.
>
>> specified in the grammar are implicitly omittable [sic] in some circumstances,
>
> omissible [1]

Imho this is an un-American spelling (since we Americans tend to normalize
such things). However, I concede to fix it.

>> For re-orderable combinators (||, &&), ordering of the grammar does not matter:
>
> Google says:
> Showing results for reorderable [2]
> Search instead for re-orderable
>
> note that yourdictionary is right, the base word is `reorder`, not `orderable`.

Fixed.

>> In this case, a space would be required before the 2 to get this parsed as the two lengths '1em'and [sic] '2em'.
>
> there's a space missing before `and`

Fixed.

>> Identifiers cannot be quoted; otherwise they would be interpreted as a string.
>
> a string => strings
> (or An identifier/it)

Fixed.

>> In the value definition fields, keywords with a pre-defined meaning appear literally.
>> Keywords are CSS identifiers and are interpreted ASCII case-insensitively (i.e., \[a-z] and [A-Z] are equivalent).
>
> \[a-z] and [A-Z] differ in two ways, depending what you are trying to
> say, i'd suggest:
> \[a-z], [a-z], and [A-Z] are equivalent (assuming that's what you mean...)

Stray backslash. Removed.

>> RFC 3986, section 3, defines the normative algorithm for this process.
> ... why isn't this written like this:
>> ... [RFC6694].

Fixed.

>> The url() function supports specifying additional '<url-modifier>'s,...
> ... you don't consistently include quotes around this...
>> This specification does not define any <url-modifier>s, ...
>
>> vw 1% of viewport’s width
>> vh 1% viewport’s height
> missing `of`

Fixed.

>> Equal to the used x-height of the first available font. [CSS3-FONTS] The x-height ...
>
> I know there's a style that suggests putting stuff after punctuation,
> please put []s after their reference and before the period ending the
> sentence instead.

Fixed.

>> Note: Note that if the anchor unit is the pixel unit,
>> Note: Note that this definition of the pixel unit and
>> Note: Note that due to the 1:96 fixed ratio
>> Note: Note that algebraic simplifications
>> Note: Note this requires all contexts
>> Note: Note that toggle()
>> Note: Note that the computed value
>> Note: Note that, unlike <toggle-value>s,
>
> I'm pretty sure more Note:s don't Note: Note than do. Personal Note:
> Note Note: Note'ing is annoying.

The old generator didn't generate the "Note: " bit, so that was put
in manually at the time... Fixed.

>> (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)
>
> breaks => broke

:)

>> Showing that more device pixels (dots) are needed to cover a 1px by 1px area on a high-resolution device than on a low-res one
>
> Isn't the technical claim that it's `a medium viewed at a greater
> distance` and not `a higher resolution device`?
> If you're talking about the same viewing distance, you should say
> so... But then, you're really just saying "if the size of a thing is
> smaller than something else, then it takes more of that thing to fill
> the same space as the thing w/ the larger base unit", which seems
> pretty obvious and uninteresting.

It's not obvious to people who expect 'px' to mean "device pixel".

> Most of these units include periods, as here:
>> s
>> Seconds.
>
> until here:
>> dpi
>> dots per inch
>> dpcm
>> dots per centimeter
>> dppx
>> dots per px unit
> where you lost the periods...

Fixed.

>> White space is allowed, ...
>> If a comma is used to separate arguments, whitespace is optional before and after the comma.
>
> I favor whitespace

Sorry, one of the few things the W3C style guide says
is that it's "white space". :)

>> For example, calc(5px - 5px + 10s) or calc(0 * 5px + 10s) are both invalid due to the attempt to add a length and a time.
>
> or => and

Fixed.

>> These two are equivalent to 'width: 0px' since widths smaller than 0px are not allowed.
>> width: calc(5px - 10px);
>> width: 0px;
>
> I think you can omit `to 'width: 0px'` - The two examples are
> equivalent since ...

Hm. Not sure if Tab meant to put something else in this example,
so will check with him first before rewording.

>> The toggle() notation is not allowed to be nested; nor may it contain attr() or calc() notations.
>
> According to Grammar Girl [3]:
> or => nor may it contain
>
> I think that sounds awkward, I'd probably go with:
> ...; and it may contain neither attr() nor calc() ...

The negation here is applied to the verb "contain",
so I think we're good.

>> Note that, since 1px appears twice in the top and bottom margins, they will cycle between only two value while the left and right margins cycle through three.
>
> `two value` sounds awkward, did you mean `two values`?

Fixed.

> Ignoring the wording nit here, I don't understand how what it's saying
> is correct. The initial introduction to toggle() didn't indicate to me
> that:
>
> toggle(1, 1, 2, 3, 5, 8) would be the same as:
> toggle(1, 2, 3, 5, 8)
> or that
> toggle(1, 2, 3, 1) would be the same as:
> toggle(1, 2, 3)

The example here is illustrating two principles:
   * shorthanding
   * cycling over repeated values
It should probably be split into two examples for that reason...
But what's happening is that the mechanism for tracking the position
in the list is a comparison to each item in the list starting from
the beginning... if an item is repeated, then we return to its first
position in the list and take the next one from there.

>> The attr() expression is only valid if:
>> the attr() expression’s type is valid where the attr() expression is placed,
> this item doesn't end with a comma:

Fixed.

>> if the attribute name is given with a namespace prefix, the prefix is defined
>> the <attr-fallback> is valid where the attr() expression is placed,
>> the <attr-fallback> does not contain another attr() expression,
>> and, if the attr() expression is not the sole component value of a property, the <attr-fallback> matches the attr()’s type
>
> i think rewording it to `there is no namespace prefix for the
> attribute name or the namespace prefix for the attribute name is
> defined,` would be the easiest fix.

Switched to "the namespace prefix of the attribute name, if any, is defined,"

>> If the attr() is used alongside other values to form the full property value, however, the default value must match the attr()'s type.
>
> ParseError: `expected then while parsing if`
>
> Moving `however` to the beginning of the sentence allows my parser to
> read an implied `then` before `the default`

Interesting. Fixed.

>> an attribute whose value is "\33" will produce a string containing those three characters, not a string containing "3" (the character that the escape would evaluate to).
>
> Using an example with 3 threes is confusing, it'd be easier on my poor
> parser if the first number after the slash wasn't the same thing as
> the character that would be evaluated. (In other languages, backslash
> of something uninteresting is the thing itself.) -- "\67" might work
> assuming I'm understanding what this is doing.

lol, that's a fantastic example and I kindof want to keep it because
it's amusing. However, I will fix it as you suggest. :)

>> INVALID EXAMPLE26
>
> There's a space missing before 26

Fixed.

~fantasai

Received on Tuesday, 16 February 2016 05:36:24 UTC