Re: regarding table-row styling (feature request)

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.

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)".

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?

This is not what tiling-a-table needs.

But may be I'm just missreading the specs, so if there are 
examples/tutorials of styling TR with display:other-then-table-row, pls 
point me there.

In the mean time I've tested what I've found. Yet before I'll say my 
"expectations" pls have a look at the following:

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

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".

In additional to that, it would be desirable for future evolution of 
such tiled-style, if new scrolling event was introduced. That event 
should be linked to an additional attribute, since such deck-of-tiles 
can be displayed in two modes:
1. like in a table: one tile after another. or....
2. ... like in a deck of cards: one tile on top of another.
For the second "styling of tiles", it would be desirable to be able to 
"slide them over" by that additional/local scroller. Like on 
touchscreen-smallwidth devices like smartphones: when normal page 
scrolls vertically, the "other scroll" would engage (and swap next tile 
in a deck, or just show "the back of current tile") when scrolled 
horizontally. When ordinary pointer is available, that event should 
probably be linked to "grab-and slide" mouse event - e.g without 
explicitly rendering a scroller widget; or rendering it only as overlay 
when hovered.

A small comment regarding p.5 above: The main feature of a table (as 
currently specified, compared to an ordinary run of DIV/SPAN elements) 
is that, distinct table elements (TD cells) have coordinated dimentions 
according to calculations taken on all of them. That same coordinated 
calculation I'd expect of TD cells turned into SPAN in consequence of TR 
being "display:deck". So if for example, we tile an index card, and one 
book title is "DUNE", while the other is "Bang!: The complete history of 
the universe", and if the second SPAN takes two lines to display in the 
DIV, than the tile containing the first one should also occupy space for 
two lines; so that subsequent SPANs start at the very same position on 
every tile.  (I may cook a live example if that explanation is not 
sufficient - just let me know).

But if it's all there in the specs, pls point me to relevant sections.

-R

Received on Saturday, 21 June 2014 09:21:21 UTC