OK, I guess you guys do it daily so it's no big deal for you,  but
you've been very helpful in helping me understand what needs to be
done.  

It's registered with 123-reg and we'll probably use them for hosting
until we know better! 

Of course, I suppose I could have just clicked the first "buy now"
button I saw, but I always prefer to understand what I'm doing and why
- and I couldn't have done that without your  your patience and
kindness

"me here"  wrote in message 
news:okruq4tibqgoh2a861ndl5skqlostm5m71@4ax.com...
> OK, I guess you guys do it daily so it's no big deal for you,  but
> you've been very helpful in helping me understand what needs to be
> done.
>
> It's registered with 123-reg and we'll probably use them for hosting
> until we know better!
>
> Of course, I suppose I could have just clicked the first "buy now"
> button I saw, but I always prefer to understand what I'm doing and why
> - and I couldn't have done that without your  your patience and
> kindness

What a gobsmackingly fantastic domain name!!!! Get Bob Geldof in on the act 
now!

It's good that someone asks a question and listens to the answer. You'd be 
amazed how many come on this forum and similar and just start arguing with 
the advice they're given.

--
+mrcakey
www.everythingthatswrongwiththeworld.com

On Thu, 5 Mar 2009 09:34:43 -0000, "+mrcakey"
 wrote:


>What a gobsmackingly fantastic domain name!!!! Get Bob Geldof in on the act 
>now!

Well, now you mention it I suppose it is quite memorable, isn't it. 

The full name of the charity (not a ltd co) is "Soft Landings Parrot
Aid". Oddly we were going to try for softlandings.co.uk etc but that
was already taken by a playground mat company!  I think I'm glad it
was now. 

We just have to make proper use of it now, and that certainly won't be
by using "InstantSite".  What total rubbish.  

Would you (or indeed anyone) have any idea how long it should take for
the 'default page' to go away once the single 'holding page' has been
created? 

Thanks again

On Mar 5, 9:29 pm, me here  wrote:
> On Thu, 5 Mar 2009 09:34:43 -0000, "骷᪑"
>
>  wrote:
> >What a gobsmackingly fantastic domain name!!!! Get Bob Geldof in on the act
> >now!
>
> Well, now you mention it I suppose it is quite memorable, isn't it.
>
> The full name of the charity (not a ltd co) is "Soft Landings Parrot
> Aid". Oddly we were going to try for softlandings.co.uk etc but that
> was already taken by a playground mat company!  I think I'm glad it
> was now.
>
> We just have to make proper use of it now, and that certainly won't be
> by using "InstantSite".  What total rubbish.  
>
> Would you (or indeed anyone) have any idea how long it should take for
> the 'default page' to go away once the single 'holding page' has been
> created?
>
> Thanks again
You will need web hosting. ]
You could get that through your domain name registrar or use another
company. You could also just forward the domain (but to be honest you
would be better off getting some hosting for it. Once you get some
hosting you can then replace the holding page with your own page,
called index.html or .php or whatever.
--
Free Web Design Online, free web design for community groups and
organisations.
http://freewebdesignonline.org

On Thu, 5 Mar 2009 02:48:09 -0800 (PST), Chaddy2222
 wrote:

>> Would you (or indeed anyone) have any idea how long it should take for
>> the 'default page' to go away once the single 'holding page' has been
>> created?
>>
>> Thanks again
>You will need web hosting. ]
>You could get that through your domain name registrar or use another
>company. You could also just forward the domain (but to be honest you
>would be better off getting some hosting for it. Once you get some
>hosting you can then replace the holding page with your own page,
>called index.html or .php or whatever.
Ahhh!

Now, you see - I thought you were allowed to create a holding page
without having bought web hosting!   They cunningly let you use that
dreadful 'IinstantSite' to build one and even publish it with a
"successfully published" result.  But from what you say, it may be
that that page is only visible once you've bought heir hosting.  

Not a problem  - they're cheap and we'd have gone for them anyway to
beg in  with, but another example of how 'deliberate obfuscation' is
alive and well!

At least once I've bought the hosting I'll be able to do the work
locally and ftp it to their server.  Now that's technology I *do*
understand! 

Thanks for the pointer!

On Mar 5, 10:04 pm, me here  wrote:
> On Thu, 5 Mar 2009 02:48:09 -0800 (PST), Chaddy2222
>
>  wrote:
> >> Would you (or indeed anyone) have any idea how long it should take for
> >> the 'default page' to go away once the single 'holding page' has been
> >> created?
>
> >> Thanks again
> >You will need web hosting. ]
> >You could get that through your domain name registrar or use another
> >company. You could also just forward the domain (but to be honest you
> >would be better off getting some hosting for it. Once you get some
> >hosting you can then replace the holding page with your own page,
> >called index.html or .php or whatever.
>
> Ahhh!
>
> Now, you see - I thought you were allowed to create a holding page
> without having bought web hosting!   They cunningly let you use that
> dreadful 'IinstantSite' to build one and even publish it with a
> "successfully published" result.  But from what you say, it may be
> that that page is only visible once you've bought heir hosting.  
>
> Not a problem  - they're cheap and we'd have gone for them anyway to
> beg in  with, but another example of how 'deliberate obfuscation' is
> alive and well!
>
> At least once I've bought the hosting I'll be able to do the work
> locally and ftp it to their server.  Now that's technology I *do*
> understand!
>
> Thanks for the pointer!

That's fine, mind you, you might want to check with the registrar as
they might have a way to delete the hosts holding page. Although you
will need hosting anyway.
How are you in terms of website design?
--
Regards Chad. http://freewebdesignonline.org

Message-ID:  from me here
contained the following:

>Now, you see - I thought you were allowed to create a holding page
>without having bought web hosting!   They cunningly let you use that
>dreadful 'IinstantSite' to build one and even publish it with a
>"successfully published" result.  But from what you say, it may be
>that that page is only visible once you've bought heir hosting.  

When you register a domain and nameservers and take on some hosting  it
takes one or two days for the information to propagate throughout the
wibbly wobbly web.  After that any changes you make to files (e.g. via
ftp) should be instant.

A note about hosting. I think most hosting comes with PHP scripting but
not all come with a database which you'd need if you wanted to add a
forum.

My best friend is mad about parrots and has an African Grey.  As a
gesture to him, I can offer you free hosting if you are not already
fixed up.

If you want to contact me via email, don't forget to put thecat out.
-- 
Geoff Berrow  0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
http://slipperyhill.co.uk - http://4theweb.co.uk

On Thu, 5 Mar 2009 03:41:34 -0800 (PST), Chaddy2222
 wrote:


>How are you in terms of website design?
I think I'm about to find out! 

I used to hand-code stuff in text editors a decade or so ago.  I think
things have moved on slightly since then :)

We're just starting to talk about content and how we want the site to
function and support our activities.  All we have really decided is
that the site isn't about entertainment and WON'T have a forum!

What I do know is that if the activity and the site develops the way
we want it to (although we'd rather we didn't exist - a bit like how
much more it would say about a society that didn't NEED the NSPCC)
then it will be beyond any capabilities I would want to acquire. 

In the meantime, given my semi-retired status, I'm enjoying the
learning experience.    I also know only too well that it's way more
expensive, complicated and fraught to pick up someone else's work than
it is top start from scratch, so I'll not be investing any emotional
capital in what I do, or taking it too far before getting the
professionals involved!

On Thu, 05 Mar 2009 12:02:20 +0000, Geoff Berrow
 wrote:


>When you register a domain and nameservers and take on some hosting  it
>takes one or two days for the information to propagate throughout the
>wibbly wobbly web.  After that any changes you make to files (e.g. via
>ftp) should be instant.
Ahhh!  Another light bulb is switched on.  I couldn't understand how
web sites could be maintained if EVERY change took many hours or a day
or so to propagate.  But it's only the 'initialization that takes that
long. Thank you!

>A note about hosting. I think most hosting comes with PHP scripting but
>not all come with a database which you'd need if you wanted to add a
>forum.
No!  No way!  They are the work of the devil!   I have never been on a
forum that hasn't been a bitch fest  and I can't do 'nicey nicey'.
Hmmm .... is that REALLY a coincidence .....
 
>My best friend is mad about parrots and has an African Grey.  As a
>gesture to him, I can offer you free hosting if you are not already
>fixed up.
That is a very kind offer: thank you.  I'll talk to the Boss lady (no
not SWMBO) about that :)

"me here"  wrote in message 
news:ejkvq49orjetv928ltg6nf1ckecqbc6egn@4ax.com...
: On Thu, 5 Mar 2009 03:41:34 -0800 (PST), Chaddy2222
:  wrote:
:
:
: >How are you in terms of website design?
: I think I'm about to find out!
:
: I used to hand-code stuff in text editors a decade or so ago. 
I think
: things have moved on slightly since then :)

Probably not if you know your coding, but if your not up to speed 
on ASP/PHP, CSS etc...
-- 
Regards, Jerry.
Location - United Kingdom.
In the first instance please reply to group, sorry,
Emails to this address are deleted unread.

On Thu, 5 Mar 2009 14:46:55 -0000, "Jerry"
<mapson.scarts@btinternet.com.INVALID> wrote:


>: I used to hand-code stuff in text editors a decade or so ago. 
>I think
>: things have moved on slightly since then :)
>
>Probably not if you know your coding, but if your not up to speed 
>on ASP/PHP, CSS etc...

eh? 

:)

Which do you prefer, the nested list version:

<h1>Events</h1>
<ul>
        <li>Today
                <ul>
                        <li>today's 1st event</li>
                        <li>today's 2nd event</li>
                </ul>
        </li>
        </li>Forthcoming
                <ul>
                        <li>1st forthcoming event</li>
                        <li>2nd forthcoming event</li>
                        <li>3rd forthcoming event</li>
                </ul>
        </li>
</ul>

or the headered version:

<h1>Events</h1>
<h2>Today</h2>
                <ul>
                        <li>today's 1st event</li>
                        <li>today's 2nd event</li>
                </ul>
<h2>Forthcoming</h2>
                <ul>
                        <li>1st forthcoming event</li>
                        <li>2nd forthcoming event</li>
                        <li>3rd forthcoming event</li>
                </ul>

I think the former is to be preferred, but I can't see a tremendous
reason for preferring one over the other.

Daniele

"D.M. Procida"  
wrote in message 
news:1iwojhd.1mqp9ba1wz9g1sN%real-not-anti-spam-address@apple-juice.co.uk...
: Which do you prefer, the nested list version:
:
: <h1>Events</h1>
: <ul>
:        <li>Today
:                <ul>
:                        <li>today's 1st event</li>
:                        <li>today's 2nd event</li>
:                </ul>
:        </li>
:        </li>Forthcoming
:                <ul>
:                        <li>1st forthcoming event</li>
:                        <li>2nd forthcoming event</li>
:                        <li>3rd forthcoming event</li>
:                </ul>
:        </li>
: </ul>
:
: or the headered version:
:
: <h1>Events</h1>
: <h2>Today</h2>
:                <ul>
:                        <li>today's 1st event</li>
:                        <li>today's 2nd event</li>
:                </ul>
: <h2>Forthcoming</h2>
:                <ul>
:                        <li>1st forthcoming event</li>
:                        <li>2nd forthcoming event</li>
:                        <li>3rd forthcoming event</li>
:                </ul>
:
: I think the former is to be preferred, but I can't see a 
tremendous
: reason for preferring one over the other.
:

Horses for courses surely, in the context of a *vanilla list of 
data* the first example looks better in the flesh, OTOH as a 
*list important, perhaps date or time, sensitive data* etc. the 
second example is a lot clearer in the flesh - obviously either 
could look like the other once styling is applied!
-- 
Wikipedia: the Internet equivalent of
Hyde Park and 'speakers corner'...
Sorry, mail to this address goes unread.
Please reply via group.

In article 
<1iwojhd.1mqp9ba1wz9g1sN%real-not-anti-spam-address@apple-juice.co.uk>,
 real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

> Which do you prefer, the nested list version:
> 
> <h1>Events</h1>
> <ul>
>         <li>Today
>                 <ul>
>                         <li>today's 1st event</li>
>                         <li>today's 2nd event</li>
>                 </ul>
>         </li>
>         </li>Forthcoming
>                 <ul>
>                         <li>1st forthcoming event</li>
>                         <li>2nd forthcoming event</li>
>                         <li>3rd forthcoming event</li>
>                 </ul>
>         </li>
> </ul>
> 
> or the headered version:
> 
> <h1>Events</h1>
> <h2>Today</h2>
>                 <ul>
>                         <li>today's 1st event</li>
>                         <li>today's 2nd event</li>
>                 </ul>
> <h2>Forthcoming</h2>
>                 <ul>
>                         <li>1st forthcoming event</li>
>                         <li>2nd forthcoming event</li>
>                         <li>3rd forthcoming event</li>
>                 </ul>
> 
> I think the former is to be preferred, but I can't see a tremendous
> reason for preferring one over the other.

Well, you should not prefer the first to the second because the first is 
all wrong and would make a doc invalid. 

Fix it up and then I will tell you which is to be preferred and why. 
This offer is open for 21 days. But do not delay too much, my shop is 
very busy and the stock goes in and out quickly. <g>

-- 
dorayme

dorayme  wrote:

> > Which do you prefer, the nested list version:

> > or the headered version:

> > I think the former is to be preferred, but I can't see a tremendous
> > reason for preferring one over the other.
> 
> Well, you should not prefer the first to the second because the first is
> all wrong and would make a doc invalid. 
> 
> Fix it up and then I will tell you which is to be preferred and why. 
> This offer is open for 21 days. But do not delay too much, my shop is
> very busy and the stock goes in and out quickly. <g>

All right then, apart from the typo, which do you prefer?

Daniele
-- 
Wanted: TEAC A-2300SX, Akai GX-4000D

In article 
<1iwp1pb.1qpnyo8o3ccqvN%real-not-anti-spam-address@apple-juice.co.uk>,
 real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

> dorayme  wrote:
> 
> > > Which do you prefer, the nested list version:
> 
> > > or the headered version:
> 
> > > I think the former is to be preferred, but I can't see a tremendous
> > > reason for preferring one over the other.
> > 
> > Well, you should not prefer the first to the second because the first is
> > all wrong and would make a doc invalid. 
> > 
> > Fix it up and then I will tell you which is to be preferred and why. 
> > This offer is open for 21 days. But do not delay too much, my shop is
> > very busy and the stock goes in and out quickly. <g>
> 
> All right then, apart from the typo, which do you prefer?
>

OK, I am suitably chastized. Did not look closely! <g>

First markup: <http://dorayme.netweaver.com.au/markup1.html>

Second markup: <http://dorayme.netweaver.com.au/markup2.html>

Well, one thing we can say is that the first markup is simpler than the 
second in that it uses one actual element to make do for what the second 
uses four. If you are impressed by Ockam's Razor, you will surely use 
the first. It elegantly and simply and less disjointedly represents the 
structure inherent in what you are saying.
 
Let's suppose that more than a monk's thoughts from about 800 years ago 
is needed before a final decision. Here is more. 

It is almost always a good idea in these matters to compare the choices 
you face in the event of your author style sheet being not available and 
a default used by the browser. 

If the browser does use its styles then both choices have their 
strengths and weaknesses on mere presentational grounds in tests that I 
have conducted. The all one list is neat and understandable, the meaning 
is represented by indentation and differential bulleting. Personally I 
feel the lack of font-weight in the primary list items does not help out 
enough and I am irritated by the primary list item bulleting. But the 
meaning is terribly clear! 

In the more profligate second version, this lack of font-weight is made 
up for. But that is the trouble, it is made up with too much of a 
vengeance and second order headings are awfully big. Not only that, the 
vertical spacings between headings and lists are too big and ugly. On 
the other hand, the lack of bullets for the headings is nicer than the 
sight of the first order bullets in the first mark up imo.

I would say on aesthetic grounds alone, the first markup wins by half a 
length. 

But presentation is *everything* when it comes to human observers' 
appreciation of meaning and there is more than aesthetics involved. If 
your list is longer than the example, and let us suppose it is so we can 
answer a more general query, then the first would win hands down on 
communication in visual browsers because it better uses the screen area. 
If a user can get your content with less scrolling and effort then they 
get the meaning better. Simple as that. On this ground, again, the first 
markup wins. 

I will discuss the issue under the assumption that maintenance and 
author styling efforts are important factors if you really want. But 
perhaps this will do for now.

I desist for the moment telling you about a wonderful and apt third way 
to organise your lists in a table, but we should keep it in mind as a 
player when complex lists are involved.

-- 
dorayme

In article ,
 dorayme  wrote:

> In article 
> <1iwp1pb.1qpnyo8o3ccqvN%real-not-anti-spam-address@apple-juice.co.uk>,
>  real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:
> 
> > > > I think the former is to be preferred, but I can't see a tremendous
> > > > reason for preferring one over the other.

> 
> First markup: <http://dorayme.netweaver.com.au/markup1.html>
> 
> Second markup: <http://dorayme.netweaver.com.au/markup2.html>
> 
> 
> I desist for the moment telling you about a wonderful and apt third way 
> to organise your lists in a table, but we should keep it in mind as a 
> player when complex lists are involved.

Here is a third type of way, it still does not beat the sheer clarity of 
the first markup but only because the default styles are so severe! I 
have no real idea why default style sheets do not put a modicum of 
padding and border and border-collapse in. So I put this in to show what 
the bare minimum of style would make it look like.

Third markup: <http://dorayme.netweaver.com.au/markup3.html>

Looks pretty clear to me and if default styles were better thought out 
along the lines you can see, I would say this is best of all to 
communicate the event schedule at least in visual browsers. I welcome 
comments about the effects for other modalities.

Note that if you remove the author styles in this table markup, it 
simply looks shithouse and markup1 wins yet again! That markup 1 is 
quite a thoroughbred, no?

I think it is a very telling mistake of browser makers to adopt a 
default style sheet that does not include the bare minimum of styles I 
include above. To me, it says loud and clear: we do not really 
understand the function or semanticity of tables! 

Or is it, oh gee... no... a sheer yellow streak, a miserable cowardly 
giving into the table layout brigade! This perfectly fits their crime. 
Folk who use tables for sheer page layout and not for organizing lists 
would not want borders by default! Poor lambs, they would have to 
actually remove default borders. I am disgusted! <g> 

The meaning of a table is best brought out by a few simple borders and a 
modicum of padding. This presentation is part and parcel of user 
understanding. Here is a case where open mindedness is simple mindedness 
or sheer wickedness as per above.

The border in a default situation is quite important for human 
recognition of what is going on, meaning-wise in a table properly used. 
For so called tabular data, or, as I prefer, as a way to organise lists 
and bring their relationships out to human observers. 

This does not mean I advocate borders full stop. Authors can use their 
judgement. With suitable cell spacing and/or padding and sometimes 
elegant backgrounding, no-border is a *perfectly* good option. But in 
the default situation, it is an almost perverse thing to leave out. If 
you don't believe me, remove my styles completely and see how awful and 
mildly confusing it looks in FF, to take an example.

-- 
dorayme

dorayme  wrote:

> > All right then, apart from the typo, which do you prefer?
> >
> 
> OK, I am suitably chastized. Did not look closely! <g>
> 
> First markup: <http://dorayme.netweaver.com.au/markup1.html>
> 
> Second markup: <http://dorayme.netweaver.com.au/markup2.html>
> 
> I would say on aesthetic grounds alone, the first markup wins by half a
> length. 

I think we should disregard the aesthetics - we can change the
presentation any way we like. 

If for some reason the user isn't seeing styles, then it could be
because they've chosen that, or because they can't (maybe they're blind)
- either way, they're used to seeing content like that, and more
importantly, the nested list structure gives more clues about the
relationships within its contents.

That's why I prefer the first way.

The downside is that more CSS is required, and the application of a
suitable class falls to the author, in order to improve the appearance
in most contexts.

> I desist for the moment telling you about a wonderful and apt third way
> to organise your lists in a table, but we should keep it in mind as a
> player when complex lists are involved.

Your table would be better achieved by using CSS to style the nested
list for you - as long as the author keeps the list at two levels.

Daniele

In article 
<1iwpvzi.t602jt13g2dczN%real-not-anti-spam-address@apple-juice.co.uk>,
 real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

> dorayme  wrote:
> 
> > > All right then, apart from the typo, which do you prefer?
> > >
> > 
> > OK, I am suitably chastized. Did not look closely! <g>
> > 
> > First markup: <http://dorayme.netweaver.com.au/markup1.html>
> > 
> > Second markup: <http://dorayme.netweaver.com.au/markup2.html>
> > 
> > I would say on aesthetic grounds alone, the first markup wins by half a
> > length. 
> 
> I think we should disregard the aesthetics - we can change the
> presentation any way we like.

I was speaking in the context of where author styles were not available. 
Aesthetics is not about merely pretty. Aesthetics is good when function 
shines through. And we are talking a particular functional bit of a 
page, not the whole page. 

Preceding my last remark was:

"... the first markup is simpler than the second in that it uses one 
actual element to make do for what the second uses four. ... It 
elegantly and simply and less disjointedly represents the structure..."

and

"... always a good idea ... to compare the choices ... in the event of 
... a default used by the browser."

> 
> If for some reason the user isn't seeing styles, then it could be
> because they've chosen that, or because they can't (maybe they're blind)
> - either way, they're used to seeing content like that, and more
> importantly, the nested list structure gives more clues about the
> relationships within its contents.
>

First, the user *always* sees styles. Don't miss this like troops miss 
road-side bombs! 

Where no author styles operate, the vacuum is necessarily immediately 
filled by a browser supplied set of styles. These styles are very 
important communication factors. If the beloved abstract correct element 
to use does a worse job to communicate information than what is regarded 
by the orthodox as an incorrect or even non-semantic element, then maybe 
a different road should be chosen.

I too regard the relationship within content to be important. But the 
proof is in the pudding and the pudding is not the HTML, it is in the 
results on the countless devices that humans use. 

> The downside is that more CSS is required, and the application of a
> suitable class falls to the author, in order to improve the appearance
> in most contexts.
>

Certainly it is an important factor how much CSS fiddling is needed to 
bring something up to a fine communication.

 
> > I desist for the moment telling you about a wonderful and apt third way
> > to organise your lists in a table, but we should keep it in mind as a
> > player when complex lists are involved.
> 
> Your table would be better achieved by using CSS to style the nested
> list for you - as long as the author keeps the list at two levels.
> 

Are you saying that better than  

<http://dorayme.netweaver.com.au/markup3.html>

would be to make markup 1 look something similar?

-- 
dorayme

dorayme  wrote:

> > I think we should disregard the aesthetics - we can change the
> > presentation any way we like.
> 
> I was speaking in the context of where author styles were not available.
> Aesthetics is not about merely pretty. Aesthetics is good when function
> shines through. And we are talking a particular functional bit of a 
> page, not the whole page. 

My point was that we can manage the appearance spearately, so we don't
need to worry about that here. As for the functional component of the
aesthetics that can't be dealt with in the styling - well, that's the
list structure question I was aksing.

> > If for some reason the user isn't seeing styles, then it could be
> > because they've chosen that, or because they can't (maybe they're blind)
> > - either way, they're used to seeing content like that, and more
> > importantly, the nested list structure gives more clues about the
> > relationships within its contents.
> >
> 
> First, the user *always* sees styles. Don't miss this like troops miss
> road-side bombs! 
> 
> Where no author styles operate, the vacuum is necessarily immediately
> filled by a browser supplied set of styles.

Not necessarily. The browser provides information to the user about the
content via HTML. Sometimes it does this through styles (bold for
<strong>, big text for headings) but sometimes it simply says "heading
level one".

> I too regard the relationship within content to be important. But the
> proof is in the pudding and the pudding is not the HTML, it is in the
> results on the countless devices that humans use. 

No, the proof of the pudding is in the *eating*. 

That aside, since humans use countless devices to read HTML, I shouldn't
try to second-guess them - I should follow the same rules that the
devices should be following.

Where the rules need interpretion that isn't dead simple, then I still
think that aiming to understand the rules rather than second-guess the
browsers is the best policy.

> > Your table would be better achieved by using CSS to style the nested
> > list for you - as long as the author keeps the list at two levels.
> > 
> 
> Are you saying that better than  
> 
> <http://dorayme.netweaver.com.au/markup3.html>
> 
> would be to make markup 1 look something similar?

If that's really a list of events, then yes. But not if it's supposed to
be tabular data.

Daniele

On 16 Mar, 16:44, real-not-anti-spam-addr...@apple-juice.co.uk (D.M.
Procida) wrote:
> Which do you prefer,

Neither. Check the DTD for the nesting rules around lists, and how
restrictive they are. You can't easily place any captioning inside a
list (unless you mess with the CSS of a first list element, which is
icky as it's not a "member" of that list), so you really are forced
into placing a header-like element outside the <ul>. This is weakly
bound to the list by sequence, but not by a strong semantic
relationship that's obvious from the HTML structure.

As you have it, the first is slightly preferable from a purist
semantics aspect, but it's an evil bitch to control the presentation
of because that "Today" heading is floating around as anonymous text
with no way to address it through a CSS selector.

So in general I'd prefer a "nested list" approach, provided of course
that both lists can be said to express a semantically clear
relationship. But you still need to wrap the header text in some
element (maybe a <h2>) or else it's simply impractical to work with
it.

The software engineering of "cohesion" (and it's related term
"coupling") is worth understanding. Lists should have good cohesion
amongst their members, not just coincidental coupling or usage-based
coincidental coupling, i.e. the bad situation where two groups appear
together in one instance on one page, but this relationship isn't
strong enough that it would always be applicable to them.

D.M. Procida wrote:
> dorayme  wrote:
> 
>> Are you saying that better than  
>>
>> <http://dorayme.netweaver.com.au/markup3.html>
>>
>> would be to make markup 1 look something similar?
> 
> If that's really a list of events, then yes. But not if it's supposed to
> be tabular data.

That is just a list of events. Table markup is illogical because there 
is no relationship between the cells in a row, other than the headers. 
If it were tabular there would be some kind of relationship between data 
cells.

-- 
Berg

In article 
<1iwtmle.1qlfwnx1ds6dp3N%real-not-anti-spam-address@apple-juice.co.uk>,
 real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

> dorayme  wrote:
> 
> > > I think we should disregard the aesthetics - we can change the
> > > presentation any way we like.
> > 
> > I was speaking in the context of where author styles were not available.
> > Aesthetics is not about merely pretty. Aesthetics is good when function
> > shines through. And we are talking a particular functional bit of a 
> > page, not the whole page. 
> 
> My point was that we can manage the appearance spearately, so we don't
> need to worry about that here. As for the functional component of the
> aesthetics that can't be dealt with in the styling - well, that's the
> list structure question I was aksing.
>

We cannot manage the the appearance separately in the context of author 
styles being off. And it is only in this context that I am talking. I 
won't go into it here, but I believe if we *really* could manage the 
appearances with author styles, it would not really matter so much how 
we marked up, anything to get the appearance needed to communicate with 
humans.

 
> > > If for some reason the user isn't seeing styles, then it could be
> > > because they've chosen that, or because they can't (maybe they're blind)
> > > - either way, they're used to seeing content like that, and more
> > > importantly, the nested list structure gives more clues about the
> > > relationships within its contents.
> > >
> > 
> > First, the user *always* sees styles. Don't miss this like troops miss
> > road-side bombs! 
> > 
> > Where no author styles operate, the vacuum is necessarily immediately
> > filled by a browser supplied set of styles.
> 
> Not necessarily. The browser provides information to the user about the
> content via HTML. Sometimes it does this through styles (bold for
> <strong>, big text for headings) but sometimes it simply says "heading
> level one".
> 

According to my way of thinking, if a browser causes a voice to say 
"Heading level one" and following with the heading content, then that is 
a default presentation of that part of the web page. It is a didactic 
form of presentation. I believe that HTML markup is only good for its 
ability to be a reliable cause of presentation that communicates 
information that webpage makers want communicated.

> > I too regard the relationship within content to be important. But the
> > proof is in the pudding and the pudding is not the HTML, it is in the
> > results on the countless devices that humans use. 
> 
> No, the proof of the pudding is in the *eating*. 
>
My phrase is a modern shortened version as befits the wild young modern 
thing I am. But I accept the seniority of your version. <g> 
 
> That aside, since humans use countless devices to read HTML, I shouldn't
> try to second-guess them - I should follow the same rules that the
> devices should be following.
>

Under a certain interpretation, I agree wholeheartedly

<http://netweaver.com.au/semantics/whySemanticElements.php>
 
> Where the rules need interpretion that isn't dead simple, then I still
> think that aiming to understand the rules rather than second-guess the
> browsers is the best policy.

Understanding the rules so that you are practically equipped involves 
knowledge of browsers, their defaults, their faults, the likelihood of 
device and browser makers understanding what you understand and they 
putting into practice these understandings.
> 
> > > Your table would be better achieved by using CSS to style the nested
> > > list for you - as long as the author keeps the list at two levels.
> > > 
> > 
> > Are you saying that better than  
> > 
> > <http://dorayme.netweaver.com.au/markup3.html>
> > 
> > would be to make markup 1 look something similar?
> 
> If that's really a list of events, then yes. But not if it's supposed to
> be tabular data.
> 
Tables are for displaying lists, from the simplest to the most complex, 
and an excellent way to show relationship between list items in 
different lists. I use the word "list" in the ordinary English sense of 
the word. To use it in an the HTML sense is to beg questions that should 
not be begged. 

Your original question is enormously interesting to me, Daniele, because 
it brings out so many important issues. Thanks for asking it!

I won't bang on here now but I disagree that there is some one "real 
structure" of what you wish to communicate. You can see why I favoured 
the nested list option. I said why. But it did not include the component 
of the one true real structure. I think this is a fantasy of some 
website theorists!

I know, I said at the start of my response to your question, "Well, one 
thing we can say is that the first markup is simpler than the second in 
that it uses one actual element to make do for what the second uses 
four. If you are impressed by Ockam's Razor, you will surely use the 
first. It elegantly and simply and less disjointedly represents the 
structure inherent in what you are saying."

I was talking loosely or, shall we say, without an implication that 
there was some one fixed in stone structure. I just meant that you 
wanted to let people know when things were on. And I said that I 
preferred the first on grounds of simplicity in the one situation we 
must always be prepared for, with default styles on. In short, it gets 
across what events are on when in a simpler way in this situation. 

But there is no inner one abstract structure. If we could rely on author 
styles - which we can't rely on - then other markups, such as your 
second one or my table example would be fine. At least that is what I am 
thinking at the moment. I am happy to consider the matter further and 
modify if necessary.

-- 
dorayme

dorayme  wrote:

> We cannot manage the the appearance separately in the context of author
> styles being off. And it is only in this context that I am talking. I
> won't go into it here, but I believe if we *really* could manage the 
> appearances with author styles, it would not really matter so much how
> we marked up, anything to get the appearance needed to communicate with
> humans.

That's simply not true.

Indexing software, and software that needs to parse structures to
present them to other software or to humans, need properly marked up
content.

> According to my way of thinking, if a browser causes a voice to say 
> "Heading level one" and following with the heading content, then that is
> a default presentation of that part of the web page. 

That looks like information, not presentation.
 
Daniele
-- 
Wanted: TEAC A-2300SX, Akai GX-4000D

In article 
<1iwu5dd.wfcwqqa8lm0bN%real-not-anti-spam-address@apple-juice.co.uk>,
 real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

> dorayme  wrote:
> 
> > We cannot manage the the appearance separately in the context of author
> > styles being off. And it is only in this context that I am talking. I
> > won't go into it here, but I believe if we *really* could manage the 
> > appearances with author styles, it would not really matter so much how
> > we marked up, anything to get the appearance needed to communicate with
> > humans.
> 
> That's simply not true.
> 

> Indexing software, and software that needs to parse structures to
> present them to other software or to humans, need properly marked up
> content.
> 

Good point which I have addressed a bit elsewhere; I agreed that 
presentation does not matter when a device is merely, to take an 
imaginary example, counting how many P elements are used on a site. 

But your point is not quite on the button here. I said "anything to get 
the appearance needed to communicate with humans" and I meant directly 
to humans at the browser or device end. 


> > According to my way of thinking, if a browser causes a voice to say 
> > "Heading level one" and following with the heading content, then that is
> > a default presentation of that part of the web page. 
> 
> That looks like information, not presentation.
>
I have gone on about this before, so sorry, everyone, to repeat. Your 
remark is a mistake in my opinion. Information cannot be communicated to 
human beings except by appearances (sounds, touch etc). It cannot be 
done by spooky stuff. ESP is unlikely. And if it were likely, I would 
have something to say about its default working CSS sheet. The fact is 
that humans get info via presentations of some kind or other. They do 
not get it direct or unmediated. 

> Daniele

-- 
dorayme

dorayme  wrote:

> > > According to my way of thinking, if a browser causes a voice to say
> > > "Heading level one" and following with the heading content, then that is
> > > a default presentation of that part of the web page. 
> > 
> > That looks like information, not presentation.
> >
> The fact is that humans get info via presentations of some kind or other.
> They do not get it direct or unmediated.

But they can still distinguish between information and presentation, or
should be able to. 

The very fact that humans "get info via presentations" entails that
presentation is not information.

Daniele
-- 
Wanted: TEAC A-2300SX, Akai GX-4000D

In article 
<1iwuhgn.xx7cfx3x16z4N%real-not-anti-spam-address@apple-juice.co.uk>,
 real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

> dorayme  wrote:
> 
> > > > According to my way of thinking, if a browser causes a voice to say
> > > > "Heading level one" and following with the heading content, then that is
> > > > a default presentation of that part of the web page. 
> > > 
> > > That looks like information, not presentation.
> > >
> > The fact is that humans get info via presentations of some kind or other.
> > They do not get it direct or unmediated.
> 
> But they can still distinguish between information and presentation, or
> should be able to. 
>
I have no idea what this *really* means, sorry. Where are the paragraphs 
in this:

<http://dorayme.netweaver.com.au/analyseThis.html>

Had I put a simple <br> between the 'information bits' you would be able 
to distinguish them. If I marked up as in 

<http://members.optushome.com.au/droovies/opinion/drugLaws.html>

and you turned off all author styles, you would see the information bits 
because the browser supplies a pretty good default stylesheet. 

If I marked up similarly as previous but had a better go at the barely 
conceivable idea of webpage that was deprived of both an author-CSS and 
also a default-CSS you might see something not even as good as this:

<http://dorayme.netweaver.com.au/drugLaws_sans_dpr.html>

With this latter, you would do better to view Source to read the 
article! But remember, source is not something that the audience knows 
anything about. That is strictly secret website maker business. 

 
> The very fact that humans "get info via presentations" entails that
> presentation is not information.
>

I have never claimed that you can identify information with 
presentation. But I have flirted with the idea that information 
supervenes on presentation. But never mind this for now. 

The fact is that in the end, information gets communicated via 
presentation. The website maker must have a pretty good idea of what the 
*default* effect of his elements are going to be. By and large. The 
makers of HTML and browsers and devices also have a pretty good idea 
about *default* presentational matters without which the very creation 
of HTML elements would have been impossible. 


> Daniele

-- 
dorayme

wrote:

> On Thu, 19 Mar 2009 21:40:57 +0000,
> real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:
> 
> 
> >But they can still distinguish between information and presentation, or
> >should be able to. 
> Au contraire.  
> 
> Since all information must be presented to be available to cognition*,
> one CANNOT distinguish  information from presentation.  What one CAN
> do is to _differentiate between presentations_ and have a response to
> and/or opinion and/or preference  about the contribution (+ve/-ve) the
> presentation makes to the ease of assimilating the information.

Of course one can distinguish.

The information is: "The building is on fire. You must leave
immediately."

The presentation is: shouting, urgent voices.

The mere fact that one can have different presentation of the same
information means that they must be distinguishable. If they weren't,
then affecting the mode of presentation would affect the semantic
content.

> *Information can EXIST without presentation, but - as dorayme rightly
> observes - it is not available to humans (or indeed more generally to
> cognition of any sentient creature) except when presented in a manner
> that the recipient can utilise.  

Unless they have what Kant calls intellectual intuition (such as he
speculates hypothetical beings such as angels might have), but that -
even if it's a more interesting and important question than the use of
HTML - is hardly the point here.
 
The point is that HTML offers mechanisms for the informative structuring
and labelling of content, and if we are going to use it to its best
effect, then we should exploit those mechanisms to the fullest extent
possible, and not allow questions of "how it looks" to affect how we use
it.

Daniele

In article 
<1iwveaq.p1x6occfacmlN%real-not-anti-spam-address@apple-juice.co.uk>,
 real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

"The mere fact that one can have different presentation of the same
information means that they must be distinguishable. If they weren't,
then affecting the mode of presentation would affect the semantic
content."

But note that it does not follow that the information has no inherent 
presentational attributes, it may be that there is a set of core 
intrinsic presentations the members of which are the simplest 
appearances that human would recognise as the essential information. 
That is at least as good as the unexplained object - 'the information' - 
you refer to.  

Just because a number of presentations are said to share things in 
common, that does not explain the nature of what it is they share. It 
may very well be some set of appearances. If anyone does not like the 
set I proposed, how about the set consisting of all present and all 
future *default* styles? At least this last is not something anyone can 
fail to understand.

-- 
dorayme

In article ,
 Bergamot  wrote:
> 
> ...is just a list of events. Table markup is illogical ...

Let's step back from the particulars of the OP's case and look at this 
business of some information being *just* this or that.

We want to let people know, in some context of a website page, which are 
earth's planets and their relative sizes in terms as simple as "is 
bigger than". This last is a general description of the information I 
want to impart. The more complete one that contains all the information 
could come from any of a number of quite different sentences, bits of 
sentences, a speech haltingly made, not particularly grammatical, in no 
particular order. 

Here is the information in a more ordered way, smallest to biggest:  
Mercury, Mars, Venus, Earth, Neptune, Uranus, Jupiter.

How is this "information" to be marked up? Here are the four likeliest 
candidates.

1. A UL under a heading that says: "Our Sun's planets from small to big, 
starting with small" 

2. An OL with or without bullet numbers, with a heading like in 1 above 
or a different heading or lead paragraph to set context and simply the 
inclusion of the sun as last item - everyone knows the sun is way more 
massive than all and that alone provides the clue to the order. 

3. A table element with a heading and/or a summary.

4. A paragraph element with text that reads "Our sun's planets, smallest 
to biggest: Mercury, Mars, Venus, Earth, Neptune, Uranus, Jupiter"

The information has no *one inner structure*, at least not one that is 
best reflected by any particular markup. There is no identifiable 
contextless inner structure to the information. There are a number of 
ways a website maker can receive this information and there are a few 
HTML ways that would suit the information. 

Pretty well the same remarks go if the case is one giving info of 
planets and actual sizes. It might seem that the real inner structure  
is tabular and needs a table. This is a mistake. It has no inner 
structure. A simple UL would capture the info, each list item reading 
like

Mercury - 2439 km radius 

An OL too would be fine, this would perhaps say more than merely show 
the relative sizes (but there is a big question mark about this)

A table would be fine enough too, either as a single column or better, a 
two col job.

Picking over raw information to display the microfinest details in it 
might be ok, it might not be ok. It is a matter of context and 
convenience to all overall. You cannot judge these things in advance. 
There is no given structured information. It is we who give info 
structure in a context.

-- 
dorayme