On 29 Jul 2001, Mama Cass Elliot wrote:
>
> In netscape.public.mozilla.seamonkey the people heard Ian Hickson say these
> wise words:
>
>>> So, has Mozilla already specified how the Mozilla Browser will handle
>>> those previously unspecified conditions?
>>
>> Some of them, yes.
>
> Are all *known* (by Mozilla), but previously unspecified, conditions now
> specified in Mozilla?
Nope, although most are. Some "open issues" remain and are currently being
discussed with the W3C. (You can do a search of these bugs, most of them
have "WG" in the status whiteboard)
>> If the spec says
>>
>> if A then do x
>> if B then do y
>> if C then do z
>>
>> ...then it seems well defined, right?
>
> Agreed. That would, by all reasonable accounts, be well defined.
>
>
>> So you write your program to do
>> this. Then, 4 months later, someone comes along and says "what if D?".
>
> Yes - tricky - adding a previously undefined, unspecified condition. But
> surely a logical structure would enable another condition to be added -
> wouldn't it?
Yep. Unfortunately, this is a massive simplification. In real life, the
W3C specifications, like most of the standards that Mozilla attempts to
follow, have literally THOUSANDS of such conditions, and the specs do not
always define the exact interaction of each of these, again because people
have often simply not thought of them.
To extend the example above, if a spec says
if A then turn off x and turn on y
if B then turn off y and turn on x
...then it seems well defined, right?
So you write your program to do this. Then, 4 months later, someone comes
along and says "what if both A and B at the same time?".
> AFter all, each condition would merely be another separate, parallel
> path/option through to the next stage of the logic tree - wouldn't it?
Not necessarily. They might be orthogonal.
Here's an example. In CSS, you can have a set a property to 'inherit'.
This means it should look at its parent, and inherit the colour from that.
Seems logical, right?
Unfortunately, there is one case that was forgotten while that was being
defined. What if the element in question has *two* parents? What element
should the property inherit from? (This can occur, for instance, with a
pseudo-element like '::selection'. In fact, this is one of the 'open
issues' that I mentioned above.)
> Um, isn't it possible to design something to make alowences for expansions
> as needed? Wasn't this the whole reason behind Mozilla's modular design?
Yes, indeed. But this doesn't guarentee that someone won't have missed a
case -- for example "D" or "both A and B at the same time" as illustrated
above -- and these are exactly what bugs are. Unexpected cases.
--
Ian Hickson )\ _. - ._.) fL
Netscape, Standards Compliance QA /. `- ' ( `--'
+1 650 937 6593 `- , ) - > ) \
irc.mozilla.org:Hixie _________________________ (.' \) (.' -' __________
