LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave HTML-WG
Reply | Post New Message
Search Archives


Subject: Re: Remarks on Tables draft
From: Bert Bos <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Wed, 26 Jul 95 10:17:03 EDT
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (185 lines)



Chris Tilbury writes:

 |Chris (making a fool of himself in his first message, no doubt :-)

No, not at all. In fact I agree with the gist of what you said,
while disregarding the exaggeration.

 |On 26 Jul 95 at 7:40, Bert Bos wrote:
 |
 |> Terry Allen writes:
 |>
 |>  |Some comments and questions on:
 |>  |
 |>  || HTML Tables                                                      7th July 1995
 |>  ||    INTERNET DRAFT                                 Dave Raggett, W3C
 |>  ||                        <draft-ietf-html-tables-00.txt>
 |>  || 
 |>  ||    Tables can contain a wide range of content, such as headers, lists,
 |>  ||    paragraphs, forms, figures, preformatted text and even nested
 |>  ||    tables. When the table is flush left or right, subsequent elements
 |>  ||    will be flowed around the table if there is sufficient room. This
 |>  ||    behaviour is disabled when the noflow attribute is given or the
 |>  ||    table align attribute is center (the default), or justify. 
 |>  |
 |>  |Does this mean one cannot have a centered table with text flowing
 |>  |around both sides?  
 |> 
 |> Are you suggesting that that should be possible? If so, why?
 |
 |Because someone, somewhere, might need this?
 |
 |Because the specification (and this applies to the ALIGN="CENTER" in 
 |general both in tables and other elements) is pointlessly removing 
 |functionality which could be useful?

My point is that I doubt someone needs this. If somebody tries to use
this, than he should probably think again. Text flowing at two sides
of something is almost unreadable.

I don't think HTML limits the possibilities, it is just trying to
avoid *requiring* too much functionality of the browser.

 |Because the whole ALIGN attribute is nothing but a great big 
 |confusing mess at the moment?
 |
 |Let's look at it, shall we. ALIGN can be ...
 |
 |ALIGN="LEFT"
 |	Means that the object will be flush left aligned with the 
 |	margin and with text wrapping around it to the right.
 |
 |ALIGN="BLEEDLEFT"
 |	Flushleft with the /window/ border as opposed to margin.
 |
 |ALIGN="RIGHT"
 |	Means that the object will be flush right aligned with the margin, 
 |	and with text wrapping around it to the left.
 |
 |ALIGN="BLEEDRIGHT"
 |	Flushright with the /window/ border as opposed to margin.
 |
 |ALIGN="CENTER"
 |	Means that the object will be centered horizontally, with no text 
 |	wrapping.
 |
 |ALIGN="TOP"
 |	Means that the baseline of the following text is 
 |	aligned with the top of the image.
 |
 |ALIGN="BOTTOM"
 |	Means that the baseline of the following text is aligned with the 
 |	bottom of the image.
 |
 |ALIGN="MIDDLE"
 |	Means that the baseline of the following text is aligned with the
 |	middle of the image.
 |
 |ALIGN="JUSTIFY"
 |	Means all sorts of stuff - either text is fully justified to both 
 |	margins, or images are horizontally expanded to fit the page width.
 |
 |Frankly, all we need now is ALIGN="SATURN" to complete the confusion. 
 |
 |The ALIGN attribute is /very/ element or context sensitive. Because 
 |of this, not all possible attribute values are valid for it in all 
 |possible contexts. This makes it hard to use, and this is one thing 
 |that HTML is /not/ supposed to be. Remember, we're all supposed to be 
 |able to dig out 'jove', 'edit.com', 'notepad.exe' and knock up an 
 |effective HTML document. Giving attribute values such a degree of 
 |context sensitivity makes them hard to use unless you're either an 
 |expert, or have a proper HTML/SGML editor which can work out which 
 |are valid values.

I've suggested a long time ago that the different roles of ALIGN
should be given different names, HALIGN and VALIGN to start with.

In the case of a table or figure, the choices are LEFT, RIGHT and
CENTER. BLEEDLEFT and BLEEDRIGHT are just variations of LEFT and RIGHT
that can better be left to the style sheet. (In fact, I sometimes
think that we don't need both LEFT and RIGHT, a single FLOAT would be
enough, except that people want be able to refer to "the figure on the
left".)  JUSTIFY can be dropped, since it is the same as CENTER, but
for a full-width table.

In my view, CENTER doesn't mean that the table is centered between the
margins, it just means that it is put in the middle (or main) track,
as opposed to floated to the left or right. Whether it is actually
centered depends on the formatter/style sheet. `CENTER' may not be the
best name for it, though, how about `NORMAL'?

 |This, however, is something we're going to have to live with I 
 |suspect since changing ALIGN now will be a real downer on existing 
 |documents.

Unfortunately, yes. But for tables and figures it's not too late yet.

 |Just to make things worse though, we also find that we have
 |
 |CLEAR="LEFT"
 |	Move down until the left margin is clear
 |
 |CLEAR="RIGHT"
 |	Move down until the right margin is clear
 |
 |CLEAR="ALL"
 |	Move down until both margins are clear
 |
 |Which can be used in many elements to effectively kill off the text 
 |flow, as well as
 |
 |NOFLOW
 |	The presence of this attribute disables text flow around the 
 |	[figure/table]

The CLEAR attribute will probably have to stay, despite its awkward
syntax (it's actually more complex than you describe), because there
is a semantic difference between a figure next to a title and a title
on a line of its own. But the NOFLOW seems to be meant purely for
presentation: `ALIGN=LEFT NOFLOW' is a hacker's trick to get
`ALIGN=CENTER' with the table left justified. As I said above, whether
the table is centered or left justified doesn't need to be specified
in HTML.

 |Which can be used to disable text flow in the element in question.
 |
 |So, let's turn this question around, shall we.
 |
 |With 2 different means available to /disable/ text flow, why is 
 |it necessary to involve the issue of text flow in the ALIGN 
 |attribute at all? The damn thing is a big enough mess as it is already, 
 |without making some of the attribute values twice as complicated by 
 |having to remember which does what to text flow.
 |
 |What's wrong with turning text flow on, by default, and telling 
 |people to just use NOFLOW if they don't want it to flow? Specifiying 
 |that ALIGN="CENTER" has no text flow is, perhaps, needlessly limiting 
 |the capabilities of HTML.

Because, as I said, ALIGN wasn't meant to specify the position, but the
flow. NOFLOW probably was an afterthought, a trick to make ALIGN into
a means of positioning the table, without the need for a style sheet.

 |(If we do cripple HTML like this, then you can guarantee that someone 
 |*will* come up with a "FLOW" attribute, outside of this working 
 |group, and I'll give you one guess who that someone will be ...)

In general, yes. But in this case, I expect that the people you refer
to will have learned enough about typography by then that they will
not honour requests for text flow at both sides of a figure.

(Btw. a figure in between two columns, with text flowing on both
sides, is a different thing altogether, and very useful. But I hope
there will never be a tag or an attribute in HTML that requires two
columns.)


Bert
-- 
                          Bert Bos                      Alfa-informatica
                 <[log in to unmask]>           Rijksuniversiteit Groningen
    <http://www.let.rug.nl/~bert/>     Postbus 716, NL-9700 AS GRONINGEN



Back to: Top of Message | Previous Page | Main HTML-WG Page

Permalink



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager