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

[Adrian Sutton]

On 2/5/07 1:28 AM, "Sander Tekelenburg" <st at isoc.nl> wrote:
> 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>.

I've honestly never come across anyone who did that. Interesting.

> 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 would tend to agree with that sentiment. Having now heard that only the
style attribute is currently allowed, the font tag is equivalent to span and
there's no point in having it at all.

>> 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.

Embedded and inline editors would include the textarea tag, which is clearly
not WYSIWYG for HTML (but is for plain text) so both are poor terms.

> 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.

I'd agree that people do take WYSIWYG in the original DTP meaning - that
said, I've found that people aren't all that confident that what they see in
Word will work cross-platform or look exactly the same when it prints
anyway. It's probably not worth discussing this further here though.

>> 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.

Any good editor is already using h1 when they mean h1 and making it easy for
users to apply it at the right time. I see no reason to believe that a
developer who didn't care enough to support headings correctly will care
about supporting HTML 5 down to the letter.

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

Quite a number of the cheap HTML to PDF conversion processes don't support
CSS. Additionally, syndicated HTML (via Atom, RSS etc) tends to have inline
CSS removed because of cross site scripting vulnerabilities (you can embed
JavaScript in CSS and at least IE will execute it).

> 
>> 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?

The system administrators that configure the editor in whatever system
they're using. Some people do restrict the editor to just applying
predefined CSS classes and as a result they get a very consistent, easy to
maintain site. Most however, prefer having the flexibility of a font menu so
they can apply the specific font they won't precisely when they want it.
Obviously I have more contact with users of EditLive! but I've seen this
pattern with a huge range of editors. People want the editor to look and
work like Microsoft Word and Word has a font menu.

Regards,

Adrian Sutton.
______________________
Adrian Sutton, Integrations Product Manager
Global Direct: +1 (650) 292 9659 x717  Australia: +61 (7) 3858 0118
UK +44 (20) 8123 0617 x717    Mobile +61 (4) 222-36329
Ephox <http://www.ephox.com/>,   Ephox Blogs <http://planet.ephox.com/>