On 29 Jul 2001, Mama Cass Elliot wrote:
>
> Isn't it a pity that businesses like M$ seem unwilling to contribute
> in an open way to the ironing out / bedding down, of these
> specificatons. :o(
Companies like Microsoft (and AOL and American Express and Ericsson and so
on) are the main participants to the standards process.
>>> 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.
>
> Why should that be the case?
Well, for example, the colour of text and the font of text are two totally
unrelated items.
>> 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?
>
> Yes - look to *the* parent.
>
>
>> 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.)
>
> IMHO, wouldn't the best method be to look to the immediate parent, which
> would itself in turn look to it's own parent?
>
> Wouldn't it simply be a case of poor CSS writing to have two immediate
> parents? How could a browser possibly choose between two immediate parent
> CSS?
Exactly. These are the questions that pose themselves.
BTW, the case I raised here is a real one. If you have the following
document tree:
ROOT
|
+--------+---------+
| |
A B
|
+---+---+
| |
C D
...and your pseudo element ::selection looks like this:
ROOT
|
+--------+---------+
| |
A B
: |
: +---+---+
: | |
: C D
:..............:
:
selection
...then it doesn't have a particular parent. It has at least two, and
depending on how you look at it, it has three. (A, C, and maybe B.)
So yes, you have to define a particular case. However the answer might not
be easy, and may require going back to the W3C (with Microsoft and other
companies) and discussing the issue.
> I thought that bugs were normally faulty coding - typos, bad logic,
> etc, rather than needed additions.
They are both.
Taking the other two cases:
Typos: Not many ways to avoid these, with a perfect design you could
still have these.
Bad Logic: If you are tired when you design the logic, there is no
guarentee that the logic is going to be perfect.
IMHO, programming is an art, not a science.
--
Ian Hickson )\ _. - ._.) fL
Netscape, Standards Compliance QA /. `- ' ( `--'
+1 650 937 6593 `- , ) - > ) \
irc.mozilla.org:Hixie _________________________ (.' \) (.' -' __________
