RE: [css-flexbox-1] Untestable assertions

On Monday, April 15, 2013 11:18 AM Tab Atkins Jr. wrote:
> On Mon, Apr 15, 2013 at 10:31 AM, Arron Eicholz
> <Arron.Eicholz@microsoft.com> wrote:
> > On Monday, April 15, 2013 9:52 AM Tab Atkins Jr. wrote:
> >> On Mon, Apr 15, 2013 at 8:49 AM, Arron Eicholz
> >> <Arron.Eicholz@microsoft.com> wrote:
> >> > On Saturday, April 13, 2013 12:10 PM Tab Atkins Jr. wrote:
> >> >> The words are intended to be part of RFC2119.  The fact that they
> >> >> can't be automatically tested is irrelevant, because we won't be
> >> >> testing them anyway (they're authoring conformance, not UA
> >> conformance).
> >> >
> >> > I really don't care about the RFC2119 in this situation. I am
> >> > pointing out the
> >> fact that we can't test author's conformance. And we cannot require
> >> authors to do anything. Authors have the freedom of choice to do things.
> >>
> >> And *I'm* pointing out that we don't test authoring conformance criteria.
> >> That's for validators and evangelists to do.
> >
> > Ahh but we have to verify normative statements in the spec that have
> testable assertions. And in these cases they are testable assertions.
> 
> Who is "we"?  If you're trying to imply that the CSSWG has to test authoring
> conformance criteria in order to exit CR, you're wrong.  No WG has ever been
> blocked from advancing for failing to test authoring criteria.

"We" is test writers and the testers that have to verify the test cases that are written. The working group has very little to do with either of these. The WG sets of the criteria to write tests and right now it is loosely defined to encompass all normative statements require tests. Thus we then run into my issue that I called out.

A WG would be blocked if such tests were written but there have been from what I can tell no cases written in CSS 2.1 (which has the most complete suite). In fact CSS 2.1 explicitly identified author information as non-normative. The Flexbox spec does not have similar text in the conformance section. This is another issue that should be corrected and actually would fix this problem all together.

CSS 2.1 states
#   At times, this specification recommends good practice for authors and
#   user agents. These recommendations are not normative and conformance
#   with this specification does not depend on their realization. These
#   recommendations contain the expression "We recommend ...", "This
#   specification recommends ...", or some similar wording.

> >> >> As Henrik says, this style of authoring conformance is used
> >> >> elsewhere, such as HTML.
> >> >
> >> > While I agree that there may be other places that follow this same
> pattern.
> >> It does not justify the fact that it is incorrect to state the sentence this
> way.
> >> Also I have seen very few normative, if any, statements that use this
> >> particular grammar and fall into this situation. We could also make
> >> these notes and that would also solve the problem.
> >>
> >> No, this is literally used everywhere.  Every single time a validator
> >> raises an error, it's because of an authoring conformance criteria.
> >> These are sometimes implicit rather than explicit, but that's largely
> >> because we simple don't care as much about being precise with
> >> authoring conformance.
> >
> > Please point me to more situations like this. I will raise issues because they
> require tests to test authors' compliance with something. All the other cases I
> have seen similar to this right now are in notes, which aren't normative.
> 
> See: any part of CSS that would result in a validator error, any part of HTML
> that would result in a validator error, etc.

I am not reviewing HTML, nor am I reviewing any other specs as the moment. I have found issues in the Flexbox spec and this is what I have called out for now. When I review the next CSS spec I will call out the same issues if I find them there as well.

> >> > Wouldn't it just be easier to fix the issue since and issue was
> >> > raised, than to
> >> continue to argue this point over email?
> >>
> >> ...really?
> >
> > Yes really. It's easy to fix these simple grammar mistakes I have pointed
> out. I have edited specs and I know it takes only 5-10 minutes to make simple
> edits like this.
> 
> I wasn't questioning the ease - of course it's easy.  I was questioning the
> tone, which implies that I should be taking the easiest way out rather than
> the correct way.  But this is an irrelevant tangent, and I'm not going to pursue
> it.

Then you incorrectly took my tone from my email. I am not trying to be difficult or argumentative I am trying to be helpful and constructive. If you take offense to me correcting your grammar in your spec, I am sorry, but this grammar needs to change only slightly to be ok. Am I a little frustrated that you won't fix a simple grammar error, yes, but I am not trying to be rude to you about fixing this issue in any way.

--
Thanks,
Arron Eicholz

Received on Monday, 15 April 2013 18:47:45 UTC