Is the end of HTML as we know it?

[1001 Webs]

Speaking from the viewpoint of a USER of the web rather than from the
viewpoint of a DEVELOPER of web sites:

I prefer web sites built with table-based layouts. I have trouble
reading the tiny, tiny fonts that are all the rage on the web these
days. I almost always increase the font size a step or two.

Table-based layouts seem to handle my font size increases without any
problems (for the most part).

CSS-based layouts seem to have trouble handling my font size
increases. This usually results in sections overlapping other
sections and, in many cases, some sections being completely obscured.
Sometimes, sections even vanish entirely, apparently being rendered
into some kind of void.

So it's not just me and my user preferences...

Right about now, I'm sure Ivory Tower types are blaming this on web
developers writing bad CSS or something.

They also blame it on users not configuring their browsers properly.

But the fact of the matter
is, if a tool makes it hard to do things right, then the tool should
probably be considered fundamentally broken.

As a result, I tend to consider CSS fundamentally broken for the task
of layout.

HTML 1 - CSS 0

just kidding, but there's a good point

 

[Jerry Stuckle]

Speaking from the viewpoint of a USER of the web rather than from the
viewpoint of a DEVELOPER of web sites:

I prefer web sites built with table-based layouts. I have trouble
reading the tiny, tiny fonts that are all the rage on the web these
days. I almost always increase the font size a step or two.

I understand what you're saying - I do the same. But don't blame CSS on
the developer's poor choice of font sizes.

Table-based layouts seem to handle my font size increases without any
problems (for the most part).

CSS-based layouts seem to have trouble handling my font size
increases. This usually results in sections overlapping other
sections and, in many cases, some sections being completely obscured.
Sometimes, sections even vanish entirely, apparently being rendered
into some kind of void.

Not if they're designed properly. However, there are too many people
who think they're web developers who don't have any idea what they're
doing. And they don't try different default font sizes.

Right about now, I'm sure Ivory Tower types are blaming this on web
developers writing bad CSS or something. But the fact of the matter
is, if a tool makes it hard to do things right, then the tool should
probably be considered fundamentally broken.

Sure. Good CSS doesn't suffer from those problems. It's all in
understanding the markup and testing.

As a result, I tend to consider CSS fundamentally broken for the task
of layout.

Not at all.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[1001 Webs]

Well bust mah britches and call me cheeky, on Mon, 05 Nov 2007 10:08:18
GMT David Dorward scribed:

That is just due to the way browsers have implemented it, not a
requirement of the specification.

and you have to put something like [[CDATA && ]] (?) near the element
terminators.

XML is simpler than SGML and doesn't have a means of saying "Ignore <
and & characters inside <foo> elments". This means XML can be parsed
without needing access to a DTD, and that XML parsers can be smaller
and faster than SGML parsers.

Ditto. You don't need a DTD to find out if the element is finished or
not.

(For all the above, read "DTD" as "DTD or another means of knowing the
specific XML dialect")

Well, I didn't know some of that, particularly that XML can be parsed
without accessing a dtd. But xhtml "needs" a dtd, or is it just because
of the compatibility issues with appendix c et al? And if in the context
of what you said there's a meaningful difference between XML and xhtml,
the logical question is can SGML (not html) be parsed without a dtd also?

Anyway, I'm still not impressed. What's wrong with making <img
src="my.png">Look at me.</img> the "right way to do it" and getting rid
of the stupid "alt" attribute?

The <img> element is not strictly necessary, but is included to ease
the transition to XHTML2.
Like the object element, this element's content is only presented if
the referenced resource is unavailable.
http://www.w3.org/TR/xhtml2/mod-image.html#s_imagemodule

 

[dorayme]

I believe Jerry just likes to pick fights. You are wasting your time
here Jerry is a closed minded buffoon. He fears what he does not
understand

I was - naively I guess - hoping to get him to define a few
things so that the exchanges could actually be a bit informative
to whoever might read them on usenet. I suspect he is simply not
prepared to do the hard work of rubbing some words together.

The fact is that many table layouts are very fluid in all sorts
of good senses. There are some deeper senses in which they are
not - to do with platform and device variations. And there are
other senses in which they are not as easy to update, rearrange
or adapt as templates. But none of this stuff is he interested in
even listing (never mind explaining), hurling abuse, saying as
little as possible and oozing hints of knowledge and authority is
more his game. And ever ready with his oft repeated accusations
of trolling by people who do not fall into line with him quietly.
There is indeed a strong argument that people like him have a
fair number of the characteristics of a troll than those he
accuses.

 

[Ed Jensen]

Rocket science and brain surgery are fundamentally broken?

And rocket science and brain surgery have what to do with tools
exactly?

 

[Ed Jensen]

I understand what you're saying - I do the same. But don't blame CSS on
the developer's poor choice of font sizes.

It's not really a font size problem. People viewing web pages should
be able to override the fonts and font sizes in web pages and the web
page should still render correctly.

The problem is that when users do that, the web pages end up rendering
incorrectly.

Not if they're designed properly. However, there are too many people
who think they're web developers who don't have any idea what they're
doing. And they don't try different default font sizes.

My experience has been that CSS based layout problems are pretty much
universal. Big sites, small sites, free sites, expensive sites,
amateur sites, professional sites.

Sure. Good CSS doesn't suffer from those problems. It's all in
understanding the markup and testing.

This is where we disagree.

I've been in the software development field for a long time, and I've
come to realize that when almost everyone is using a tool incorrectly,
it's almost always because the tool itself is poorly designed.

If almost everyone is getting their CSS based layouts wrong, something
is probably wrong with CSS based layout technology in general.

 

[André Gillibert]

Speaking from the viewpoint of a USER of the web rather than from the
viewpoint of a DEVELOPER of web sites:

I prefer web sites built with table-based layouts. I have trouble
reading the tiny, tiny fonts that are all the rage on the web these
days. I almost always increase the font size a step or two.

Table-based layouts seem to handle my font size increases without any
problems (for the most part).

CSS-based layouts seem to have trouble handling my font size
increases. This usually results in sections overlapping other
sections and, in many cases, some sections being completely obscured.
Sometimes, sections even vanish entirely, apparently being rendered
into some kind of void.

Now, I'll talk about my recent user experience.
I used to access to two Web BBS.
The first one (site X) uses an awful table layout + some small bits of
very bad CSS.
The second one (site Y) uses CSS (+ tables for tabular data) with many
non-semantic nested DIV whose only purpose is CSS styling.
Both are a logical structure mess, though the first one is much worse than
the second one.

site Y has a fixed layout: Fixed font size, fixed font family, fixed
width. It assumes a 800 px window width. Unfortunately I often have a left
panel and I don't always maximize my windows, which reduce the window
width to fewer than 800 px.

site X has a more fluid layout. I can use a left panel without getting a
horizontal scroll bar.

Both sites have a bad layout, full of useless decorations, navigation bars
and stuff that clutter the interface.
Without user CSS, I would've slightly prefered the layout of site X.

Since I liked both sites content (as opposed to structure and
presentation), I invested resources in styling them.

For site Y, in a few hours, I removed all the fixed widths. I removed all
the navbars and I replaced fixed position divisions with floating
divisions. With !important rules in my user CSS, I got a fluid, pretty
layout.
This was possible thanks to the ID and CLASS attributes of every HTML
element.

For site X, I tried for hours to find CSS selectors specifically
identifying some parts of the site. Combining direct child selectors,
attribute selectors and adjacent selectors. I knew that any tiny
modification in the site would break my user CSS. But, even with those
complex CSS selectors, I couldn't select things accurately enough. I gave
up.
For instance, one of the very few CSS classes used was "smallfont". It was
used for everywhere for unrelated things.

Eventually, site X got yet another 18 kilobytes navigation bar, full of
inline style. e.g. The style "color: #fff; font-size: 9px; font-family:
arial,verdana,helvetica; text-decoration: none;" duplicated for every list
item element (approximatively 100 elements).

site X became far too cr*ppy for my preferences. I don't use it anymore.
site Y is now perfectly styled. I use it daily.

Conclusions:
1) 99% of the Web s*cks.
2) A CSS based layout, with not too illogical class names (e.g. "forumnav"
rather than "smallfont"), is easier to control manually through a user CSS.
3) Inline style is not better than the FONT element.
4) A "smallfont" class used everywhere for anything isn't better than
inline style.
5) You can get the worst of both worlds (table layout and CSS) if you're a
bad designer.

But the fact of the matter
is, if a tool makes it hard to do things right, then the tool should
probably be considered fundamentally broken.

It isn't hard to do things right. It is easy to do things wrong, because
it's easy to do things.
A language learnt without any manual or whith manuals who where written by
people who never read the specifications, can be used by novice people who
produce bad code.
Anyway, with your argument, all computer technologies are fundamentally
broken. Statement with which I wouldn't really disagree.

Since this usenet group is about HTML authoring, it would be on topic to
figure which way is better for an expert programmer who read
specifications.
I know that a novice will write very bad code with table layouts and
equally bad (or worst) code with CSS.
But, I'm not novice, and I assume that a large (non-negligible) part of
alt.html members aren't novice.
In that case, a question can be raised: What must I use if I've a brain?
Examples of cr*ppy code mustn't be used to answer. Examples of good code
must be given.

The question: "I don't have a brain, and I want to style my page, what
must I use?", makes sense too, and should be answered separately.

 

[dorayme]

If almost everyone is getting their CSS based layouts wrong, something
is probably wrong with CSS based layout technology in general.

This sounds good and it will resonate with many people. But it is
a simplification of the facts.

If untrained people are allowed to build and/or maintain complex
things, and the inevitable happens, then it may not be simply
because their tools are "wrong" but because the nature of the
whole practice is very complicated and unregulated. It may simply
be very hard to build good simple tools that everyone can use to
do nearly everything they want to do. All sorts of things can
stand in the way of this. In the case of website building,
browser manufacturers adherence to a common standard would make
things incredibly better. Even wsiwig tool makers would then be
able to fashion things that worked well.

 

[Beauregard T. Shagnasty]

If almost everyone is getting their CSS based layouts wrong, something
is probably wrong with CSS based layout technology in general.

It is only a bad carpenter who blames his chisel for the shoddy
cabinetry he produces.

 

[Travis Newbury]

It is only a bad carpenter who blames his chisel for the shoddy
cabinetry he produces.

Its NOT the chisel? Damn that carpenter!!! Damn him to hell!!!

 

[Travis Newbury]

Now, I'll talk about my recent user experience.

You know, I have seen great fixed with sites, and crappy fixed width
sites. I have seen great fluid sites, and crappy fluid sites. I have
seen great sites made with table layout, and great ones with CSS
layout. I have seen crappy sites made with tables, and crappy ones
made with CSS. (I have even seen an occasional great all flash site)

There is no single right way to create a great site.

 

[Jonathan N. Little]

You know, I have seen great fixed with sites, and crappy fixed width
sites. I have seen great fluid sites, and crappy fluid sites. I have
seen great sites made with table layout, and great ones with CSS
layout. I have seen crappy sites made with tables, and crappy ones
made with CSS. (I have even seen an occasional great all flash site)

There is no single right way to create a great site.

There are some define wrong ways though

 

[rf]

It is only a bad carpenter who blames his chisel for the shoddy
cabinetry he produces.

Wife uses chisels to open paint tins. Her house painting is pretty damn good

 

[Beauregard T. Shagnasty]

Wife uses chisels to open paint tins. Her house painting is pretty
damn good

We use big screwdrivers for paint tins; don't you dare touch my chisels
though.

 

[Travis Newbury]

There are some define wrong ways though

I don't believe there are. Not globally wrong at least. You have to
define the type of site to decide what might be wrong. For example,
for a site like google, Flash is a wrong way. For a site like cartoon
network, simple text and static images is wrong.

I don't believe there are any chiseled in stone rules for web
development.

 

[Ed Jensen]

If untrained people are allowed to build and/or maintain complex
things, and the inevitable happens, then it may not be simply
because their tools are "wrong" but because the nature of the
whole practice is very complicated and unregulated. It may simply
be very hard to build good simple tools that everyone can use to
do nearly everything they want to do. All sorts of things can
stand in the way of this. In the case of website building,
browser manufacturers adherence to a common standard would make
things incredibly better. Even wsiwig tool makers would then be
able to fashion things that worked well.

Gazing into my crystal ball, I'm going to guess a certain large
software company will ensure "adherence to a common standard" will
never happen, and will instead eventually push a different technology
(conveniently enough, invented by them) instead.

 

[Ed Jensen]

It is only a bad carpenter who blames his chisel for the shoddy
cabinetry he produces.

Yeah, that's a cute saying.

Too bad that's all it is.

 

[Beauregard T. Shagnasty]

Yeah, that's a cute saying.

Too bad that's all it is.

You need to sharpen your chisel.

 

[dorayme]

Gazing into my crystal ball, I'm going to guess a certain large
software company will ensure "adherence to a common standard" will
never happen, and will instead eventually push a different technology
(conveniently enough, invented by them) instead.

Funny you should say that; on one of the main channels of my
crystal ball, I am getting that too. <g>

 

[asdf]

Gazing into my crystal ball, I'm going to guess a certain large
software company will ensure "adherence to a common standard" will
never happen, and will instead eventually push a different technology
(conveniently enough, invented by them) instead.

Actually, probably not IMO. Are any of you folks old enough to remember
'Blackbird'?

It was going to be 'better than the web', apparently. It lasted about 6
months (from memory) before the 'very large company' pulled the plug and
recognised that the genie was well and truly out of the bottle in the form
of the www. They were playing around with this in the very early 90s I seem
to remember. I could be wrong about the dates, though.

In some respects they were right... it *was* better than the web, or at
least it looked prettier (at the time). You could, however, *only* look at
it on Windoze machines.

Ubiquity tends to lead to standards, methinks. By it's very dominiance www
technologies will probably prevail for the time being at least.