website builders' newsgroup

On Wed, 19 Jun 2013 11:53:56 -0500, "Steve Thackery"
wrote:

Java Jive wrote:

Or people with visual difficulties! Go on then, let's ask Brian, if
he's listening.

You need to be careful here, because you are assuming what it is that
visually handicapped people need. I've got a visually handicapped
buddy (but not completely blind) and he doesn't try to disable the
fixed layout of web pages.

Perhaps he doesn't realise that with many browsers he can impose his
own stylesheet, which may help him. However, I wouldn't expect
someone with visual difficulties would be likely to discover this, or
be able to design their own stylesheet without great difficulty if
they happened upon the option. Rather, I'd expect the suppliers of
any assistive technologies that he uses to configure that as part of
installing their system.

But anyway ...

http://www.w3.org/WAI/WCAG20/quickref/

Some quotes follow which emphasize points I've been making variously
in this thread:

"1.3 Adaptable: Create content that can be presented in different ways
(for example simpler layout) without losing information or structure."
....
"The purpose of this guideline is to ensure that all information is
available in a form that can be perceived by all users, for example,
spoken aloud, or presented in a simpler visual layout. If all of the
information is available in a form that can be determined by software,
then it can be presented to users in different ways (visually,
audibly, tactilely etc.). If information is embedded in a particular
presentation in such a way that the structure and information cannot
be programmatically determined by the assistive technology, then it
cannot be rendered in other formats as needed by the user."

Wrt to this, flowing layout tends to be more adaptable than fixed
layout.

Particularly, putting text in two or three fixed width columns
apparently f*ks up any screen reading device that intercepts content
sent to the screen, or one that actually reads off the screen itself,
and tries to OCR it - AIUI the user tends to get the text from
different columns read across the page as one garbled 'sentence'.
Those screen reading devices that try to interpret the actual HTML may
have a fighting chance, but even they will be highly affected by how
content in columns is expressed in HTML form.

Also, just how is a blind user using a screen-reader supposed to cope
with text that disappears off the right hand side of the screen, as is
highly likely to happen with small-screen, low-resolution device if a
fixed width layout has been used?

The next point also refers indirectly to this sort of problem ...

"3.2 Predictable: Make Web pages appear and operate in predictable
ways."

Having to use a horizontal scroll-bar to read text that has been
formatted too wide for the screen is wearisome enough for a normal
user like myself, but I would imagine blind users and/or the
technologies they use are likely to find the page becomes largely
inaccessible through that fact alone.

"4.1 Compatible: Maximize compatibility with current and future user
agents, including assistive technologies."
....
"Parsing:

4.1.1 In content implemented using markup languages, elements have
complete start and end tags, elements are nested according to their
specifications, elements do not contain duplicate attributes, and any
IDs are unique, except where the specifications allow these features.
(Level A)Understanding Success Criterion 4.1.1

Note: Start and end tags that are missing a critical character in
their formation, such as a closing angle bracket or a mismatched
attribute value quotation mark are not complete.
Sufficient Techniques for 4.1.1 - Parsing

1. G134: Validating Web pages
2. G192: Fully conforming to specifications
3. H88: Using HTML according to spec (HTML)
4. Ensuring that Web pages can be parsed by using one of the
following techniques:
H74: Ensuring that opening and closing tags are used according
to specification (HTML) AND H93: Ensuring that id attributes are
unique on a Web page (HTML) AND H94: Ensuring that elements do not
contain duplicate attributes (HTML)
H75: Ensuring that Web pages are well-formed (HTML)
" ...

In one phrase, all that means making your pages fully compliant.

Others:

"Using CSS rather than tables for page layout"

Etc, etc.

In fact, he has at his disposal a number of tools to help. The point
is, just fixing web pages for the visually impaired is only one aspect
of it - he needs help with ALL the stuff that gets displayed on the
computer screen, not just web pages.

Sure, but we're not discussing those others things here.

So it's quite wrong to think that your preference for reflowing web
pages is somehow morally superior because you are helping blind people.

You're trying to put words into my mouth that I have never used, and
thereby make out that I am trying to act as a self-appointed web
policeman. Presumably this is because you have run out of rational
arguments.

I've merely pointed out that free-flowing layout tends to work better
in many situations where fixed width layout FAILS according to some
simple, basic usability requirements, and that it makes no more SENSE,
however commonly it is actually done in the fashionable practice of
the day, deliberately to design a web-page that you know is more
likely to fail than it would be deliberately to design a car that is
more likely to break down in normal use and expected lifetime.

From what I've gathered, they need solutions that address *all* their
applications, not web pages specifically. At least that's what my
buddy has. He's only a sample size of one, obviously.

Of course, but we're discussing web design here.
--
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

On Wed, 19 Jun 2013 12:21:02 -0500, "Steve Thackery"
wrote:

Steve, you're really doing a lot of blustering now. The only salient
point in your reply that matters is this ...

I AM saying this:
....
2/ The publisher is free to choose which philosophy they want to use;
based upon any criteria they like (including irrational criteria).
It's their web page.

.... which I've never denied, even as recently as the post to which
yours was a reply:

On Wed, 19 Jun 2013 16:50:33 +0100, Java Jive
wrote:

Of course it's a matter of choice, but one
would hope that such choices are made on rational grounds,

.... also making the point that it is not rational to deliberately
design weakness into anything, whether it be a car or a web-page.

nowhere in
any of the published standards is anyone promoted to Web Policeman with
the right to wag their finger at a publisher and say "Naughty person,
you should have made it reflow" or equally "Naughty person, you should
have fixed that layout".

See the link in my other reply concerning accessibility. No-one is
trying to be a web-policeman. All that is being repeatedly pointed
out to you is that flowing layout DEMONSTRABLY works better in more
situations than fixed layout.
--
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

On Wed, 19 Jun 2013 07:59:14 +0100, David Woolley
wrote in :

Owen Rees wrote:

to match the already selected card. Given various security notices I
have seen, I believe that the numer is some cryptographically strong
hash of device identity, card number and time. (Fraudsters will try to

I'm pretty sure that all the intelligence and cryptographic processing
for this are on the card, and the device only provides a keyboard and
display. I don't believe either card or device have any concept of time
and the responses from the Nationwide one seem to start with a serial
number. As Nationwide say you can use any device, the device cannot be
providing the serial number.


Yes, that makes sense - I was probably thinking about the RSA SecureID
device that uses time and mixing up the way the things work. All the
crypo processing and memory of where you are in the sequence being on
the card makes much more sense.

make you resynchronise the device - never do that!)

I susepct that is more because the central software requires the serial
number to be higher than the previous one, but not much higher, so
resetting it will cause the authentication to fail. The basic fraud
risk with these devices is that you can read out a series of one time
passwords ahead of time and record them on insecure media, and anyone
with one or more of the upcoming responses can authenticate as you.


It might be using a counter for a serial number but using the output as
the input to the encryption engine is another option. In that case the
requirement is that the output be in the sequence and not too far beyond
the last one used successfully. I am not sure if the chip and pin cards
work that way but it is consistent with the resynchronization protocol
for my VPN token that requires a number of consecutive output values.

On Wed, 19 Jun 2013 12:58:31 -0500, "Steve Thackery"
wrote:

As you will have gathered, I am usually happy - both as a publisher and
a reader - with web pages that have a fixed layout when they are
primarily aimed at desktop browser users. Style and content can both
be given the degree of emphasis the designer chooses.

See below ...

I also think that many fixed layout pages are a damn nuisance when
viewing them with a mobile device (especially a mobile phone).

See below ...

Now, one superficially tempting approach is to ditch the fixed layout
and make the page reflowing, much as Jim does with most of his web
pages. Thus it would (in theory) work on both desktop browsers and
mobile phone browsers.

Well, in theory yes, but there's a major problem to overcome first.
Read on ...

BUT, I'm not convinced this is actually the best way forward. For one
thing, in order to accommodate the widest of the fixed layout pages I
currently have open, I need the "viewport" in my web browser to be
something like 1000px wide. There may be some pages that require wider
still, but I can't think of any offhand. So, Opera sits there with its
19 tabs, and each page is rendered at 1000px wide.

But don't forget in all this, that you are not everyone else. Everyone
has their own way of working. Just as an example, mine happens to be
different as follows ...

I use a single monitor screen at 1024 * 768 which is conventional 4:3
aspect ratio. My monitor and graphics cards will go to higher
resolutions, but those that aren't 4:3 just look awful, and those that
are get progressively too small to read. I find 1024 * 768 a good
compromise between having plenty of real estate, but being able to
read the contents comfortably without glasses.

By dint of past careful positioning when first creating the build, all
the windows of all the main apps fill this height except for the
taskbar, so are 732 pixels high, but start the same distance in from
the left, so they are only 952 pixels wide. As they all exactly
overlay each other, this leaves a strip down the left which is useful
for keeping an eye on progress bars, command console apps, etc, and
also has some items on the desktop that accept drag'n'drop.

To change apps is very quick using alt-tab, and, through long
experience, after the initial investment of time positioning things
carefully, and apart from the occasional accidental grabbing of a
border, I find this a very efficient and quick way to work.

Straight then away there is a contradiction here, if you design your
web page to have a fixed width of 1024, or even just 1000, part of it
is going to be missing off the right-hand-side of my screen. See also
below ...

This is obviously fine for fixed layout pages, but here's the rub: it's
*actually far too wide* for reflowing pages. I've just done a quick
test and, rendered at the standard font size, each line is around 28
words long. As any publishing or typography expert will tell you, that
is FAR too long. Less that half that would be ideal.

Most books these days do seem to be about 8-15 words across a single
page. However, letters to and from officialdom, fliers, etc, lie in
the range 15 - 25 words per line, and, depending on the page and
font-size, on my site in my own chosen window size, a full width of
text comes to about the same, as do word-wrapped paragraph lines in my
text editor. As long as the font-size is adequate, I don't have any
difficulty at all in reading anything like that, and I don't believe
anyone with normal vision would either.

Frankly, any publishing or typography 'expert' who says otherwise is
talking through his arse, but I suspect that's not what they're really
saying ...

When I used to write reports at work, I was constantly being told by
my boss two things:

He never like the layout of my reports, for example, the margins
needed to bigger - I used 1 or 2cm but he wanted 1.5" each side,
thus, amongst other things, needlessly wasting paper - and the text
was too dense, etc, etc. He believed something was easier to read if
you spread it sparsely over lots and lots of pages. I pointed out
that this was the exact opposite of both what I had been taught
throughout school, college, and university, and my own experience. It
appeared that whereas he would get a sinking feeling from a smaller
number of pages but densely printed, I would get a sinking feeling
from a whole stack of pages to read, however sparsely printed.

Secondly, he always wanted me to shorten them: "You don't really need
to give this technical information here, as the option is non-viable
anyway!" So with the greatest reluctance, because I knew exactly what
the result would be, I used to cut out such huge chunks of technical
explanation. Then inevitably, while the report was being debated,
someone would have the bright idea "why don't we do such'n'such?" and
suggest something that I had ruled out as impractical in one of the
sections that my boss had cut. So instead of my dismissal of it as
impractical being given in clear, concise and unanswerable logic as it
had been originally in the unexpurgated report, that could have been
read and understood in a minute or so, we'd have to waste some time
debating something that wasn't worth debating in the first place,
while I tried to explain, while being questioned and interrupted, why
this bright idea actually wasn't so very bright after all.

Basically, what it boiled down to was this: my boss wanted the
impossible - he wanted a report that explained away something
complex and technical in a few short paragraphs.

I suspect that your so-called typography experts are coming from the
same angle of my former boss, in that, like him, they believe that a
page densely packed with text is bad news. I'd say it depends on what
the page is trying to do, and what it's about. If it's trying to help
you decide which takeway pizza to order, then I would agree a page of
dense text is not good news, but then on such a page it's rather more
likely there will stonking great pictures of steaming pizzas than huge
paragraphs of text. If, on the other hand, the page is trying to
explain something technical, it being densely packed with text, and
maybe if appropriate some diagrams, is good news, because it means
there's plenty of information there that someone else has gone to
considerable trouble to understand and explain for you, and all you
have to do to understand it similarly is have the patience and
concentration to read it.

Thus I think reflowing web pages have their own problems. You can
allow reflowing up to a maximum width, and then stay fixed after that,
but you end up with a lot of wasted white space either side. It gets
quite messy.

Not really. I don't think any of the full-width pages on my site look
'messy'. Certainly not as messy as they would look if I split them
all up into the standard three-column design, with maybe some blinking
adverts down the right-hand-side to constantly distract the reader, a
navigator tree down the left-hand-side to ensure that, if the reader
should wish to print the page, only half the central column of useful
information would actually print, and the rest of the printout would
be the navigator tree, useless in a printed context, and instead of
printing on one or at most two pages, as currently would most pages on
my site, they'd be garbled over three times that. The chord diagrams
I showed earlier would be absolutely useless like that, whereas now
they print neatly onto a single page that can be carried away from the
PC and placed on a music stand.

No, rather than addressing the mobile browser problem with "Just use
reflow" I think a more sophisticated approach is needed. When I look
at the web on my mobile phone, some publishers clearly serve up a
completely different page for mobile devices. Google and Wikipedia
(especially the latter) are great examples. With Wikipedia, the
content is arranged entirely differently, and even has
collapsing/expanding sections.

This makes me think that the better approach is to serve up web pages
specifically aimed at the requesting device. I believe that usually
such pages are constructed on the fly from a giant content management
system (CMS), but that isn't necessarily very realistic for smaller
sites like the ones we make.

Yes, they have the resources in terms of designer staff, server power,
and CMSs to do this.

Nevertheless, in many cases the mobile pages are better than the PC
pages at least partly because the constraints of the platform force
the designers to think about what content is really important to the
user, and thus they end up designing mobile pages which would also be
better for desktop users.

Sometimes, though, the opposite happens, eBay and Rightmove are two
sites for which I always choose the desktop layout, even on my mobile.

And so to the question: do any of you have experience with making web
pages specifically for mobile devices? Did you refer to any design
guidelines? Did you use (and can you recommend) any design tools or
aids aimed at the mobile web?

There are endless pages out there purporting to tell you how to do
this, but actually few that I've found in a search a year or two back
and a brief one just now that will give you hard and useful
information on how to set about it. Perhaps this is a reasonable
canter around the options:
http://mobiforge.com/starting/story/...ion-techniques

But there's a fundamental problem here, which I've now realised CSS on
its own cannot solve, you need some form of intelligence at the server
end.

As explained above, the resolution of my desktop monitor is 1024 x
768, and the horizontal width of the active area is 333mm, so the
dot-pitch is 1024/333 or about 3 pixels/mm. However, on my mobile, a
Samsung Galaxy Note II, which is quite big as mobiles go, the
resolution is 720 x 1280 while the screen dimensions are 70 x 123mm,
which is a dot-pitch of about 10.3 pixels/mm. This means that text of
equivalent point size is actually about a third of the physical size
on the mobile. So, to use the same font-size and have it readable on
both devices, instead of having a standard font-size based on 12pt,
you'd actually have to use something like 36pt. As an experiment, I
just tried 30pt, and it was just readable on the mobile in landscape,
while still iffy in portrait. It was absurdly huge on a PC, and
would, no offence to Brian intended, make a site when viewed on a PC
look as if it was designed for the visually impaired.

What's needed is some sort of discrimination based on the capabilities
of the device, which is possible to an extent using the @media
functionality of CSS. However, AFAIAA this is only capable of
discriminating according the screen resolution in pixel dimensions,
not according to the resolution in terms of dot-pitch, and thus is not
sufficient to meet the need. At very minimum, what is needed is
something that can work out the dot-pitch and apply on the fly an
appropriate font-size according to result. There are databases of
known devices and their capablilities, but they are aimed at the
commercial market. I'm not sure what the options are for the likes of
you and me.
--
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

On Thu, 20 Jun 2013 04:05:31 +0100, Java Jive
wrote:

But there's a fundamental problem here, which I've now realised CSS on
its own cannot solve, you need some form of intelligence at the server
end.

But now I'm not so sure.

Thinking that perhaps the mobile's browser was at fault for not
respecting the 12pt CSS settings on my page (a point = 1/72 inch, so
12pt characters should always be 1/6 inch height no matter what they
are displayed upon), I thought I'd check what height they actually
were. But this time I used Chrome and got different results, so it
depends not just upon your chosen method of layout, but also the
user's mobile's browser.

If, on both your desktop and your mobile, you examine the following
page of which I linked an image earlier, you'll see that it does
indeed fill the available screen width in either portrait or
landscape, in either Chrome or the native Samsung browser. This is
what it's supposed to do, but the result on the mobile is not easy to
read.

http://www.macfh.co.uk/Macfarlane/Mu...enCChords.html

However, if you do the same with this page (BTW a story of the
funniest thing that ever happened to me) which has no layout forcing
at all, you'll find the result unreadable in the Samsung browser for
the same reasons as before, but perfectly readable, even displayed at
the correct point size, in Chrome. Never was there a better
demonstration of the virtues of not forcing layout!

http://www.macfh.co.uk/Macfarlane/Re...ogCatDuck.html
--
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

Jim Lesurf wrote:


If you re-defined "hobbyist" to mean pages where the author felt access to
the content was more important than showing off their graphic design
skills, then I'd agree. :-)

I think the advertising people that design most "web" sites would
actually tell the clients that the design is what sells the company
products. At best the site is a proxy for products that are no better
than the competitors. At worst, the styling allows one to put over
subliminal messages that you could not do in simple text, because they
would be unsupportable.

HTML started its life as being about real knowledge and reacted against
existing tools which were designed to manipulate, rather than inform.

Steve Thackery wrote:

HOWEVER, almost immediately designers started wanting more control over
the page appearance, and ever since then a large amount of the
standards work has been to support this. Indeed, CSS was specifically

Yes. Unfortunately HTML started regressing to being a PDF alternative
quite early. The people in the HTML business will claim this is
progress, but it is actually regression. One of the things that made
the original HTML concept progress was its rejection of commercial wants
and its stress on communication of knowledge.

It is not as though computer mediated advertising tools didn't exist at
the time. PDF is contemporary with HTML and there were precursors of
Flash. Admittedly, they didn't have cross-site links, but, in spite of
the use of the term "web" site, most such sites do not have such links
in the editorial. The commercial world doesn't want a web, because it
allows consumers the knowledge to make real choices, and they might find
a better product or better offer, by following the links.

Apart from the novelty of cross site links, the other thing that made
HTML popular, initially, was that any reasonably educated person could
create it with simple, free, tools, whereas the business model for
technologies like PDF was based on selling the authoring tools. A lot
of this threaad has been about choosing tools that hide what is now a
very complex technology - even more complex htan necessary, because it
is has forced to be a PDF and Flash, when it was never intended to be.

Unfortunately, since the browser developers staged the WHATWG coup,
"web" technology has been driven by commercial wants, not the original
ideals, and commerce want to control communication.

Jim Lesurf wrote:


Personally, if I want to provide a more rigid layout and appearance, and
replicate an experience more like a printed book, I tend to use PDF or PS.

It has always amused me that the marketing types have been the ones
allowed to play with HTML, because it is fashionable, and they like
being fashionable, whereas the technical types have to use PDF, when PDF
was designed to meet marketing wants, whereas HTML was designed for the
communication of facts, needed by the technical people.

I've regularly sought out PDFs, because they actually contain real content.

In article , Steve Thackery
wrote:
Jim Lesurf wrote:


I can't remember how many times I've had to say this, but *neither is
right or wrong*, and no amount of insisting on your part will make it
so.

Just as no amount of your insisting your misunderstandings of what I've
said will make them so, either. :-)

For some commercial and professional sites, the layout, typography,
etc, is an important part of their branding (and particularly when they
are advertising-supported sites). Thus they are very insistent about
controlling the page layout, look and feel.

Agreed. Just as you and everyone else can set up their pages however they
prefer.

The points I've been raising, though, are based on the idea that the point
of a website is that people will read it, and find it convenient to do so.

Who matters most here, the authors or the readers? I can understand that it
can be very satisfying for a creator to make something the creator enjoyed
producing and think shows off their skills, etc. But it does seem to me
that the point of a website is that it is accessible and useful for as many
visitors as possible who have an interest in the *content*.


For other (usually non-commercial) sites, the emphasis is all on the
textual content, in which case reflowing is clearly the best. I've done
both types of site.

It seems an odd idea to me that those building commercial sites think their
site's approach might *not* be primarily a matter of making its content
accessible and convenient for their target audience, and to maximise that.
That seems to me basis for having people use the site and thus generate
business. Given that, it seems odd to me that some authors and their
paymasters don't feel this matters more than having the result look natty
on the author's machine and that of his boss. I'm less surprised that so
many seem unable to get beyond thinking of webpages as if they are printed
on paper.

But then I am often puzzled by the ways people behave. I gave up being
astonished by it year ago, though... :-)

But no, Jim, I simply cannot accept your argument that there is
something inherently superior about one type or the other, or that you
have any right to wag your finger at a publisher and say "You shouldn't
have done it that way."

Just as I can't accept your argument which misrepresents what I've said and
meant. ;-

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

In article , Steve Thackery
wrote:
Jim Lesurf wrote:

Personally I don't use CSS at all. But this primarily because I got
used to my own ways of generating webpages ages before it appeared.

I think that says it all, Jim. You do it this way because you've always
done it this way.

Not quite. I've continued to do it this way because of the feedback over
the years. One interesting feature of some of my sites is that I do get
feedback. This generally seems happy with the approach I've taken. But I
have also changed things over the years in response to suggestions and
developments.


Your argument that reflowing text is better for some users seems
primarily to bolster your resistance to change.

I note your use of "seem" to make an assertion of what you prefer to think
into looking as if it were 'fact' rather than OSAF. :-)

Style matters, but content matter more!

Well no, not always. Sometimes the style is the brand, and that might
be more important. It isn't up to you or me to tell the publisher which
is the more important for them.

Agreed. In some cases the style *is* the content.

BTW For many years one of my best friends was a seriously good graphic
designer and typographer. So I do have an interest in such matters and I
take them very seriously in printed material I produce. I can certainly see
that sites that are mainly to shove a brand would take their own approach,
just as I can see that sites about typography or graphic design will need
tight control over the appearance.

But the point here is that in such cases the 'style' *is* the 'content'.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html