This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Dreamweaver > June 2004 > (CSS) Line-height variable in IE6
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
(CSS) Line-height variable in IE6
|
|
| Jon Yeager 2004-06-09, 6:05 pm |
| In the following example, is there any reason why the line-height would be
ignored in IE6 (while coming across perfectly in Dreamweaver's workstation?)
:
<body>
<span class="gif-48">This is a</span><br><span class="gif-32">
<span class="gif-hi-26">test</span></span><br><br><br>
<span class="gif-36"><span class="gif-hi-38"><span class="red">Just
a <strong>somple</strong><br>
test...</span></span></span>
</body>
Where the style are defined as :
..gif-48 {
font-family: Arial, Helvetica, sans-serif;
font-size: 48px;
}
..gif-32 {
font-family: Arial, Helvetica, sans-serif;
font-size: 32px;
}
..gif-36 {
font-family: Arial, Helvetica, sans-serif;
font-size: 36px;
}
..gif-hi-26 {
line-height: 26px;
}
..gif-hi-38 {
line-height: 38px;
}
..red {
color: #CC0000;
}
======================
Isn't the whole point of CSS being able to line up and combine a bunch of
cumulative styles?
What am I doing wrong? The Size and color are coming through okay, but not
the line-height.
| |
| Murray *TMM* 2004-06-09, 7:14 pm |
| Does your page have a valid doctype?
--
Murray --- ICQ 71997575
Team Macromedia Volunteer for Dreamweaver MX
(If you *MUST* email me, don't LAUGH when you do so!)
==================
news://forums.macromedia.com/macromedia.dreamweaver - THE BEST WAY TO GET
ANSWERS
==================
http://www.dreamweavermx-templates.com - Template Triage!
http://www.projectseven.com/go - DW FAQs, Tutorials & Resources
http://www.dwfaq.com - DW FAQs, Tutorials & Resources
http://www.macromedia.com/support/search/ - Macromedia (MM) Technotes
==================
"Jon Yeager" <nospam@please.com> wrote in message
news:ca7s93$g4b$1@forums.macromedia.com...
> In the following example, is there any reason why the line-height would be
> ignored in IE6 (while coming across perfectly in Dreamweaver's
workstation?)
> :
>
> <body>
> <span class="gif-48">This is a</span><br><span class="gif-32">
> <span class="gif-hi-26">test</span></span><br><br><br>
> <span class="gif-36"><span class="gif-hi-38"><span class="red">Just
> a <strong>somple</strong><br>
> test...</span></span></span>
> </body>
>
> Where the style are defined as :
>
> .gif-48 {
> font-family: Arial, Helvetica, sans-serif;
> font-size: 48px;
> }
> .gif-32 {
> font-family: Arial, Helvetica, sans-serif;
> font-size: 32px;
> }
> .gif-36 {
> font-family: Arial, Helvetica, sans-serif;
> font-size: 36px;
> }
>
>
> .gif-hi-26 {
> line-height: 26px;
> }
> .gif-hi-38 {
> line-height: 38px;
> }
>
>
> .red {
> color: #CC0000;
> }
>
> ======================
>
> Isn't the whole point of CSS being able to line up and combine a bunch of
> cumulative styles?
>
> What am I doing wrong? The Size and color are coming through okay, but not
> the line-height.
>
>
| |
| James Shook 2004-06-09, 7:14 pm |
| <span>s don't respond to line-height. Only block-level tags like <p>
will. If DW is showing this to you, it is wrong.
--
James M. Shook
http://www.jshook.com
| |
| Murray *TMM* 2004-06-09, 7:14 pm |
| To tell you the truth, I don't see what the problem is....
--
Murray --- ICQ 71997575
Team Macromedia Volunteer for Dreamweaver MX
(If you *MUST* email me, don't LAUGH when you do so!)
==================
news://forums.macromedia.com/macromedia.dreamweaver - THE BEST WAY TO GET
ANSWERS
==================
http://www.dreamweavermx-templates.com - Template Triage!
http://www.projectseven.com/go - DW FAQs, Tutorials & Resources
http://www.dwfaq.com - DW FAQs, Tutorials & Resources
http://www.macromedia.com/support/search/ - Macromedia (MM) Technotes
==================
"Jon Yeager" <nospam@please.com> wrote in message
news:ca7s93$g4b$1@forums.macromedia.com...
> In the following example, is there any reason why the line-height would be
> ignored in IE6 (while coming across perfectly in Dreamweaver's
workstation?)
> :
>
> <body>
> <span class="gif-48">This is a</span><br><span class="gif-32">
> <span class="gif-hi-26">test</span></span><br><br><br>
> <span class="gif-36"><span class="gif-hi-38"><span class="red">Just
> a <strong>somple</strong><br>
> test...</span></span></span>
> </body>
>
> Where the style are defined as :
>
> .gif-48 {
> font-family: Arial, Helvetica, sans-serif;
> font-size: 48px;
> }
> .gif-32 {
> font-family: Arial, Helvetica, sans-serif;
> font-size: 32px;
> }
> .gif-36 {
> font-family: Arial, Helvetica, sans-serif;
> font-size: 36px;
> }
>
>
> .gif-hi-26 {
> line-height: 26px;
> }
> .gif-hi-38 {
> line-height: 38px;
> }
>
>
> .red {
> color: #CC0000;
> }
>
> ======================
>
> Isn't the whole point of CSS being able to line up and combine a bunch of
> cumulative styles?
>
> What am I doing wrong? The Size and color are coming through okay, but not
> the line-height.
>
>
| |
| Jon Yeager 2004-06-09, 7:14 pm |
| You know what's strange? I tried px line heights, pt, and even %... but IE6
and NN7 both respond better to a MULTIPLE line height in a span tag.
i.e.: line-height: 0.85
But what is the difference between "multiple" and "%"? Doesn't a multiple
of 0.85 = 85%?
Either way, it works, only that Dreamweaver won't calculate 0.85 the same
way IE and NN do. Oddly enough, IE6 and NN7 both calculate the value of
"line-height: 0.85" the EXACT same way... but in DWMX, it adds a bit more
space... making it pretty difficult to place large amounts of text in
limited spaces.
I have to constantly F12 to see if I've exceeded the alotted space...
because DWMX interprets the line-heights differently in the workstation than
the two other browsers do. I can exceed my space in DWMX while remaining
within my limitations in the final output (ie, in the browser).
Is there a way to manually compensate for this somehow? To tell DWMX to read
a line height of 0.85 as smaller than it currently does?
"Murray *TMM*" <forums@HAHAgreat-web-sights.com> wrote in message
news:ca7uhb$is6$1@forums.macromedia.com...
> James:
>
> Both IE6 and FF on PC showed changes in line-heights for me.
>
> --
> Murray --- ICQ 71997575
> Team Macromedia Volunteer for Dreamweaver MX
> (If you *MUST* email me, don't LAUGH when you do so!)
> ==================
> news://forums.macromedia.com/macromedia.dreamweaver - THE BEST WAY TO GET
> ANSWERS
> ==================
> http://www.dreamweavermx-templates.com - Template Triage!
> http://www.projectseven.com/go - DW FAQs, Tutorials & Resources
> http://www.dwfaq.com - DW FAQs, Tutorials & Resources
> http://www.macromedia.com/support/search/ - Macromedia (MM) Technotes
> ==================
>
> "James Shook" <jshook@dont_mail.com> wrote in message
> news:ca7tcl$h8i$1@forums.macromedia.com...
>
>
| |
|
|
| Murray *TMM* 2004-06-09, 7:14 pm |
| Try using a block-level container instead of an inline one.
--
Murray --- ICQ 71997575
Team Macromedia Volunteer for Dreamweaver MX
(If you *MUST* email me, don't LAUGH when you do so!)
==================
news://forums.macromedia.com/macromedia.dreamweaver - THE BEST WAY TO GET
ANSWERS
==================
http://www.dreamweavermx-templates.com - Template Triage!
http://www.projectseven.com/go - DW FAQs, Tutorials & Resources
http://www.dwfaq.com - DW FAQs, Tutorials & Resources
http://www.macromedia.com/support/search/ - Macromedia (MM) Technotes
==================
"Jon Yeager" <nospam@please.com> wrote in message
news:ca7v0h$jgn$1@forums.macromedia.com...
> You know what's strange? I tried px line heights, pt, and even %... but
IE6
> and NN7 both respond better to a MULTIPLE line height in a span tag.
>
> i.e.: line-height: 0.85
>
> But what is the difference between "multiple" and "%"? Doesn't a multiple
> of 0.85 = 85%?
>
> Either way, it works, only that Dreamweaver won't calculate 0.85 the same
> way IE and NN do. Oddly enough, IE6 and NN7 both calculate the value of
> "line-height: 0.85" the EXACT same way... but in DWMX, it adds a bit more
> space... making it pretty difficult to place large amounts of text in
> limited spaces.
>
> I have to constantly F12 to see if I've exceeded the alotted space...
> because DWMX interprets the line-heights differently in the workstation
than
> the two other browsers do. I can exceed my space in DWMX while remaining
> within my limitations in the final output (ie, in the browser).
>
> Is there a way to manually compensate for this somehow? To tell DWMX to
read
> a line height of 0.85 as smaller than it currently does?
>
> "Murray *TMM*" <forums@HAHAgreat-web-sights.com> wrote in message
> news:ca7uhb$is6$1@forums.macromedia.com...
GET[color=darkred]
>
>
| |
| Jon Yeager 2004-06-09, 7:14 pm |
| You mean like TD? Funny you should suggest that, that's what I've been
using. However, the problem of DW not interpreting line-heights the same was
as the browsers persists.
line-height: 0.85 is a wider line height in the workstation than it is in
either IE6 or NN7 (which, I feel obligated to bring up again, both interpret
the line heights the EXACT same way, working harmoniously together for
once... with DW being the ugly duckling for a change. Used to be, DW and IE
would interpret things the same way, and NN would be the odd man out.)
Times change! :)
"Murray *TMM*" <forums@HAHAgreat-web-sights.com> wrote in message
news:ca7vqh$kbu$1@forums.macromedia.com...
> Try using a block-level container instead of an inline one.
| |
| Murray *TMM* 2004-06-09, 7:14 pm |
| No - I mean like <div> rather than <span>.
--
Murray --- ICQ 71997575
Team Macromedia Volunteer for Dreamweaver MX
(If you *MUST* email me, don't LAUGH when you do so!)
==================
news://forums.macromedia.com/macromedia.dreamweaver - THE BEST WAY TO GET
ANSWERS
==================
http://www.dreamweavermx-templates.com - Template Triage!
http://www.projectseven.com/go - DW FAQs, Tutorials & Resources
http://www.dwfaq.com - DW FAQs, Tutorials & Resources
http://www.macromedia.com/support/search/ - Macromedia (MM) Technotes
==================
"Jon Yeager" <nospam@please.com> wrote in message
news:ca805n$kpm$1@forums.macromedia.com...
> You mean like TD? Funny you should suggest that, that's what I've been
> using. However, the problem of DW not interpreting line-heights the same
was
> as the browsers persists.
>
> line-height: 0.85 is a wider line height in the workstation than it is in
> either IE6 or NN7 (which, I feel obligated to bring up again, both
interpret
> the line heights the EXACT same way, working harmoniously together for
> once... with DW being the ugly duckling for a change. Used to be, DW and
IE
> would interpret things the same way, and NN would be the odd man out.)
>
> Times change! :)
>
> "Murray *TMM*" <forums@HAHAgreat-web-sights.com> wrote in message
> news:ca7vqh$kbu$1@forums.macromedia.com...
>
>
| |
| James Shook 2004-06-09, 7:14 pm |
| Murray *TMM* wrote:
> James:
>
> Both IE6 and FF on PC showed changes in line-heights for me.
After some research I can see that you're right--line-height can be
applied to inline elements. When this is done, something E. Meyer refers
to as an "inline box" is created. The line-height value is divided in
two and half is applied above the element and half below.
Since the code in the message is obviously a test, I can't tell if a
more elegant solution to what the poster is trying to do exists.
Frankly, the creation of inline boxes gives me the metaphysical
heebie-jeebies.
--
James M. Shook
http://www.jshook.com
| |
| Jon Yeager 2004-06-09, 7:14 pm |
| Can I tell DW to start using DIVs instead of SPANs to see what that
produces? Though even if it works, I doubt it will solve the problem at hand
of DW not interpreting spacial equations the same way the browsers do.
As you can guess, I rely heavily on the graphical interface and the mouse,
as opposed to manual coding. ;)
"Murray *TMM*" <forums@HAHAgreat-web-sights.com> wrote in message
news:ca80j5$l53$1@forums.macromedia.com...[color=darkred]
> No - I mean like <div> rather than <span>.
>
>
> "Jon Yeager" <nospam@please.com> wrote in message
> news:ca805n$kpm$1@forums.macromedia.com...
> was
| |
| Murray *TMM* 2004-06-09, 11:14 pm |
| Excellent. So Eric - what is the concise answer to Jon's poser?
Would it be fair to say "YES?" 8)
I don't get the heebie-jeebies anymore since I started on hinky. I just
like it so much better.
--
Murray --- ICQ 71997575
Team Macromedia Volunteer for Dreamweaver MX
(If you *MUST* email me, don't LAUGH when you do so!)
==================
news://forums.macromedia.com/macromedia.dreamweaver - THE BEST WAY TO GET
ANSWERS
==================
http://www.dreamweavermx-templates.com - Template Triage!
http://www.projectseven.com/go - DW FAQs, Tutorials & Resources
http://www.dwfaq.com - DW FAQs, Tutorials & Resources
http://www.macromedia.com/support/search/ - Macromedia (MM) Technotes
==================
"Eric A. Meyer" <eric@meyerweb.com> wrote in message
news:eric-E35224.18253609062004@forums.macromedia.com...
> In article <ca811d$ku8$1@forums.macromedia.com>,
>
> Then Web design may not be for you unless you really like the
> metaphysical heebie-jeebies, because every piece of content in every
> line of text-- whether or not the content is contained in an inline
> element, whether or not an explicit 'line-height' has been assigned to
> the content, and whether the content is text or an image or something
> else-- creates an inline box. Those inline boxes are what determine the
> height of each line box, and the line boxes determine how the content of
> block-level boxes is constructed.
| |
| Eric A. Meyer 2004-06-09, 11:14 pm |
| In article <ca811d$ku8$1@forums.macromedia.com>,
James Shook <jshook@dont_mail.com> wrote:
> After some research I can see that you're right--line-height can be
> applied to inline elements. When this is done, something E. Meyer refers
> to as an "inline box" is created. The line-height value is divided in
> two and half is applied above the element and half below.
>
> Since the code in the message is obviously a test, I can't tell if a
> more elegant solution to what the poster is trying to do exists.
>
> Frankly, the creation of inline boxes gives me the metaphysical
> heebie-jeebies.
Then Web design may not be for you unless you really like the
metaphysical heebie-jeebies, because every piece of content in every
line of text-- whether or not the content is contained in an inline
element, whether or not an explicit 'line-height' has been assigned to
the content, and whether the content is text or an image or something
else-- creates an inline box. Those inline boxes are what determine the
height of each line box, and the line boxes determine how the content of
block-level boxes is constructed.
It might seem like laying out lines of content is dirt simple, but
trust me, it's the most complex and difficult aspect of CSS-- and I mean
ALL of CSS. Floating and positioning are kids' stuff compared to the
internals of the inline layout model... and the scary part is that it
has to be at least that complex just to describe what little
typographical control CSS offers.
If you want to peruse the gory details in a terse format, there's
always <http://www.meyerweb.com/eric/css/inline-format.html>. For a
more readable but potentially no less intimidating explanation, there's
pages 180-194 of "Cascading Style Sheets: The Definitive Guide," Second
Edition. Yes, it takes 14 pages to complete, and even at that I
sometimes worry I didn't include enough explanatory text.
--
Eric A. Meyer | http://www.meyerweb.com/eric/ | CSS and standards guy
Yes.[color=darkred]
> Are you sure?
| |
| Eric A. Meyer 2004-06-09, 11:14 pm |
| In article <ca835s$no8$1@forums.macromedia.com>,
"Murray *TMM*" <forums@HAHAgreat-web-sights.com> wrote:
> Excellent. So Eric - what is the concise answer to Jon's poser?
There isn't one at this stage, because I don't know what he's trying
to do, nor do I know exactly what's meant by the 'line-height' being
"ignored in IE6". Without a test page and a screenshot of what's
expected to happen, any answer is as likely to be wrong as right.
Possibly more so.
--
Eric A. Meyer | http://www.meyerweb.com/eric/ | CSS and standards guy
Yes.[color=darkred]
> Are you sure?
| |
|
| I have had the same problem:
line height is defined in my css.
I apply it to <span> and IE PC ignores it. (line height is wrong).
Meanwhile all Mac browsers do it right.
It seems that IE PC ignores line height when applied to <span>
I have to apply it to <span> (and not <p>, because I don't want
paragraph breaks but line breaks <br>, and have different styles from
one line to the next.)
Eric A. Meyer wrote:
> In article <ca835s$no8$1@forums.macromedia.com>,
> "Murray *TMM*" <forums@HAHAgreat-web-sights.com> wrote:
>
>
>
>
> There isn't one at this stage, because I don't know what he's trying
> to do, nor do I know exactly what's meant by the 'line-height' being
> "ignored in IE6". Without a test page and a screenshot of what's
> expected to happen, any answer is as likely to be wrong as right.
> Possibly more so.
>
| |
| James Shook 2004-06-10, 12:14 pm |
| Eric A. Meyer wrote:
> For a
> more readable but potentially no less intimidating explanation, there's
> pages 180-194 of "Cascading Style Sheets: The Definitive Guide," Second
> Edition. Yes, it takes 14 pages to complete, and even at that I
> sometimes worry I didn't include enough explanatory text.
That's what I did read. Or, rather, started to read until it felt like
the room was spinning....
I understand that lines of text have at the least an implicit set of
properties, one of which is line-height. My conceptual block is with
applying an explicit line-height to a <span> within a block of text. I
have always visualized line-height as being internal to the tag to which
it applied. So in a <p> it will apply to all the lines of text in that
tag, no matter how they flow. But since a <span> is usually a short
stretch of text within another tag, what does it set its line-height
relative to? (Ignoring the odd case where the text within it happens to
wrap to a new line.) I now see that it sets it relative to the
line-height of the containing element (whether the line-height is
implicit or explicit), but this breaks my (obviously flawed) conceptual
model of the relationship between inline and block-level tags.
--
James M. Shook
http://www.jshook.com
| |
|
| as far as I know the line height in a <span> does work exactely on all
browsers EXCEPT IE for PC.
So I don't think it's fair to make it the most profound and complex
issue of CSS/html.
It's just about a crappy browser.
James Shook wrote:
> Eric A. Meyer wrote:
>
>
>
> That's what I did read. Or, rather, started to read until it felt like
> the room was spinning....
>
> I understand that lines of text have at the least an implicit set of
> properties, one of which is line-height. My conceptual block is with
> applying an explicit line-height to a <span> within a block of text. I
> have always visualized line-height as being internal to the tag to which
> it applied. So in a <p> it will apply to all the lines of text in that
> tag, no matter how they flow. But since a <span> is usually a short
> stretch of text within another tag, what does it set its line-height
> relative to? (Ignoring the odd case where the text within it happens to
> wrap to a new line.) I now see that it sets it relative to the
> line-height of the containing element (whether the line-height is
> implicit or explicit), but this breaks my (obviously flawed) conceptual
> model of the relationship between inline and block-level tags.
>
| |
| Michael Fesser 2004-06-10, 12:14 pm |
| .oO(James Shook)
><span>s don't respond to line-height. Only block-level tags like <p>
>will. If DW is showing this to you, it is wrong.
JFTR:
'line-height'
Value: normal | <number> | <length> | <percentage> | inherit
Initial: normal
Applies to: all elements
^^^
Inherited: yes
Percentages: refer to the font size of the element itself
Media: visual
Micha
| |
|
| thanks.
That seem to confirm that IE6 for PC is the faulty one?
Michael Fesser wrote:
> .oO(James Shook)
>
>
>
>
> JFTR:
>
> 'line-height'
> Value: normal | <number> | <length> | <percentage> | inherit
> Initial: normal
> Applies to: all elements
> ^^^
> Inherited: yes
> Percentages: refer to the font size of the element itself
> Media: visual
>
>
> Micha
| |
| Jon Yeager 2004-06-10, 7:14 pm |
| Guess not.
"Jon Yeager" <nospam@please.com> wrote in message
news:ca81cf$m0i$1@forums.macromedia.com...
> Can I tell DW to start using DIVs instead of SPANs to see what that
> produces? Though even if it works, I doubt it will solve the problem at
hand[color=darkred]
> of DW not interpreting spacial equations the same way the browsers do.
>
> As you can guess, I rely heavily on the graphical interface and the mouse,
> as opposed to manual coding. ;)
>
> "Murray *TMM*" <forums@HAHAgreat-web-sights.com> wrote in message
> news:ca80j5$l53$1@forums.macromedia.com...
| |
| Michael Fesser 2004-06-10, 7:14 pm |
| .oO(seb)
>That seem to confirm that IE6 for PC is the faulty one?
Would be no surprise.
SCNR ;)
Micha
| |
| Eric A. Meyer 2004-06-12, 4:14 am |
| In article <ca9nl7$gjt$2@forums.macromedia.com>,
James Shook <jshook@dont_mail.com> wrote:
> Eric A. Meyer wrote:
>
>
> That's what I did read. Or, rather, started to read until it felt like
> the room was spinning....
This might help (or not). Consider a single line of text containing
the text that corresponds to the following content fragment:
for all <big>good men</big> to come to
Okay? Just worry about that. Assume the line is contained in a
paragraph, although that won't be relevant until later.
All right. For every character-- including the spaces-- a browser
has to figure out the height of the character box, otherwise known as
the em box. In CSS, that's defined by the value for 'font-size' set for
the element that is parent to the character. Thus, for all the
characters "good men" the controlling font size comes from the 'big'
element. For the rest of the line, it's whatever elements contains them.
[Note that the character glyphs are not necessarily the same height
as the em box. In fact, for about 99.9% of fonts, the glyphs are not
the same height as the em box. In about 99% of those cases, the glyphs
are smaller, which is why for some fonts you can declare something like
'font-size: 20px' and get characters that are 15 or so pixels tall.]
So the browser has figured out the height of every em box via the
value(s) for 'font-size'. These are also called content boxes, since
they're analogous to the content area aof a block box. Now the browser
computes the value of 'line-height' for each character. Any relative
measure, like ems or percentages, is calcualted with respect to the
'font-size' of the character. The difference between 'line-height' and
'font-size' is split in half and applied to the top and bottom of each
content box. The result is an inline box.
So let's stop for a moment and assume the following rule is applied
to our fragment:
big {font-size: 20px; line-height: 1.2em;}
The 'line-height' computes to 24px. Two pixels is thus added to the top
of the 'big' element's content box, and two more to the bottom. The
content box is 20 pixels tall, and the inline box is 24 pixels tall.
[Aside: the height of the content box is ALWAYS equal to the computed
value of 'font-size' and the height of the inline box is ALWAYS equal to
the computed value of 'line-height'.]
Back to our line construction (what, you thought we were done?). At
this point, the browser has calculated the inline boxes of every
character in the line. It now vertically aligns them with respect to a
common baseline. By default, all text is baseline-aligned. If we had
set the 'big' element's vertical alignment to, say, 'super', then its
characters would be shifted upwards. That would raise their inline
boxes, along with everything else about them, by whatever distance
'super' caused an element to be raised.
But never mind that now: we're going to baseline-align all the text.
Now, suppose the enclosing paragraph was styled like so:
p {font-size: 16px; line-height: 1em;}
That means for all the non-'big' characters, their content boxes AND
inline boxes will be 16 pixels tall. Since all the text is
baseline-aligned, that means that the 'big' characters will have inline
boxes whose bottoms will be a little below the bottoms of the non-'big'
characters' inline boxes, and the tops of the 'big' characters' inline
boxes will be a short distance above the non-'big' inline boxes. So the
tallest inline boxes in the line are those of the 'big' element's
characters.
With all that done, it's time to define the line box. This is simply
the box that encloses every inline box within the line. In our
hypothetical case, that means a box that's just tall enough to enclose
the 'big' element's inline boxes. The non-'big' characters will fit
into that line box with room to spare.
Now that the line box has been determined, it is placed just below
the line box for the previous line of text. In order to lay out the
next line of text, the browser has to go through all that again in order
to compute a line box. It has to do this for every single line of text
in your document.
And remember, this was a fairly simple case. There's a lot more that
has to be done in cases where-- for example-- there are three inline
elements, each with a different font family (and therefore slightly
different baselines) and vertical alignment, as well as an inline image
or two. IMages have their own special behaviors, which are related to
what I just described, but different in many ways.
I sometimes wonder how browsers manage to lay out anything at all.
Fun fact: there is nothing that forces an inline box to be equal to
or larger than a content box; in fact, an inline box can be much shorter
than the content box. Consider:
big {font-size: 20px; line-height: 2px;}
That will move the top of the inline box so it's 9 pixels BELOW the top
of the content box, and the bottom of the inline box 9 pixels ABOVE the
bottom of the content box. In that sort of case, you'll likely end up
with content intruding into other lines, because remember: the line box
only encloses inline boxes. It doesn't care one bit about content
boxes. So content can stick out of a line box as easily as it can an
inline box.
Bonus fun fact: padding, borders, and margins have NO effect on the
height of a line box at all when applied to characters. They only
affect the line box's height when applied to replaced elements, like
images.
How's the head doing now?
--
Eric A. Meyer | http://www.meyerweb.com/eric/ | CSS and standards guy
Yes.[color=darkred]
> Are you sure?
| |
| Murray *TMM* 2004-06-12, 12:14 pm |
| Eric:
I looked on the back of the seat, but there were none of those little ...
you know ... bags there. Ew.
Nice explanation.
--
Murray --- ICQ 71997575
Team Macromedia Volunteer for Dreamweaver MX
(If you *MUST* email me, don't LAUGH when you do so!)
==================
news://forums.macromedia.com/macromedia.dreamweaver - THE BEST WAY TO GET
ANSWERS
==================
http://www.dreamweavermx-templates.com - Template Triage!
http://www.projectseven.com/go - DW FAQs, Tutorials & Resources
http://www.dwfaq.com - DW FAQs, Tutorials & Resources
http://www.macromedia.com/support/search/ - Macromedia (MM) Technotes
==================
"Eric A. Meyer" <eric@meyerweb.com> wrote in message
news:eric-DBDF5B.23255411062004@forums.macromedia.com...
> In article <ca9nl7$gjt$2@forums.macromedia.com>,
> James Shook <jshook@dont_mail.com> wrote:
>
there's[color=darkred]
Second[color=darkred]
>
> This might help (or not). Consider a single line of text containing
> the text that corresponds to the following content fragment:
>
| |
| James Shook 2004-06-12, 12:14 pm |
| Eric A. Meyer wrote:
> Bonus fun fact: padding, borders, and margins have NO effect on the
> height of a line box at all when applied to characters. They only
> affect the line box's height when applied to replaced elements, like
> images.
Thank you for your detailed explanation of what goes on in doing
something as simple as "just" laying out a paragraph of text. As you
say, it's a wonder that you ever see anything at all when your page
loads, considering what goes into the calculations for laying it out.
Your Bonus Fun Fact jogged my memory a bit, and I believe my
pronouncement that line-height doesn't apply to inline elements in fact
derived from my futile efforts to apply margin and/or padding in a
structure that was similar to that of the example given by the original
poster. I can't remember why I was trying to so this. Obviously I
over-generalized from that experience.
I didn't realize that browsers have to lay out every character. I mean,
I knew they did, obviously, but not in such explicit detail. I sort of
assumed that once they had the line-height and any other attributes
affecting the text they could just sort of let 'er rip, perhaps by
tapping into some sort of system routine(s).
> How's the head doing now?
I'm OK now. I've been looking at the illustrations in your book that
illustrate this and it all makes sense. At least while I'm reading it.
It strikes me that a lot of the problems I, and perhaps others, have
with CSS and CSS-P derive from assumptions about how something should
work (based on my experience as a graphic artist) compared to how
something actually does work. The behavior of some CSS doesn't map well
to the behavior of things with which I am already familiar, or how I
would do it if I were implementing it.
Just one example: A floated element, if tall enough, can extend beyond
the bottom of the element which contains it. I understand why this is
what should happen, but it contradicts, at least to me, the idea of what
is meant by "containing element" since the floated element is not
contained in the element. And that's not what happens if the containing
element is a table cell. I don't want to get into the hoary Tables vs
CSS discussion, but the table cell behaves as I expect and the CSS-P
equivalent doesn't. It's possible to use either, but you have to shift
your mental image of what the page flow is in order to get the effect
you want depending on which technique you are using. And sometimes the
CSS-P mental image is not intuitive.
--
James M. Shook
http://www.jshook.com
| |
| Eric A. Meyer 2004-06-14, 11:14 pm |
| In article <caf0cc$i3v$2@forums.macromedia.com>,
James Shook <jshook@dont_mail.com> wrote:
> Thank you for your detailed explanation of what goes on in doing
> something as simple as "just" laying out a paragraph of text.
No problem.
> I didn't realize that browsers have to lay out every character. I mean,
> I knew they did, obviously, but not in such explicit detail. I sort of
> assumed that once they had the line-height and any other attributes
> affecting the text they could just sort of let 'er rip, perhaps by
> tapping into some sort of system routine(s).
They certainly do tap into OS features for things like character
rendering (which is why OS X browsers have such pretty text, for
example). But to do the CSS layout model correctly, they have to do a
lot of work that can't be handed off to the OS.
> I'm OK now. I've been looking at the illustrations in your book that
> illustrate this and it all makes sense. At least while I'm reading it.
I have the same feeling sometimes. To get the inline layout model
really straight in my head took two weeks of e-mail back and forth
between me, Ian Hickson, and David Baron. There were times I wanted to
drive my forehead through the monitor just to make the pain stop.
And, as I say, this is a simple system. It's laughably stupid
compared to 'real' typography, and yet has to act the way it does to
capture 1995-era layout behaviors while offering something better.
> It strikes me that a lot of the problems I, and perhaps others, have
> with CSS and CSS-P derive from assumptions about how something should
> work (based on my experience as a graphic artist) compared to how
> something actually does work. The behavior of some CSS doesn't map well
> to the behavior of things with which I am already familiar, or how I
> would do it if I were implementing it.
I think perhaps that things in CSS are close to what you expect, but
not as close as they first appear. It's hard to get powerful layout
mechanisms from a simple language like CSS. Ever looked at the
internals of a robust, deep layout system? They're usually far too
complicated to be read by humans. And then there's the price tag. I
figure that, given what CSS costs to author and use, we're getting way
more than our money's worth.
> Just one example: A floated element, if tall enough, can extend beyond
> the bottom of the element which contains it. I understand why this is
> what should happen, but it contradicts, at least to me, the idea of what
> is meant by "containing element" since the floated element is not
> contained in the element.
It would indeed be helpful if there were a property that controlled
whether or not an element visually contained the floatas that descended
from it. So far, there have been proposals for CSS3, but nothing
concrete has emerged.
Of course, floats tend to get a bum rap because they were never, ever
intended as a page layout system. They were been forced into that role
for a number of reasons, and perhaps predictably, funkiness ensued. If
only there were a CSS-P equivalent to 'float', we might have avoided a
good deal of angst.
> And that's not what happens if the containing
> element is a table cell.
Yeah. Tables are incredibly funky, and can't even be properly
described, in CSS2.1 terms. That's why they get their own chapter in
the specification, and there's a lot of verbiage about the unique stuff
that tables do.
When I informed my technical reviewers that I was starting on the
tables chapter of CSS:TDG, 2ed.-- and it was the last chapter I wrote,
finishing it the day before Carolyn came home-- they both wrote me back
to say, "Sorry to hear that."
> I don't want to get into the hoary Tables vs
> CSS discussion, but the table cell behaves as I expect and the CSS-P
> equivalent doesn't.
Yep. That's why so many have called over the years for a CSS-grid
system, one which would act more or less like tables do without using
actual table markup. Of course, we'd be 90% of the way there if it
weren't for the limitations in IE/Win, but that's another story.
--
Eric A. Meyer | http://www.meyerweb.com/eric/ | CSS and standards guy
Yes.[color=darkred]
> Are you sure?
| |
| Al Sparber- PVII 2004-06-15, 4:14 am |
| Eric A. Meyer wrote:
> In article <caf0cc$i3v$2@forums.macromedia.com>,
> They certainly do tap into OS features for things like character
> rendering (which is why OS X browsers have such pretty text, for
> example).
Perhaps if I had been a Mac user for years I would have noticed an
improvement, but all 4 Macs in use at PVII have rather poor text
rendering (from a purely visual perspective). The text smoothing
algorithms are horrid and while I hear some people actually like it, we
all seemed to need a dose of Tinker Tools to slap OSX into line. While a
default Win XP system can be made to look as bad - one has to enable
Clear Type font smoothing.
> I think perhaps that things in CSS are close to what you expect,
> but not as close as they first appear. It's hard to get powerful
> layout mechanisms from a simple language like CSS. Ever looked at the
> internals of a robust, deep layout system? They're usually far too
> complicated to be read by humans. And then there's the price tag. I
> figure that, given what CSS costs to author and use, we're getting way
> more than our money's worth.
>
Perhaps it all started with the box model :-). I thoroughly believe that
CSS can be made to overcome its current limitations (outside the scope
of temporal browser limitations) with the proper specifications. It's
not rocket science. We tend to focus on IE-PC as the bane when there is
a bit of toxicity in the current CSS specs. Why the current CSS box
model makes sense to anyone is something I'll never understand. It was
written too rigidly. Far too rigidly. Now please don't get me wrong. I
understand it and I work within its constraints, and it's the best thing
we have to work with - but CSS is nevertheless a very funny technology
:-)
[color=darkred]
> It would indeed be helpful if there were a property that controlled
> whether or not an element visually contained the floatas that
> descended from it. So far, there have been proposals for CSS3, but
> nothing concrete has emerged.
You're involved with the W3C. Perhaps one of the problems is that you
need to be a member to write a recommendation - and membership costs an
arm and a leg (at least this is what I understand when I read the W3C
web site). Maybe the W3C needs to spend some money on employees or
consultants whose talents could better serve the cause. I'm sure there
are people with traditional media expertise who could cast a whole new
light on things - if given the opportunity.
I don't have a blog, so I do my imagining and speculations in places
like this :-)
--
Al Sparber - PVII
http://www.projectseven.com
DW Extensions - Menu Systems - Tutorials - Templates
---------------------------------------------------------
Webdev Newsgroup: news://forums.projectseven.com/pviiwebdev/
CSS Newsgroup: news://forums.projectseven.com/css/
RSS Feeds: http://www.projectseven.com/xml/
|
|
|
| | Copyright 2003 - 2009 forum4designers.com Software forum Computer Hardware reviews |
|