[whatwg] <font> (was Support Existing Content)

[Sander Tekelenburg]

At 12:48 +1000 UTC, on 2007-05-01, Adrian Sutton wrote:

[...]

> The only debate about what a WYSIWYG editor is on the web is between a very
> strict interpretation (it must look precisely like what you get) and the
> What You See Is What You Mean editors.

That's one, yes. But also plenty of people don't even distinguish between the
editor embedded within a publishing tool, and the publishing tool as a whole.
So as it is phrased now in WebApps 1.0, I wouldn't be surprised if it will be
taken to mean that any authoring tool is allowed to produce <font>.

Anyway, I understand that there can be exceptional conditions (not that I'm
convinced that this is one) that require that something that we don't really
want is allowed in HTML after all. But I'm worried about setting the
precedence that the source of a document can be decisive in whether or not it
is conforming. Next could be to allow authors to whom CSS is too hard to
abuse <blockquote> and <table>, or to consider a "colour" property conforming
if the author isn't american.

So what I'm saying is that, *if* <font> must be allowed, let's just plain
allow it -- not only allow some authors to use it.

I'm also worried  about how allowing <font> would affect end users. What
guarantee is there for end users that when they set their default and minimum
font sizes, be it through User CSS or a GUI, that that one single setting
will affect both <font> and CSS font rules?

> The term WYSIWYG really shouldn't be
> a concern for any reasonable person reading the spec.

FWIW, my impression is that it is and will be. That's why at
<http://webrepair.org/> we avoid the term and instead say "inline editor".
"Embedded editor" might work too.

Anyway, is the current phrasing intended to mean that an editor that 'is' not
WYSIYWG, but *is* an editor, is not allowed to produce <font>?

> I've been working in
> this area for around 6 years now and I've never met anyone even
> semi-technical that didn't immediately understand the term WYSIWYG and know
> what it meant in terms of HTML editors.

I'm surprised. My experience is that people take "WYSIWYG" in the original
DTP meaning. Slapping that terminology onto the context of the Web confirms
their misguided idea that that meaning of WYSIWYG applies to the Web. We
cannot force authors of such tools to avoid that term, but I believe it is
unwise to use the term in the spec.

> If you outlaw the <font> tag, you'll just get <span style="font-family:
> ..."> instead which has no more semantic benefit and is far more difficult
> to work with.

The current phrasing doesn't restrict this to span. It allows "WYSIWYG
editors" to produce <p><font size=7>blah</font</p> where <h1>blah</h1> is
appropriate.

As to span, can you explain exactly how span is much more difficult to work
with, and for whom?

> That said, in general I recommend configuring the editor so it
> doesn't have a font menu and use predefined CSS styles instead

Agreed.

>, but few people ever take that advice.

Which people are you referring to? Authoring tool authors? Or the users of
EditLive?


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>