- From: Adrian Lynch <adrian@millstream.com.au>
- Date: Wed, 9 May 2007 15:07:50 +0800
On 09/05/2007, at 1:59 PM, Adrian Sutton wrote: > 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). But again - why set the standard at that level? Is the standard there to make existing incorrect systems validate? Or is the standard there to establish best practice for moving forward? It may very well be the case that existing systems do not validate to this new standard - either those systems validate to an older standard - or they simply do not validate against HTML5. Older systems that do not validate to HTML5 won't break. It won't make a scrap of difference to them. Once the vendors have been able to migrate all the systems to accommodate they can then proudly claim they are HTML5 compliant. What vendors are having problems with this? And should those vendors determine that this 'WYSIWYG' clause should set the benchmark where it is clearly contrary to the rest of the spec? 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. Regards, Adrian Lynch adrian at adrianlynch.id.au http://adrianlynch.id.au
Received on Wednesday, 9 May 2007 00:07:50 UTC