Re: layout idea

Brad, I apologize.  I'm not intending to call your arguments
ridiculous, and I'm sorry that I'm stating things in such a way to
sound like that.  Whenever I do call something ridiculous (or
similar), I'm referring to some abstract spec or idea, not to you or
something you've specifically created.  At least, I'm trying to.
Sorry.  T_T

On Fri, Mar 20, 2009 at 1:44 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Mar 20, 2009, at 9:55 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
>> On Fri, Mar 20, 2009 at 11:47 AM, Brad Kemper <brad.kemper@gmail.com>
>> wrote:
>>>
>>> On Mar 19, 2009, at 12:39 PM, David Hyatt wrote:
>>>
>>>>> No. We don't flow contents *into* cells. We *absolutely position*
>>>>> contents to align with edges of particular cells.
>>>>>
>>>>
>>>> Three kinds of positioning:
>>>>
>>>> (1) table-position on a display:table-cell.  The object actually becomes
>>>> the cell at that position.  A pseudo-element can't refer to this cell
>>>> position when this is done.
>>>> (2) table-position on a normal flow object like a block.  The object is
>>>> placed *into* the cell at that position.  If no cell exists at that
>>>> position, then an anonymous one gets made.  A pseudo element can be used
>>>> to
>>>> style this cell.
>>>> (3) position:absolute with grid units.  Provides out of flow alignment
>>>> to
>>>> cells in tables.
>>>
>>> Please note that I am not totally against #2, above. Just somewhat
>>> against
>>> it, because I think it confuses the understanding of the rest of it,
>>> complicates things that would otherwise be simpler (the automatic
>>> wrapping
>>> of cells into new rows), and is unnecessary for the goals of source-order
>>> independence. I think if you had #1 above, plus row-spans/col-spans, it
>>> would satisfy the vast majority of layout needs, and also be a great boon
>>> to
>>> creating table-like structures out of non-table HTML structures (like
>>> definition lists, or headline/paragraph combinations).
>>>
>>> #3 is a "nice-to-have" for abs-pos items to align with
>>> table-display-based
>>> layouts. #2 just seems extraneous. Is it so that you can put a group of
>>> things, like paragraphs, into a cell without actually having a wrapper of
>>> some sort (like <DIV class="article">) around them first?
>>
>> Yes, exactly.  Without #2, you have to explicitly add wrappers to your
>> HTML,
>
> It is a natural division anyway, and so one place where a DIV is perfectly
> semantic. There's even a new tag for it in HTML5  Plus, most existing markup
> using floats or abs-pos for layout would already have that "central area
> wrapper" anyway.

In many cases, there will be a convenient wrapper.  In many, there
won't be.  In a previous email I gave an example of a 3-col layout
that's fairly common in the blogging world these days that requires
either the ability to flow elements into a block, or the imposition of
an artificial division in the HTML source.  Unfortunately when you
responded to that email, you had to cut your response off due to time
constraints before you reached that example, so we didn't get to
discuss it directly.

As well, content wrapping is only convenient if you have control over
the markup.  Making a layout language require it limits the ability of
viewers, using alternate style sheets or tools such as Stylish, from
manipulating a page's layout fully.  Users of templating systems are
similarly inconvenienced.

I also consider today's necessity of wrapping elements to be a bug,
and would like to see it disappear in the future.

>> and you have to *change* those wrappers if you want to alter the
>> layout significantly.
>
> Change the HTML? How so? I would think so, if you are using classed or id'ed
> DIVs (likely).

If you want to divide things up differently.  In the 3-col example I
provided in an earlier email in this thread, two of the columns
consist of 'side content', things that are incidental to the main
content, and most importantly, *which aren't connected to each other
in any significant way*.  In order to split them across the two
columns, one has to either add a <div> wrapper which does *not*
actually convey a significant division, and change this wrapper if one
wishes to change the layout of the columns, or put each item into a
separate cell, which adds additional and likely unattractive
constraints on row heights.

>> The first part is unpalatable and should be
>> avoided if possible, and the second is simply ridiculous for a layout
>> manager.
>
> That's the second time in about as many days when you've declared my
> arguments ridiculous. I'd appreciate it if you could just discuss the matter
> in a little less insulting manner.

As noted, I don't mean to be insulting, and I'm really sorry.  T_T
The thing I'm referring to with the 'ridiculous' insult is the idea of
a layout manager that still requires substantial additional
information in the content it's laying out, such that you have to
alter the content to change the layout in fairly natural ways.

> Even with no appropriate container,, an anonymous table-cell would be
> generated, and the question is just whether or not you can select it with
> the new pseudo-class, or if you need to after moving around the other cells.
> If it could be selected, then it really really doesn't need this further
> complication.

Indeed, an anonymous cell would be created.  The question is whether
you can place more than one thing in that cell.  That is, if placing
an object automatically makes it into a table-cell, or places it
*within* an anonymous table-cell.  The former case requires a
container element in order to place multiple elements.  The latter
does not.

>> As an author, it would be a significant impediment if I didn't have
>> #2.  I could get around it by manually altering my source, as previous
>> noted, but that shouldn't be necessary.
>
> As an author, I would not find it an impediment at all. Nor would I need to
> alter any of the source that I've written style sheets for in the last
> decade for this. #2 might be occasionally useful as an extra feature to add
> later, but should not be allowed to have an impact on keeping #1 (or
> row/col-spans) simple and easy to use.

Reasonable people can differ.  However, I have a feeling that #2 is
actually a minor issue in this whole thing.  It seems like figuring
out how to resolve positional conflicts and just what exactly
table-rows and table-cols do is a more controversial issue.

~TJ

Received on Friday, 20 March 2009 19:07:23 UTC