Re: [proposal] Table cell selectors.

Andrew Fedoniouk wrote:
> | What happens with
> |   E[@column=1 @row=1] {
> |     display: block;
> |   }
> 
> Boris, seems I do not understand your question well....
> First child of first row of table (inline-table) element will become block 
> instead of table-cell.

But then it's not in the first row and first column of a table, is it?

How about this example:

   div { display: table }
   div.cell { display: table-cell }
   div[@column=1 @row=1].cell { display: block }

   <div>
     <div class="cell">Text</div>
   </div>

> This is just a short form of
> table tr[@index=1] td[@index=1]

It can't be, because that would involve CSS knowing something about "<table>" 
being a table.

> | More generally, please see http://ln.hixie.ch/?start=1070385285&count=1
> 
> I think that problems mentioned by Ian here is slightly outdated.
> We already have Panteon full of different selectors. E.g. td[foo*=bar] is 
> already not simple computationaly.

The problem clearly described in Ian's article is not one of computational 
complexity but one of circular dependencies.  Your proposal either has the 
circular dependency problem or makes CSS make assumptions about what tag names 
mean or something.  I can't tell which, because you have not clearly explained 
your proposal.

> No as @ is such vendor prefix in this case.

No, it is NOT a vendor prefix.  There is nothing preventing the CSS WG from 
introducing an @index notation in the future, and then your engine will cause 
namespace clashes.  Please, please use a proper vendor prefix for extensions. 
Especially ones that seem as ill-thought-out as this one.

> BTW: We are using %% units heavily these days. Do you have any idea what is
> vendor prefixes should we use for them?

That's something you should have considered before starting to use them, 
frankly.  Perhaps you should have raised the issue on this mailing list?

-Boris

Received on Sunday, 14 November 2004 18:40:16 UTC