(In reply to comment #0)
> Specification: http://dev.w3.org/html5/spec/
> Section: http://www.whatwg.org/specs/web-apps/current-work/#top
> 
> Comment:
> Presentational tag [font,b,u,i] CANNOT be removed for many reasons.
> 
> Three scenarios very good scenarios:
> 1. HTML5 Mobile sites with BlackBerry8xxx and 9xxx support
> 2. HTML5 Emails
> 3. Legacy content
> 4. Injected legacy content via iframe/scripts
> 
> 1) Producing a mobile HTML5 website for iPhone, iPad, Android
> and old BlackBerry 8xxx series.
>
> The old BlackBerry needs presentational tags to work at all,
> it does not support CSS. In some BlackBerry,
> the phone comes out of the box with JavaScript disabled
> and it has been found in testing that when JavaScript is disabled,
> if any support for CSS is also present on that phone,
> the CSS engine is ALSO disabled! (Total non-sense but true)
[snip other stuff about how bad old Blackberry is]

I don't believe it should be the responsibility of HTML (or CSS for that matter) to attempt to cater to such blatantly broken devices.  Modern internet-capable devices may be underpowered relative to the desktop, but are at least sane in their treatment of HTML.  The Blackberry devices you describe are not. 

> 2. When sending HTML emails to be read on various email clients,
> some will render them without formatting, some will render them
> only with presentational tag and some will also render the CSS.
> 
> So, to have a consistent layout for all of those use cases, presentational tag
> 
> duplicating the CSS styling is required and no ignoring this large portion of
> end-user who do not have CSS capable email clients is NOT an option.

Modern mail readers understand CSS perfectly well.

Text-based email readers should also be able to view your email perfectly well.  Emails, like webpages, should be usable without CSS, just less pretty.  If your email requires CSS support to be readable, you are doing it wrong.

The class of mail readers that only understand a somewhat-random set of presentational HTML and CSS is luckily small and shrinking, and falls into the same "not sane" class as the old Blackberry devices above.

 
> 3. Legacy pages or web application that needs to be maintained
> or must "quickly" be improved to have a CSS3/iPhone/Android look.
> 
> In those case, presentational tag will be overridden by CSS 
> on those specific targets.

Legacy pages may not ever be maintained.  That's fine, they'll still render correctly; they'll just be non-conformant.

We should not allow haste to be a valid excuse for non-conformance.

 
> Finally, presentational tags are currently working in all browsers,
> I can fully understand the CSS arguments, the problem is that 
> they are often used to work-around either browser bugs 
> or are already used in legacy projects.

They do indeed work in current browsers, and will continue to forever, as there is significant legacy content using them that will never be updated.  That doesn't mean they are a good idea, or that we should encourage or allow their use in new content.

> [snip other stuff about how bad old Blackberry is]
> 
> I don't believe it should be the responsibility of HTML (or CSS for that
> matter) to attempt to cater to such blatantly broken devices.  Modern
> internet-capable devices may be underpowered relative to the desktop,
> but are at least sane in their treatment of HTML. 
> The Blackberry devices you describe are not. 

Correct, but they have to work.

You cannot tell your client that you wrote a nice mobile web site,
if it does not work on ALL recent BlackBerry models.

We are talking about BlackBerry Curve 8xxx, BlackBerry Bold 9000,
which are device you can buy right now in 2010.

If you do not believe me, you can download the emulator:
http://us.blackberry.com/developers/resources/simulators.jsp

For Bold, go to the options and disable JavaScript
and you will see all the CSS styling becomes disabled.

You could mark all those presentational elements "deprecated" 
in a transitional doctype that would be fine,
and have them removed and non-validating in a "strict mode".

Furthermore, if you define those tags to be non-mandatory,
that's fine with me also.

For most use cases, they are not needed, but when they are needed 
it is because we have no other choices.

It also ensures that nobody will redefine those tags to behave differently 
in the future.

> > 2. When sending HTML emails to be read on various email clients,
> > some will render them without formatting, some will render them
> > only with presentational tag and some will also render the CSS.
> > 
> > So, to have a consistent layout for all of those use cases,
> > presentational tag
> > duplicating the CSS styling is required and no ignoring
> > this large portion of
> > end-user who do not have CSS capable email clients is NOT an option.
> 
> Modern mail readers understand CSS perfectly well.
> 
> Text-based email readers should also be able to view your email 
> perfectly well.
> Emails, like webpages, should be usable without CSS, just less pretty. 

Less pretty is unacceptable by our client standards.

> If your email requires CSS support to be readable, you are doing it wrong.

You clearly have never written "pixel-perfect" Business Newsletters
for "important clients" that must look NICE and PROFESSIONAL at all cost.

> The class of mail readers that only understand a somewhat-random set of
> presentational HTML and CSS is luckily small and shrinking,

WRONG. 90% of our big clients are stuck in this scenario, 
as imposed by their IT dept.

> and falls into the same "not sane" class as the old Blackberry devices above.

If you choose to not support those use cases for your web application, newsletter, website, that is your choice, but that is not our choice.
We are successful because we have to support "everyone"
and it has to be pixel-perfect in every possible use cases.
 
> > 3. Legacy pages or web application that needs to be maintained
> > or must "quickly" be improved to have a CSS3/iPhone/Android look.
> > In those case, presentational tag will be overridden by CSS 
> > on those specific targets.
> 
> Legacy pages may not ever be maintained.  That's fine, they'll still render
> correctly; they'll just be non-conformant.

Except that we have to maintain them and improve them.

> We should not allow haste to be a valid excuse for non-conformance.

> > Finally, presentational tags are currently working in all browsers,
> > I can fully understand the CSS arguments, the problem is that 
> > they are often used to work-around either browser bugs 
> > or are already used in legacy projects.
> 
> They do indeed work in current browsers, 
> and will continue to forever, as there
> is significant legacy content using them that will never be updated.
> That doesn't mean they are a good idea, or that we should encourage
> or allow their use in new content.

I am NOT in any way suggesting that they are a good idea or that they should be encouraged, what I'm saying is that they may not be mandatory, they may be only available in a "transitional" doctype or similar. But the behavior of the content should not go into some weird quirks mode, because the author has to do a best effort to make it look right in all weird use cases.

(In reply to comment #2)
> > [snip other stuff about how bad old Blackberry is]
> > 
> > I don't believe it should be the responsibility of HTML (or CSS for that
> > matter) to attempt to cater to such blatantly broken devices.  Modern
> > internet-capable devices may be underpowered relative to the desktop,
> > but are at least sane in their treatment of HTML. 
> > The Blackberry devices you describe are not. 
> 
> Correct, but they have to work.
> 
> You cannot tell your client that you wrote a nice mobile web site,
> if it does not work on ALL recent BlackBerry models.
> 
> We are talking about BlackBerry Curve 8xxx, BlackBerry Bold 9000,
> which are device you can buy right now in 2010.
> 
> If you do not believe me, you can download the emulator:
> http://us.blackberry.com/developers/resources/simulators.jsp
> 
> For Bold, go to the options and disable JavaScript
> and you will see all the CSS styling becomes disabled.
> 
> You could mark all those presentational elements "deprecated" 
> in a transitional doctype that would be fine,
> and have them removed and non-validating in a "strict mode".
> 
> Furthermore, if you define those tags to be non-mandatory,
> that's fine with me also.
> 
> For most use cases, they are not needed, but when they are needed 
> it is because we have no other choices.
> 
> It also ensures that nobody will redefine those tags to behave differently 
> in the future.

You seem to be under the impression that these elements are being removed from the language.  They are not.  Some of them, such as <font>, are no longer allowed to be use; any document using them is non-conforming.  They are still part of the language and are defined by the spec.


> > > 2. When sending HTML emails to be read on various email clients,
> > > some will render them without formatting, some will render them
> > > only with presentational tag and some will also render the CSS.
> > > 
> > > So, to have a consistent layout for all of those use cases,
> > > presentational tag
> > > duplicating the CSS styling is required and no ignoring
> > > this large portion of
> > > end-user who do not have CSS capable email clients is NOT an option.
> > 
> > Modern mail readers understand CSS perfectly well.
> > 
> > Text-based email readers should also be able to view your email 
> > perfectly well.
> > Emails, like webpages, should be usable without CSS, just less pretty. 
> 
> Less pretty is unacceptable by our client standards.

I'm sorry.


> > If your email requires CSS support to be readable, you are doing it wrong.
> 
> You clearly have never written "pixel-perfect" Business Newsletters
> for "important clients" that must look NICE and PROFESSIONAL at all cost.

I certainly have.  It is a massive pain with very little reward.  After doing a single one I instead convinced my bosses that the time required for me to do so was not a good use of company resources.


> > The class of mail readers that only understand a somewhat-random set of
> > presentational HTML and CSS is luckily small and shrinking,
> 
> WRONG. 90% of our big clients are stuck in this scenario, 
> as imposed by their IT dept.

I'm sorry.

 
> > and falls into the same "not sane" class as the old Blackberry devices above.
> 
> If you choose to not support those use cases for your web application,
> newsletter, website, that is your choice, but that is not our choice.
> We are successful because we have to support "everyone"
> and it has to be pixel-perfect in every possible use cases.

I'm sorry.


> > > 3. Legacy pages or web application that needs to be maintained
> > > or must "quickly" be improved to have a CSS3/iPhone/Android look.
> > > In those case, presentational tag will be overridden by CSS 
> > > on those specific targets.
> > 
> > Legacy pages may not ever be maintained.  That's fine, they'll still render
> > correctly; they'll just be non-conformant.
> 
> Except that we have to maintain them and improve them.

Then you can maintain and improve them to use valid HTML.


> > We should not allow haste to be a valid excuse for non-conformance.
> 
> > > Finally, presentational tags are currently working in all browsers,
> > > I can fully understand the CSS arguments, the problem is that 
> > > they are often used to work-around either browser bugs 
> > > or are already used in legacy projects.
> > 
> > They do indeed work in current browsers, 
> > and will continue to forever, as there
> > is significant legacy content using them that will never be updated.
> > That doesn't mean they are a good idea, or that we should encourage
> > or allow their use in new content.
> 
> I am NOT in any way suggesting that they are a good idea or that they should be
> encouraged, what I'm saying is that they may not be mandatory, they may be only
> available in a "transitional" doctype or similar. But the behavior of the
> content should not go into some weird quirks mode, because the author has to do
> a best effort to make it look right in all weird use cases.

Luckily, this is already true.  There is no special quirks mode.  If you use presentional elements, the rendering of your page is perfectly described.  It just might be non-conforming.

Just to reiterate: the spec says that you cannot use <font>, as an author.  It also says what <font> must do and says that all browsers must render it as expected.  So your pages will work correctly in any HTML5 user agent, as well as in Blackberries, forever.  The validator will report them as non-conformant HTML5, but you can ignore that if you want.  (Unless your clients also demand conformant HTML5.  In that case you'll have to inform them that their requirements are contradictory.)

So basically the spec just says that conformant pages cannot use <font> or <u>, but they are still defined and will continue to work forever, they'll just make HTML5 validators complain but will otherwise cause no problems.  Is this okay with you, or is your point that you want the validator not to complain, or to only raise a warning, etc.?  If you want that, then this is a duplicate of bug 9355, which is WONTFIX.

> So basically the spec just says that conformant pages
> cannot use <font> or <u>, but they are still defined
> and will continue to work forever, they'll just make
> HTML5 validators complain but will otherwise cause no problems.
> Is this okay with you, or is your point that you want
> the validator not to complain, or to only raise a warning, etc.?
> If you want that, then this is a duplicate of bug 9355, which is WONTFIX.

What I was suggesting is to create a "transitional" mode
validator like we had for HTML4 and XHTML1.

Then people ignore the strict modes and still get to claim that their code validates.  Instead, HTML5 is trying to only have a strict mode, and people can either follow recommended coding practices or decide they don't care about the validator.  If this helps you convince your boss or client that you should follow better coding practice, or helps convince Blackberry to support CSS, great.

I don't fully agree with this approach, but it's been discussed a lot and is unlikely to change.  (I'd have preferred warnings for presentational elements.)

(In reply to comment #6)
> Then people ignore the strict modes and still get to claim that their code
> validates.  Instead, HTML5 is trying to only have a strict mode,
> and people can either follow recommended coding practices
> or decide they don't care about the validator.

Or they can follow recommended coding practices, brag about being fully conformant, and their work does not even cover weird use cases.

Remembers me a sales guy, who said they had 
this "super HTML5 mobile website framework"...
but they only support the iPhone.

When asked about Blackberry support?
"Yeah, it works fine!!! I'm telling you!"
Their mobile version looked like crap on BlackBerry as in "unusable".

> If this helps you convince your boss or client that you should
> follow better coding practice, or helps convince Blackberry
> to support CSS, great.

Well, you are dreaming in blue color for sure.

This statement sounds like: 
"If this helps you convince MS Office team
to support a native version working on Linux", great!

Even, if tomorrow I convince BlackBerry to fully support HTML5/CSS3,
all the existing phones still won't work properly.
 
> I don't fully agree with this approach,
> but it's been discussed a lot and is unlikely to change. 
> (I'd have preferred warnings for presentational elements.)

If people prefer transitional, then this means only one thing,
it's more practical for them, purist can go in strict mode if they want to.

http://stackoverflow.com/questions/432933/will-html-5-validation-be-worth-the-candle

I guess we will have to create our own HTML5 transitional validator,
for the practical people.

The goal of validation is to know,
if the website will work reliably across all browsers.

The point of conformance becomes purely useless,
when having different validators complaining about different parts, 
either using recent HTML5/XHTML1 feature, or older HTML4 feature,
while it works (as in display pixel-perfect) in all browsers
and mobile phones (and a very good best effort in CSS disabled mode).
It becomes useless "noise", when the goal is actually to find "real issues" quickly.

If you have a perfectly validating HTML5/CSS3, 
but it does not work on IE6, IE7 and BlackBerry 
then your web site is useless for Business people.

Here's another valid example for tag <u> used to indicate the form access key:

<!doctype html>
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Form AccessKey example</title>
<style type="text/css">
body{font-family:Arial,Verdana,sans-serif;font-size:10pt;}
label,#submit{font-weight:bold;}
div,label,input{display:block;float:left;width:120px;}
div,fieldset,#submit{clear:both;padding:10px;width:250px;}
input{border-width:1px 2px 2px 1px;}
#submit{width:245px;border-width:1px;}
</style>
</head><body>
<form id="f" name="f"><fieldset>
<div><label for="firstname" accesskey="f"><u>F</u>irst name: </label>
<input type="text" id="firstname" name="firstname" value="" tabindex="1" /></div>
<div><label for="lastname" accesskey="l"><u>L</u>ast name: </label>
<input type="text" id="lastname" name="lastname" tabindex="2" /></div>
<div><label for="email" accesskey="e"><u>E</u>mail: </label>
<input type="text" id="email" name="email" tabindex="3" /></div>
<div><input type="submit" id="submit" name="submit" value="Submit" /></div>
</fieldset>
</form>
</body>
</html>

(In reply to comment #7)
> If you have a perfectly validating HTML5/CSS3, 
> but it does not work on IE6, IE7 and BlackBerry 
> then your web site is useless for Business people.

What 10-years-old browsers to should not affect what the specification allows. If you find your clients need HTML from the nineties, use HTML from the nineties: HTML4 or HTML3.2, rather than HTML5. Nobody is forcing you to use HTML5.

mass-move component to LC1