<br> and generated-content (was: page-break properties on <br>)

It's off-topic but since we deal with <brhere, I urge
browser vendors to fully support ::before and ::after on <br>.
This allows very simple effects like

body[showBRs="true"] br::before {
content: "\0000b6"; /* ¶ */
}

and that is important for wysisyg editors.
It also allows line numbering in a context missing element
containers for lines

</Daniel>

Alex Mogilevsky wrote:

This would pretty much mean <bris a real element, not a magic construct. I welcome that line of thought.

Even if it is really a magic construct, it's not understandable from an
author's point of view if ::before and ::after don't apply to <br>.
<bris in the DM, insertable and manageable just like any other
element. GC must apply and be rendered.

</Daniel>

Tab Atkins Jr. wrote:
Actually, it seems explicitly *not* an HTML decision. HTML says that
the <brelement produces a line-break; it has *no* instructions on
*how* to produce this, nor should it.

Perhaps. Unless you actually want interoperability.

Whether <bris implemented with
::before, ::after, or as a replaced element (or in any other way) is
completely the domain of CSS.

Not really. Nowhere in CSS is it specified which elements are or are
not replaced. All that's specified is what to do with replaced or
non-replaced elements. Given that CSS also aims to be somewhat
language-agnostic, adding one specific HTML element here like this is a
little odd to me.

This should be obvious merely from the
fact that we're wondering which *CSS selectors* apply to the element

There is no question about what selectors apply. The question is
whether it's a replaced element (maybe) and whether certain boxes should
be generated. If it's not a replaced element, that answers the box
question, assuming a certain set of stylesheets. If it is, the box
question stays. In either case, there is the question of what UA
default stylesheets should look like. And possibly of whether author
sheets should be able to change whether the line-break is 'before' the
<bror 'after'.

I'll be completely honest: what makes the most sense to me in some ways
is to make <brnot be a replaced element (in whatever spec), have

br { content: "\A"; white-space: pre; }

in the default UA sheet, and not have any default ::before/::after (but
allow them, of course, since it's not a replaced element). But that
relies on CSS3 Generated Content stuff which is nowhere close to being
finalized.

-Boris

Daniel Glazman wrote:
It's off-topic but since we deal with <brhere, I urge
browser vendors to fully support ::before and ::after on <br>.
This allows very simple effects like

body[showBRs="true"] br::before {
content: "\0000b6"; /* ¶ */
}

So in a UA which implements <brusing generated ::before this would
remove the line-break, and in a UA which implements <brusing generated
::after this would leave the line-break, right?

And in a UA which treats <bras a replaced element this may or may not
do anything at all?

I don't see anything wrong with requiring that <brnot be a replaced
element, but that seems like an HTML decision, not a CSS one.

-Boris

Boris Zbarsky wrote:
Daniel Glazman wrote:
>It's off-topic but since we deal with <brhere, I urge
>browser vendors to fully support ::before and ::after on <br>.
>This allows very simple effects like
>>
>body[showBRs="true"] br::before {
>content: "\0000b6"; /* ¶ */
>}

So in a UA which implements <brusing generated ::before this would
remove the line-break, and in a UA which implements <brusing generated
::after this would leave the line-break, right?

I never said the behaviour of <brdoes not have to be standardized
first. For the time being, <bris just a black hole. I do hope HTML5
has a take on that issue.

</Daniel>

Jul 1, 2008, at 9:51 AM, Boris Zbarsky wrote:

I'll be completely honest: what makes the most sense to me in some
ways is to make <brnot be a replaced element (in whatever spec),
have
>
br { content: "\A"; white-space: pre; }

How about this:

br { height:0; display:block; }

It breaks lines by creating a zero-height block in the middle of
inline content. Like as with most browsers, two of them has the same
effect as one, unless there is some non-collapsing character in-
between, such as a &nobr;

Brad Kemper wrote:
How about this:

br { height:0; display:block; }

Does that do the right thing with inline borders?

As far as that goes, does it do the right thing with clearance?

What should happen if the <bris floated?

-Boris

Daniel Glazman wrote:
Alan Gresley wrote:

>Boris, why would an author bother floating a <brelement?

Because nothing forbids it ? And because implementors MUST think of all
the weird cases ?

</Daniel>


Well implementors shouldn't concern themselves with what authors might
do. If an author wants to float a <br>, I say they do that at their own
peril.

That's why I suggested float:none as a default. We already have <head
display:hidden as a default. Consider the author who foolishly declares.

head {
display: visible !important;
position: static !important;
float: left; !important;
}



Alan

Alan Gresley wrote:

Well implementors shouldn't concern themselves with what authors might
do.

May I disagree ? It is the duty of an implementor to
concern him/herself with everything that an author
might do <stress>that is consistent with the specification</>.

Philip TAYLR

Alan Gresley wrote:

Well implementors shouldn't concern themselves with what authors might
do.

Then implementors spent the last 15 years doing exactly the wrong thing.
The first postulate in our world is the following one :

Not only Web authors will try things that you never though of, but
they will use it extensively to the point it's a known hack or
workaround. It can be ugly, hacky, invalid, whatever.
Resistance is futile because whatever the uglyness or the invalidity,
the browser MUST render something w/o crashing or failing.


</Daniel>

Daniel Glazman wrote:

Resistance is futile because whatever the uglyness or the invalidity,
the browser MUST render something w/o crashing or failing.

"render something", yes;
"render what the author intended" : an impossible dream.

Far better to render what the author apparently
intended for valid markup, and to display an
error message otherwise. by so doing will
we ever have a hope in hell of bringing sanity
to the chaos that currently masquerades as "HTML".

Philip TAYLR

Alan Gresley wrote:
Boris, why would an author bother floating a <brelement?

I have no idea. I can just guarantee that some of them will, given past
experience with what authors do. And when they do it, I want to make
sure that my UA renders that page "as expected".

-Boris

Alan Gresley wrote:
Well implementors shouldn't concern themselves with what authors might
do.

Uh no. They should. And so should spec writers.

If an author wants to float a <br>, I say they do that at their own
peril.

Fine, but the spec still needs to make it clear what happens in that
case, and the UAs need to implement it.

That's why I suggested float:none as a default.

It already is. That doesn't change the above considerations.

-Boris

Brad Kemper wrote:
So, it wasn't just a retorical question? You want to know what the
"expected behavior" is if an author floats a BR?

That's correct, since just treating it as a non-replaced block means
that floating it will do absolutely nothing in the way of line-breaking.

What is it now? That would be a good starting place. What happens in the
various UAs if you make it display:block and give it some height and
width and float?

That's the question I was asking, yes.

-Boris

Jul 2, 2008, at 10:25 AM, Boris Zbarsky wrote:

>
Alan Gresley wrote:
>Boris, why would an author bother floating a <brelement?
>
I have no idea. I can just guarantee that some of them will, given
past experience with what authors do. And when they do it, I want
to make sure that my UA renders that page "as expected".
>
-Boris
>

So, it wasn't just a retorical question? You want to know what the
"expected behavior" is if an author floats a BR?

What is it now? That would be a good starting place. What happens in
the various UAs if you make it display:block and give it some height
and width and float?

Daniel Glazman wrote:

Alan Gresley wrote:

>Well implementors shouldn't concern themselves with what authors might
>do.

Then implementors spent the last 15 years doing exactly the wrong thing.
[]
</Daniel>


Precisely.


Alan

Alan Gresley wrote:

Precisely.

come on, we're not on www-style to remake history
but to work on technical matters related to CSS.

The browser vendors made what was absolutely needed
to make the Web a mass-media from a network reserved
to scientists in labs. It's because browser vendors
insisted (apart from the original Hotjava experience)
on never refusing markup invalidity, moved so fast they
did not have time to standardize, that the Web is the
marvelous tool we know today. Not a perfect tool, but
not one user out of ten thousands cares about the
technical side of the Web. They just expect the Web to
work, whatever the technical skill of the Web authors.
And most Web authors - my dad is my best example at
all times - are not experienced web designers. The end
user does not care about it and even if my dad's page
is technically ugly, the visitor will throw away the
browser if he/she cannot visit my dad's page. Like it
or not.

Speaking of the Web as we know it, I think that fifteen
years of doing the wrong thing (according to you) AND
leading to a medium used on a daily basis by hundreds of
millions of people and becoming mandatory for education,
science, work, government and all areas of life just
CANNT be called a real failure. So much for the "wrong
thing".

You can be a perfectionnist and troll here forever, that
will NT change that fact. That said, can we please come
back on Earth and could you please listen to the browser
implementors when they say "no, that just cannot be like
that" ? Thanks.

</Daniel>

Alan Gresley wrote:
Robert 'Callahan wrote:
>of the first lessons of browser implementation is that authors
>cannot be trusted.

Roc, which authors are you referring to.

1. Code valid CSS and HTML.
2. Code invalid CSS and valid and HTML.
3. Code valid CSS and invalid HTML.
4. Code invalid CSS and HTML.
5. Code invalid and propriety HTML.

I think I can speak for Robert here in saying "every single one of them".

You want to cater for the full spectrum, even those authors that
ignorantly mangle there code into knots.

Indeed.

So you are saying that the spec authors duty is to have CSS rendering
defined.

Yes, indeed.

This is a double edge sword where the author coding by best practices
are penalized.

I'm not sure I follow this at all.

-Boris

Daniel Glazman wrote:
Alan Gresley wrote:

>Precisely.

come on, we're not on www-style to remake history
but to work on technical matters related to CSS.


So rescue jobs by implementations are outside the technical discussion
on CSS. I disagree. BTW, what history would we be remaking?


The browser vendors made what was absolutely needed
to make the Web a mass-media from a network reserved
to scientists in labs. It's because browser vendors
insisted (apart from the original Hotjava experience)
on never refusing markup invalidity, moved so fast they
did not have time to standardize, that the Web is the
marvelous tool we know today.


To my knowledge Netscape 4 was a unforgiving browser. Then IE4 came
along and now all browsers repair invalid markup. They had time to
standardize but then there was this issue of *making money* from the web
that stopped that process in it's tracks.


Not a perfect tool, but
not one user out of ten thousands cares about the
technical side of the Web. They just expect the Web to
work, whatever the technical skill of the Web authors.


Do you have the data to prove that. Has there been a world poll
conducted asking if browsers should repair invalid markup. This is
just a mantra that is preached over and over again. It is just one wild
assumption that you use in your defense.


And most Web authors - my dad is my best example at
all times - are not experienced web designers. The end
user does not care about it and even if my dad's page
is technically ugly, the visitor will throw away the
browser if he/she cannot visit my dad's page. Like it
or not.


Firstly you say that your father is the best example and secondly the
end user doesn't care. Your examples are unqualified.


Speaking of the Web as we know it, I think that fifteen
years of doing the wrong thing (according to you) AND
leading to a medium used on a daily basis by hundreds of
millions of people and becoming mandatory for education,
science, work, government and all areas of life just
CANNT be called a real failure. So much for the "wrong
thing".


I am not alone in believing this is wrong. Today we have IE, ,
Gecko and WebKit all doing there *own thing*. It is a failure when the
web became a tool to make *multinationals or monopolies rich*. This is
the real failure.


You can be a perfectionnist and troll here forever, that
will NT change that fact. That said, can we please come
back on Earth and could you please listen to the browser
implementors when they say "no, that just cannot be like
that" ? Thanks.

</Daniel>


I am a dreamer (not a perfectionist) and my dream is a one interoperable
open web. This may mean that we don't have many implementors but just
one. There is nothing to stop all of you working together on *one
implementation*. That one implementation can have two modes, one
supporting invalid code and the other mode that experience authors can use.


I will accept your *no* when you can provide evidence. All opposition to
my beliefs (wrongful error recovery and`undefined behaviors) come from
those who are connected to the development of Gecko and are in the CSS
working group.


Alan

Robert 'Callahan wrote:
concern him/herself with everything that an author might do, "consistent
with the specification" or not. (And it is the duty of the spec author
to ensure that specifications prescribe behaviour for everything an
author might do, so that question does not arise.)


This is something that is special to the modern web. Most other
standards make heavy reliance on defining areas where behaviour is
explicitly undefined. It is probably impossible, because there will
always be combinations the specifiers forgot and get implemented
differently.

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.