W3C home > Mailing lists > Public > www-style@w3.org > June 2014

Re: regarding table-row styling (feature request)

From: Rafał Pietrak <rafal@ztk-rp.eu>
Date: Sat, 28 Jun 2014 10:39:22 +0200
Message-ID: <53AE7F3A.2070207@ztk-rp.eu>
To: www-style@w3.org
W dniu 26.06.2014 01:18, Tab Atkins Jr. pisze:
> On Sat, Jun 21, 2014 at 2:20 AM, Rafał Pietrak <rafal@ztk-rp.eu> wrote:
[-------------]
>
> 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.

Hm. I know that, and in fact, I tried to asked for takeing all that 
"magic" just a little bit further.

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

OK. So I've taken my case "the other way around". Here 
http://jsfiddle.net/fexp/LfCcW/6/, I've made a showcase. the case is:

1. so let's have a DIV/SPAN structure initially (instead of 
TABLE/TR/TD).....
2. .... and go towards TABLE from there, by applying relevant table 
DISPLAY styling at apropriate levels, and see if we can get the original 
table layout.

This didn't happen.

psl keep in mind, that (almost) all I'm asking for is:
1. When one has a wide table, which want fit into a small-width-device 
.. by far. Could be "rearranged" into small-width by special layout for it.
2. but on the other hand, for computer "normal-width-device" It should 
be able to retain all the "original" table-styling magic.
3. The little extra (td width coordination).... would'd be good, is that 
all

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

I can see (example checks it on jfiddle), that some of the table-cell 
magic is retained there, but:
1. the most important one - that is: the width/height coordination - is 
lost ... despite the fact, that higher level boxes are requested to 
"display:table" (and table-row).
2 and even more surprisingly, the ".tr td" selector does not catch, if 
the higher element is not originally "table-related" ... (is it a 
feature or a bug?).
.
>
>> 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?

I hope the jsfiddle example does show it up. Let me know if it's still 
insufficiently clear. For tiling to work nicely, it's desirable to have 
".tr > *" coordinated across all the ".tr" elements inside ".tbl" box.

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

Yes it doesn't.

And some of the selectors don't catch as expected (see jsfiddle).


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

Yes.

So, I'll be doing more examples soon, particularly with wider tables if 
the one I've just did is not clear anough. For now I'd prefere to do 
this as: one small example at a time, as I "king of feel" that you see 
my request as something "big (in codeing) and particular (in 
application)", while my understanding is the oposit. I may be wrong of 
course ... happens all the time :(

Summarizing: my goal is to have only styling change the display of my 
last example (on jsfiddle) into the first one (or the other way around). 
No matter if going from DIV to TABLE, or from TABLE to DIV.


-R
Received on Saturday, 28 June 2014 08:40:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:22 UTC