[CSS21] shaping newcomers contributions (was Re: cases that do not pass in any browser

On Fri, Aug 13, 2010 at 06:24:57PM -0700, L. David Baron wrote:

> However, text that's *much* worse is actually labeled a
> Recommendation (CSS 2.0).  So I'd rather see 2.1 advance to the
> level where it can formally replace 2.0, which is still frequently
> normatively referenced by other standards because of requirements on
> the maturity level of references.

Thank you for explaining that: that does help.

I'd like to help fixing the problems I see in the spec, but I'm still trying
to understand when and how to do that.

For example, let's say I want to find how common web browsers resolve the
interactions between two different parts of the spec (or whatever other
behaviour isn't clearly described in the current spec) and I write some test
cases and find that different user agents get different answers.  I'm sure
this is a common story for anyone starting to implement some part of CSS.

What should I (or such a person) do then?  Should we report the problem now,
or would that just slow down more important CSS work ?  It's clear to me that
people value interoperability, but chances are that most of these issues will
affect only relatively rare cases (at least in the sense that mixing
:first-line with floats is rare).

As another example, suppose someone posts a proposal for text for CSS2.1,
and it has what I consider to be a problem.  Let's say it's one of those
cases where text isn't clear about whether something sometimes happens or
always happens in a particular condition.  On one hand, this might be seen
as a minor problem, while on the other hand it can result in divergent
implementations because one implementor is more swayed by the idea that the
text probably intends "always", while another implementor is more swayed by
evidence elsewhere in the spec.  (A lot of discussions on www-style involve
different people taking different interpretations and correspondingly different
conclusions.)

So when I see an arguably minor problem like this, should I bring it to
people's attention and in so doing slow down progress at getting the new text
in (which is typically still an improvement to the text despite whatever
potential issues I might notice), or should I just make a private note of it
to report it later ?  And if later, then when (if ever) is the right time to
report such ambiguities?  Should I wait until I'm aware of a test case that
different major user agents display differently, or is there a stage in CSS'
development where it's appropriate to work on such things?

If the answer is that I shouldn't report such an issue until I'm aware of a
test case that's implemented differently, then are there any other sorts of
issues that should be reported even without a test case?  Someone mentioned
contradictions in the spec as one criterion, but usually there's enough
looseness in the text that there isn't an absolute contradiction.  For example,
my understanding of the diagram just before section 17.4.1 conflicts with the
diagram's caption, but in section 8.3.1 (Collapsing Margins) I don't understand
the intended meaning of some of the basic relationships that everything is
defined in terms of, so it's hard for me to get as far as trying to apply that
section's rules to the situation to know the meaning of the caption and whether
there's a conflict or not.  There are certainly lots of examples of where
sections 10.3 / 10.6 say "the width/height in this circumstance is X" and where
another part of the spec (say the min-width etc. properties or tables.html)
says "ignore section 10.3 / 10.6"; does that count as a contradiction ?


I know that some of the questions I'm asking here don't have simple answers,
but I think that any guidance you can give to me and any other newcomers
to the list is likely to pay off in how it affects our contribution
and avoiding counter-productive diversions.

pjrm.

Received on Sunday, 15 August 2010 11:58:45 UTC