Re: regarding table-row styling (feature request)

On Sat, Jun 21, 2014 at 2:20 AM, Rafał Pietrak <rafal@ztk-rp.eu> wrote:
> W dniu 21.06.2014 01:39, Tab Atkins Jr. pisze:
>> On Fri, Jun 20, 2014 at 9:00 AM, Rafał Pietrak <rafal@ztk-rp.eu> wrote:
>
> [-----------------]
>
>>> /tbody
>>> parts). So "display: [table-tiled | table-rows]" at the "<colgroup>"
>>> token,
>>> look most apropriate to me. Naturaly, this is only switching the mode of
>>> display, not syntax to design a tile - the later is not clear to me, yet.
>>>
>>> Does it look reasonable?
>>
>> You can do this today, by just changing the 'display' value of table
>> rows to whatever you need, and committing additional tweaks as
>> necessary.  Is there anything missing?
>>
>
> Hmmm, I asked because I wasn't able to google that.
>
> But as you say its standarised, I've looked at:
> http://www.w3.org/TR/CSS21/tables.html .... and regretably found there:
> "User agents may ignore these 'display' property values for HTML table
> elements". Which does not sound like "I can display row as anything". And in
> fact, I haven't found a word on rendering table/row in case when it's
> requested to style as "display:block". I've checked the working draft for
> CSS3, and styling of TR when it's "display:block" is not specified there
> either.

That's rather old and incorrect at this point; all UAs allow you to
style table elements with whatever 'display' value you want.

We haven't published a Tables Module since then, because tables are
complicated magic that nobody wants to put in the effort to actually
spec.

> So I gather, the intention here was: "if any table element (like TR) is
> styled as 'display:something-else-not-table', then we forget the table
> styling for that element at all (e.g. no interaction betweend
> display-block/display-table is actually defined in standards)".

No, the interaction is well-defined.  Table-* display values have to
occur in a particular structure, and they'll auto-generate anonymous
boxes to maintain that structure if you dont' have it.

So, for example, if you set a TR to display:block, it'll get wrapped
in an anonymous table-row and table-cell box.  If you didn't do
anything special to the TDs inside of it (so they're still
display:table-cell), they'll glom together and auto-wrap themselves in
table, table-row-group, and table-row boxes.

> Thus, although it looks like I can "display" TR as anythinig, in doing so I
> loose all the coordinated display behavior, that TABLE gives me. Do I?

Yes.  Coordination happens within a table layout context.  If you
break out of it, you're not coordinating any more.

> This is not what tiling-a-table needs.

Then I'm not sure what you're asking for; it looked like your example
were *semantically* table-like, but didn't actually use table styling
at all, and that then led to your question about styling.  Can you
elaborate?

> ---------------example--------------------
> <table>
> <tr><td>one</td><td>two</td><td>thr</td><td>our</td> </tr>
> <tr
> style="display:block;width:20ex"><td>sdjkls</td><td>repoijs</td><td>sdjkweoif</td><td>pweojgrrnk</td>
> </tr>
> <tr><td>one</td><td>two</td><td>thr</td><td>our</td> </tr>
> </table>
> -----------end-example--------------------
>
> The second row (the one TR style is tested), is rendered (on my firebird)
> so, that it "ocupies" the space of first TD of other rows. This is not what
> an "author like myself" would have expected even without tiling. I would
> expect that every row of a table occupies the same width, not when
> "display:block" the same width of other rows "first-child". So if it's a
> feature not a bug, it's counterintuitive.

That's because, as I say above, it gets wrapped in anonymous table-row
and table-cell boxes.  It thus takes up only one cell in the outer
table.

> And for tiling the table, I'd actually expect:
> 1. that "display:tiled" (or: "display:deck") could be applied to any of
> table/thead/tfoot/tbody/tr elements. This is sementically different from
> "display:block" by the "coordination of positioning" I'm explaining below.
> 2. to give a good tiling support, it should turn EVERY-TR contained there,
> into a respective DIV.
> 3. it should set the width of all such DIVs to the width of the entire
> table, ... and it should "influence back" the width of that element as in
> normal table, width of any TR, influences the width of the entire table. In
> that sense, sucn DIV should have its with computation follow exactly that of
> original TR.
> 4. it should set every TH/TD element contained in such (turned into DIV) TR
> into a SPAN. In consequence, the TH/TD elements in such TR should behave as
> if they were SPAN elements in DIV... but with a twist ....
> 5. .... it should coordinate positioning of every :nth SPAN so, that those
> apear at exactly the same positions within every DIV (formerly TR) of such
> deck, as the other :nth SPAN.
>
> Here, when I say: "turn TR into DIV" I only mean, that I'd expect all
> styling of TR as TABLE-ROW should be dropped; apart from positioning with
> respect to other TR and its width; and positioning and "boxing" behavior od
> DIV should be assumed instead.
>
> When I say: "turn TD/TH into SPAN", I mean that quite literaly. I mean that
> table-cell styling those TD/TH should be entirely replaced by ordinary SPAN
> styling, and its positioning within containing DIV.
>
> Yet, I don't mean by the above "turn TR/TH/TD into DIV/SPAN" as replaceing
> the names of the elements for the purpose of styling. Authors should referre
> to those "turned" elements as before: th:last-child {float:left}; even
> though, the ROW is now turned to "display:deck".

If I understand what you're asking for, you can accomplish this by
setting all the TRs to "display: table-cell" and all the TDs to
"display: inline".

However, this does not accomplish what you seemed to be asking for in
either of your examples.

I'm really just not sure what it is you're asking for.  Attempting to
dictate a solution isn't helpful here, because I can't evaluate what
it is you're trying to accomplish with the solution.  Instead, could
you just provide examples of what you want to do, and I can tell you
whether it's already possible, or will be possible in the future, or
likely won't be possible for some reason?

~TJ

Received on Wednesday, 25 June 2014 23:19:16 UTC