Layout inconsistent between modern browsers

[Philip Herlihy]

I've been working on this:

http://www.stjamesbaroque.com/

... and it's driven me potty for hours. What's there is a working
draft, published because we need the information out there. Needs a lot
of polishing - and the code will need a lot of simplification before I
leave it alone.

One problem has me completely foxed: With the browser expanded so that
all four can fit on one row, in IE9 and Firefox 12 the layout is just as
I'd expect it, but in Chrome 18.0.1025.168 m and Safari 5.1.5 the "gig"
DIVs aren't level - they form an ascending "staircase" from left to
right.

I thought I'd fixed this when I hit on setting {overflow: hidden} on
these divs, but half the browsers I test on don't like my code.

Any ideas?

--

Phil, London

[tlvp]

No idea, but let me report what it looks like in FF 3.6.28, with a viewport
maybe 950 px wide (later: 1280 px wide; and last: BB PB):

Centered across the top, a 1" deep black banner with garish red "St. James
Baroque" emblazoned across its central 400 px worth; beneath that, a 670 px
wide centered photo of the dozen musicians; and then, beneath that, the
first two "gig" rectangles, that for Saturday 19th May about 100 px below
the bottom edge of the musicians group photo and on the left, and that for
Monday 21st May maybe only 30 px below the bottom edge of the musicians
group photo and on the right (with about 150 px of brown background off to
the left of the former and to the right of the latter (what you might call
two steps of "an ascending "staircase" from left to right" on a field of
brown).

Beneath those two, two more 'steps of "an ascending "staircase" from left
to right" ', but with slightly shorter "riser"; and finally, a centered
Founder/Leader/Telephone block.

If I drag the viewport as wide open as my LCD allows, 1280 px, I can't get
more than three of your "gig" blocks to line up in a row, and they again
form a staircase ascending from left to right, with the 4th centered under
the 2nd, and the Founder/Leader/Telephone block centered beneath that.

How broad a screen do you design your pages to be seen on, anyway :-) ?

For giggles, I opened the page on a Blackberry Playbook. Looked for all the
world like a 200 px/inch version of what I described as the initial 950 px
wide view in Firefox 3, basically with two NE-stepped gig-blocks under the
musicians, and the remaining two gig-blocks NE-stepped under the first two,
Looks good there, almost as if the NE-stepping were intentional :-) .

BTW, each individual "gig" block just fits comfortably within the upper and
lower boundaries of the non-maximized Playbook browser viewport :-) .

HTH. What causes the staircase effect, and how to cure it, I leave to
others to diagnose and prescribe :-) . Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

[tlvp]

On Sun, 6 May 2012 00:20:55 -0400, tlvp wrote:

> On Sun, 6 May 2012 02:55:47 +0100, Philip Herlihy wrote:
>
>> I've been working on this:
>>
>> http://www.stjamesbaroque.com/
>>

>> Any ideas?
>
> No idea, but let me report ...

... what validator.w3.org says:

> Line 28, Column 10: end tag for element "P" which is not open
> </p>

I doubt that can be at the root of your difficulties, but, fwiw, ... :-) .

[tlvp]

On Sun, 6 May 2012 02:55:47 +0100, Philip Herlihy wrote:

> I've been working on this:
>
> http://www.stjamesbaroque.com/
>
> ... and it's driven me potty for hours.

What can be the role of the four invocations of the no-content DIV

| <div class="dark-screen"></div>

? Can that be doing much of anything at all?

(Maybe if I knew how the class "dark-screen" were defined in the CSS I'd
not need to ask, but ... :-) .) Cheers, -- tlvp

[tlvp]

On Sun, 6 May 2012 02:55:47 +0100, Philip Herlihy wrote:

> I've been working on this:
>
> http://www.stjamesbaroque.com/

Another thought. If the line

| <p>"Aus der Tiefen ruhe ich, Herr, su dir",</p>

refers to the De Profundis (out of the depths, O Lord, I call to You),
then the German's garbled: not "ruhe" but "rufe", not "su" but "zu".
And "dir" probably capitalized out of respect for the Lord: "Dir".

(Bitte schön :-) .) Cheers, -- tlvp

[dorayme]

In article <MPG.2a0fea7cf...@news.demon.co.uk>,

Forget about the overflow for a moment, browsers do differ in the more
basic way they treat elements displayed as inline-block.

Take a look at

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

in different browsers.

Many browsers, including FF and Safari do have this in common: they
take the bottom of the text as sitting on the inline line. If we had
no border to say otherwise, it would be as if the they were just
blocks of text of different heights and this borderless view is what
is common.

Not even Firefox lays them out so their tops or bottoms line up. Opera
ignores the author set height and takes notice instead of the actual
and natural text height and borders around this.

Adding overflow to all this is playing with fire.

My advice to you is not to set a height, a great big point about
inline-blocking is the way the element then sits on the line and line
up at the bottom. You will get into bother trying to line up both top
and bottom. There are other ways to do this. You can set heights on
floats and use overflow and get results that are more consistent. You
can set widths and height in em units too that may be better. It is
almost always bad news setting px width heights for boxes that contain
text.

(And, btw, the markup in those boxes is not very good, I assume you
inherited it)

--
dorayme

[Ben C]

It looks like Chrome is the one that's rendering it correctly (according
to the spec as opposed to according to what you wanted :)

If you just put vertical-align: top (or bottom) on those div.gig
inline-blocks it should sort it out.

By default most things are vertical-align: baseline, which means the
text should line up. But inline-blocks can contain all manner of other
nested blocks, tables, etc., and several lines of text. So where is the
baseline of the inline block as a whole? Well, the spec says:

"The baseline of an 'inline-block' is the baseline of its last line
box in the normal flow, unless it has either no in-flow line boxes
or if its 'overflow' property has a computed value other than
'visible', in which case the baseline is the bottom margin edge."

(http://www.w3.org/TR/CSS2/visudet.html#line-height, right at the
bottom).

Chrome is faithfully lining up "2pm", "SW1X 8SH" and "Part of the
Lufthansa Festival of Baroque Music", which are the last line boxes in
the normal flow in each of the first three divs.

[dorayme]

In article <slrnjqdv24....@bowser.marioworld>,

Ben C <spam...@spam.eggs> wrote:

> On 2012-05-06, Philip Herlihy <bounc...@you.com> wrote:
> > I've been working on this:
> >
> > http://www.stjamesbaroque.com/
> >
> > ... and it's driven me potty for hours. What's there is a working
> > draft, published because we need the information out there. Needs a lot
> > of polishing - and the code will need a lot of simplification before I
> > leave it alone.
> >
> > One problem has me completely foxed: With the browser expanded so that
> > all four can fit on one row, in IE9 and Firefox 12 the layout is just as
> > I'd expect it, but in Chrome 18.0.1025.168 m and Safari 5.1.5 the "gig"
> > DIVs aren't level - they form an ascending "staircase" from left to
> > right.
> >
> > I thought I'd fixed this when I hit on setting {overflow: hidden} on
> > these divs, but half the browsers I test on don't like my code.
> >
> > Any ideas?
>
> It looks like Chrome is the one that's rendering it correctly (according
> to the spec as opposed to according to what you wanted :)
>

FF, Chrome, Opera and no doubt some other good browsers line up the
bottom of the last bit of text to a baseline (on which there could be
text outside the inline-block boxes). They all follow the specs as you
quote below. Here is a basic layout with assigned widths and heights.

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

But Safari and iCab (presumably same basic engine) decide differently.
They have a complicated, crazier algorithm: "If there is a stated
height, let the bottom of this height be on the baseline, but if the
text inside does not overflow, use the last bit of text as baseline
and let the box itself (as represented by its borders) drop below the
base".

The differences among browsers has to do with how they react to
variables of the stated fixed height, stated border and even overflow
if this is added to the mix.

Opera ignores the stated height as far as the border is concerned, it
draws the border around the actual height of the text *if* the text
overflows the author's stated height.

> If you just put vertical-align: top (or bottom) on those div.gig
> inline-blocks it should sort it out.
>

Perhaps it is not the best to use an inline-block if one is going to
style it to behave more like a regular float. An inline block really
comes into its own where no height is put on it and the browser
calculates to line the boxes up nicely. When they wrap, they don't
snag like floats. But if they are of fixed height, floats don't snag
either so the inline block has no advantage on this score. Not that
you can't use it, but perhaps the more generally feared float is more
consistent between browsers!

> By default most things are vertical-align: baseline, which means the
> text should line up. But inline-blocks can contain all manner of other
> nested blocks, tables, etc., and several lines of text. So where is the
> baseline of the inline block as a whole? Well, the spec says:
>
> "The baseline of an 'inline-block' is the baseline of its last line
> box in the normal flow, unless it has either no in-flow line boxes
> or if its 'overflow' property has a computed value other than
> 'visible', in which case the baseline is the bottom margin edge."
>
> (http://www.w3.org/TR/CSS2/visudet.html#line-height, right at the
> bottom).
>
> Chrome is faithfully lining up "2pm", "SW1X 8SH" and "Part of the
> Lufthansa Festival of Baroque Music", which are the last line boxes in
> the normal flow in each of the first three divs.

--
dorayme

[Ben C]

On 2012-05-07, dorayme <dor...@optusnet.com.au> wrote:
[...]

> FF, Chrome, Opera and no doubt some other good browsers line up the
> bottom of the last bit of text to a baseline (on which there could be
> text outside the inline-block boxes). They all follow the specs as you
> quote below. Here is a basic layout with assigned widths and heights.
>
><http://dorayme.netweaver.com.au/inlineBoxes.html>

Actually it's unexpected (and as far as I know not justified by the
spec) that they align to the last line of text even if it overflows.
Overflow is generally just something visual, not something that affects
the position of any element (although some values of overflow have the
side-effect of making a block formatting context, and that does affect
positions of things).

> But Safari and iCab (presumably same basic engine) decide differently.

The version of Konqueror I have (a bit more like Safari) does it how I
would have done it-- uses the last line of text that doesn't overflow.

> They have a complicated, crazier algorithm: "If there is a stated
> height, let the bottom of this height be on the baseline, but if the
> text inside does not overflow, use the last bit of text as baseline
> and let the box itself (as represented by its borders) drop below the
> base".

That is a bit crazy. Work in progress I think since Safari, Chrome and
Konqueror are all based on Webkit.

[...]

> Opera ignores the stated height as far as the border is concerned, it
> draws the border around the actual height of the text *if* the text
> overflows the author's stated height.

My Opera (11.61) isn't doing that.

>> If you just put vertical-align: top (or bottom) on those div.gig
>> inline-blocks it should sort it out.
>>
>
> Perhaps it is not the best to use an inline-block if one is going to
> style it to behave more like a regular float.

But don't we only think of those as regular floats because for years
inline-block wasn't even supported by Firefox and therefore off-limits?
If everything had worked from the start, we might never have used floats
for that sort of thing.

> An inline block really comes into its own where no height is put on it
> and the browser calculates to line the boxes up nicely.

If you're using it for buttons then that's what you want (<button> is an
inline-block in the default stylesheet usually), but for everything
else, you probably want to change its vertical-align to something other
than baseline, especially if it contains a whole subtree of elements.

> When they wrap, they don't snag like floats. But if they are of fixed
> height, floats don't snag either so the inline block has no advantage
> on this score. Not that you can't use it, but perhaps the more
> generally feared float is more consistent between browsers!

Yes, that might be right. I tend to stick to floats unless there's a
reason not to.

[dorayme]

In article <slrnjqf1uj....@bowser.marioworld>,

Ben C <spam...@spam.eggs> wrote:

> On 2012-05-07, dorayme <dor...@optusnet.com.au> wrote:
> [...]
> > FF, Chrome, Opera and no doubt some other good browsers line up the
> > bottom of the last bit of text to a baseline (on which there could be
> > text outside the inline-block boxes). They all follow the specs as you
> > quote below. Here is a basic layout with assigned widths and heights.
> >
> ><http://dorayme.netweaver.com.au/inlineBoxes.html>
>
> Actually it's unexpected (and as far as I know not justified by the
> spec) that they align to the last line of text even if it overflows.
> Overflow is generally just something visual, not something that affects
> the position of any element (although some values of overflow have the
> side-effect of making a block formatting context, and that does affect
> positions of things).
>

There is no overflow set (it being simply the default visible) in my
above url. And I would have expected what FF and Opera does in regard
to baseline line up from:

"The baseline of an 'inline-block' is the
baseline of its last line box in the normal
flow, unless it has either no in-flow line
boxes or if its 'overflow' property has a
computed value other than 'visible', in which
case the baseline is the bottom margin edge."

The last line box in the normal flow suggests to me the last line of
the text full stop (as when overflow is 'visible').

We must distinguish the mass of text (or content) from the box as
defined by the height and width. The text is royalty, and the last
line of text is king. The above spec is about where the king places
himself. Only Safari and Chrome (on the limited number of browsers I
have seen) seem not to honour it and are more impressed by the author
dictated border (as I have described and we have agreed is a bit crazy)

> > But Safari and iCab (presumably same basic engine) decide differently.
>
> The version of Konqueror I have (a bit more like Safari) does it how I
> would have done it-- uses the last line of text that doesn't overflow.
>
> > They have a complicated, crazier algorithm: "If there is a stated
> > height, let the bottom of this height be on the baseline, but if the
> > text inside does not overflow, use the last bit of text as baseline
> > and let the box itself (as represented by its borders) drop below the
> > base".
>
> That is a bit crazy. Work in progress I think since Safari, Chrome and
> Konqueror are all based on Webkit.
>
> [...]
> > Opera ignores the stated height as far as the border is concerned, it
> > draws the border around the actual height of the text *if* the text
> > overflows the author's stated height.
>
> My Opera (11.61) isn't doing that.
>

Opera 11.61 (and 62 as it happens) in Windows XP does not do it either
and is like yours.

But what they all do in Opera (from what I have seen and including
your version) is interpret the spec as saying the baseline is the
bottom of the last line of text. That is the most important thing to
them. As it seems to be with some if not all other browsers. Not with
Safari and iCab though.

But even with those that do follow the above spec as I see it, they
simply make up their own mind about how to place the border! Each
version sticks a finger out in the wind when the very first person
uses it for the very first time and that version then decides on a
policy on this and then sticks with it, it seemingly transmitting all
over the world according to Rupert Sheldrake's wacky theory of morphic
resonance.

What Opera does with the border is different in different versions. On
my Mac, as I say. On Windows XP (and yours), the border obeys the
author height and is way above the overflowing text. The
none-overflowing boxes, where the text easily falls short of the 100px
set height, the base of the inline block is the last bit of text, the
border dips way below. They *all* do this in the versions of Opera I
have seen. They all stagger in appearance (no neat line up), including
Safari and iCab and Chrome.

> >> If you just put vertical-align: top (or bottom) on those div.gig
> >> inline-blocks it should sort it out.
> >>
> >
> > Perhaps it is not the best to use an inline-block if one is going to
> > style it to behave more like a regular float.
>
> But don't we only think of those as regular floats because for years
> inline-block wasn't even supported by Firefox and therefore off-limits?
> If everything had worked from the start, we might never have used floats
> for that sort of thing.
>

And not supported by IE. But best not to talk about older IE and its
support for anything. At least it was honest about inline-blocks, it
shunned them. With floats it just played cruel tricks - all day long!

> > An inline block really comes into its own where no height is put on it
> > and the browser calculates to line the boxes up nicely.
>
> If you're using it for buttons then that's what you want (<button> is an
> inline-block in the default stylesheet usually), but for everything
> else, you probably want to change its vertical-align to something other
> than baseline, especially if it contains a whole subtree of elements.
>

Not sure about this, I often turn to them for pictures and captions,
and their magic is that they do line up at the bottom. But it is a
matter of taste I guess, some might like them hanging like monkeys
from the top. But seems to me the eye and brain is happier to see
bottom caption neatly in lines... Their real magic is that they don't
snag and they calculate their heights, it just seems wrong to impose
heights on them for most purposes. They get along nicely. They are
simpler and have less hangups than floats. Have you ever seen an
inline-block in a psychiatrist's waiting room? But, boy o boy, have I
had a few conversations with floats while waiting. I say, if we start
monkeying with them too much and making them out like floats...
well... what can we expect? <g>

> > When they wrap, they don't snag like floats. But if they are of fixed
> > height, floats don't snag either so the inline block has no advantage
> > on this score. Not that you can't use it, but perhaps the more
> > generally feared float is more consistent between browsers!
>
> Yes, that might be right. I tend to stick to floats unless there's a
> reason not to.

--
dorayme

[Ben C]

I was wrong that overflow is not expected to have an effect on layout
here-- as the text you quoted says, overflow of non-visible means use
the bottom of the box itself.

Anything else would be mad-- you'd have the situation where if you
scrolled the text in one inline box, all the others would have to move!

But when it says, "its last line box", couldn't that be taken to mean
the last line _inside_ the box? Maybe not.

> We must distinguish the mass of text (or content) from the box as
> defined by the height and width. The text is royalty, and the last
> line of text is king.

Yes, I think you're right.

> The above spec is about where the king places himself. Only Safari and
> Chrome (on the limited number of browsers I have seen) seem not to
> honour it and are more impressed by the author dictated border (as I
> have described and we have agreed is a bit crazy)

I think vertical-align: baseline on inline boxes with more than one line
of text in them is a bit crazy, and very rarely something anyone would
want. But they have to specify it somehow.

[...]

>> If you're using it for buttons then that's what you want (<button> is an
>> inline-block in the default stylesheet usually), but for everything
>> else, you probably want to change its vertical-align to something other
>> than baseline, especially if it contains a whole subtree of elements.
>>
>
> Not sure about this, I often turn to them for pictures and captions,
> and their magic is that they do line up at the bottom.

Yes I can see that would be useful.

[Dr J R Stockton]

In comp.infosystems.www.authoring.stylesheets message <MPG.2a0fea7cfce06
ce29...@news.demon.co.uk>, Sun, 6 May 2012 02:55:47, Philip Herlihy
<bounc...@you.com> posted:

>I've been working on this:
>
>http://www.stjamesbaroque.com/

Fails in Firefox with Zoom Text Only wound up, the bottom text box is
OK, but the four panels lose text.

Cause : setting the height of div.gig in px units. Give the height in
em or ex, and it will grow to suit the increased text line height,
without allowing for line-wrap. Give the width likewise, and it will
grow fatter to include your lines. And set the size of the image, in em
or ex, to a shade bigger than the text box.

<http://www.merlyn.demon.co.uk/www-use1#ZTO> may help.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Philip Herlihy]

In article <8wl036romi85.1h...@40tude.net>,
mPiOsUcB...@att.net says...

Thanks for this detailed report. First comment is that you're using
Firefox 3, and I'm using Firefox 12, so I'd expect some differences!

Your careful description did bring to mind some HSS I came across. HSS
(short for Heraldic Style Sheets, otherwise called Blazon) describes the
Royal Coat of Arms (http://bit.ly/3XjzyL) thus:

"Quarterly, first and fourth Gules three lions passant gardant in pale
Or armed and langued Azure (for England), second quarter Or a lion
rampant within a double tressure flory-counter-flory Gules (for
Scotland), third quarter Azure a harp Or stringed Argent (for Ireland),
the whole surrounded by the Garter; for a Crest, upon the Royal helm the
imperial crown Proper, thereon a lion statant gardant Or imperially
crowned Proper; Mantling Or and ermine; for Supporters, dexter a lion
rampant gardant Or crowned as the Crest, sinister a unicorn Argent
armed, crined and unguled Proper, gorged with a coronet Or composed of
crosses patée and fleurs de lis a chain affixed thereto passing between
the forelegs and reflexed over the back also Or. Motto 'Dieu et mon
Droit' in the compartment below the shield, with the Union rose,
shamrock and thistle engrafted on the same stem."

.. though why they didn't just post a screenshot of a Photoshop Comp I
can't imagine.

Apart from some differences in the dimensions, it sounds as if your FF3
is rendering my site very much like Chrome. Here's a screenshot, with
Chrome at 1596px (as measured by the excellent Jruler Pro):
http://sdrv.ms/JTRmf9

You ask what sizes I'm designing for - ideally the site should look
coherent or at least intelligible at any common screen size, fully
expanded. I'm using a monitor of width 1920 and one customer
(architect) has one of 2400px. I don't expect many people to be using
monitors of 800px width, but when your monitor is wide enough so that
side-by-side windows becomes the norm then folk like us need to have our
sites look acceptable at fairly narrow widths. I aim in recent sites
(this one is a regular rework) to get down to well under 500px before
you really have to scroll horizontally to read stuff, and having
recently learned a little (here!) about HTML5 media queries I'll
eventually start aiming lower than that.

Interesting that an old version of FF has the same problem as Safari and
Chrome. IE9 and FF12 are fine.

--

Phil, London

[Philip Herlihy]

In article <1uzuwvqc8g85b.1...@40tude.net>,
mPiOsUcB...@att.net says...

>
> On Sun, 6 May 2012 00:20:55 -0400, tlvp wrote:
>
> > On Sun, 6 May 2012 02:55:47 +0100, Philip Herlihy wrote:
> >
> >> I've been working on this:
> >>
> >> http://www.stjamesbaroque.com/
> >>
> >> Any ideas?
> >
> > No idea, but let me report ...
>
> ... what validator.w3.org says:
>
> > Line 28, Column 10: end tag for element "P" which is not open
> > </p>
>
> I doubt that can be at the root of your difficulties, but, fwiw, ... :-) .
>

Thanks - I'll check this out. It was about 2:30 am when I gave up and
howled for help, and I should have checked a validator first.

--

Phil, London

[Philip Herlihy]

In article <1ox8kle4sq294.1...@40tude.net>,
mPiOsUcB...@att.net says...

This was me trying to solve the problem of having my text readable when
overlaid on a background-image with a lot of contrast. The dark-screen
div is a couple of z-index ticks behind the content, the same size as
the div, and simply intervenes a layer of small PNG files I created in
Photoshop to be semi-transparent, to darken the background. I used
Alpha blending of two layers, and I believe that in browsers which can't
handle Alpha blending this layer will obscure the background, but I do
rather choose to neglect old browsers as policy. The effect works
fairly well for St. Giles, Cripplegate (27 June) but dulls the otherwise
rather lovely gold detail on the screen for 24 May (actually a shot from
St. Paul's Knightsbridge rather than the Abbey, but no matter). If I'm
going to lark around with background images which are photos I'll need
to figure out how to keep the text readable, and this was one
experiment.

Dorayme (a respected contributor here) pointed out that FF can use this
extension:
http://chrispederick.com/work/web-developer/
... and also 'Firebug' to allow you to view the CSS affecting an element
on a page, and all sorts of other useful dodges. IE9 also has something
similar built-in, and so far I rather prefer the IE9 facility - tap F12
to bring up the "Developer Tools"; click the arrow on the toolbar and
then click an element on the main page to view both HTML and CSS.
Brill... The Javascript debugger in this toolset is very good too.

--

Phil, London

[Philip Herlihy]

In article <1du2n2hrlf9zi$.jd2a4ky5...@40tude.net>,
mPiOsUcB...@att.net says...

Thanks - I'll check with my client!

--

Phil, London

[Philip Herlihy]

In article <1uzuwvqc8g85b.1...@40tude.net>,
mPiOsUcB...@att.net says...
>

When I opened Dreamweaver to check that I hadn't left the HTML comments
in the <STYLE> block on a page before squirting it through the
validator, it spotted this very problem and corrected it automatically.
Whoops!

Validates ok. I notice the Validator gives a neat summary of the CSS,
so that might be a simple way of examining someone else's markup without
having to fool around with Developer Tools.

--

Phil, London

[Philip Herlihy]

In article <dorayme-F9713F...@news.albasani.net>,
dor...@optusnet.com.au says...

>
> In article <MPG.2a0fea7cf...@news.demon.co.uk>,
> Philip Herlihy <bounc...@you.com> wrote:
>
> > I've been working on this:
> >
> > http://www.stjamesbaroque.com/
> >
> > ... and it's driven me potty for hours. What's there is a working
> > draft, published because we need the information out there. Needs a lot
> > of polishing - and the code will need a lot of simplification before I
> > leave it alone.
> >
> > One problem has me completely foxed: With the browser expanded so that
> > all four can fit on one row, in IE9 and Firefox 12 the layout is just as
> > I'd expect it, but in Chrome 18.0.1025.168 m and Safari 5.1.5 the "gig"
> > DIVs aren't level - they form an ascending "staircase" from left to
> > right.
> >
> > I thought I'd fixed this when I hit on setting {overflow: hidden} on
> > these divs, but half the browsers I test on don't like my code.
> >
> > Any ideas?
>
> Forget about the overflow for a moment, browsers do differ in the more
> basic way they treat elements displayed as inline-block.
>
> Take a look at
>
> <http://dorayme.netweaver.com.au/inlineBoxes.html>
>
> in different browsers.

Thanks - that's a really clear demo.

>
> Many browsers, including FF and Safari do have this in common: they
> take the bottom of the text as sitting on the inline line. If we had
> no border to say otherwise, it would be as if the they were just
> blocks of text of different heights and this borderless view is what
> is common.
>
> Not even Firefox lays them out so their tops or bottoms line up. Opera
> ignores the author set height and takes notice instead of the actual
> and natural text height and borders around this.
>
> Adding overflow to all this is playing with fire.
>
> My advice to you is not to set a height, a great big point about
> inline-blocking is the way the element then sits on the line and line
> up at the bottom. You will get into bother trying to line up both top
> and bottom. There are other ways to do this. You can set heights on
> floats and use overflow and get results that are more consistent. You
> can set widths and height in em units too that may be better. It is
> almost always bad news setting px width heights for boxes that contain
> text.
>

As often happens, there's a tension between getting a page to
accommodate varying amounts of text flexibly (and also user-initiated
changes in font-size) and the wish to impose a structure on the purely
visual side of things. In this case I really wouldn't want the panels
to be different sizes, so I thought I'd found a suitable size which
allowed a little room for error in font-size while not leaving any of
them looking under-filled. I'll have to experiment more and see what I
can come up with.

> (And, btw, the markup in those boxes is not very good, I assume you
> inherited it)

Sadly, not. I was under pressure to get something up (I'd promised open
publication of a first draft) while nodding off in the early hours, so
it was fairly crudely trowelled-in. However, it's much more useful to
know what "is not very good" than just have that evaluation!

I've never felt very good at CSS - it always seems a fight. You might
be interested/appalled to see earlier versions of this site, kept
together under:
http://stjamesbaroque.com/archive/
When there are no concerts coming up it reverts to the "Essential" page.

--

Phil, London

[Philip Herlihy]

In article <slrnjqdv24....@bowser.marioworld>,
spam...@spam.eggs says...

Thanks - that's really clear, and useful. I don't know how I missed the
fact that the bottom line of text in each panel was neatly lined up!

--

Phil, London

[Philip Herlihy]

In article <dorayme-E696BB...@news.albasani.net>,
dor...@optusnet.com.au says...

This does make sense - but I moved to inline-blocks after having trouble
getting floated elements to centre. There ought to be a "float:middle"!

Given that the inline-block is sensitive to the dimensions of its
contents, perhaps the problem is that I'm using background-image instead
of having the image as a true child element of the block, and then using
relative positioning to superimpose the text on top of it?

>
> > By default most things are vertical-align: baseline, which means the
> > text should line up. But inline-blocks can contain all manner of other
> > nested blocks, tables, etc., and several lines of text. So where is the
> > baseline of the inline block as a whole? Well, the spec says:
> >
> > "The baseline of an 'inline-block' is the baseline of its last line
> > box in the normal flow, unless it has either no in-flow line boxes
> > or if its 'overflow' property has a computed value other than
> > 'visible', in which case the baseline is the bottom margin edge."
> >
> > (http://www.w3.org/TR/CSS2/visudet.html#line-height, right at the
> > bottom).
> >
> > Chrome is faithfully lining up "2pm", "SW1X 8SH" and "Part of the
> > Lufthansa Festival of Baroque Music", which are the last line boxes in
> > the normal flow in each of the first three divs.



--

Phil, London

[Philip Herlihy]

In article <slrnjqf1uj....@bowser.marioworld>,
spam...@spam.eggs says...

>
> On 2012-05-07, dorayme <dor...@optusnet.com.au> wrote:
> [...]
> > FF, Chrome, Opera and no doubt some other good browsers line up the
> > bottom of the last bit of text to a baseline (on which there could be
> > text outside the inline-block boxes). They all follow the specs as you
> > quote below. Here is a basic layout with assigned widths and heights.
> >
> ><http://dorayme.netweaver.com.au/inlineBoxes.html>
>
> Actually it's unexpected (and as far as I know not justified by the
> spec) that they align to the last line of text even if it overflows.
> Overflow is generally just something visual, not something that affects
> the position of any element (although some values of overflow have the
> side-effect of making a block formatting context, and that does affect
> positions of things).
>
> > But Safari and iCab (presumably same basic engine) decide differently.
>
> The version of Konqueror I have (a bit more like Safari) does it how I
> would have done it-- uses the last line of text that doesn't overflow.
>
> > They have a complicated, crazier algorithm: "If there is a stated
> > height, let the bottom of this height be on the baseline, but if the
> > text inside does not overflow, use the last bit of text as baseline
> > and let the box itself (as represented by its borders) drop below the
> > base".
>
> That is a bit crazy. Work in progress I think since Safari, Chrome and
> Konqueror are all based on Webkit.

I read that Dreamweaver CS6 is now using "the latest version of Webkit"
for its "Design" view, so that might mean a big improvement. Worth a
trial run for me, anyway. (I guess that's a bit more relevant to my
other thread: "Which Editor?".)

>
> [...]
> > Opera ignores the stated height as far as the border is concerned, it
> > draws the border around the actual height of the text *if* the text
> > overflows the author's stated height.
>
> My Opera (11.61) isn't doing that.
>
> >> If you just put vertical-align: top (or bottom) on those div.gig
> >> inline-blocks it should sort it out.
> >>
> >
> > Perhaps it is not the best to use an inline-block if one is going to
> > style it to behave more like a regular float.
>
> But don't we only think of those as regular floats because for years
> inline-block wasn't even supported by Firefox and therefore off-limits?
> If everything had worked from the start, we might never have used floats
> for that sort of thing.
>
> > An inline block really comes into its own where no height is put on it
> > and the browser calculates to line the boxes up nicely.
>
> If you're using it for buttons then that's what you want (<button> is an
> inline-block in the default stylesheet usually), but for everything
> else, you probably want to change its vertical-align to something other
> than baseline, especially if it contains a whole subtree of elements.

I'll certainly try this, as the inline-block lends itself better than
Floats to having the content centred.

>
> > When they wrap, they don't snag like floats. But if they are of fixed
> > height, floats don't snag either so the inline block has no advantage
> > on this score. Not that you can't use it, but perhaps the more
> > generally feared float is more consistent between browsers!
>
> Yes, that might be right. I tend to stick to floats unless there's a
> reason not to.

Thanks Ben!

--

Phil, London

[Philip Herlihy]

In article <8F7wIkd8...@invalid.uk.co.demon.merlyn.invalid>,
repl...@merlyn.demon.co.uk.not.invalid says...

>
> In comp.infosystems.www.authoring.stylesheets message <MPG.2a0fea7cfce06
> ce29...@news.demon.co.uk>, Sun, 6 May 2012 02:55:47, Philip Herlihy
> <bounc...@you.com> posted:
>
> >I've been working on this:
> >
> >http://www.stjamesbaroque.com/
>
> Fails in Firefox with Zoom Text Only wound up, the bottom text box is
> OK, but the four panels lose text.
>
> Cause : setting the height of div.gig in px units. Give the height in
> em or ex, and it will grow to suit the increased text line height,
> without allowing for line-wrap. Give the width likewise, and it will
> grow fatter to include your lines. And set the size of the image, in em
> or ex, to a shade bigger than the text box.
>
> <http://www.merlyn.demon.co.uk/www-use1#ZTO> may help.

Thanks - interesting. By the way, the URL is:
http://www.merlyn.demon.co.uk/www-use1.htm#ZTO

I note that the default zoom behaviour is to zoom the page, not just the
text, and I remember thinking that older browsers (IE7?) which zoomed
only the text were a pain (at least in my view). My difficulty with
this is in maintaining the proportions of a site, and in figuring out
how many ems high a 450px image should be. It's tempting to fall back
on the notion that a user who's savvy enough to change his/her browser
from default settings ought to be savvy enough to cope with undesirable
consequences, but I'll take on board what you've pointed out and will
experiment at some point. I do use ems rather than px whenever images
are *not* involved. Maybe with some thought the containers could be
specified in ems anyway.

--

Phil, London

[David Stone]

In article <MPG.2a134af8a...@news.demon.co.uk>,
Philip Herlihy <bounc...@you.com> wrote:
[snip]

>
> Thanks - interesting. By the way, the URL is:
> http://www.merlyn.demon.co.uk/www-use1.htm#ZTO
>
> I note that the default zoom behaviour is to zoom the page, not just the
> text, and I remember thinking that older browsers (IE7?) which zoomed
> only the text were a pain (at least in my view). My difficulty with
> this is in maintaining the proportions of a site, and in figuring out
> how many ems high a 450px image should be.

Stick the image in an appropriate container sized in ems, and set the
image height or width to 100%? I've done that with images in a side-bar
div sized in ems and used as a navigation pane, and it works well as
long as you start with images larger than you need. Just remember to
specify only the height OR the width, not both!

As you note, however, the default in Firefox (and possibly Safari?) is
now to zoom the whole page and, since most users aren't even aware of
this option (much less zoom text only), the point may be moot.

[dorayme]

In article <MPG.2a133b33f...@news.demon.co.uk>,

Philip Herlihy <bounc...@you.com> wrote:

> In article <dorayme-F9713F...@news.albasani.net>,
> dor...@optusnet.com.au says...
> >

...

> > (And, btw, the markup in those boxes is not very good, I assume you
> > inherited it)
>
> Sadly, not. I was under pressure to get something up (I'd promised open
> publication of a first draft) while nodding off in the early hours, so
> it was fairly crudely trowelled-in. However, it's much more useful to
> know what "is not very good" than just have that evaluation!
>

Ah, OK, I did not go into it as I thought at the time it was a real
btw (not that relevant to the problem you were concerned about). Don't
I already talk too much? <g>

Contents of one of the boxes:

<h2>Monday 21st May 2012</h2>
<h1>Handel's Israel in Egypt</h1>
<p>A pan European broadcast for the BBC</p>
<p>with</p>
<p>BBC Singers</p>
<p>St James's Baroque</p>
<p>conducted by</p>
<p>David Hill</p>
<p>7:30 pm</p>
<p>live from St. Paul's Knightsbridge</p>
<p>32a Wilton Place,</p>
<p>London</p>
<p>SW1X 8SH</p>

This is too far from good semantic markup to make even those of us who
are a bit practical about it comfortable. "with" is not a paragraph.
It is not good practice to use HTML elements just because they are
styled by the (hidden) default stylesheet to look the way you want it
to. It is best to have a go at using markup appropriate to the meaning
and then later to style things.

The concept of semantic markup has been a great talking point in
HTML/CSS circles for quite a while, the idea of separating the content
from the style, there is a great deal of iLiterature on the subject.
It is still an interesting topic in all sorts of ways. Attitudes have
changed about it - some say soured - over time with the realization
that HTML and browsers have not quite lived up to the needs of
authors. But that does not mean there is no worth to the distinction.

--
dorayme

[dorayme]

In article <MPG.2a133e6e8...@news.demon.co.uk>,

Philip Herlihy <bounc...@you.com> wrote:

> In article <dorayme-E696BB...@news.albasani.net>,
> dor...@optusnet.com.au says...
> >

...

> > Perhaps it is not the best to use an inline-block if one is going to
> > style it to behave more like a regular float. An inline block really
> > comes into its own where no height is put on it and the browser
> > calculates to line the boxes up nicely. When they wrap, they don't
> > snag like floats. But if they are of fixed height, floats don't snag
> > either so the inline block has no advantage on this score. Not that
> > you can't use it, but perhaps the more generally feared float is more
> > consistent between browsers!
> >
>
> This does make sense - but I moved to inline-blocks after having trouble
> getting floated elements to centre. There ought to be a "float:middle"!
>

Yes, you have put your finger on an advantage to the inline block that
I thought of later and meant to come back to. While not a big fan of
centring things in general, I can see it is sometimes nice. In your
case, there is no big problem in centring two or three blocks as
floats, not that you need absolutely to use floats. But I agree it
gets trickier if you have a lot of floats. But there is light on this
too which I will mention in a minute.

Since you have fixed width and heights, the bare bones for three, is

<div class="wrapper">
<div></div>
<div></div>
<div></div>
</div>

styled with

.wrapper {

margin: auto;
width: 300px;
}

.wrapper div {
float: left;
color: black;
background: white;
width: 100px;
height: 100px;
}


You can add margins and fiddle about for nicer still.

But this is not a nice big general solution! It requires some
attention to the case in hand. I mention it out of interest.

Now, as it happens, years back, I wanted blocks of floats to be
centred. I did not want the pictures of my daughter's wedding to be
lurking to the left or the right. Bootnic came riding in to the rescue
with some javascript. The point of this, Phillip, is that if js is
off, the sky does not fall in, my daughter still keeps loving her
husband even when I turn js off.

<http://dorayme.netweaver.com.au/thumbnailGalleryWithShortCaptions/thum
bPortraitGallery7.html>

Note how the mass of floats are centred.

--
dorayme

[Philip Herlihy]

In article <no.email-F0AB71...@news.eternal-september.org>,
no.e...@domain.invalid says...

>
> In article <MPG.2a134af8a...@news.demon.co.uk>,
> Philip Herlihy <bounc...@you.com> wrote:
> [snip]
> >
> > Thanks - interesting. By the way, the URL is:
> > http://www.merlyn.demon.co.uk/www-use1.htm#ZTO
> >
> > I note that the default zoom behaviour is to zoom the page, not just the
> > text, and I remember thinking that older browsers (IE7?) which zoomed
> > only the text were a pain (at least in my view). My difficulty with
> > this is in maintaining the proportions of a site, and in figuring out
> > how many ems high a 450px image should be.
>
> Stick the image in an appropriate container sized in ems, and set the
> image height or width to 100%? I've done that with images in a side-bar
> div sized in ems and used as a navigation pane, and it works well as
> long as you start with images larger than you need. Just remember to
> specify only the height OR the width, not both!
>

Interesting suggestion - thanks!

> As you note, however, the default in Firefox (and possibly Safari?) is
> now to zoom the whole page and, since most users aren't even aware of
> this option (much less zoom text only), the point may be moot.

Just so.

--

Phil, London

[Philip Herlihy]

In article <dorayme-3723DB...@news.albasani.net>,
dor...@optusnet.com.au says...

Everything you say is true. At the time I was writing this I needed the
fastest way to get something on the page which would render predictably.
It worked, and it is probably simpler than a more semantically correct
expression of what I wanted. Simple is good.

All I wanted here was to choose how the text fell on separate lines. I
guess I could have made it a list, but while the address could be seen
as a list, the "with" isn't semantically part of that. I could have
used <BR> tags, with appropriate padding, line-height, margin on the
encompassing <P>. I could have put it all in a table. But any of these
would have heavily increased the markup-to-content ratio, which to me
seems a bad thing.

As I've commented before recently, there's a tension between the eye you
use when reading code to see if it makes any meta-grammatical (?) sense,
and the eye you'd use if you were laying out a document for print. I'm
certainly open to criticism, and I've learned that your criticism is
both constructive and insightful, so I'd certainly be interested to know
how you'd mark up that text, given that I wanted it laid out as it
appears in the browser now. And it's true that I had meant to go back
and look at it again! Looking at it now, I'd imagine that the most
appropriate markup would be a table, unless I create a custom block
element for these "lines". If I did that, I guess it would look quite a
lot like a <P>.

div.like-a-paragraph-but-not-a-paragraph {
display: block;
text-align: center; /*mis-spelling of "centre" grates every time!*/
}
<DIV class="like-a-paragraph-but-not-a-paragraph">with</DIV>

:-)

Worth thinking about, certainly.

(Thanks)

--

Phil, London

[Philip Herlihy]

In article <dorayme-9F1CDC...@news.albasani.net>,
dor...@optusnet.com.au says...

You've been good enough to show me this before, and it's clearly an
elegant solution. My own prejudice, though, means I'm uneasy at using
105 lines of Javascript to do what I'd *expect* (if I could only pin
them down!) half-a-dozen lines of CSS to achieve. Javascript is also
procedural, whereas HTML and CSS are declarative, and my own take on the
semantic side of things here is that the JS solution provides the
browser with the elements and then micro-manages the browser into
pushing them where you want them (even though it does so by manipulating
the CSS in real time). It seems to me that a purely HTML/CSS solution
*ought* to be possible. Purists say that if you want a link to appear
in a new window you should use JS to achieve that, rather than the HTML
target="_blank" option. I can see the point of that argument, but my
software engineering background has left me with the view that every
line of code is potentially both a source of errors and a maintenance
burden, so all things being equal the shortest code is the best. I
managed to get inline-blocks to behave themselves here:
http://www.walthamsoft.com/foef/walks12.htm
.. as you may recall - you helped me with this too!
I'd like to experiment a bit with either vertical-align (as suggested by
Ben) or by moving my panel images from the background to the foreground,
and using relative positioning to put the text where I want it.

--

Phil, London

[tlvp]

Frankly, I'd be curious -- indeed, I *am* curious -- what makes you shy
away from single <BR> tags in favor of </P><P> pairs for line breaks :-) .

Cheers, -- tlvp

[tlvp]

On Wed, 9 May 2012 14:35:24 +0100, Philip Herlihy wrote:

> text-align: center; /*mis-spelling of "centre" grates every time!*/

Does seeing "enter" affect you the same way :-) ? Cheers, -- tlvp

[Dr J R Stockton]

In comp.infosystems.www.authoring.stylesheets message <MPG.2a134af8a9d3c
1229...@news.demon.co.uk>, Tue, 8 May 2012 16:25:45, Philip Herlihy
<bounc...@you.com> posted:

>
>Thanks - interesting. By the way, the URL is:
>http://www.merlyn.demon.co.uk/www-use1.htm#ZTO

OOps! Apologies.

>I note that the default zoom behaviour is to zoom the page, not just the
>text, and I remember thinking that older browsers (IE7?) which zoomed
>only the text were a pain (at least in my view). My difficulty with
>this is in maintaining the proportions of a site, and in figuring out
>how many ems high a 450px image should be. It's tempting to fall back
>on the notion that a user who's savvy enough to change his/her browser
>from default settings ought to be savvy enough to cope with undesirable
>consequences, but I'll take on board what you've pointed out and will
>experiment at some point. I do use ems rather than px whenever images
>are *not* involved. Maybe with some thought the containers could be
>specified in ems anyway.

Take a look at
<http://www.merlyn.demon.co.uk/euler327.htm#ATP>, paragraph 3, sentence
2, "Greek beta occurs in two forms, ?/old-beta and ?, assumed equivalent
and both shown here as ?.", where here you see "old-beta".

File old-beta.png is a screen-grab of a PDF image of E.327 from the
Euler Archive - I suspect the printer-man did not have old-beta in his
fonts, since no two seem quite alike in the PDF and all are slightly
furry.

The point is that its size, set by
<img src="graphics/old-beta.png" style="width:0.57em;" alt="old-beta">,
always matches that of the surrounding HTML characters. So if you style
the widths of the containers in ems, and the height of the image to
match, then text which fits at one Zoom should fit in all Zooms.

Feel free, but not obliged, to read the rest of the page.

[dorayme]

In article <MPG.2a1482f6f...@news.demon.co.uk>,

Philip Herlihy <bounc...@you.com> wrote:

> In article <dorayme-3723DB...@news.albasani.net>,
> dor...@optusnet.com.au says...
> >
> > In article <MPG.2a133b33f...@news.demon.co.uk>,
> > Philip Herlihy <bounc...@you.com> wrote:
> >
> > > In article <dorayme-F9713F...@news.albasani.net>,
> > > dor...@optusnet.com.au says...
> > > >
...
> >

> > Contents of one of the boxes:
> >
> > <h2>Monday 21st May 2012</h2>
> > <h1>Handel's Israel in Egypt</h1>
> > <p>A pan European broadcast for the BBC</p>
> > <p>with</p>
> > <p>BBC Singers</p>

> > etc

> >
> > This is too far from good semantic markup to make even those of us who
> > are a bit practical about it comfortable. "with" is not a paragraph.
> > It is not good practice to use HTML elements just because they are
> > styled by the (hidden) default stylesheet to look the way you want it
> > to. It is best to have a go at using markup appropriate to the meaning
> > and then later to style things.
> >
> > The concept of semantic markup has been a great talking point in
> > HTML/CSS circles for quite a while, the idea of separating the content
> > from the style, there is a great deal of iLiterature on the subject.
> > It is still an interesting topic in all sorts of ways. Attitudes have
> > changed about it - some say soured - over time with the realization
> > that HTML and browsers have not quite lived up to the needs of
> > authors. But that does not mean there is no worth to the distinction.
>

...

> All I wanted here was to choose how the text fell on separate lines. I
> guess I could have made it a list,

As you recognise below, that would be a bit like jumping from the
frying pan into the fire.

> but while the address could be seen
> as a list, the "with" isn't semantically part of that. I could have
> used <BR> tags, with appropriate padding, line-height, margin on the
> encompassing <P>. I could have put it all in a table.

A table would really be jumping into worse. An HTML table, properly
used, is not just a semantically empty presentational thing. It is for
relating lists, showing relationships between items both horizontally
and vertically. The message you are conveying is rightly a paragraph.
You are not showing relationships between words or phrases as you
would when you list in a table adjectives, nouns etc.

In no sense, literally, could "with" be a table content that could
have some sort of sensible TH heading to classify it, not that you
would always need to actually have THs.

> But any of these
> would have heavily increased the markup-to-content ratio, which to me
> seems a bad thing.
>

Well, I don't mean to be argumentative but first, making it a list -
we have agreed this would be bad - would not "massively" increase the
number of tags. Instead of the <p>s, you would have <li>s, there would
be just the extra two <ul>s. But about these two extra, you could do
without the DIV containers and directly style the ULs as inline boxes
(or floats).

Second, more markup is not a bad in itself if overall there are
economies (economies of management, economies of understanding,
economies of cross browser and cross modality user experiences (to
someone hearing rather than seeing, it might be important that it be
an appropriate element, the voice might read a list differently to the
way it might read a paragraph and it might need the cue of the element
tags.

To be fair, you might be meaning by markup (I have just realised), css
styling as well. Even so, CSS is mostly and mainly about styling that
is not essential to the communication of information. So it is ipso
facto, scrotum datum, hey already, deeply unnecessary if you truly
want simple above all else. <g>

> As I've commented before recently, there's a tension between the eye you
> use when reading code to see if it makes any meta-grammatical (?) sense,
> and the eye you'd use if you were laying out a document for print. I'm
> certainly open to criticism, and I've learned that your criticism is
> both constructive and insightful, so I'd certainly be interested to know
> how you'd mark up that text, given that I wanted it laid out as it
> appears in the browser now.

Sure. One paragraph element and <br>s within, as you mention and
reject, would be the natural way for saying things like "A pan
European broadcast for the BBC with BBC Singers..."

As for the headings, I would feel uncomfortable having so many H1s
(one in each box), they are more to tell user what the main subject of
the page is about. I guess you can have an H2 before an H1 but this
also would make me feel a little uncomfortable (for a date)?

The truth is that I would likely take a different overall path and
make all the information in all the boxes into a proper HTML table,
bringing all together, having meaningful THs (which might include
dates) etc. And I would likely be pleased with how that would look
because it would be functional and useful and I would style it to be
pleasant enough afterwards. But if you decide on the look you want for
your page beforehand, you tend to think rather differently.

--
dorayme

[dorayme]

In article <MPG.2a1488ab7...@news.demon.co.uk>,

> procedural, whereas HTML and CSS are declarative, and my own take on the
> semantic side of things here is that the JS solution provides the
> browser with the elements and then micro-manages the browser into
> pushing them where you want them (even though it does so by manipulating
> the CSS in real time). It seems to me that a purely HTML/CSS solution
> *ought* to be possible.

I did offer one above and it is fine for just a few boxes. As for js,
there is no harm if the feature is not essential to the page and if
there are no pure HTML/CSS solutions.

> Purists say that if you want a link to appear
> in a new window you should use JS to achieve that, rather than the HTML
> target="_blank" option.

Well, we can safely ignore such purists surely? It is the same in
moral matters, there needs to be real reasons behind standards of
practice, not just posings.

--
dorayme

[tlvp]

On Thu, 10 May 2012 09:24:17 +1000, dorayme wrote:

> In no sense, literally, could "with" be a table content that could
> have some sort of sensible TH heading to classify it,

TH content for "with" : "conjunction" :-) ?

[dorayme]

In article <vwjwuxtvr5js$.tlnj8etp...@40tude.net>,

tlvp <mPiOsUcB...@att.net> wrote:

> On Thu, 10 May 2012 09:24:17 +1000, dorayme wrote:
>
> > In no sense, literally, could "with" be a table content that could
> > have some sort of sensible TH heading to classify it,
>
> TH content for "with" : "conjunction" :-) ?

No. This is a deep misunderstanding of the context.

There is a distinction between talk about the world and talk about
talk about the world. In the latter case the objects under discussion
are linguistic objects like words and phrases and sentences, in the
other, the objects talked about are objects like rocks and cats. Both
objects can be referred to in table cells, a table can be about all
sorts of things. But in the case of the OP, the words are about
non-linguistic objects and events.

If I say "sugar" in a cell and give the price of sugar in the adjacent
cell I am not talking about the word "sugar". If I say something comes
with something else, the "with" is not part of the scenery being
tabled, it a means to describe the objects being talked about.

--
dorayme

[Philip Herlihy]

In article <43ex4lnvor8d.12...@40tude.net>,
mPiOsUcB...@att.net says...

Probably a vague (and inaccurate) sense that <BR> is somehow deprecated,
just as people go to uneccessary lengths to shun tables when they do
have their place. If you simply shower <BR>s into a <P> you may need to
adjust line-height and padding to get the desired effect - an effect I
did achieve by using <P>s, of course.

I must say that I don't really buy the idea that a <P> has to be a real
paragraph - which must surely have a verb. I think of a <P> as "some
text".

--

Phil, London

[Philip Herlihy]

In article <1qsbp2hho799m$.qe5fvebn...@40tude.net>,
mPiOsUcB...@att.net says...

>
> On Wed, 9 May 2012 14:35:24 +0100, Philip Herlihy wrote:
>
> > text-align: center; /*mis-spelling of "centre" grates every time!*/
>
> Does seeing "enter" affect you the same way :-) ?

I think you know the answer to that one :-)

--

Phil, London

[Philip Herlihy]

In article <aYRpv2EX...@invalid.uk.co.demon.merlyn.invalid>,
repl...@merlyn.demon.co.uk.not.invalid says...

Interesting illustration of the underlying point, and possibly the best
possible illustration. However, the number of users who are aware that
browsers can zoom is surely small, and the number of those who would
even be aware of the possibility of turning off the default zoom
behaviour will be smaller still. Nevertheless, I take your point that
this is a technique worth remembering, although I do have some
misgivings about what happens to the quality of images when browsers
expand and contract them.

--

Phil, London

[Philip Herlihy]

In article <dorayme-1AF609...@news.albasani.net>,

A table is also much harder to lay out in a way which will cope readily
with browsers of greatly varying widths.

> > But any of these
> > would have heavily increased the markup-to-content ratio, which to me
> > seems a bad thing.
> >
>
> Well, I don't mean to be argumentative but first, making it a list -
> we have agreed this would be bad - would not "massively" increase the
> number of tags. Instead of the <p>s, you would have <li>s, there would
> be just the extra two <ul>s. But about these two extra, you could do
> without the DIV containers and directly style the ULs as inline boxes
> (or floats).
>
> Second, more markup is not a bad in itself if overall there are
> economies (economies of management, economies of understanding,

A cherished belief, indeed: I've often chosen to write longer code where
the shorter version would have been harder for the human reader to
follow, even though conciseness has other benefits.

> economies of cross browser and cross modality user experiences (to
> someone hearing rather than seeing, it might be important that it be
> an appropriate element, the voice might read a list differently to the
> way it might read a paragraph and it might need the cue of the element
> tags.

I guess it's not likely that text-to-speech engines will have become so
nuanced by 27th June this year, when my content becomes obsolete!

>
> To be fair, you might be meaning by markup (I have just realised), css
> styling as well. Even so, CSS is mostly and mainly about styling that
> is not essential to the communication of information. So it is ipso
> facto, scrotum datum, hey already, deeply unnecessary if you truly
> want simple above all else. <g>
>
> > As I've commented before recently, there's a tension between the eye you
> > use when reading code to see if it makes any meta-grammatical (?) sense,
> > and the eye you'd use if you were laying out a document for print. I'm
> > certainly open to criticism, and I've learned that your criticism is
> > both constructive and insightful, so I'd certainly be interested to know
> > how you'd mark up that text, given that I wanted it laid out as it
> > appears in the browser now.
>
> Sure. One paragraph element and <br>s within, as you mention and
> reject, would be the natural way for saying things like "A pan
> European broadcast for the BBC with BBC Singers..."
>
> As for the headings, I would feel uncomfortable having so many H1s
> (one in each box), they are more to tell user what the main subject of
> the page is about. I guess you can have an H2 before an H1 but this
> also would make me feel a little uncomfortable (for a date)?

Yes, I acknowledge that I'm neglecting the weight that (e.g.) search
engines might give to the level and sequencing of <Hx> tags, and simply
relying on browser default styling to give me a little more size here,
and a little less there. It works, and it works reliably. And how many
visitors, whether robot or human, will be sensitive to the choice of
tags? For this job, at this time, I only really care how browsers will
render them.

The key to this side-discussion is whether my slicing of what could be
seen as a single semantic element (The concert description) is proper.
I think it depends on how you see the <P> tag. If there is a real
reason that it should only be used to signal the beginning of a body of
content having both cohesion and semantic independence then my
fracturing of it is to be scowled at. On the other hand, if you see a
<P> as shorthand for (loosely) "some text" then it's entirely proper.
The suggestion of using <BR> is an interesting one in this context, as
it's an HTML tag whose function is solely stylistic, so maybe it belongs
more properly in CSS somehow.

>
> The truth is that I would likely take a different overall path and
> make all the information in all the boxes into a proper HTML table,
> bringing all together, having meaningful THs (which might include
> dates) etc. And I would likely be pleased with how that would look
> because it would be functional and useful and I would style it to be
> pleasant enough afterwards. But if you decide on the look you want for
> your page beforehand, you tend to think rather differently.

I wouldn't want a table. I'd be sorry to lose the adaptability to
variations in browser width, and in any event, I rather see the concerts
as independent entities rather than components of a series. So even
semantically that wouldn't fit my conception of the page.

Yes, I did conceive the layout before figuring out how I might achieve
it - but if you take my point in the previous paragraph, even that was
semantically driven.

--

Phil, London

[Philip Herlihy]

In article <dorayme-976D78...@news.albasani.net>,

In that we can wholeheartedly agree. I was told off at the weekend for
eating asparagus with a fork. Whether that is indeed a violation of
convention in fine dining circles, or a delusion in the mind of my host,
I don't happen to give a fig (however eaten).

It's always interesting to re-consider guiding principles of the sort
we've been discussing, and I do share your respect for them - I am,
after all the sort of person who puts semi-colons in text messages. We
merely seem to differ a little in the weight we give to them in various
situations.

--

Phil, London

[Jonathan N. Little]

Philip Herlihy wrote:
> text-align: center; /*mis-spelling of "centre" grates every time!*/

Must be because you are too close to France ;-)

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[Philip Herlihy]

In article <slrnjqdv24....@bowser.marioworld>,
spam...@spam.eggs says...
>

> On 2012-05-06, Philip Herlihy <bounc...@you.com> wrote:

> > I've been working on this:
> >
> > http://www.stjamesbaroque.com/
> >

> > ... and it's driven me potty for hours. What's there is a working
> > draft, published because we need the information out there. Needs a lot
> > of polishing - and the code will need a lot of simplification before I
> > leave it alone.
> >
> > One problem has me completely foxed: With the browser expanded so that
> > all four can fit on one row, in IE9 and Firefox 12 the layout is just as
> > I'd expect it, but in Chrome 18.0.1025.168 m and Safari 5.1.5 the "gig"
> > DIVs aren't level - they form an ascending "staircase" from left to
> > right.
> >
> > I thought I'd fixed this when I hit on setting {overflow: hidden} on
> > these divs, but half the browsers I test on don't like my code.
> >
> > Any ideas?
>
> It looks like Chrome is the one that's rendering it correctly (according
> to the spec as opposed to according to what you wanted :)
>

> If you just put vertical-align: top (or bottom) on those div.gig
> inline-blocks it should sort it out.
>

> By default most things are vertical-align: baseline, which means the
> text should line up. But inline-blocks can contain all manner of other
> nested blocks, tables, etc., and several lines of text. So where is the
> baseline of the inline block as a whole? Well, the spec says:
>
> "The baseline of an 'inline-block' is the baseline of its last line
> box in the normal flow, unless it has either no in-flow line boxes
> or if its 'overflow' property has a computed value other than
> 'visible', in which case the baseline is the bottom margin edge."
>
> (http://www.w3.org/TR/CSS2/visudet.html#line-height, right at the
> bottom).
>
> Chrome is faithfully lining up "2pm", "SW1X 8SH" and "Part of the
> Lufthansa Festival of Baroque Music", which are the last line boxes in
> the normal flow in each of the first three divs.

Exactly right. Simply putting div.gig {vertical-align:top} solved the
problem instantly.

For anyone interested, the fixed version is here:
http://stjamesbaroque.com/
... and I've put a comparison here:
http://stjamesbaroque.com/index-old.htm
... which recreates the former situation by including div.gig {vertical-
align: inherit} in a style section at the top of the HTML.

[dorayme]

In article <MPG.2a15e0973...@news.demon.co.uk>,

Philip Herlihy <bounc...@you.com> wrote:

> Yes, I acknowledge that I'm neglecting the weight that (e.g.) search
> engines might give to the level and sequencing of <Hx> tags, and simply
> relying on browser default styling to give me a little more size here,
> and a little less there. It works, and it works reliably. And how many
> visitors, whether robot or human, will be sensitive to the choice of
> tags? For this job, at this time, I only really care how browsers will
> render them.
>

There is a view some people have - deep down and paying no lip service
to various ideals - concerned only with the visual presentation. This
view sees HTML elements as having no particular semantics at all.
Elements are for the look they give. In spite of that they have
default styles to convey the various categories that literate people
are used to. Why bother now to even think of a P as "some text" (as
you imply you do below) when this element can as easily contain just a
picture, or, if it comes to this, nothing at all, to be used as a
space (people actually do this quite often!)? Why not just think it is
a DIV, a semantically empty container that happens, for reasons of
historical curiosity, to have a certain style that is (at least a bit)
common to different browsers?

> The key to this side-discussion is whether my slicing of what could be
> seen as a single semantic element (The concert description) is proper.
> I think it depends on how you see the <P> tag. If there is a real
> reason that it should only be used to signal the beginning of a body of
> content having both cohesion and semantic independence then my
> fracturing of it is to be scowled at. On the other hand, if you see a
> <P> as shorthand for (loosely) "some text" then it's entirely proper.
> The suggestion of using <BR> is an interesting one in this context, as
> it's an HTML tag whose function is solely stylistic, so maybe it belongs
> more properly in CSS somehow.

If its function was to go over to CSS, it would be a bit cumbersome
because then the HTML would have to carry signals for where the style
was to apply. If the distinction between webpage content and styling
was to be really sharp and pure, there should be a convenient way to
break text up in CSS. In truth, the distinction cannot bear that much
weight!

It is perfectly OK to use BRs to create line breaks in blocks of text,
often done in presentations of poems. In fact, in poems, the break is
an essential part of the communication, so maybe here it is not
*merely* stylistic. It would not be the same poem with all the text
continuous.

In the case where you really want text to break up stylistically,
where it would not lose its meaning if you did not, most of us would
just use the BR combined with a big CSS line-height setting for the P.

--
dorayme

[tlvp]

On Thu, 10 May 2012 14:54:20 +0100, Philip Herlihy wrote:

>> ... I *am* curious -- what makes you shy

>> away from single <BR> tags in favor of </P><P> pairs for line breaks :-) .
>
> Probably a vague (and inaccurate) sense that <BR> is somehow deprecated,

I go exactly the other way -- I prefer <BR> because it does *not* carry
with it all the styling conventions that a <P> carries with it (if I don't
explicitly override them with either inline or CSS style imprecations.

> ... just as people go to uneccessary lengths to shun tables when they do

> have their place. If you simply shower <BR>s into a <P> you may need to
> adjust line-height and padding to get the desired effect - an effect I
> did achieve by using <P>s, of course.
>
> I must say that I don't really buy the idea that a <P> has to be a real
> paragraph - which must surely have a verb. I think of a <P> as "some
> text".

In effect, "P is for Phrase", not "P is for Paragraph", eh? But then you
could just as well use <span> or <div> for "some text" too, couldntcha?
Or even &#13;&#10; for a CR LF invocation of a new line :-) (browsers do
honor that just as much as printers do, don't they :-) ?)?

[tlvp]

On Thu, 10 May 2012 14:54:51 +0100, Philip Herlihy wrote or quoted:

>>> text-align: center; /*mis-spelling of "centre" grates every time!*/
>>
>> Does seeing "enter" affect you the same way :-) ?
>
> I think you know the answer to that one :-)

Why do you keep me so on tentrehooks :-) ?
--
Avant de repondre, jeter la poubelle, SVP, -- tlvp

[tlvp]

Ah, but if there are alternatives to "with', and they are "without", "in",
"upon", "beside", "along", "under", "near to", "far from", and the like,
as might be the case for such foods as coffee, cream, milk, donuts,
icecream, apple pie, whipped cream, and the like, one might well offer a

table with 4-celled rows of the form
Item_1 Conjunction Item_2 price (row with TH data)
coffee with cream $1.25 (rows with TD data)
icecream upon applepie $2.50
lemon beside hot tea $ 1.10
donut without anything $0.50
bagel under creamcheese $3.25
...

N'est-ce pas :-) ? Cheers, -- tlvp

[tlvp]

On Thu, 10 May 2012 16:18:13 +0100, Philip Herlihy wrote:

>> Chrome is faithfully lining up "2pm", "SW1X 8SH" and "Part of the
>> Lufthansa Festival of Baroque Music", which are the last line boxes in
>> the normal flow in each of the first three divs.
>
> Exactly right. Simply putting div.gig {vertical-align:top} solved the
> problem instantly.
>
> For anyone interested, the fixed version is here:
> http://stjamesbaroque.com/
> ...

> Thanks Ben!

How much more lovely that looks! Nice! Cheers, -- tlvp

[Jukka K. Korpela]

Under Re: Layout inconsistent between modern browsers

2012-05-11 7:48, tlvp wrote:

> On Thu, 10 May 2012 14:54:20 +0100, Philip Herlihy wrote:
>
>>> ... I *am* curious -- what makes you shy
>>> away from single <BR> tags in favor of </P><P> pairs for line breaks :-) .
>>
>> Probably a vague (and inaccurate) sense that <BR> is somehow deprecated,

In the old times, I would have reminded that the discussion has got very
off-topic. Now that Usenet is really dying, I just change the Subject
line and make some ObCSS noises.

First, <BR> has not been deprecated in any way. HTML5 drafts (which do
not use the word "deprecated") say that <BR> should only be used when
the data itself contains a line break. This is a bit obscure but I would
say that a postal address or a poem is inherently divided into lines, so
<BR> would be OK there.

But wrapping each line in a <DIV> element is another possibility, with
the potentially important benefit that it makes each line an element, so
that you can set styles on it (e.g., specifying that if a line does not
fit on one visual line within the available width, it will wrap so that
continuation lines are indented).

So there's really not much use for <BR>, except (as mostly a stylistic
device) within a paragraph e.g. when you wish to display a formula on a
line of its own and centered. You can't use <DIV> inside <P>. Splitting
a logical paragraph to three elements is possible of course, and maybe
not that sinful. The HTML <P> does not *really* mean paragraph. What it
really means is a block of text that will by default be rendered with
margins above and below, and possibly with a short pause before and
after in aural presentation.

> I go exactly the other way -- I prefer<BR> because it does *not* carry
> with it all the styling conventions that a<P> carries with it (if I don't
> explicitly override them with either inline or CSS style imprecations.

The only "styling conventions" in the sense of default rendering
(browser style sheets, to say it in CSS) that I know of are what I
mentioned above. For visual presentation, you just set margin: 0 on
those <P> elements that should not have empty space before and after.
But the other option is to use <DIV>.

According to my HTML Anarchists Cookbook, or manifesto,
http://www.cs.tut.fi/~jkorpela/pragmatic-html.html8
you use <P> for a block of text when you want the margins by default,
<DIV> when you don't. And you can then add fine tuning in CSS, like very
small top and bottom margins for <DIV> if you like.

From the CSS perspective, the main reason for not using <BR> is that it
does not create an element. Another reason is that there is no reliable
cross-browser way to kill the effect of <BR> using CSS. But more
importantly, if you have

xxx <BR> yyy zzzz <BR> xxx

then you can't style yyy zzzz without adding markup, like

xxx <BR> <SPAN CLASS=FOO> yyy zzzz </SPAN> <BR> xxx

and then you might just as well simply use

xxx <DIV CLASS=FOO> yyy zzzz </DIV> xxx

(if you are not inside <P>).

> In effect, "P is for Phrase", not "P is for Paragraph", eh?

No, P is for "Plock", a variant of "Block". :-) More exactly, the HTML
"paragraph" concept really derives from word processors, rather than
traditional typography.

> But then you
> could just as well use <span> or <div> for "some text" too, couldntcha?

Yes, surely. But the pragmatic way is to use the markup that gives the
most reasonable default rendering (i.e. without a style sheet). It would
be odd to choose <P> just because "it's *logically* a paragraph" and
then immediately attack that <P> with CSS weapons to prevent it from
looking like a "paragraph".

> Or even &#13;&#10; for a CR LF invocation of a new line :-) (browsers do
> honor that just as much as printers do, don't they :-) ?)?

That wasn't serious at all, was it? &#13;&#10; is simply a way to insert
CR LF in an odd way, and by the specifications it will be taken as yet
another whitespace, equivalent to a space character.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[dorayme]

In article <15v95krdfymbe.uks6krfxlmmn$.d...@40tude.net>,

tlvp <mPiOsUcB...@att.net> wrote:

> On Thu, 10 May 2012 14:48:22 +1000, dorayme wrote:
>
> > In article <vwjwuxtvr5js$.tlnj8etp...@40tude.net>,
> > tlvp <mPiOsUcB...@att.net> wrote:
> >
> >> On Thu, 10 May 2012 09:24:17 +1000, dorayme wrote:
> >>
> >>> In no sense, literally, could "with" be a table content that could
> >>> have some sort of sensible TH heading to classify it,
> >>
> >> TH content for "with" : "conjunction" :-) ?
> >
> > No. This is a deep misunderstanding of the context.
> >
> > There is a distinction between talk about the world and talk about
> > talk about the world. In the latter case the objects under discussion
> > are linguistic objects like words and phrases and sentences, in the
> > other, the objects talked about are objects like rocks and cats. Both
> > objects can be referred to in table cells, a table can be about all
> > sorts of things. But in the case of the OP, the words are about
> > non-linguistic objects and events.
> >
> > If I say "sugar" in a cell and give the price of sugar in the adjacent
> > cell I am not talking about the word "sugar". If I say something comes
> > with something else, the "with" is not part of the scenery being
> > tabled, it a means to describe the objects being talked about.
>
> Ah, but if there are alternatives to "with', and they are "without", "in",

If you are pricing coffee with cream and coffee without cream, then
the TH "Coffee with cream" might be appropriate to a column of prices
for coffee with cream of different sizes, another column might be
prices of coffee without cream. There is no particular logical sense
in having cells filled with "with"s and others with "without"s. And
there is less sense in the context of telling people about Abbott and
Costello to have an "and" in some cell.

But all this is possibly terribly old fashioned, nowadays it seems
anything goes, do anything you want really.

--
dorayme

[tlvp]

Mmmph! As a kid I got taken to Austria by my folks one summer; there, in
the mountaineers' travel huts, one could refresh oneself with a cup or a
mug of hot tea, with any of a great number of "Beilagen", served in an
astonishing variety of ways that a naive American might have supposed
shouldn't make much difference to the price -- but difference they made!
With lemon (a) in the cup before hot water was added; (b) added to the cup
after hot water and tea bag were put in place; (c) laid alongside cup for
customer to add, 'ad lib', to tea (or even to chew on in parallel with
tea); likewise for sugar; a similarly large choice of slightly different
options for rum; and assorted options for accompanying pastries, filled, or
topped, or just accompanied, with/by ice cream and/or whipped cream.

The nature of the conjunctive preposition linking add-on to tea played a
crucial role in both the presentation and the fee for the tea. That is, the
nature of the "with" certainly *was* "part of the scenery being tabled".

Also certainly qualifies as old-fashioned, wouldn't you say :-) ?

Oh, well, let's bury this hatchet, let bygones be bygones, and live
amicably ever after again, shall we? Thanks; cheers, and a nice steaming
glass of Tee mit Ausländer Rhum und Honig :-) , -- tlvp

[tlvp]

On Fri, 11 May 2012 08:19:10 +0300, Jukka K. Korpela commented on:

>> Or even &#13;&#10; for a CR LF invocation of a new line :-) (browsers do
>> honor that just as much as printers do, don't they :-) ?)?
>
> That wasn't serious at all, was it? &#13;&#10; is simply a way to insert
> CR LF in an odd way, and by the specifications it will be taken as yet
> another whitespace, equivalent to a space character.

It was half in jest, half serious. I brought it up at all because I was
shocked, recently, to see that Microsoft, in its infinite je-ne-sais-quoi,
saw fit to include a &#13;&#10; in the HTML it had rendered a Word document
of interest to me into. (You think US State Department renditions are bad?
You haven't seen a bad rendition until you've seen an HTML document as
rendered by Word out of a poor, naive, innocent Word document! Our common
friend the validator, poor overworked thing, can easily find 1,000 points
of invalidity in a 50,000 byte Word-generated HTML file, so badly does Word
deform its victims.)

I'm sure you're right that a mere unprotected &#13;&#10; will be taken as
nothing more harmful than innocuous white space. But surround it within
opening and closing PRE tags, and I believe it *will* cause a proper visual
line-feed in what a browser shows you -- at least under the right
circumstances. But surely a <BR> would be shorter and easier :-) .

As always, your thoughts here are grist for my mill, and I shall try to
incorporate them, suitably leavened, in my future loaves of web-bread.

So thank you, and cheers, -- tlvp

[dorayme]

In article <1r44l9l6oi2ty.1...@40tude.net>,

tlvp <mPiOsUcB...@att.net> wrote:

> Mmmph! As a kid I got taken to Austria by my folks one summer; there, in
> the mountaineers' travel huts, one could refresh oneself with a cup or a
> mug of hot tea, with any of a great number of "Beilagen", served in an
> astonishing variety of ways that a naive American might have supposed
> shouldn't make much difference to the price -- but difference they made!
> With lemon (a) in the cup before hot water was added; (b) added to the cup
> after hot water and tea bag were put in place; (c) laid alongside cup for
> customer to add, 'ad lib', to tea (or even to chew on in parallel with
> tea); likewise for sugar; a similarly large choice of slightly different
> options for rum; and assorted options for accompanying pastries, filled, or
> topped, or just accompanied, with/by ice cream and/or whipped cream.
>
> The nature of the conjunctive preposition linking add-on to tea played a
> crucial role in both the presentation and the fee for the tea. That is, the
> nature of the "with" certainly *was* "part of the scenery being tabled".
>
> Also certainly qualifies as old-fashioned, wouldn't you say :-) ?
>
> Oh, well, let's bury this hatchet, let bygones be bygones, and live
> amicably ever after again, shall we?

No, I am sorry. This cannot rest! You cannot just decide that
something ends when it boils and bubbles under the surface. The
linguistic object "with" had absolutely nothing to do with the price
of the fish you were served. None at all. Now we can bury a hatchet
into the real thing being talked about, a kipper and a nice cup of
tea.

--
dorayme

[tlvp]

On Fri, 11 May 2012 21:31:47 +1000, dorayme wrote:

> Now we can bury a hatchet
> into the real thing being talked about, a kipper and a nice cup of
> tea.

Sold! Kipper for you, and a little Shavian ghotipue for me :-) .

Cheers, -- tvp

[Andreas Prilop]

On Fri, 11 May 2012, Jukka K. Korpela wrote:

> So there's really not much use for <BR>,

<BR style="display: none">

is sometimes useful when CSS is off.

--
In memoriam Alan J. Flavell
http://www.alanflavell.org.uk/charset/

[dorayme]

In article
<Pine.LNX.4.64.12...@zen.rrzn.uni-hannover.de>,

Andreas Prilop <prilo...@trashmail.net> wrote:

> On Fri, 11 May 2012, Jukka K. Korpela wrote:
>
> > So there's really not much use for <BR>,
>
> <BR style="display: none">
>
> is sometimes useful when CSS is off.

Like ordering coffee with cream in case there is no cream available.

--
dorayme

[Evertjan.]

Savoy, 1944:
Blck or white, Sir?
White.
Sorry, sir, no milk, Sir.


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Andreas Prilop]

On Sun, 13 May 2012, dorayme wrote:

>> <BR style="display: none">
>> is sometimes useful when CSS is off.
>
> Like ordering coffee with cream in case there is no cream available.

I try to explain in more detail so that you can understand, too.

<BR style="display: none"> gives a linebreak for text browsers,
search engines, and browsers with CSS turned off by the reader.

With CSS-enabled browsers, the corresponding formatting is done
through style sheets.

So you can have the best of two worlds.

--
¹ superscript 1 ¼ fraction 1/4 Ð D stroke Þ Thorn
² superscript 2 ½ fraction 1/2 ð d stroke þ thorn
³ superscript 3 ¾ fraction 3/4 Ý Y acute
× multiply sign ¦ broken bar ý y acute

[dorayme]

In article
<Pine.LNX.4.64.12...@zen.rrzn.uni-hannover.de>,
Andreas Prilop <prilo...@trashmail.net> wrote:

> On Sun, 13 May 2012, dorayme wrote:
>
> >> <BR style="display: none">
> >> is sometimes useful when CSS is off.
> >
> > Like ordering coffee with cream in case there is no cream available.
>
> I try to explain in more detail so that you can understand, too.
>
> <BR style="display: none"> gives a linebreak for text browsers,
> search engines, and browsers with CSS turned off by the reader.
>
> With CSS-enabled browsers, the corresponding formatting is done
> through style sheets.
>
> So you can have the best of two worlds.

So, gentle humour does not work on you! I am sure deep down there is a
broad sense of humour that could be stirred.

<br> gives a linebreak for text browsers, search engines, and browsers
with CSS turned off by the reader. It is not just "sometimes useful
when CSS is off by the reader", it is (at least it is meant to be)
always useful when CSS is turned off. Adding the style might rather be
more useful for when CSS is on. You could also accurately say that
adding the style is useful to the world at large, both author,
css-enable browser users and others.

--
dorayme

[tlvp]

On Tue, 15 May 2012 09:06:15 +1000, dorayme wrote:

> So, gentle humour does not work on you! I am sure deep down there is a
> broad sense of humour that could be stirred.

Careful, dorayme, don't stir that: remember the fellow on the flight who
asked the stewardess for five sachets of sugar for his coffee. She poured
them in, and offered to stir them as well, but he refused, saying, "No, no,
don't stir it, please, I don't like my coffee too sweet."

[dorayme]

In article <g6r37kc0kr45.uc58fg6shbtv$.d...@40tude.net>,

tlvp <mPiOsUcB...@att.net> wrote:

> On Tue, 15 May 2012 09:06:15 +1000, dorayme wrote:
>
> > So, gentle humour does not work on you! I am sure deep down there is a
> > broad sense of humour that could be stirred.
>
> Careful, dorayme, don't stir that: remember the fellow on the flight who
> asked the stewardess for five sachets of sugar for his coffee. She poured
> them in, and offered to stir them as well, but he refused, saying, "No, no,
> don't stir it, please, I don't like my coffee too sweet."

Yes, I remember him well, I always try to sit next to him and swap
yarns. On our first flight together, I told him about Sartre's
ordering of coffee,

<http://dorayme.netweaver.com.au/jokes/beingAndNothingness.html>

and he has been living off it with variations for years.

--
dorayme

[tlvp]

Ah, yes. That would all be very well and good, unless they're out of
coffee, too :-) . Meanwhile, do remember to ask before acting, even if it's
only "a broad sense of humour" you think needs stirring. Cheers, -- tlvp

[dorayme]

In article <kyrynzguuodv.9f1o3d0iuuli$.d...@40tude.net>,
tlvp <mPiOsUcB...@att.net> wrote:

> remember to ask before acting

You do the same. Ask everything that is relevant of anyone before
doing or saying anything. Let me know how you go.

--
dorayme

[Philip Herlihy]

In article <joi7gb$r2f$1...@dont-email.me>, jkor...@cs.tut.fi says...

Particularly interesting comments, and I think after reflection on this
interesting digression that's going to be my view - that I'll tend to
use tags more for their default rendering than for their notional
semantic significance, although I'll try not to write real nonsense!

I do like the HTML Anarchist's cookbook!

--

Phil, London

[dorayme]

In article <MPG.2a2f432f4...@news.demon.co.uk>,

Philip Herlihy <bounc...@you.com> wrote:

> In article <joi7gb$r2f$1...@dont-email.me>, jkor...@cs.tut.fi says...
> >

...

>
> Particularly interesting comments, and I think after reflection on this
> interesting digression that's going to be my view - that I'll tend to
> use tags more for their default rendering than for their notional
> semantic significance, although I'll try not to write real nonsense!
>

What could be nonsensical in your idea of this?

--
dorayme

[Philip Herlihy]

In article <dorayme-60526D...@news.albasani.net>,
dor...@optusnet.com.au says...

That's a fair question! If I'm really abandoning the idea that HTML
tags have semantic connotations then it's all nonsense, and tags are
being used completely pragmatically based on what I expect current
browsers to do with them (and Devil take the future).

But these are extremes, and to my mind a compromise seems appropriate.
If I re-style an H1 so that the font is smaller than most, the display
is inline and the padding and margins match a nearby P tag, and then use
it as if it were a SPAN then I'm surely weakening the value of my code
to software (e.g. search bots) which disregard styling and parse
content. That would be a wild and foolish extreme. On the other hand,
stressing over whether the word "with" qualifies as a P goes a bit too
far for me, although I'd surely try BRs next time. I've pondered on how
(e.g.) a screen reader might be influenced by the markup in thos panels,
and I have to say I don't think it matters if the word "with" is given
the extra emphasis appropriate to the beginning and end of a
"Paragraph" - I can imagine a continuity announcer reading it just that
way! Meanwhile, I do try to avoid things like class="left" although
when I'm pushed for time...

I've learned to listen carefully to what you say, and I do respect your
argument in this. However, I also respect what jkorpela has written,
and I've certainly been known to use a sock to get the lid off a jam-
jar.

When we write for the web, we're writing code to be read by machines.
When I write program code, it needs to go through the compiler but its
more important to be readily intelligible to the next person to work on
it (which might be me!). Then I readily make sacrifices in efficiency
and in "neat" ways of doing things for the save of clarity. If I felt
web code was going to be read by either a person or a machine in a way
that meant the semantics of the HTML mattered, then I'd certainly be
less ready to hijack tags for their likely stylistic treatment.

--

Phil, London

[dorayme]

In article <MPG.2a3022768...@news.demon.co.uk>,

Philip Herlihy <bounc...@you.com> wrote:

> In article <dorayme-60526D...@news.albasani.net>,
> dor...@optusnet.com.au says...
> >
> > In article <MPG.2a2f432f4...@news.demon.co.uk>,
> > Philip Herlihy <bounc...@you.com> wrote:
> >
> > > In article <joi7gb$r2f$1...@dont-email.me>, jkor...@cs.tut.fi says...
> > > >
> > ...
> > >
> > > Particularly interesting comments, and I think after reflection on this
> > > interesting digression that's going to be my view - that I'll tend to
> > > use tags more for their default rendering than for their notional
> > > semantic significance, although I'll try not to write real nonsense!
> > >
> >
> > What could be nonsensical in your idea of this?
>
> That's a fair question! If I'm really abandoning the idea that HTML
> tags have semantic connotations then it's all nonsense, and tags are
> being used completely pragmatically based on what I expect current
> browsers to do with them (and Devil take the future).
>
> But these are extremes, and to my mind a compromise seems appropriate.

I agree. But note that we all *do* compromise. Almost no one gets to
make their webpages using the elements that seem deemed for the job a
la the W3C HTML 4.01 Specification. The elements are not that good or
not that flexible or the browsers have sadly disappointed. But there
is a central idea which I think is a shame to give up, to use what is
reasonable solid, to separate the markup from the styling as much as
possible and to not over-think or fret about this.

> If I re-style an H1 so that the font is smaller than most, the display
> is inline and the padding and margins match a nearby P tag, and then use
> it as if it were a SPAN then I'm surely weakening the value of my code
> to software (e.g. search bots) which disregard styling and parse
> content.

This is a spectacular case of *not* using elements for their default
styling.

> That would be a wild and foolish extreme.

Doubtless it would be if you really were just wanting what a SPAN
would afford you. But if you were not wanting this, if you were
engaged in styling or restyling or making a fresh alternative look for
your page, if the content of the H was a heading (in spite of not
looking like a trad one) it would not weaken anything. If you pulled
it off and could produce various nice different looks to your page, it
would be a mark of great strength and flexibility.

> On the other hand,
> stressing over whether the word "with" qualifies as a P goes a bit too
> far for me, although I'd surely try BRs next time. I've pondered on how
> (e.g.) a screen reader might be influenced by the markup in thos panels,
> and I have to say I don't think it matters if the word "with" is given
> the extra emphasis appropriate to the beginning and end of a
> "Paragraph" - I can imagine a continuity announcer reading it just that
> way! Meanwhile, I do try to avoid things like class="left" although
> when I'm pushed for time...
>
> I've learned to listen carefully to what you say, and I do respect your
> argument in this. However, I also respect what jkorpela has written,
> and I've certainly been known to use a sock to get the lid off a jam-
> jar.
>

It is right to respect Korpela. But be careful how you interpret him.
With me, it is different. With me you can completely and utterly
trust, your future assured, whether you understand me or not. If an
elderly distant relative leaves you a fortune and I say send me half,
just do it. In fact, my advice is always designed to be right even
when completely misunderstood, that is its dark secret. I bet Korpela
can't match that! His advice *always* needs to be understood correctly
and that is its terrible downside. But he tries his best.

> When we write for the web, we're writing code to be read by machines.
> When I write program code, it needs to go through the compiler but its
> more important to be readily intelligible to the next person to work on
> it (which might be me!). Then I readily make sacrifices in efficiency
> and in "neat" ways of doing things for the save of clarity. If I felt
> web code was going to be read by either a person or a machine in a way
> that meant the semantics of the HTML mattered, then I'd certainly be
> less ready to hijack tags for their likely stylistic treatment.

Very good point indeed and it is a point that reminds me of one made
by Hickson in exchanges with Korpela:

"The use case for most of the "semantic" markup is just easier
authoring and maintenance, in particular for selectors in CSS."

His words rather neatly sum up the idea.

For example in

<http://old.nabble.com/The-blockquote-element-spec-vs-common-quoting-pr
actices-td32010330i40.html>

And I think Korpela might agree with this, as most reasonable people
would.

All my raving on this need not be read as saying a great deal more.
The bits more I might have added in various exchanges need not be
interpreted as hopeless idealism about browser behaviour. They can be
seen as a more extreme form of what Hickson is saying.

But note something that Hickson relies on which may have not been
brought out into the open in the exchanges with Korpela. The people
who invented the elements had certain meanings and uses in mind and
this has formed a tradition. You cannot simply forget about this
tradition, it is a fait accompli, and that has imbued a certain
meaning to elements. It is *behind* the reasons for the styling
defaults. You can *pretend* later that it is, deep down, all about the
default styling, but this is a sophistical conjuring trick imo.

When I bang on about using OLs for where the author means the order to
be important and ULs for when not, when I say a P is for a paragraph
(slightly stretched in meaning for webpages maybe), think of it as a
particularly consistent recommended discipline for authors taking
their whole intentions into account (human meaning/semantics is all
about human intentions, mostly clear enough; transcendental
meaning/intention is about God's intentions, mostly terribly obscure)
and it provides a rough map for usage, for not having to fret about
what to use when. If it is a word, you want on a separate line, it is
simply not a paragraph, it is nothing like a paragraph and that is
that!

--
dorayme