 | |
How to center some text nicely between two floats
Cascading Style Sheets Layout/presentation on the WWW (comp.infosystems.www.authoring.stylesheets)
 |
| | Thread Tools | Display Modes |
#21
 
| |||
| |||
|
Re: How to center some text nicely between two floats -
11-25-2008
, 02:20 PM
|
Johannes Koch schreef: Hendrik Maryns schrieb: So where can I read up on this table mimicking CSS? In the CSS 2.1 spec, section 17. Right. I was hoping for more of a cookbook-like page, but if nothing helps, I?ll have to fight through that text. |
there. One exception is this reference: http://xhtml.com/en/css/reference/
I use it because it is well organized. But it lacks detail and I sill need to
access the spec for genuine semantics. I find tutorials and how-to guides to
be the worst, mostly because their examples don't really include layout issues
I encounter (what they do include are the simpler things I can figure out).
--
Quote:
|
WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance | by the abuse department, bellsouth.net is blocked. If you post to | Usenet from these places, find another Usenet provider ASAP. | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) | |
#22
| |||
| |||
|
|
phil-news-nospam (AT) ipal (DOT) net wrote: CSS2 has display modes to mimic tables but this is not widely implemented Actually, it *is* widely implemented - by the mozilla-based browsers, Opera, and KHTML/Webkit - and has been for quite a while. |
If you figure it by count of users with implementations in hand, then the
majority is slim at best, and likely not quite a majority. For websites
targeted to the open source community, I'd use the display:table* styles.
For websites targeted to the general population masses, I would not, and
thus for many layout issues I would have to revert to markup tables.
Quote:
|
(reportedly unsupported in IE). Not reportedly - it's a fact. This may persuade you to avoid using display:table, but I think it depends on the project. I'd just as soon let IE use some fallback. |
to modify content. If I'm going to have tables in there for some browsers,
it saves my time just to go ahead and leave it that way for all, since they
do work.
There is the principle of that which is style should be specified as style,
and that which is content should be specified as content. This principle
would avoid doing any layout or style in HTML. The sad fact is that CSS 2.1
is simply NOT mature enough to achieve this lofty goal. There are still many
cases where desired layout and style cannot be achieved without adding extra
<div> or <span> elements to the HTML. A simplistic example is a rainbow of
border colors. You need extra <div> elements nested to do that, and style
each with a different color. Once CSS has a means to let style do anything
that could be done with as many elements, and apply it to exactly one element
via one ID or one class, then we may have something. But then this would be
a box model that can contain an infinite number of layers, instead of the fixed
set of margin, border, padding. CSS is still weak, and has not kept up with
the imaginations of web designers.
--
Quote:
|
WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance | by the abuse department, bellsouth.net is blocked. If you post to | Usenet from these places, find another Usenet provider ASAP. | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) | |
#23
| |||
| |||
|
|
There is the principle of that which is style should be specified as style, and that which is content should be specified as content. This principle would avoid doing any layout or style in HTML. The sad fact is that CSS 2.1 is simply NOT mature enough to achieve this lofty goal. There are still many cases where desired layout and style cannot be achieved without adding extra <div> or <span> elements to the HTML. A simplistic example is a rainbow of border colors. You need extra div> elements nested to do that, and style each with a different color. Once CSS has a means to let style do anything that could be done with as many elements, and apply it to exactly one element via one ID or one class, then we may have something. |
A few simple styling rules PLUS being able to change the document tree
is very powerful. If you can't touch the tree there is always going to
be much less you can do with the stylesheets. You can keep adding
properties to CSS to do different individual things, to try to keep up
with the imaginations of designers, but that would quickly get out of
hand (although that doesn't stop people suggesting it).
More powerful stylesheet languages can transform the tree so the problem
disappears. But those were rejected for CSS because they make
progressive rendering much harder. You can read about this in Hakon Wium
Lie's thesis (http://people.opera.com/howcome/2006/phd/).
Quote:
|
But then this would be a box model that can contain an infinite number of layers, instead of the fixed set of margin, border, padding. CSS is still weak, and has not kept up with the imaginations of web designers. |
either (in rough order of preference):
1. Compromise the design.
2. Use extra divs and spans anyway.
3. Use Flash or something equally horrible.
4. Add hundreds of fabulous new properties to CSS until it can do
everything you can think of.
Somewhere between 1 and 2 is usually the best advice. A couple of extra
divs aren't going to hurt anyone, and fancy overconstrained designs
usually create a lot of other problems anyway.
#24
| |||||||||
| |||||||||
|
|
On 2008-11-25, phil-news-nospam (AT) ipal (DOT) net <phil-news-nospam (AT) ipal (DOT) net> wrote: [...] There is the principle of that which is style should be specified as style, and that which is content should be specified as content. This principle would avoid doing any layout or style in HTML. The sad fact is that CSS 2.1 is simply NOT mature enough to achieve this lofty goal. There are still many cases where desired layout and style cannot be achieved without adding extra <div> or <span> elements to the HTML. A simplistic example is a rainbow of border colors. You need extra div> elements nested to do that, and style each with a different color. Once CSS has a means to let style do anything that could be done with as many elements, and apply it to exactly one element via one ID or one class, then we may have something. But to do that would bloat CSS unacceptably. |
layers. If you want to create 200 layers of borders, each with a unique
color, of course you have to provide 200 colors, in the correct order.
Doing this without an integral feature in CSS means you have to create
200 CSS selectors AND 200 nested elements in HTML. That's MORE bloat.
If you want to argue that 200 layers of borders is bloat, I would agree.
But I don't see making CSS know how to handle this is bloat.
Quote:
|
A few simple styling rules PLUS being able to change the document tree is very powerful. If you can't touch the tree there is always going to be much less you can do with the stylesheets. You can keep adding properties to CSS to do different individual things, to try to keep up with the imaginations of designers, but that would quickly get out of hand (although that doesn't stop people suggesting it). |
changed.
One component of extending CSS would be to provide for multiple borders.
For example:
..rainbowborder {
border: 4px solid #f00, 4px solid #0f0, 4px solid #00f;
}
This would simply imply 3 borders on one element. No document tree change
is needed. The total border size is 12. And this is merely a simple and
convenient change. The same should be done with other rules where it would
accomplish something.
Quote:
|
More powerful stylesheet languages can transform the tree so the problem disappears. But those were rejected for CSS because they make progressive rendering much harder. You can read about this in Hakon Wium Lie's thesis (http://people.opera.com/howcome/2006/phd/). |
NOT doing so leads people to making layouts in the markup (whether that is
by using table elements, or by adding more and more elements).
NOT doing so keeps us from reaching the point where style and markup are
truly separate.
Quote:
|
But then this would be a box model that can contain an infinite number of layers, instead of the fixed set of margin, border, padding. CSS is still weak, and has not kept up with the imaginations of web designers. CSS _is_ weak compared to a transformation language. This means you can either (in rough order of preference): 1. Compromise the design. |
Quote:
|
2. Use extra divs and spans anyway. |
Quote:
|
3. Use Flash or something equally horrible. |
Quote:
|
4. Add hundreds of fabulous new properties to CSS until it can do everything you can think of. |
I suggest some extensions on some existing rules (see border example above).
A generalized approach would be a virtual document tree. This would be an
expression in CSS that specifies an extension of the document tree branch to
which the rules apply. The document tree itself would be unchanged in terms
of its delivery by HTML/XHTML/XML/etc or construction by ECMAScript/JavaScript.
An implementation (of a browser) may choose to actually reconstruct the tree
internally, or choose to refer to a separate branch extension that includes a
back reference (where the branch extension ends, it refers back to the part
of the tree that referred to it, much like a function call).
The rule applied to the selected elements would add virtual elements, which
can then be styled in place, or styled separately by element or class selection.
Here is an example. The syntax here is ad-hoc and NOT specifically what I am
suggesting. Focus on the semantics. The whole idea is open to tweaking and
other changes, including how the syntax should be done.
..mybox {
inside-div: {
position: relative;
top: 4px;
left: 4px;
background-color: #cccccc;
}
inside-div: {
position: relative;
top: 0px;
left: 0px;
border: 1px solid #000000;
background-color: #eeee00;
}
}
A generalized form of rules would be:
before-(element-name)
inside-(element-name)
after-(element-name)
These rules can then specify their own set of rules like show above, or can
specify a referenced class to use another selector elsewhere, or both.
In the above example 2 divs are added inside the selected element, but not
inside each other. To make 2 divs inside each other, nest them:
..myclass {
...
inside-div: {
...
inside-div: {
...
}
...
}
...
}
The form of implied element rules that begin with "before" and "after" would
place the implied elements before the selected element, or after it, in the
order given if more than one.
Cascading multiple selectors means using the implied elements only from ONE
of the rules, in the same order as other rules are overridden.
Quote:
|
Somewhere between 1 and 2 is usually the best advice. A couple of extra divs aren't going to hurt anyone, and fancy overconstrained designs usually create a lot of other problems anyway. |
What the extra divs will hurt is the proper separation of markup and style.
Proper separation will allow markup to be created entire oblivious to what
the style will be. Proper separation will allow style to be changed to any
design without having to make any change whatsoever to the document.
I will continue to tell people to go ahead and use table elements in document
markup until such time as the definition of separation of markup and style is
complete (e.g. that CSS can do what would otherwise require adding elements to
the document to do). As long as I have to tell people to "add a div" then I
know the separation of markup and style is not complete, and thus will have no
qualms about _also_ telling them "go ahead and use table elements in markup"
because both suggestions are essentiall the same violation of the principle
(that is not yet realized).
--
Quote:
|
WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance | by the abuse department, bellsouth.net is blocked. If you post to | Usenet from these places, find another Usenet provider ASAP. | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) | |
#25
| ||||||||
| ||||||||
|
|
On Tue, 25 Nov 2008 17:01:30 -0600 Ben C <spamspam (AT) spam (DOT) eggs> wrote: | On 2008-11-25, phil-news-nospam (AT) ipal (DOT) net <phil-news-nospam (AT) ipal (DOT) net> wrote: | [...] |> There is the principle of that which is style should be specified as |> style, and that which is content should be specified as content. This |> principle would avoid doing any layout or style in HTML. The sad fact |> is that CSS 2.1 is simply NOT mature enough to achieve this lofty |> goal. There are still many cases where desired layout and style cannot |> be achieved without adding extra <div> or <span> elements to the HTML. |> A simplistic example is a rainbow of border colors. You need extra |> <div> elements nested to do that, and style each with a different |> color. Once CSS has a means to let style do anything that could be |> done with as many elements, and apply it to exactly one element via |> one ID or one class, then we may have something. | | But to do that would bloat CSS unacceptably. The bloat would only be if you use such a feature to create an excess of layers. If you want to create 200 layers of borders, each with a unique color, of course you have to provide 200 colors, in the correct order. Doing this without an integral feature in CSS means you have to create 200 CSS selectors AND 200 nested elements in HTML. That's MORE bloat. If you want to argue that 200 layers of borders is bloat, I would agree. But I don't see making CSS know how to handle this is bloat. |
rainbow borders, they might be worth putting in CSS3. (In fact they
probably have been).
Curved borders are something you can do with CSS2.1 and extra elements.
But you might need up to 8 extra elements and it's a lot of trouble for
a popular feature. So those are a good addition to CSS3 (and already
partially implemented in Firefox).
But if something's easy to do with just one or two extra divs and isn't
also seriously popular then I don't think it should be added to CSS3
because that will make CSS3 too big.
A document bloated by a few extra elements is bad, but not as bad as a
specification bloated by hundreds of extra rules to make up for its
inherent lack of combinative power.
Quote:
|
| A few simple styling rules PLUS being able to change the document tree | is very powerful. If you can't touch the tree there is always going to | be much less you can do with the stylesheets. You can keep adding | properties to CSS to do different individual things, to try to keep up | with the imaginations of designers, but that would quickly get out of | hand (although that doesn't stop people suggesting it). IMHO, the document tree should not be changed, and ideally need not be changed. |
can think of rainbow borders, but if you added properties so that you
could do anything anybody could reasonably want to do without changing
the tree, how many properties would you need?
Assume for this experiment that you cannot change CSS into a
"transformation-based language". All you can do is stuff in more
properties.
Quote:
|
One component of extending CSS would be to provide for multiple borders. For example: .rainbowborder { border: 4px solid #f00, 4px solid #0f0, 4px solid #00f; } This would simply imply 3 borders on one element. No document tree change is needed. The total border size is 12. And this is merely a simple and convenient change. The same should be done with other rules where it would accomplish something. |
have as many background images as you like, clip and position them all
differently, and they all sit on top of each other.
And yes, that would be a fine way to do rainbow borders in CSS. Check
the spec-- they may already be there in CSS3.
Quote:
|
| More powerful stylesheet languages can transform the tree so the problem | disappears. But those were rejected for CSS because they make | progressive rendering much harder. You can read about this in Hakon Wium | Lie's thesis (http://people.opera.com/howcome/2006/phd/). NOT doing so makes web development harder. NOT doing so leads people to making layouts in the markup (whether that is by using table elements, or by adding more and more elements). NOT doing so keeps us from reaching the point where style and markup are truly separate. |
Quote:
|
|> But then this would be a box model that can contain an infinite number |> of layers, instead of the fixed set of margin, border, padding. CSS |> is still weak, and has not kept up with the imaginations of web |> designers. | | CSS _is_ weak compared to a transformation language. This means you can | either (in rough order of preference): | | 1. Compromise the design. Unacceptable. | 2. Use extra divs and spans anyway. Unacceptable. | 3. Use Flash or something equally horrible. Unacceptable. Any form of client side programming/scripting is unacceptable. | 4. Add hundreds of fabulous new properties to CSS until it can do | everything you can think of. Not what I suggested. I suggest a few (generalized) ideas, not hundreds. I suggest some extensions on some existing rules (see border example above). A generalized approach would be a virtual document tree. This would be an expression in CSS that specifies an extension of the document tree branch to which the rules apply. The document tree itself would be unchanged in terms of its delivery by HTML/XHTML/XML/etc or construction by ECMAScript/JavaScript. |
many advantages.
But it was rejected because of the progressive rendering problem. All
the same I don't find that perfectly convincing-- you could still do
some progressive rendering, and even as things stand today, progressive
rendering already consists of complete reflow in a lot of cases.
Quote:
|
An implementation (of a browser) may choose to actually reconstruct the tree internally, or choose to refer to a separate branch extension that includes a back reference (where the branch extension ends, it refers back to the part of the tree that referred to it, much like a function call). The rule applied to the selected elements would add virtual elements, which can then be styled in place, or styled separately by element or class selection. Here is an example. The syntax here is ad-hoc and NOT specifically what I am suggesting. Focus on the semantics. The whole idea is open to tweaking and other changes, including how the syntax should be done. .mybox { inside-div: { position: relative; top: 4px; left: 4px; background-color: #cccccc; } inside-div: { position: relative; top: 0px; left: 0px; border: 1px solid #000000; background-color: #eeee00; } } A generalized form of rules would be: before-(element-name) inside-(element-name) after-(element-name) These rules can then specify their own set of rules like show above, or can specify a referenced class to use another selector elsewhere, or both. In the above example 2 divs are added inside the selected element, but not inside each other. To make 2 divs inside each other, nest them: .myclass { ... inside-div: { ... inside-div: { ... } ... } ... } The form of implied element rules that begin with "before" and "after" would place the implied elements before the selected element, or after it, in the order given if more than one. |
pseudo-elements (CSS2.1). We also have anonymous blocks and table boxes
which add boxes to the box-tree for layout purposes without affecting
the DOM tree.
But what you are describing is what Lie calls a "transformation-based
style sheet language" and which he says he didn't want to use for CSS.
The most interesting thing about the thesis though is the survey of
other stylesheet languages.
Quote:
|
Cascading multiple selectors means using the implied elements only from ONE of the rules, in the same order as other rules are overridden. | Somewhere between 1 and 2 is usually the best advice. A couple of extra | divs aren't going to hurt anyone, and fancy overconstrained designs | usually create a lot of other problems anyway. I strongly disagree. What the extra divs will hurt is the proper separation of markup and style. Proper separation will allow markup to be created entire oblivious to what the style will be. Proper separation will allow style to be changed to any design without having to make any change whatsoever to the document. |
suited to that job. It's like trying to build a wall out of icing sugar.
That's why I say accept the compromise. If CSS were transformation-based
there would be no compromise.
Quote:
|
I will continue to tell people to go ahead and use table elements in document markup until such time as the definition of separation of markup and style is complete (e.g. that CSS can do what would otherwise require adding elements to the document to do). As long as I have to tell people to "add a div" then I know the separation of markup and style is not complete, and thus will have no qualms about _also_ telling them "go ahead and use table elements in markup" because both suggestions are essentiall the same violation of the principle (that is not yet realized). |
of principle. The real harm is not in breaking a rule, but in breaking
it _badly_. For me a couple of extra divs is OK, but nested tables and
<font>s everywhere isn't.
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.