- From: Mihai Sucan <mihai.sucan@gmail.com>
- Date: Sun, 18 Mar 2007 14:31:19 +0200
- To: public-html@w3.org
Very interesting thread.
Le Sun, 18 Mar 2007 06:51:22 +0200, Marcos Caceres <m.caceres@qut.edu.au>
a écrit:
> Maybe it's the programmers who are screwing up the markup as they are
> the ones writing the PHP, .Net, Rails, ColdFusion, etc that eventually
> comes out as HTML . Have you seen the nonsense markup that .Net's web
> controls produce? Seems to me programmers just as likely to be
> responsible for poor markup than anyone else.
No, actually, everyone screws up the markup:
a) the designer
b) the programmer
c) the libraries being used
d) the the frameworks (ASP.NET, Ruby on Rails, etc)
e) Content Management Systems
f) Web browsers
Each and every single one is responsible for the generated tag soup.
a) the designers
Le Sun, 18 Mar 2007 06:51:22 +0200, Marcos Caceres <m.caceres@qut.edu.au>
a écrit:
> As an indication, if you want to know what topics web designers are
> interested in go to a list apart [1] or look at CSS garden [2]. There
> you will find that yes, designers understand menus as list, and that
> probably a lot of designers understand HTML/CSS better than you think.
Those are expert designers. They do not represent the masses.
The definition of a web designer is very vague.
Blind-folded web designers (or extreme novices):
There are those amateur web designers who do layouts in Ulead PhotoImpact,
or in best case with Photoshop. They use the provided tools to slice the
layout, to export it to HTML. After that, there's lots of guess work, when
they create the other pages, using products similar to Dreamweaver. They
change values in attributes, in CSS properties, they add/remove tags, just
to see what happens, hoping the page will eventually show as they want in
IE.
"Real" web designers who work for local companies, regional, or even
national companies
These create their layouts, on schedules, for the company they work, most
likely in Pohotoshop (since it might be a requirement). Then they redo the
layout in Dreamweaver (or similar). Similarly to the amateurs, they do
lots of guess work when something doesn't work as they want - that's
because they *still* do not know *anything*. They do combine CSS with
table layouts.
Another type of web designers is those who know to code, who use
Dreamweaver (or similar products) just for convenience - they almost know
to manually code the layout. They still do some guess work, but they are
on the right path.
And, finally, there are two types of experts: experts who like to write
everything their own way, who try to write semantic code, CSS layout, etc.
The other type of "experts" are those in big companies, which have a
serious name, "experts" that still do table-CSS layouts and love using The
Tools of The Future, the best productivity tools: Dreamweaver, Frontpage,
what-not.
b) the programmers
Programmers who know to code want to write their own stuff, making sure
everything in their output is generated by *them* not by some library
"magic". They like to know everything that happens.
And there's the majority of programmers: give them a library which can
make them cofee, then they'll be happy. They want to finish their projects
as fast as possible, with as little coding as possible, they don't care
what the libraries do. "What do you complain? Does it work or not?"
c) the libraries
By design, libraries offer more functionality than is needed within the
given project, project page, etc.
Add to that: some libraries dont even generate proper code, some of them
are poorly coded.
d) the frameworks
Similar to libraries, Ruby on Rails, ASP.NET and others, provide lots of
"magic": "just look how easy it is to create a blog!". All of this is done
without developers being aware *what* code is generated - they don't even
look at the HTML source, they only do this when it's absolutely necessary
(something doesn't *look*/work as they want).
e) the Content Management Systems are built on top of all the above. Now
imagine how good they must be. The CMS is not the only one to be blamed
for generating bad markup, because we also have...
f) the Web browsers, which themselves generate bad markup in designMode.
Le Sun, 18 Mar 2007 05:29:30 +0200, Robert Accettura
<robert@accettura.com> a écrit:
> Take the following as an example (it's not really a proposal): If the
> markup
> were so that all tags were equal (think <span>,<a>,<img>,<input>, and a
> handful
> of others as the only tags not depricated), and an attribute
> ("datatype") were
> to describe the data in more casual terms of what it contains ("quote",
> "citation", "navigation", "paragraph", etc. it's much more intuitive.
I believe this is utopic. You cannot create a fool-proof language. No
matter what language, people *will* write bad code.
The fact C/C++ can't be compiled until you fix all compilation errors,
doesn't mean programmers inherently write proper code.
There are pages which use very ugly PHP code.
Le Sun, 18 Mar 2007 08:17:16 +0200, Robert Accettura
<robert@accettura.com> a écrit:
> It's not that they can't (technically a child 8 years of age, can learn
> it...
> it's not difficult) but they don't care to. And nothing you say/do will
> force
> them to change, other than require XML and completely break with the
> slightest
> defect.
Correct, they do not care. It just works.™ Why bother more?
However, it's false to assume they'll suddenly write proper code if you
require the XML rules (proper nesting, closing tags, etc). I've seen many
XHTML 1.0 Strict pages, valid, but ironically served as text/html. The
code was still a mess, even if it has proper tag nesting, tag closing, etc.
What we can do:
1. proper frameworks can be developed
Frameworks that generate better markup.
2. server-side scripting languages with better support (HTML5 parsing,
solid DOM support, etc)
I do not want, web developers in general do not want, to write their own
DOM implementation, their own HTML5 parser, XHTML/HTML serializer, etc. We
also don't want to write our own htmltidy-like tool.
The server-side scripting languages must push forward their tools for such
work.
3. better web browsers
Web browsers must have better tools for reporting CSS, JS, HTML errors,
DOM Inspectors, CSS Inspectors, JS debuggers, etc. This is already
happening and it's very good.
Web browsers also must generate better code in designMode. They need some
kind of htmltidy integrated within, so when developers try to read the
generated HTML code, we automatically get a clean code.
4. better content management systems
Once we have better web browsers, better frameworks and more tools, web
developers will be able to code proper content management systems.
This is not to say that *now* better content management systems can't be
made. Actually, fairly good content management systems can be done right
now, but ... most likely it takes too much work for average Joe web
developer.
What we can't do:
1. We can't teach every single web designer about proper HTML/CSS. I
believe a designer is a designer, he/she must evolve in his/her own areas
of interesting, (application GUIS, web interfaces, digital art, 3D
modelling, digital painting, whatever). He/she should not go over board
and do it all. (Jack of all trades, master of none.)
2. We can create languages within which developers are constrained enough
to write proper code - that is, if you want the language to be used by the
masses.
3. We can't teach users of various content management systems to not use
ugly colours, bold, font changes, what-not. They don't need to learn this.
Le Sun, 18 Mar 2007 08:17:16 +0200, Robert Accettura
<robert@accettura.com> a écrit:
> Don't forget even Google's homepage uses things like <font>, unnecessary
> <table>, <b>... and they have more resources and pro's available than the
> majority of sites on the web.
Precisely. That's probably a very good example of "I don't care".
How can we force/teach others to write proper code if not even Google does
it?
Now, the problems, I'd say, go even more further:
a) We also have teachers at universities who, by an (un)fortunate twist of
destiny, end up teaching students about HTML, PHP and what-not.
I have several real-life examples of students who asked me about HTML,
because they wanted to learn for their courses. I, of course, took the
semantic-view approach, but teachers *require* students to write poor code.
b) Some web developers right now are soo stubborn that they still use
tables for layouts. They are stubborn because they have arguments like
"thousands of dollars are being made in this industry by expert web
developers/designers who still write table-based layouts. You go write
your semantic code, I'll make some money". The point is, such people
consider we live in a world where money doesn't matter, and we like to
write semantic code just for the beauty of doing so. They consider us
naive.
Regarding the initial question about WYSIWYM editors, I don't believe HTML
is to be blamed because editors generate poor markup. Editors need to be
blamed, and their users. Actually, their users are the ones who carry the
most of the blame. Allow me to explain why, based on some real examples. I
wrote some PHP script which tries to clean lots of usual ugly markup. I
use htmltidy, but I didn't like htmltidy tries too much to keep the
original intact. So, my PHP script uses (*cough*) regex and PHP 5 DOM to
clean the following (often encountered problems):
1. Users don't even know how to use tables.
Given the following example:
<table>
<tr>
<td>
<p>blah 1</p>
blah 2<br />
blah 3</td>
<td>
<p>boom 1</p>
boom 2<br />
boom 3</td>
</tr>
</table>
My script generates:
<table>
<tr>
<td>blah 1</td>
<td>boom 1</td>
</tr>
<tr>
<td>blah 2</td>
<td>boom 2</td>
</tr>
<tr>
<td>blah 3</td>
<td>boom 3</td>
</tr>
</table>
Isn't the initial table *seriously* broken? Can you blame Word for that?
When I make a table in Word I don't do *that*. The user is to be blamed.
Must add that the I provide here as the initial table is actually quite
clean, what I had to clean where tons of <font>, <b>, <dd> tags within the
same table. Nonetheless, the output, is real output. (My script simply
ignores all fonts, colors, etc)
You need artificial intelligence within the editor to warn the user when
one does such a broken table.
2. Users like to insert lots of <br>s. Should editors disallow line breaks?
We have <br>s between paragraphs, tables, lists, at the start/end of
paragraphs <p><br>The time has come<br></p>, etc. We have <br>s everywhere.
3. Users don't even know what lists are.
It's quite often that I have to clean such markup:
<ul>
<li>lily</li>
...
</ul>
<br>
<ul>
<li>flower</li>
....
</ul>
Just to generate a single <ul>, with all the list items.
In such cases, the editor can do some clean up, but you can never be sure.
The editor could provide a warning "should the two lists be merged?"
3a. Another example of "users don't even know what lists are".
Users simply don't allow the editors to automatically create semantic
lists based on the content. As is known, Microsoft Word, OpenOffice Writer
automatically generate (un)ordered lists for input like:
a) you
b) me
c) and the Web
However, almost every Word document I have to put on the Web contains the
"a) you<br>b) me<br>c) and the Web". Was that a failure on the editor
side? No, it's the user who had no clue.
4. Another general problem of markup code generated from Word documents is
evidenced by the following code:
<p>Opera 9 comes loaded with </p> <p>the tools to keep you productive and
safe.</p>
As one can notice, the two paragraphs should be merged into one.
Again, you need AI and/or draconian restrictions in an editor to be able
to disallow such human errors.
5. Headings are a complete mess. *If* they are used, they are chosen based
on font size.
All of this only scratches the surface.
--
http://www.robodesign.ro
ROBO Design - We bring you the future
Received on Sunday, 18 March 2007 12:31:30 UTC