Re: HTML adequacy

I couldn't disagree more from your proposal: it asks for UA vendors
and content authors to send all the effort invested since the mid-90's
to redo everything in a new way. Well, that'd be a huge cost, so the
benefit of doing that gotta be also huge to offset the cost. Let's see
what'd be the benefits from your proposal:

On Fri, Jan 22, 2010 at 5:42 AM, Lars Hansen <lars.hansen@yahoo.co.uk> wrote:
> [...]
>
> Most people using the Internet today access some web resource for
> whatever they want to do and they conduct their interaction with web
> resources by browsing webpages.
Remember that a significant fraction of these "people" are search
engine spiders, people with sight problems using screen readers,
people connecting to the web through unusual devices (such as
cellphones), and so on. One of the critical aspects of the web is that
its contents must be usable from most of these contexts to be useful
at all. Thus, its technologies need to be much more flexible than
specific software designed to run only on a specific platform.

> Webpages are they main experience on the
> Internet. Thus webpages have the main attention of people wanting to
> bring quality to other people. For webpage design HTML is currently
> used.
Yep. And for nearly two decades, HTML has managed to get the job done.

> And this is a mess.
Indeed, HTML is a mess. By definition, it has to: it is the language
for the Web, and the Web will always be a mess. What would you expect
from an infrastructure that allows anyone to either publish or view
contents and resources through such a huge range of devices?

> A by now huge standard and additions to
> implement with many miniscule unobvious details and webpage renderers
> with many faults have lead to headaches everywhere (people developing
> the renderers a.k.a. browsers, people designing the webpages, people
> viewing the pages).
As I said, this mess is a side issue of the nature of the web.

> Webpage design suffers from HTML being a text content description language.
IMO, webpage design enjoys from HTML being a text content description
language. And that's simply because the vast majority of the web's
contents are still some for of text.

> Some problems: For text to display, a p tag is necessary.
Actually, that is just not true. I have just tested a page with this code:
<body>Hello World!</body>
And the text is rendered by Firefox, Explorer, Opera, Chrome, and
Safari. I also tried removing the <body> and </body> tags, and again
it renders perfectly. For any page on the entire web, if you removed
all the <p> tags and left only their contents, you'd get the same text
rendered by any of the browsers; the only differences would be the
lack of spacing between paragraphs and any CSS styling depending on
the presence of the <p> tag (in other words, the only difference would
be that the text is not made of paragraphs anymore, just what one
would expect when removing the tags that mark fragments of text as
paragraphs).
> This implies the text being a paragraph which is not
> always the case, more later. The paragraph as then rendered by browsers
> has no defined position: its position from a corner, let it be the top
> left one, is browser dependent. (As tested with Internet Explorer 7 and
> Opera 9.5).
Yeah. But if you really think it *only* depends on which browser is
being used, you are being quite innocent: it also depends on the
device, user options, and even styling rules applied to the page (such
as CSS, XSL, or XBL). But wait, it gets even better: try the same
paragraph on an aural browser, and you'll see that there even isn't
any "top left corner".
But, if you want to specify the exact position for visual browsers,
you can do that through CSS' absolute positioning (just be careful to
provide reasonable alternatives for other devices that are visual but
aren't computers, such as handheld devices).

> The p tag would be fine to relay information that the text
> is a paragraph but it is not suited for the thing people conduct their
> interaction with when accessing web resources.
That depending on what the resource and the interaction are. When the
resource is a document, and the interaction is reading it, marking
paragraphs as such can be quite helpful. For other cases (resources
that aren't intended to be read, or things on a page that are not
paragraphs) just don't use the p tag.

>    A layout and positioning language is needed.
Indeed. Back in the late 90's, seeing that adding so much
presentational stuff to HTML 3.2 had backfired, the folks at the W3C
realized the same fact (actually, they also knew about the need for
other forms of styling, such as text formatting), so they made that
language. It's called CSS, and work has been done continuously to
improve it.

> Here is one: let there be pure boxes only: define their position from
> any corner of the parent box absolutely or relatively. Define their size
> absolutely or relatively to the parents box size. Allow rounded
> elliptical corners. Give the boxes a resource definer (flat color,
> image, text file, video, web page) to have that resource be fetched and
> displayed inside (without margins). Define opaque or transparent
> background for the box.
Yeah, nice. CSS already does a good deal of that, I hope you know:
absolute and relative positioning, margins (and padding and borders)
and, to some degree, replaced content (like fetching a resource to
display within a box instead of the contents directly provided by the
document) are already there. Last time I checked, work was in progress
for alpha transparency for everything that might have a color (I'm not
sure about the current state of that aspect); and rounded corners are
also on their way (with the plus of image-based borders, in the case
you need even finer control)... keep asking.

> This way every layout of today is possible in an
> easy to design manner and with a homogene display across browsers as it
> is easy to implement.
Every layout of today is already possible, by definition. Whether
something is easy to design or not is subjective, and may also depend
on the tools you are using. For example, do you really think that it
would be easier to figure out the new size for a paragraph or any
other block of text every time its contents are changed, updated, or
corrected?
And homogeneous display is by definition impossible. One of the good
things of the Web infrastructure is that users have the last word
about how things are displayed on the UA (maybe that's why it's called
"User agent" and not something like "Author agent"). For the common
case, if you are building some desktop software in the form of a
website, you can get consistent rendering among all major desktop
browsers (at least for up to date browsers).
Oh, and how would it be easier to implement than what is already
implemented? For all the features you have suggested, the
implementation cost for all modern browsers would be zero for CSS,
because it is already implemented: that's quite hard to beat (irony
aside, that's impossible to beat by definition).

> For text allow fonts (to be downloaded from the
> server the page is on) and utilize a simple character styling language
> including definition of line division sizes.
The CSS Fonts module is also work in progress. If I recall correctly,
it'll allow to have fonts stored on the server and pages using them.

> Language details for
> dynamic contents like menus is still needed though an onhover definer
> may be enough.
We have CSS's :hover pseudo-class to describe the styling of an item
when its hovered; and HTML's attributes @onmouseover and @onmouseout
to hook scripts when more elaborate behavior is needed.

> I can write this down a bit more formal if you agree that HTML is
> outdated (by no deadline though).
Of course, I agree that HTML is outdated. That's why we are updating
it. But don't worry about writing it down, Hixie (HTML5's Editor) is
already doing quite a good job on that; even despite I don't agree
with some of his decisions.


Regards,
Eduard Pascual

Received on Friday, 22 January 2010 18:16:20 UTC