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

On Sunday 2010-08-15 21:58 +1000, Peter Moulder wrote:
> 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).

In my opinion, this is certainly worth posting.

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

I think this is worth posting as well.

However, I'd note that you really have three options, not just two:
  1. raise the issue as part of the existing discussion
  2. raise it as a separate issue
  3. not raise it.
Whether (1) or (2) makes more sense likely depends, in my opinion,
on whether the new issue is easier or harder to solve than the
original one.  If it's an easy revision to the proposal, I think
it's probably best within the same discussion; if it requires
research to figure out the right thing to do, it's probably better
off as a separate one.

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

Well, test cases are useful in general, even if they're not actually
implemented differently.  Showing a testcase that could be
implemented differently based on what the spec currently says is
useful.

But many issues are also easy to understand 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'm skeptical that the best way to arrive a at more formal spec is
by piecemeal edits of the current one; it seems more likely that
we'd get a more formal spec by somebody sitting down and trying to
specify it more formally.  We can improve things here-and-there, but
I think the biggest benefits would come from reorganization of the
document and other similar changes, which are probably out-of-scope
for CSS 2.1.  So in the scope of CSS 2.1, I guess I tend to think
that there's some amount of looseness we'll have to live with.

But this is just my opinion, and it's also an opinion I'd be rather
open to changing depending on what others think.

On the other hand, that doesn't mean we shouldn't fix things that
you find unclear.  For example, I think the spec could certainly
benefit from being much more explicit about which rules override
which other rules.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Sunday, 15 August 2010 13:13:11 UTC