...

View Full Version : adorable float (?) problem



bryndyment
01-24-2004, 01:45 AM
I have an image that I want flush-left, plus text that I want flush-right, but I want both to be aligned on their bottom edge. Like this:

IMAGE
IMAGE
IMAGE TEXT
--------------------------------------
Ideas?

Vladdy
01-24-2004, 04:26 AM
Is image content or presentation???

bryndyment
01-24-2004, 04:30 AM
Content.

Vladdy
01-24-2004, 04:43 AM
Try this:



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Test</title>
<style type="text/css">
body
{ font-family: Arial, sans-serif;
}

.slide
{ border-bottom: solid 1px black;
padding: 0px;
}

.slide img
{ float: left;
}

.slide div
{ position: relative;
margin: 0px 0px 0px 300px;
height: 300px;
}

.slide p
{ position: absolute;
right: 0px;
bottom: 0px;
margin: 0px;
padding: 0px;
}
</style>
</head>
<body>

<div class="slide">
<img src="image.gif" width="300" height="300" alt="image" />
<div><p>Image Caption</p></div>
</div>
</body>
</html>



Assumed image 300x300 - change margins accordingly

bryndyment
01-24-2004, 10:46 PM
Thanks so much for the fully working solution. I'm still a little confused, but now understand that (a) making a containing DIV "relative" allows me to absolutely position its child P with respect to the parent's coordinates, and (b) setting that child P's "right" and "bottom" attributes to "0" positions it in the bottom right of the parent DIV.

I optimized things a bit... anything in my solution that raises any flags?
<div style="border-bottom: 1px solid black; height: 100px; position: relative;">
<img alt="image" height="100" src="image.jpg" width="100">
<p style="bottom: 0px; position: absolute; right: 0px;">heya</p>
</div>Thanks again... I learned a bunch.

me'
01-25-2004, 10:42 AM
Yes, you shouldn't use inline styles, and <img> needs to be <img /> if you're using XHTML (whih you should be).

bryndyment
01-25-2004, 06:19 PM
What's bad about inline styles? Can you point me to some discussion on that? Thanks...

Vladdy
01-25-2004, 07:20 PM
There is nothing wrong with inline styles.

The negativity towards inline styles stems from the banwidth optimization.

At a glance, it seems like putting all your style information in an external stylesheet allows to save bandwidth, because in can be downloaded once and then applied to all your pages. Considering graphical browsers, this is true for the styles that are used on multiple pages or those used with dynamic pages (the ones that are not cached).

For a style within a single static page, it makes no difference if it is specified within an external stylesheet or within the HTML page. Since both are downloaded once and cached, there is no gain in performance (actually there can be a loss in performance if you decide to create a separate external stylesheet for such definitions since it would require an extra server request).

Same logic can be applied to styles defined within <style> element and inline style. If a style within a page is applied to a single element there is no gain in assigning a class to it.

Another possible reasoning is reduction of bandwidth for non-graphical browsers which can ignore external stylesheet all-together. In this case it can be successfully argued that any style definitions within HTML file increases the bandwidth.

bryndyment
01-25-2004, 08:03 PM
I agree. I prefer inline styles for "one-off" style definitions, as I find it's easier to understand/maintain the CSS. Definitions grouped at the top add a layer of indirection that makes the code a little harder to grasp (constantly paging up/down within the source to toggle between the HTML and the CSS). Strictly for one-offs, though, as duplicating inline code for multiple elements with the same style is definitely bad. At this point, I move the code out and up into a <style> element, or, if it's used across pages or in a template, into a .css file.

me'
01-26-2004, 07:42 PM
There is everything wrong with inline styles. <span style="color: #f00"> is as bad as <font color="#ff0000">. In fact the <font> method is better because <font> has richer semantics for what you're trying to achieve there. There's one underlying theme that drives the advancement of CSS and XML.

The seperation of content and style!

Leave your content in *ML, and use CSS for the style! The amount of problems this gets rid of, benefits it carries! It's not just bandwidth saving. It's ease of updateability, cleaner code for alternate devices, etc.

In my opinion, all presentational markup should be obselete (not just deprecated). That includes the style attribute.

This is exactly what the id attribute is for.

rmedek
01-26-2004, 08:04 PM
Originally posted by me'
It's ease of updateability, cleaner code for alternate devices, etc.

In my opinion, all presentational markup should be obselete (not just deprecated). That includes the style attribute.

Don't you think that's taking things a bit too far? What about webpage whose content is style, such as a design house? Or a webpage whose redesign only occurs as content changes? Not to mention some of the most beautiful websites I've seen (okay, if not the most accessible ;)) were designed in Flash. No separation of style or content there...

me'
01-26-2004, 08:07 PM
What about webpage who's content is style, such as a design house?Tricky. Their content should be displayed as semantically as possible, and you might be able to squeeze a semantic use out of <img/>, but that's still no reason for inline styles.
No separation of style or content there...No indeedy, but that's because Flash is compiled binary format (I think). With something like SVG you'd have that, though.

Vladdy
01-26-2004, 08:13 PM
I think you are confused, me'

<font> tag is an HTML element that has no semantical meaning and therefore is rightfully depreciated. If you are an ultimate purist, then you can lobby for removal of the generic elements (<div> and <span>) from (X)HTML specification as well, since they do not carry any semantical meaning either.

Neither of the above have anything to do with inline styles. Inline style is CSS specified within the style attribute of an element. It is separate from the content and does not affect the presentation of the code on alternative devices.

Association of id attribute with a particular style declaration is only one of the uses of id attribute. Polluting markup with id attributes just to style a single element on a static page is hardly a good practice compared to an inline style.

DsgnrsTLZAdmin
01-26-2004, 08:32 PM
Not to be rude but its not called "inline styles" its called an internal style sheet

liorean
01-26-2004, 08:37 PM
You are wrong on that first point - div and span carry semantic meaning, but it's weak. Div means a division, or a section, of a document. Span is even weaker, and means a span of content that belong together. Note that both of those actually have some meanig as to the nature of the content. The font element carries ONLY presentational data, and no meaning as to the nature of the content.

The reason for using embedded or external styles instead of inline styles for an element, and instead polluting the class and id attributes of elements that needn't have those, is that you make one large win: One way you pollute the content with structure and the structure with presentation, one way you pollute the content with structure and the structure with superflous structure, but keep the presentation separated. They key is that it is better to make the structure addressable and let the presentation be separate, then to include the presentation with the structure, because you that way pollute the content less.

Vladdy
01-26-2004, 08:41 PM
Originally posted by DsgnrsTLZAdmin
Not to be rude but its not called "inline styles" its called an internal style sheet
RTFM: http://www.w3.org/TR/html401/present/styles.html#adef-style
... considering the markup on your 'Construction Page', you never did....

Vladdy
01-26-2004, 08:54 PM
Originally posted by liorean
You are wrong on that first point - div and span carry semantic meaning, but it's weak. Div means a division, or a section, of a document. Span is even weaker, and means a span of content that belong together. Note that both of those actually have some meanig as to the nature of the content. The font element carries ONLY presentational data, and no meaning as to the nature of the content.
You have a point, but it can also be argued that <font> defines a "span of content that belong together and therefore presented differently to separate it from the surrounding content". So I stand by my point that <div> and <span> as generic elements have pretty much the same semantic meaning (which is grouping) as <font>
does


The reason for using embedded or external styles instead of inline styles for an element, and instead polluting the class and id attributes of elements that needn't have those, is that you make one large win: One way you pollute the content with structure and the structure with presentation, one way you pollute the content with structure and the structure with superflous structure, but keep the presentation separated. They key is that it is better to make the structure addressable and let the presentation be separate, then to include the presentation with the structure, because you that way pollute the content less.
I'm not arguing one way or another. The reality is that there is no black and white and every way of defining styles has it's place based on the purpose of a particular document and application to a particular element (or group).
For example in case of
<div style="display:none">Content that I would like to be hidden in browsers supporting CSS</div>
it can be argued that the style definition affects the content as much as it affects presentation.

liorean
01-26-2004, 09:44 PM
Well, have a look at Google. When they added a 26 bytes long welcome message to their main page it had a radically detrimental effect on their performance. If they went valid XHTML and CSS instead of tagsoup and tables, they would get a much larger addition to the main page size than that. In their case, separation of style and content would hurt.

As for font element versus span element, I would say you are wrong. A font element doesn't semantically mean it's a group, it only means that it should be presented a certain way. The span tag is thus semantically of more value, since it has the added meaning of grouping. The div element is somewhat stronger semantic, because it doesn't only signify a grouping, it also signifies the reason for the grouping - that the content is a division or section of a page. It isn't a lot, but it's better than nothing.

ronaldb66
01-27-2004, 10:19 AM
Although I must admit I browsed this discussion somewhat quickly, I can't recall anyone mentioning the maintenance issue; inline styles require a fair amount of maintenance effort, and should alone for that reason be used sparsely.
If anyone finds him/herself applying identical inline styles on several instances in the same document, that alone should be an indication that either an inline style sheet, but probably even better an external style sheet should be chosen.

Oh, and for the record:

An external style sheet is a style sheet kept in a seperate file, linked to the document;
an internal style sheet is a style sheet specified within the head section of the document using the style element;
an inline style is a set of one or more style properties defined for a certain element using its style attribute.

rmedek
01-27-2004, 10:47 AM
I don't think anyone could have said that better :thumbsup:

me'
01-27-2004, 07:09 PM
(NB: internal style sheets are also called embedded style sheets)

I think this thread is appropriate to voice my opinions on <div> and <span>.

IMO, in XML order shouldn't matter. I'm not sure if the W3C agrees, but XSLT is declarative rather than imperative. I believe all structure should come through tags.

A XHTML file like this one (http://www.mezzoblue.com/archives/2004/01/07/abstracting_/) doesn't carry much structure. It's a list of tags. XML is nodes, not a list or plain text.

What's the structural tag for XHTML? <div>, IMO. Dividing your page up into divisions or sections of the page should be the way you should do it, even if you don't need to. For example, say we have an online version of a book. I believe that the chapters should be split up with <div>s.

It's not just <div>s. IDs and classes should be given to add more meaning (and perhaps more semantics?) to your tags, and IDs especially to identify individual sections (presumably marked up with a <div>).

Bottom line: even if you don't need to, use <div> for structure's sake.

liorean
01-27-2004, 07:35 PM
Hmm, about the terminology:
internal = embedded & inline
external = imported & linked

Whether you import or link a file makes little difference - whether you embed your style, or include it inline, makes a large difference. Use the least ambigous term for what you are talking about, and be aware that both embedded and inline styles are internal.


I agree with David on the area of using div for structure's sake. If it sounds reasonable to use divs for dividing the document into sections, you SHOULD do so.

On a separate note, XHTML2 has the section element and the div element both. The div element is intended for divisions or sections of the document, while the section element is intended for sections of content data, such as chapters in a story.


Hmm, there's another thing you might think of - what if you separate structure from content? Say you have a separate document for structure, and that document tells you what document or fragment of a document a structure describes? That is something that XInclude and XLink could give us, if coupled with a good XPath/XPointer/XQuery-like syntax for general pure-text addressing and document fragment handling.



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum