W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2009

[Bug 8365] Remove the Web Browsers Section 6

From: <bugzilla@wiggum.w3.org>
Date: Tue, 24 Nov 2009 20:21:26 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1ND1t8-0006dk-2o@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8365





--- Comment #6 from Shelley Powers <shelleyp@burningbird.net>  2009-11-24 20:21:25 ---
(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.
> 
> Our experience is that most of the contents of section 6 are applicable to all
> HTML UAs that support scripting, not just web browsers. A lot of the other
> contents of section 6 are applicable to any HTML UA that supports navigation,
> even navigation by opening an external browser window, whether or not that UA
> also supports scripting. Our experience is that nearly every kind of HTML UA
> that we have needed to build supports at least one of scripting or navigation.
> Some parts of section 6 (in particular the definitions of link relations) are
> applicable even to UAs that do not support scripting *or* navigation.
> 
> I think the problems with section 6 are twofold: (1) It should not be called
> "Web Browsers" because its contents apply to many kinds of HTML clients; I
> could not find anything that is exclusively browser-specific. (2) Some of the
> contents (such as origins, Window, navigation, etc) are actually broader than
> just HTML; they should apply even when viewing SVG or MathML or pure XML
> documents. In theory these could be factored out but the details of how to do
> so are complex. Just tearing the whole section out would leave many broken
> cross-references. Also, some parts, such as link relations and the app cache
> are clearly HTML specific as they define semantics and processing rules for
> parts of HTML.
> 
> In conclusion, based on our experience at Apple, removing the "Web Browsers"
> section of the HTML5 specification would hurt rather than help its usability
> for non-browser UAs. In addition, it would have the negative ramifications of
> leaving many broken cross-references in the remainder of the spec, and of
> leaving some parts of the HTML language underspecified or undefined.
> 
> 
> * - Safari / MobileSafari, Dashboard, Mail / MobileMail, iChat, Help Viewer,
> Dashcode, Dictionary, iWeb.
> 

If there are some objects that apply beyond HTML, such as window and navigator,
then they they definitely don't belong in HTML, and should be separated out so
that they can be referenced via these others specifications. There once was an
effort to create a specification for the window object, but it was abandoned
when Window got absorbed into the HTML5 specification. The original idea of
factoring it out into a generic interactive user agent object was a good one. 

As for cleaning up cross-references, this is going to happen when other
sections are also split out, including Microdata and Canvas. It is a matter of
editing the specification, not a deal breaker because the underlying concepts
behind the HTML specification would be harmed by such a move.

And I definitely disagree about application caching being part of a
specification detailing a syntax. HTML is not an application. Even the DOM
isn't an application. 

You mention about Apple developing specific types of HTML UAs. However, the
ebook industry is a major UA for HTML, also, and it doesn't need application
cache, window object, and any of the other aspects necessary for scripting
supporting UAs. 

Perhaps the split out section could be refocused into one specific to
script-enabled UAs, rather than just browsers. 

Regardless, there is nothing inherent in HTML that requires access to such
things as application caches and window objects.


-- 
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 Tuesday, 24 November 2009 20:21:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:05 UTC