- From: <bugzilla@jessica.w3.org>
- Date: Thu, 04 Nov 2010 09:58:34 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11206 --- Comment #3 from Tab Atkins Jr. <jackalmage@gmail.com> 2010-11-04 09:58:34 UTC --- (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. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Thursday, 4 November 2010 09:58:36 UTC