- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Mon, 6 Apr 2009 08:58:15 -0700
- To: inhahe <inhahe@gmail.com>
- Cc: www-style@w3.org
- Message-Id: <DB27A01C-6E61-45EA-8525-7EA84EE13632@gmail.com>
On Apr 1, 2009, at 5:29 PM, inhahe wrote:
> I don't have much experience with CSS, but I've read the tutorials.
> Maybe I'm wrong, but it seems that there's no good way to do
> alignment. Like, things that people prefer to do with tables,
> because it Just Works, even though the CSS community chastizes
> people for that.
>
> For example let's say I have two divs in a left column, and one on
> the right. (maybe the two left div's are within a larger div, and
> the larger div and the right div are float:left.) Now I want the
> right div to size itself just as tall as necessary to go down
> exactly as much as the two left div's do. (say i have a background
> and pretty borders and stuff. using absolute positioning and
> sizing for this kind of stuff (alignment-related) isn't very
> dynamic; it has to be changed every time content changes and changes
> the sizes of things, to make things match.
>
> I tried an experiment (hope this e-mails okay):
No, but I fixed that:
<html><body>
<div>
<div style="height: 100%; background-color: red; float:left">
this<br/>
is<br/>
a<br/>
test
</div>
<div style="background-color: blue; float:left">
hi
</div>
<div style="height: 100%; background-color: green; float:left">
foobar
</div>
</div>
> </body></html>
>
> (please ignore my lack of proper doctype, etc.)
>
> hoping that would do the trick.. it didn't. wouldn't it be nice if
> it did? (i was hoping that the left and right divs would both size
> themselves to 100% of the available height of the outer div, while
> the outer div auto-sizes itself to the minimum size necessary to
> accomodate the contents of both the left and right div's.)
For display:block the outer DIV does that, but that is not what 100%
height means for the inner DIVs. You can do that like this, however,
with no float or height properties needed (or, more precisely, with
{ float:none; height:auto; }:
DIV { display:table; }
DIV DIV { display:table-cell; }
> that would be a simple solution and not even requiring any extra
> syntax, but i thought of a whole new system that could improve on
> this ability. basically some sort of alignment commands for CSS,
> which allow you to align certain things (left/right/top/bottom
> border/margin/content edge) with certain things of other elements.
> for example you could align an element's left and right margins with
> another element's left and right margins, the other element being
> referenced by its id attribute. then additionally you could move it
> left/right from that spot with relative positioning (using the
> normal relative positoning syntax) if you wanted.
>
> i would imagine aligning a left margin with a left margin would
> require a briefer syntax then aligning a left margin with, say,
> another left border. or another *right* margin. (with the briefest
> syntax would it align only the margin by default, or margin, border,
> and content edge?) for example maybe "align-left-border: someid" to
> align the left border with someid's left border, or "align-left-
> border: someid/right" to align left border with someid's right
> border, or "align-left-border: someid/right/margin" (obvious
> meaning), or "align-left-border: someid/margin" for someid's left
> margin, or "align-left:someid" to align left margin with someid's
> left margin (or left margin/border/content-edge?)
>
> of course you don't always want to just align one thing with
> another, because hwat if the sizes of both things are dynamic (auto-
> generated or frequently modified) and you're not sure which will
> need more space, but you want both things aligned (like in my html
> code above, only you don't know which div will be taller). in that
> case i think the simplest solution would just be to align all the
> things you want to align with eachother to a common id attribute
> which doesn't actually refer to an existing element. but not to
> make things confusing, such ad hoc referents should probably be
> distinguished somehow from actual id's, for example by prefixing
> with a certain character.
Please read the latest draft about a system under development that
would allow elements to arbitrarily align to various grid lines. Its
called "Advanced Layout."
http://www.w3.org/TR/2009/WD-css3-layout-20090402
It may be just what you are looking for.
> i wrote more about this in my blog at http://inhahe.blogspot.com
> (after my ramblings about a few other things which may not be actual
> issues).
Extra dot in your URL. Should be: http://inhahe.blogspot.com/
Here are some thoughts about that:
> So what tags do we have for containing content, other than div? Span
> would be nice, except that it has strange limitations: it can't
> contain certain other HTML tags, and apparently it can't even
> contain line breaks.
DIVs and SPANS are very generic, but there are many HTML elements that
can contain content. In HTML, an inline element, such as SPAN (or B,
or I, or ACRONYMN, etc.) cannot contain a block element (like DIV, P,
BLOCKQUOTE, etc.). But in CSS almost any element can be changed from
inline to block, or vice versa, with the display property. DIVs and
SPANs can both contain line breaks (BRs), but they are often not
semantically correct. (If you are using them to divide paragraphs,
then they are the wrong HMTL. If you are using them to adjust where
the end of a line occurs within the paragraph, then there might be a
more appropriate way to do that in CSS.)
> So we just have div, and then whenever we don't want a damn margin,
> because all we want to do is demarcate data, we have to write CSS
> code to specify that.
DIVs do not, by default, have any margin associated with them.
> Divs also by default come below each other in sequence, unlike
> normal information which flows left to right, so that's another
> thing you sometimes have go out of your way to change in CSS.
DIVs are display:block by default. SPANs are display:inline by
default. You can easily change that in CSS quite easily, but it is
usually the main reason one chooses DIV instead of SPAN.
> So clearly we're missing something here, something in between div
> and span, or at least a span that likes people.
There are other values for the display property, such as inline-block,
table-cell, etc.
> I've also seen ul's used with CSS, for menus. You have to modify
> them extensively to get rid of the bullets and margins, maybe make
> them go left-to-right, etc. It seems like they're being used in
> cases like these for something other than their intended purpose,
> and I tried doing the same thing in some other way than using ul's,
> and it didn't work. So that implies that ul's are being used to fill
> in for some other shortcoming.
If ULs and LIs are used for things that are lists, then that is their
intended purpose. Those HTML lists have some default CSS styling that
can be changed if you have a list and want non-default styling (to
remove bullets and margin, for example).
> What I really was thinking right now, though, is that the degree of
> separation of content from separation in CSS is very limited.
> Basically you can specify sequences of information-elements and in
> specific hierarchies, and then display those elements and
> hierarchies in any way you want, but if the way you want to display
> it involves changing the order of the information (without using
> absolute positioning) that's a no-go. That can only be done by
> editing the HTML or the scripting code. Since a CSS file is designed
> to define only attributes of classes/tags on a syntactic level,
> there really isn't remotely a way for it to specify order of
> information. It would have to be changed dramatically.
There are a number of different proposals being reviewed and edited
that would allow out-of-source-order layout via CSS.
> To preserve backward compatibility, and its ease of specifying
> attributes, a new kind of syntactical entity should probably just be
> introduced that can specify sequences and hierarchies of
> information. The content itself, which would be found in the HTML
> code, would simply be referred to by id attributes. In the interest
> of the XML movement and consistency with HTML, the new syntax should
> probably be HTML-like, perhaps a subset of HTML. But then again in
> the interest of consistency/simplicity, why limit the HTML? Just
> make it full HTML, the only difference being the referring to of
> information by id attribute. And what if the HTML itself contains id
> attributes? Just allow it to refer to those too, I think..
CSS can select and style HTML elements based on the id attributes in
the HTML.
> But this just begs for a much simpler and somewhat more generalized
> and versatile solution: a) allow *all* HTML to convey other parts of
> the HTML, referred to by their id attributes, and b) allow HTML to
> include other HTML files. B) isn't so radical, since HTML can
> already include .css, .js, and image files. We're only making it
> more consistent here.
(B) is currently allowed via the IFRAME element. Its not perfect, but
it sounds like what you are asking for.
> Another shortcoming, and this is really the one that bugs me most
> often, is alignment.
>
> There's a *big* issue in CSS where all the CSS gurus yell DON'T USE
> TABLES, not for layout purposes. Now here's the rub: people use
> tables for a reason. It's *easy*. In HTML, and in almost every other
> area of computer technology and life itself, simple things should be
> able to be done simply. Doing the same things you can do with a
> table with CSS is a real P.I.T.A. It's not at all obvious how to do
> it (to understate the problem), it's not quick and easy, and even a
> highly paid web front-end guru admitted to me that CSS has
> shortcomings in this area, when I asked him if there should perhaps
> be a CSS-equivalent to tables.
Actually it is HTML, not CSS, that tells you not to use TABLEs for non-
tabular information, because HTML structures are supposed to be
semantic. CSS is not semantic, it is just a way of specifying how
things display. Thus in CSS, there is a CSS-equivalent to tables;
'display:table-cell' is perfectly acceptable for almost any container
element you want to apply it to. It is only called table-cell because
it describes the display method that is most familiar to people as the
way cells are displayed in HTML TABLEs. But it is in CSS to be applied
generally, not just to tables.
> Is there a way to create a feature something like tables, per se,
> for CSS?
Yes.
> I don't know, because I don't know precisely what the contention is
> with using tables; i.e., in exactly what ways does using tables
> prevent one from customizing layout in CSS?
Nothing. HTML want you to use TABLEs for tabular elements, so that
meaningful markup (without regard to presentation) is preserved. CSS
is about presentation, so we're fine if you want to take things that
are not TABLEs and present them using the same display qualities.
> Tables provide alignment. What do they disprovide, and would this
> same limitation apply to adding, per se, a table-like feature to
> CSS? How would we do that anyway, on a semantic level?
You can read all about that, here:
http://www.w3.org/TR/CSS21/tables.html
Received on Monday, 6 April 2009 16:12:59 UTC