[whatwg] <font>

[Ian Hickson]

(I'm replying only to the more salient e-mails in this thread, as the 
others mostly just repeated stuff. I'm also only cc'ing whatwg, since that 
seems to be where most of the contributors on this thread were subscribed 
to -- please don't cross-post, as it results in threads that appears to be 
missing parts in both lists, when people only subscribed to one list reply 
to e-mails from people on both lists.)

On Thu, 3 May 2007, Sander Tekelenburg wrote:
> At 06:48 +1000 UTC, on 2007-05-03, Adrian Sutton wrote:
> > On 3/5/07 2:23 AM, "Sander Tekelenburg" <st at isoc.nl> wrote:
> > > [HTML -> PDF converters ignore CSS]
> > >
> > > OK. Real world issues. But that doesn't mean that the HTML spec is 
> > > the place to fix those. Looks more like an opportunity for better 
> > > PDF generators to grab market share and for IE to fix security bugs.
> >
> > Well sure you can ignore the real world if you like, I'm just letting 
> > you know what's currently happening. If the spec chooses to ignore 
> > that then it's gambling on the fact that implementors care more about 
> > being spec compliant than making things work for their clients.
> 
> I don't think we need look at it in such a dramatic way. While some 
> people may 'need' <font> because their HTML -> PDF converter ignores 
> CSS, I imagine they'd much rather have a HTML -> PDF converter that 
> *does* support CSS. That would give them much more control over their 
> final product after all.
> 
> Now if there is something about the HTML spec that stands in the way of 
> HTML->PDF converters to support CSS, that would logically be something 
> to try to fix in the HTML spec. But otherwise I don't see why HTML 
> should try to solve it, or even how it *could*. Authors can generate 
> <font> already anyway. Their document just won't be conforming. What 
> would those authors win by <font> being conforming? And then what about 
> the rest of their problems? Because if their problem is their tool 
> ignores CSS, they'll likely need much more presentational HTML than just 
> <font>.
> 
> And while we add all that presentational HTML to the spec, some 
> enterprising hacker builds a HTML->PDF converter that has CSS support -- 
> we'll have a spec allowing things we didn't really want to allow and for 
> which there's not even a use case anymore.

I tend to agree with this.


On Tue, 8 May 2007, Adrian Sutton wrote:
> On 8/5/07 8:13 PM, "Adrian Lynch" <adrian at millstream.com.au> wrote:
> >
> > I am sure there are just as many ingrained CMS's producing <font> tags 
> > in their output without using a WYSIWYG editor - they will need to be 
> > modified to meet specification, but WYSIWYG editors get a reprieve? 
> > Surely making a WYSIWYG editor remove font tags is no harder than any 
> > other system. Or am I seeing it from the wrong angle?
> 
> The issue isn't that it's hard to fix the WYSIWYG editor, the issue is 
> that it's hard to fix all the rest of the systems the client wants and 
> the fact that clients tend to want a font menu in their editor otherwise 
> they completely eliminate it from consideration without even talking to 
> the vendor. It's simple to make the font menu apply fonts using a span 
> tag and inline styles but that's no better than using a font tag and it 
> breaks some backend processing systems (PDF generation being the one 
> that I encounter most).
> 
> > Our CMS disallows any font menu/tags at all, has done for about 18 
> > months. Sure some clients question it initially, but after an 
> > explanation of the benefits no client has requested the feature be 
> > added back in.
> 
> I'm glad to hear it, sadly it doesn't reflect my experience despite my 
> trying.

We have to aim for the future, not the past. By the time HTML5 is done, 
hopefully non-CSS-capable backend systems will be a thing of the past.


On Wed, 9 May 2007, Adrian Lynch wrote:
> 
> I also disagree - using <SPAN> and in-line styles is a significant 
> improvement on using the <FONT> tag. <SPAN> is a well established 
> neutral container, whereas <FONT> is purely presentational. Again, I 
> don't see why this is even being questioned.

This I don't really agree with, but it's mostly moot. Having <font> with 
only style="" vs <span> with only style="" gains us nothing. Having the 
presentational attributes loses us valuable mindshare.


On Wed, 9 May 2007, Adrian Sutton wrote:
> 
> Let me first just reiterate:
> 1. The font tag allowance in the current spec is pointless, does not
> actually help any of the issues I've mentioned and needs to be removed.

It's gone now.


> 2. I strongly recommend that people don't include a font menu and 
> instead use CSS to apply styling to ensure a consistent look for their 
> site.
> 
> The only reason I said anything in this thread is so that the list was 
> aware of the realities of what a WYSIWYG HTML editor has to deal with.
> 
> Now as for particular use cases - there are many people who are using 
> HTML editors as a replacement for a word processor. They may be using an 
> internal wiki where anything goes, a content management system or a 
> range of other systems. These people basically don't care about content 
> vs presentation, they want it to work like Word does and as such they 
> want a font menu, color menus, the whole lot. For them it works and 
> since I'm not an on-site consultant, I don't necessarily have all the 
> details of why they want it to work this way. What I do know is that 
> there are people who want to use presentational markup in HTML. This use 
> case is completely supported by inline styles and span tags, there's no 
> need for an exception in the spec.
> 
> Hopefully that clears up the confusion over what I'm seeing our clients 
> do vs what I think the spec should include.

Sadly those systems end up tied to a particular medium, and fail to render 
in a good way for, say, users of text browsers or speech renderers. Not 
sure what to do about that though.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'