RE: proposal for HTML4.01 amendment: <BR PAGEBREAK="before">

Hello Philip, list members,


> -----Original Message-----
> I would like to propose that the syntax for the BR tag be ammended to add
> an optional 'PAGEBREAK' attribute, with only acceptible value to be
> "before".
> (to be somewhat close to existing CSS usage)
> EG: <BR PAGEBREAK="before">
I vote against it! ;)


> This new attribute would signify to "printing agents", that a
> page break is desired.
There's a CSS property for that purpose: page-break-after.
(Not to you, Philip, I know it exists, its for the archive)

> Yes, I realize this is a long-standing issue. I have searched through the
> archives and read the relevant messages on this topic, including ones
> dating back from HTML3.0
>
> Please read this message in its entirety.
>
> I realize that CSS provides a method of having a page break.
Yes, the "page-break-after" property.


> However, most readers will know already that while there are many browsers
> that handle a good chunk of HTML4.0, there are not too many that have a
> full implementation of CSS. Some choose not to implement it at all.
> For example, lynx.
That's lynx's problem, not ours.

First they also chose not to implement several elements of HTML, namely
frames and tables.
Now they at least recognize the frame module elements to allow the user to
display the contents of a single frame.
w3m implements tables quite well.
Okay, not implementing frames is okay, I don't like frames anyway.
But tables are quite useful, especially for tables, though even I often
abuse them for layout purposes due to the lack of other possibilities.
(I know that I could do everything I do with tables with CSS instead, but I
also know that most browsers cannot display it)

> One could argue that it does not make sense for lynx and similar browsers
> to implement CSS. However, they could still benefit from some kind of
> pagebreak functionality. While many "user agents" choose not to implement
> CSS, MOST of them have a "print" function.
In my eyes it makes sense for a text browser to implement CSS as well as
HTML. Displaying colors, bold, sometimes even italic or underlines, is
possible on modern ttys. Even positioning is possible, though it always
needs to be rounded to 1em.

So I am for a different solution: lynx, w3m and links should implement some
CSS.

Sure, they wanna be light weight browsers. But that's relative to Moore's
Law. Vim (Vi IMproved) is also considered light weight. But 10 years ago,
such an editor would have been considered heavy weight. Compared to a
Commodore 64, lynx *is* already extremely heavy weight. Compared to laptops
and desktops currently on the shop's shelves, lynx would still be
lightweight if it was twice the size.

They could offer two versions of lynx, a light weight version that suites
for 386 8 MB machines and a normal version for current machines. I wouldn't
mind 300k more code on a Dual-XP-Athlon with 1 GB of RAM. Though I do not
want to miss the comfort of a tty browser, which clearly is its
functionality and speed. CSS would definitely not mean a harmful impact on
speed and performance.


> In my search of the www-html archives, one of the earlier proposals
> was to have a wider scoped "<PRINT>" tag, with things like margins.
> This is not my goal.
> I believe margins, etc. are simply "styles", therefore truly belong only
> in something like CSS.
> However, the issue of where have a pagebreak is more integral to a
> document than "what color do I make footnotes?" or
> "Should my headers be Times-Roman, or Courier?"
I interpret pagebreaks as style as well, and while colors are restricted to
all colorful media (screen, TV, projector, tty, print etc. if it's not grey
(green etc.) scale or b/w) and fonts are restricted to all scalable media
(screen, TV, projector, print etc.), page breaks are restricted to print
only, so they are a quite media specific style.

> To prove my point, I will use the following mental illustration:
>
> Lets say a web page is divided into two logical sections, each
> with its own H1 header. (or whatever kind of header you like)
>
> The author could adjust colors, settings, fonts, you-name-it with CSS.
> The viewer/user could adjust font sizes, print margins, etc. on that end.
> But you will STILL WANT a pagebreak before the second H1 header,
> otherwise, the printout will not be clearly executed.
I think you know the solution:
<h1 style="page-break-before:always;">Second part</h1>
It already works very fine in several browsers.

> To achive this functionality, I am proposing a specificly non-CSS
> method, so that browsers that have no use for CSS, can still get
> pagebreak information with a minimum of recoding.
This sounds to me like proposing any style-related markup to HTML for
browsers that have no support for CSS.
But isn't CSS intended for avoiding exactly this?

> Some people dont like adding "new tags", therefore, I am proposing a new
> attribute to the existing tag BR, although I personally wouldnt mind
> <PAGEBREAK> instead.
To me it makes no difference in the first place wether element or attribute.
Style related markup is style related markup. It cannot hide by being not an
element.

> I chose the BR tag, because its name is almost page"break" already :-)
> and because it already has an overloaded attribute: "clear".
> "clear" is specified as for "visual user agents".
> So a "pagebreak" attribute could be described as for "printing agents".
>
> In retrospect, it would have been nice if "BR CLEAR=PAGE" was in the spec
> to begin with. But as it is not, hopefully, this will make up for it.

I do not like adding elements or attributes to HTML that are display / media
/ device specific. A <br clear="page" /> or similar markup is definitely
display / media / device specific.
I am angry enough that I still have to use tables to solve layout tasks and
that I have to wait about 3 years to be able to completely separate content
from style.
And I interpret the recent evolution of HTML as an evolution to get rid of
all mistakes of the past: mixing content and layout.
XHTML 1.1 does not contain any elements and attributes that were marked
deprecated in XHTML 1.0 or HTML 4.01 or HTML 4. XHTML 1.1 even does not
contain Frames, though you still could use XHTML 1.1 as basis for your own
XHTML impementation and additionally include the Frames Module, which still
exists in XHTML Modularization.
XHTML Basic 1.0 contains even less, and though one of its inventors told me
it is designed for cross device HTML like TVs, Set Top Boxes, Mobile
Appliances and that stuff, I think it's perfectly usably for usual HTML as
well as long as the Basic Tables Module and Basic Forms Module are enough to
you.
Currently I solve this by writing documents in a modified XHTML 1.0 Basic
(allowing %Inline; content for the <title/> element) and transforming them
to either XHTML 1.0 Basic or XHTML 1.1 using XSL Transformations, where the
Transformation Stylesheet adds layout.



* And now probably the most important argument against this (at least the
suggested solution with <br />) *


There is a technical reason why not to choose <br pagebreak="before" />. The
<br /> element is Inline markup, that means, it has to be within another
Flow markup. <br /> may not occur where only Block markup is allowed.

From the XHTML Modularization recommendation
(http://www.w3.org/TR/xhtml-modularization/), Section 5.2.2. Text Module:
Heading:
	h1 | h2 | h3 | h4 | h5 | h6
Block:
	address | blockquote | div | p | pre
Inline:
	abbr | acronym | br | cite | code | dfn | em | kbd | q | samp | span |
strong | var
Flow:
	Heading | Block | Inline

From the XHTML Modularization recommendation
(http://www.w3.org/TR/xhtml-modularization/), Section 5.2.1. Structure
Module:
+----------+------------+---------------------------+
| Elements | Attributes | Minimal Content Model     |
+----------+------------+---------------------------+
| body     | Common     | (Heading | Block | List)* |
+----------+------------+---------------------------+
[...]

So the following is illegal in XHTML 1.0 Basic, XHTML 1.1 and usual XHTML
Modularization based XHTML document types:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/dtd/xhtml11.dtd">
<html>
	<head>
		<title>Invalid document</title>
	</head>
	<body>
		<h1>Invalid document</h1>
		<p>
			This document is invalid.
		</p>
		<br />
		<h1>Reason</h1>
		<p>
			The <code>&lt;br /&gt;</code> element occurs at a place where it may not.
		</p>
	</body>
</html>


The <br /> element in the above example occurs at a place where it may not
occur. It is not allowed to have Inline elements or #PCDATA (text) as
content in the <body /> element.


Just my two cents

Christian

Received on Saturday, 12 January 2002 07:12:36 UTC