[Bug 8365] Remove the Web Browsers Section 6

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8365





--- Comment #10 from Maciej Stachowiak <mjs@apple.com>  2009-11-25 00:12:41 ---
(In reply to comment #8)
> (In reply to comment #3)
> > Comment with my Apple representative hat on: 
> > Apple is a developer and vendor of multiple HTML UAs, including a web browser,
> > a widget runtime, a mail client, a chat application, a help viewer, a widget
> > IDE, a dictionary application, and a consumer-level Web page creator(*). All of
> > these UAs are based on the same underlying engine, WebKit. In addition, we ship
> > WebKit as public API on Mac OS X and iPhone OS, leading to many more innovative
> > types of HTML UAs.
> 
> Comment with my developer hat on:
> I think this is backwards.  Apple is not a developer and vendor of multiple
> HTML UAs, Apple is a developer and vendor of many different software products
> that display formatted text.  And in all the cases you listed above, Apple has
> said, "You know, HTML would be good for that."  (As opposed to, say, RTF.)

In some cases, HTML is just used as a handy way to display formatted text (like
Dictionary). In other cases, HTML is used as an application format (as with
Dashboard). In other cases, use of HTML is intrinsically required for the
product to interoperate in its ecosystem (Safari, Mail, iChat). So your
characterization is incorrect. I hate to appeal to authority, but I actually
work at Apple and have interacted with the relevant product teams, so I can
assure you that in most cases, the choice of HTML went deeper than "I'd like to
display some formatted text".

> 
> But where does that leave installed applications that just want to show a
> little bit of formatted text?  If disentangling the formatting/parsing parts of
> the spec from the web-browser-specific parts would really break as many
> cross-references as you say, then why are you leaving it in the hands of
> implementers to make that division?  It seems like a really bad sign for the
> simple little formatting language we all know and love.

It hasn't been a problem in practice for building the apps I cited. Usually,
the most practical path to HTML display (whether you want a full-strength
browser, an app runtime, or just a wee bit of incidental formatted text) is to
use a general-purpose browser engine that lets the application turn various
capabilities on and off.


-- 
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 Wednesday, 25 November 2009 00:12:51 UTC