|
|
Posted by John Hosking on 02/18/07 14:47
robert maas, see http://tinyurl.com/uh3t wrote:
>>From: John Hosking <J...@DELETE.Hosking.name.INVALID>
>>you sound like a home construction contractor who wants to build
>>homes for a living, but doesn't own a power saw, ...
>
> Your metaphor is wrong on several counts:
Yes, you're right; I should never have mentioned it.
> I do have one present worry. With the "loose" DTD (I'm not using the word
> "transitional" more in discussions about it
> because it causes too much confusion), it allows the following trick:
> Text that introduces a list:<ul>
> <li>First item</li>
> <li>Second item</li>
> </ul>
>
> The effect is that the text that introduces is immediately adjacent
> to the first list item, no blank line between them.
....in your version of Lynx, presumably because that's what the Lynx
developers thought would be good behavior in that situation. You're
lucky you like that behavior. It's surprising behavior (to me), though.
Do you mean the results look like this:
Text that introduces a list: * First item
* Second item
Subsequent text following but not a part of the list
? That's what I understand you to mean, but it's weird.
> Is that
> guaranteed behaviour, or is that only in lynx where that's the
> effect achieved?
The correct, theoretical answer to this question is, "check the W3C
standards (for that level of HTML which you're claiming to use)." But I
think you will find, if you do that (at, for example,
http://www.w3.org/TR/html4/struct/lists.html#h-10.2), that the W3C has
nothing particular to say about spacing before or after a UL or OL
element, although it is a block-level element (like <p>, <pre>, or
<hr>). The practical answer is, "no," based on the fact that in 45
seconds I tested it in IE6 and Firefox 1.0.something and Opera 7.23 and
it didn't work that way in any of them. Unless, *sigh* I misunderstood
the behavior.
> Now at the *end* of a UL element, there's always a blank line, just
> like with a PRE element, but I never have running text that I want
> adjacent to the bottom of a UL element,
It would be strange if you (or anyone) did.
> so that's not the problem
> that it is with PRE, in fact I always *want* the blank line after a
> UL element. But I'm worried about the line just before the UL
> element, which is supposed to introduce or act as a title for the
> list items. Do all browsers present it without blank-line gap?
See above.
> I assume you're talking about free technical support from other
> users, such as the folks on this newsgroup, not formal professional
> paid technical support from the vendor of lynx. Am I the only
> person in this entire newsgroup who has access to lynx and has
> experience matching the HTML with the the way lynx renders it?
I think, sir, that you are the only person here recently for whom Lynx's
behavior is a crisis situation.
> Is
> there nobody who has figured out a lynx problem I haven't yet
> figured out, who could help me get past an obstacle? Is there any
> other newsgroup with a larger number of lynx users where such
> questions might find better answers?
There is news:comp.os.lynx, but I don't imagine they're too interested
in discussing HTML issues there. Lurk there for a while and see.
>
>>My recommendation is that you write the content and forget the
>>publishing part.
>
> I'm not sure which aspects of the HTML you consider "the publishing
> part".
I meant the part where you mark up your text as HTML and post to to the Web.
>>When your work is done, somebody else can mark it up or help you
>>mark it up, and then publish it, or help you publish it *once*.
>
> An online reference like this will never be **done**.
I see now.
> I'm also not sure what you mean by "and then publish it". It's
> already "published", in the sense of Web accessible, from the
> start. Do you mean like actively promoting it, advertising to get
> more readers, or what??
No. I just meant publishing it, not publicizing it.
>>I hesitate to mention the tool at http://www.browsershots.org/ ...
>
> I
> suppose then I go to the public library to view their screen shots?
> But the public library already has recent versions of IE and
> Mozilla, so I'm not sure how that would help me. Explain?
I see now. Your public library is better equipped than you are, so for
the particular versions of IE and Mozilla available at the library, such
a site would be no help.
HTH
--
John
Navigation:
[Reply to this message]
|