The title attribute

On 2007-12-22, Jonathan N. Little <lws4art (AT) centralva (DOT) net> wrote:

Petr Vileta wrote:

I disagree with you. If this is a bug why this bug is in all browsers
(except text like)? In addition to his I can anytime define <a> as block
element and W3C CSS2 documentation say this about it:

--- CITE ---
9.2.5 The 'display' property
'display'
Value: inline | block | list-item | run-in | compact | marker | table
| inline-table | table-row-group | table-header-group |
table-footer-group | table-row | table-column-group | table-column |
table-cell | table-caption | none | inherit
Initial: inline
Applies to: all elements
Inherited: no
Percentages: N/A
Media: all
--- CITE ---

You *may style* an A element to display as block, but that does not
reverse the invalidity of placing a block element within an inline
element and also regardless of whether or not browser parse such junk.
Look at the HTML "spec" that the DTD is based on

"<!ELEMENT A - - (%inline* -(A) -- anchor -->"
^^^^^^^^^^^

Yes, and I would add to this that you can also place an element that's
styled display: block inside one that's styled display: inline. This is
perfectly legal CSS and has well-defined results.

But from the point of view of HTML, A is always inline and P is always
block, no matter how you style them, and a block cannot be a child of an
inline.

Perhaps this is a bit of anachronism these days (what are words like
"inline" and "block" doing in the definition of a supposedly
non-presentational markup language anyway?) but you still have to make
sure the HTML is valid or you don't know how browsers are going to
"helpfully" rearrange it for you.

Petr Vileta <stoupa (AT) practisoft (DOT) cz> wrote:

2. An inline element cannot contain a block element. The a element
is inline, and p is block.

I disagree with you. If this is a bug why this bug is in all browsers (except
text like)? In addition to his I can anytime define <a> as block element and
W3C CSS2 documentation say this about it:

You can make an element *display* as inline or block, but you can't
change its fundamental nature from inline to block.

Daniele

..oO(Petr Vileta)

I disagree with you. If this is a bug why this bug is in all browsers (except
text like)?

It's a bug in your code, not in the browser. Most browsers are very
forgiving and always try to get at least something usable out of the
author's code, even if it's the worst and most invalid crap. Without
such guessing and fixing 95% of all current websites would break.

In addition to his I can anytime define <a> as block element

This makes it look and behave like a block-level element, but it doesn't
make it into one actually.

and
W3C CSS2 documentation say this about it:

--- CITE ---
9.2.5 The 'display' property
'display'
[...]

Please take attention to "Applies to: all elements" ;-) So I can define
a.block {display: block;}
and use it for my purposes I I said.

You can achieve the same result with valid HTML ('span' comes to mind),
which then even works in Lynx.

Micha

Scripsit D.M. Procida:

The problem here is that the sidenote is always visually below the
point at which its inserted.

I think it's more serious that in the HTML document, the sidenote
appears before the text it relates to. In non-CSS rendering, this means
that the user sees or hears first the sidenote, then the main text. But
maybe this is what you meant.

Odd as it may sound, using a table leads to greater robustness. You
would have, say, a paragraph of main text in one cell and the associated
sidenote in the corresponding cell of another column.

In some case, you want a sidenote to an entire paragraph, and though
the note (logically) follows the paragraph as a whole, you might want
it displayed not after the paragraph, but alongside it.

Using a table, you can specify different relationships, so that a
sidenote relates to one paragraph or a sequence of paragraphs. It gets a
bit tricky if the sidenote is expected to be longer than the main text,
in which case you would probably want to let the sidenote flow down,
continuing alongside with text that it does not relate to. But this can
be handled by modifying the table structure, possibly using the rowspan
attribute for the sidenote cell.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

On 2007-12-30, Jukka K. Korpela <jkorpela (AT) cs (DOT) tut.fi> wrote:

Scripsit D.M. Procida:

The problem here is that the sidenote is always visually below the
point at which its inserted.

I think it's more serious that in the HTML document, the sidenote
appears before the text it relates to.

But in Lauri Raittila's example it doesn't-- the sidenote appears
immediately after the text it relates to.

(The sidenote will appear one line too low in Firefox and IE7, this is a
reported as a bug against Firefox in Bugzilla.)

In non-CSS rendering, this means that the user sees or hears first the
sidenote, then the main text. But maybe this is what you meant.

Odd as it may sound, using a table leads to greater robustness. You
would have, say, a paragraph of main text in one cell and the associated
sidenote in the corresponding cell of another column.

In some case, you want a sidenote to an entire paragraph, and though
the note (logically) follows the paragraph as a whole, you might want
it displayed not after the paragraph, but alongside it.

To answer this point, if you wanted that, you could make each <p>
position: relative and then put a position: absolute container for
sidenotes at the end of each <p>. Like this:

<p>Blah blah blah
<span class="sidenotes">
Notes for this paragraph go here, after it in the HTML source
</span>

then style it like this:

p {margin-right:20em; position: relative;}
.sidenotes
{
position: absolute;
top: 0;
right: -20em;
width: 20em;
}

This only works well if you're fairly sure the sidenotes won't be longer
than the paragraphs themselves.

Using a table, you can specify different relationships, so that a
sidenote relates to one paragraph or a sequence of paragraphs. It gets a
bit tricky if the sidenote is expected to be longer than the main text,
in which case you would probably want to let the sidenote flow down,
continuing alongside with text that it does not relate to. But this can
be handled by modifying the table structure, possibly using the rowspan
attribute for the sidenote cell.

That's horrible though. You need to fiddle around with rowspan after
finding that your sidenote wraps to a few lines. Floats are a much more
natural way to lay out sidenotes for this reason.

Jukka K. Korpela <jkorpela (AT) cs (DOT) tut.fi> wrote:

Scripsit D.M. Procida:

The problem here is that the sidenote is always visually below the
point at which its inserted.

I think it's more serious that in the HTML document, the sidenote
appears before the text it relates to. In non-CSS rendering, this means
that the user sees or hears first the sidenote, then the main text. But
maybe this is what you meant.

No, that should never happen; that wpould be completely unacceptable. I
mean visually, as in a visual browser.

Daniele

Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2007-12-30, Jukka K. Korpela <jkorpela (AT) cs (DOT) tut.fi> wrote:
Scripsit D.M. Procida:

The problem here is that the sidenote is always visually below the
point at which its inserted.

I think it's more serious that in the HTML document, the sidenote
appears before the text it relates to.

But in Lauri Raittila's example it doesn't-- the sidenote appears
immediately after the text it relates to.

It depends what you consider the note to be referring to.

In some case, you want a sidenote to an entire paragraph, and though
the note (logically) follows the paragraph as a whole, you might want
it displayed not after the paragraph, but alongside it.

To answer this point, if you wanted that, you could make each <p
position: relative and then put a position: absolute container for
sidenotes at the end of each <p>. Like this:

This only works well if you're fairly sure the sidenotes won't be longer
than the paragraphs themselves.

Yup - it's not very robust.

Daniele

in comp.infosystems.www.authoring.html, Ben C wrote:

On 2007-12-30, Jukka K. Korpela <jkorpela (AT) cs (DOT) tut.fi> wrote:
Scripsit D.M. Procida:

The problem here is that the sidenote is always visually below the
point at which its inserted.

I think it's more serious that in the HTML document, the sidenote
appears before the text it relates to.

But in Lauri Raittila's example it doesn't-- the sidenote appears
immediately after the text it relates to.

But if the text it relates is several lines, then note comes too late.
And you can't know how many lines the orginal text takes. (if you could,
then it would be easy to shift note up that amount.)

To answer this point, if you wanted that, you could make each <p
position: relative and then put a position: absolute container for
sidenotes at the end of each <p>.

This only works well if you're fairly sure the sidenotes won't be longer
than the paragraphs themselves.

Which is not that likely, as side/foot/end notes are mostly used for long
pieces of information that would take too much space, so bound to be
longer than paragraph it relates.

But with absolutely positioned thing, it won't be problem when note is
longer than relating paragraph, but when it is long enough to reach next
note. Unfortunately, next note might be on next paragraph.

But this can
be handled by modifying the table structure, possibly using the rowspan
attribute for the sidenote cell.

Yes, but then you luse semantics of relating to several paragraphs.

That's horrible though. You need to fiddle around with rowspan after
finding that your sidenote wraps to a few lines. Floats are a much more
natural way to lay out sidenotes for this reason.

But if you wish to get note level to paragraph it relates, it would mean
it wouldn't linearize.

But I think the problem is not that note appears later than text it
relates (especially as if sidenote is used as footnote would be in
print), but that the relation is not apparent. So you could style the
paragraph. If there was enough visual clue, it might not be necessary to
have comment exactly paraller.
Here is try where distinction is made by colors. More than 2 colors
should be used if notes are longer.
http://www.student.oulu.fi/~laurirai/www/sidenotes.html





--
Lauri Raittila <http://www.iki.fi/lr>

On 2008-01-07, Lauri Raittila <lauri (AT) raittila (DOT) cjb.net> wrote:

in comp.infosystems.www.authoring.html, Ben C wrote:
[...]
This only works well if you're fairly sure the sidenotes won't be longer
than the paragraphs themselves.

Which is not that likely, as side/foot/end notes are mostly used for long
pieces of information that would take too much space, so bound to be
longer than paragraph it relates.

But with absolutely positioned thing, it won't be problem when note is
longer than relating paragraph, but when it is long enough to reach next
note. Unfortunately, next note might be on next paragraph.

Exactly. It's not a good general solution.

But this can
be handled by modifying the table structure, possibly using the rowspan
attribute for the sidenote cell.

Yes, but then you luse semantics of relating to several paragraphs.

That's horrible though. You need to fiddle around with rowspan after
finding that your sidenote wraps to a few lines. Floats are a much more
natural way to lay out sidenotes for this reason.

But if you wish to get note level to paragraph it relates, it would mean
it wouldn't linearize.

But I think the problem is not that note appears later than text it
relates (especially as if sidenote is used as footnote would be in
print), but that the relation is not apparent. So you could style the
paragraph. If there was enough visual clue, it might not be necessary to
have comment exactly paraller.
Here is try where distinction is made by colors. More than 2 colors
should be used if notes are longer.
http://www.student.oulu.fi/~laurirai/www/sidenotes.html

There is one technical caveat with the solution here. You have
margin-right: -20em and width: 18.8em on these floats. Where does that
mean their left and right "outer edges" are?

Outer edge is defined in CSS 2.1 8.1, although I see no mention there of
negative margins. A browser might think that on your page, the left
outer edge of each float is actually 1.2em to the _right_ of its left
outer edge.

9.5.1 explains how floats are placed with reference to their left and
right outer edges. If the left edge is actually to the right of the
right edge some interesting things can go wrong. The most likely effect
is you would get the sidenotes overlapping each other.

I don't think this happens in any of the usual browsers, but still,
maybe it's undesirable to create elements with negative outer margin
widths. It makes it difficult to point at the specification and say what
the correct behaviour should be.

What most browsers are apparently doing is deciding that the right outer
edge cannot be further left than the right border edge. But that isn't
explicit in the specification (or if it is I haven't found it).

Note also that the specification does say (8.3) "Negative values for
margin properties are allowed, but there may be implementation-specific
limits." So a conforming browser could just use 0 for the -20em right
margin.

On 2008-01-07, Ben C <spamspam (AT) spam (DOT) eggs> wrote:
[...]

Outer edge is defined in CSS 2.1 8.1, although I see no mention there of
negative margins. A browser might think that on your page, the left
outer edge of each float is actually 1.2em to the _right_ of its left
outer edge.

Sorry, I meant it might put the right outer edge 1.2em to the left of
the left outer edge.

The left outer edge can't be to the left of itself!