W3C home > Mailing lists > Public > public-html-comments@w3.org > January 2010

Re: HTML adequacy

From: Eduard Pascual <herenvardo@gmail.com>
Date: Sat, 23 Jan 2010 19:47:22 +0100
Message-ID: <6ea53251001231047o188676dbr3dd938dbb88fe16@mail.gmail.com>
To: Lars Hansen <lars.hansen@yahoo.co.uk>
Cc: public-html-comments@w3.org
On Fri, Jan 22, 2010 at 8:07 PM, Lars Hansen <lars.hansen@yahoo.co.uk> wrote:
> Hello Eduard,
>
> I registered your comments.
>
>    CSS is already implemented, yes. Still I had to use workarounds for
> IE7 when designing a menu-based webpage.
Oh, do you mean that your proposal would retroactively work on IE7?
Ok, with CSS you may have to use workarounds for older and/or buggy
browsers (note that IE7 is both: old, since IE8 has already been out
there for a while, and buggy, as all of its predecessors), but things
go smoothly with decent browsers; and at least you can get the job
done on the others. With a new language, you couldn't have it working
on any of the current browsers, not even with workarounds.
>    And onmouseover/out with different event transporting mechanisms is
> not nice when wanting to get a particular element. IE has non-standard
> onmouseenter/leave for this. Yet this also is troublesome, perhaps
> buggily implemented.
Not nice, but can get the job done. If you have any suggestion about
how to make this nicer, I bet you'll receive more positive responses
from the contributors on this list.

>    Such bugs were due to things like padding and margin in the past
> which weren't correctly implemented. With pure boxes you won't need
> those.
Bugs are not the format's fault. The same way implementations for HTML
and CSS have some bugs, implementations for any new format are also
likely to have bugs. If Microsoft took over a decade before getting
CSS2 right, how long do you think they might take to get a new format
right (if they decide to implement it to begin with)?
> Eg. for borders simply put a box inside a box, make the inside
> box opaque and have the other box contain a flat color, now you know
> exactly how many pixels the border consists of at which position.
What if I need borders on a translucent or transparent box? See, even
your example on how to deal with borders already has a bug: there is
room for bugs everywhere. It's possible to implement borders through a
pure box model (using a separate, thin box for each side), but things
aren't as simple as they were a few moments ago, are they? Wasn't your
goal to make things simpler? That's a great goal to pursue, but things
ain't as simple as they seem.
Most of what you can find in HTML is there for some reason; and what
has no reason to be is being removed (for example, <font> is not part
of HTML anymore, since it is widely accepted that its inclusion was a
mistake on the first place; but the HTML spec requires browsers to
support it for compatibility with the huge amount of content that
relies on it).
>    I haven't come across UA custom styling much, I neglected
> accessibility, yes, I apologize. I was writing from my experience of the
> websites I saw browsed which are entertainment websites mostly (espn,
> ign) and the few "page" design attempts from me for specific purposes
> (as a non-professional).
Oh, great examples: try to read and/or navigate those pages zoomed in
(all modern browsers have some zoom feature, for people with sight
difficulties and for some cases where the text is unreadably small);
or with a non-maximized window. If you last more than two minutes
without hating the horizontal scrollbar let me know ;-).
In any case, these are highly dynamic sites. Trying to perform so
complex layouts statically is, on the best case, insane; and generally
unneeded. Using modular server-side scripts to generate the page
instead makes it piece of cake (it's still a significant amount of
work, but that's not the format's fault: with a layout composed of so
many elements you have to describe them, regardless of how you do it).

>    Perhaps all the tools one needs to design exactly what one wants are
> already present, Idk (too expensive probably). Yet if one does a new
> version of HTML, perhaps one should think about all the troubles which
> exist today and attempt to specify a more simple "recursiveable"
> language (see my comment regarding borders above) (also for all those
> beginners in the new decades still using "text"-editors).
The people behind this new version of HTML indeed think about all the
troubles which exist today. But that includes troubles you might have
not thought about. For example, have you thought about accessibility,
about semantic anotations, about implementation costs, about search
engine indexing, and so on?
The worst thing of the HTML5 process is that there is a lot of people
involved, so there are a lot of clashing interests. And the best thing
of the HTML5 process is that there is a lot of people involved, so
it's really difficult to overlook some need that the language should
address.


HTML should attempt to solve everyone's needs (within the area of web
authoring and navigation). If one of these needs can be solved in an
easier way, then it's worth trying; but making things easier for
someone is generally not worth making them harder for everyone else.
I'm not sure what do you want to achieve with HTML but, in general
terms, when a tool, language, or technology doesn't work well for your
task, you should consider if it's the right one to use.

Regards,
Eduard Pascual
Received on Saturday, 23 January 2010 18:48:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:14:01 GMT